Jump to content
  • entries
  • comments
  • views

GUI stuff continues

Sign in to follow this  


Still completely distracted by writing a Direct3D GUI, but have gone a bit back to basics.

I've decided firstly to write it as an external lib rather than bodge it together in the current project. This means, as always, by the time I've finished I will have lost interest in the original project, but that's the joy of programming for fun rather than money.

After a few false starts, I've come to the conclusion that the GUI library needs to be very much non-dependant on whatever Direct3D wrapper I happen to be randomly using on a given project.

With this in mind, the version I started tonight expects the client application to initialise and manage the Direct3D device. The main GDX::Render() function takes a pointer to an IDirect3DDevice9 and takes no ownership of it.

Internally, GDX then wraps the pointer in a GDX::Canvas class that is then passed as the parameter to each window's OnRender() method. The GDX::Canvas() takes care of clipping to the window and translating rendering so that OnRender() works in client space.

One thing I've found works a lot better as well was gleaned from looking at Crazy Eddie's GUI wiki. The global GDX::MouseMove() injection function takes screen co-ordinates directly from WM_MOUSEMOVE, but converts these into relative-to-the-last-mouse-position co-ordinates before passing ont GDX::Window::OnMouseMove() for each window.

This has made click-dragging windows a breeze, unlike the last version, and it is pretty easy to get an actual mouse position in the OnMouseMove() method if I need it.

Not sure how much sense that made.

I am providing a GDX::WndProc() since it stays pretty flexible - you can either assign it to the WndProc when registering the window class to just use the built in message processing, or create your own WndProc and intercept the messages you want then call GDX::WndProc instead of DefWindowProc, much like normal window subclassing.

Obviously this GUI library is not going to be thread-friendly but I don't care about that. The main objectives are that it should work well as the basis for an entire GUI-based application in Direct3D, but equally work on top of a traditional Direct3D game to just look after GUI elements.

Crazy Eddie's GUI looks like an impressive library, but hanging around here this long has made me really uncomfortable with all this getSingleton() stuff.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!