First off, thabks for your time regarding this issue. I think my problem is that I was thinking there is a procedural way for doing this (well, there sort of is to an extent) and I was just looking for an answer I wasn't going to find. The response you gave, once again, wasn't exactly what I was looking for, but it opened up/cleared my mind from thinking too hard about this issue:
Otherwise, in-view controls aren't windows controls -- they are constructs of your own creation/imagination.
So, keeping that in mind I decided to make a button control with minimal functionality as a test, using this concept:
Buttons can be approached a number of ways. The easiest is to have a texture for the button that has the disabled, active, activehover, and pressed-in states, and use code that renders using the right 'piece' based upon the internal 'state' you are tracking for the button. State is managed in context with mouse (or keyboard) input.
I made a simple enumeration for state, with values of Normal and Pressed. Now if the state was normal it used its predefined normal state color that I had given it, and then if it was pressed it had another color. I used the form events to determine where the mouse was, like if it was over the control, and seeing as how these controls were being rendered in 2D this was a simple task.
So, anyways in short, this base button control test worked, mind you it was ugly at first. Once I had an idea to make the one button control for testing purposes (like how to do it, see if it works, etc.), I drew up some quick logic plans for all the different functionalites and controls that I would need, and created a class from that which looks amazing and has some nice features, such as transparency.
Ya, so anyways thanks again, lol still not 100% sure where I was stuck, but I guess it was just one of those cases where you think too hard (rather than what little individual steps I would need to take to create the controls), and then someone comes along and says something and you wonder why you even had trouble in the first place.
Oh ya, side note for anyone else reading this post, I used some ideas from the tutorials here:
http://www.c-unit.com/tuto
This site had some great tutorials as well, I think it's posted in some other posts already as well, but ya, great tutorials. They as well have a 4 part gui creation tutorial, which was somewhat sketchy and inefficient from my point of view, but for the most part it is a really good basis to learn from.
Main Topics
Browse All Topics
by: davebytesPosted on 2005-11-29 at 09:25:46ID: 15381722
color me confused.
what do you see as the difference between a 'windows application' and a 'dx9 application'? They are one in the same, UNLESS you are building a full-screen-only application. Your DX9 viewport can be part of a window, with controls around it -- or use toolbars, palettes, etc.
If you want in-viewport 'buttons', and really don't get the concept, you might want to find a library that already implements the functionality you are looking for. ;)
Otherwise, in-view controls aren't windows controls -- they are constructs of your own creation/imagination. In my very-old engine, we built up a GUI library that implemented push buttons, radios, checkboxes, scroll lists, etc., all using polygonal components (and/or bitmaps via polys).
Text is potentially the 'hardest', especially as there are simply no limit to solutions. The DX Font object (I think that's what it's called) can do a lot of the work for you -- it internally builds up necessary textures to render text out to a DX viewport, using sprites (well, under the hood I'd think so -- it was originally built on top of the DX Sprite class). You can also build your own 'font texture' and render individual characters out in order to create a string on screen.
Buttons can be approached a number of ways. The easiest is to have a texture for the button that has the disabled, active, activehover, and pressed-in states, and use code that renders using the right 'piece' based upon the internal 'state' you are tracking for the button. State is managed in context with mouse (or keyboard) input.
As you can tell already, 'rolling your own' takes time. I believe gamedev.net had a couple of articles on DX9 (or earlier) font rendering, and I'm sure they've got other articles around the general topic of building GUI controls (under D3D or OpenGL...)
-d