Jump to content
  • Advertisement
  • entries
  • comments
  • views

R.I.P. dftGUI V.1

Sign in to follow this  


I attempted to bring dftGUI up-to-date and I failed miserably. The problem was the major differences between my old engine and my new one:

Naming conventions
    Pretty much the only thing here is that I stopped using hungarian notation.

Coding structure/design
    This changed pretty drastically. Not only did I rewrite the entire
engine, but I did it using smart pointers.

I also started writing a bitmap font system, but it doesn't support alignment
and such at the moment. It also doesn't support measuring, so I would have had to
chop out labels and cutting off the listbox items.

Another thing I changed was the fact that I was passing around my graphics
smart pointer instead of storing an instance of it in pool. This way I could use
pool for non-graphical resources if needed (it also makes a lot more sense, since
I might need it for audio and such.)

Another good example is that instead of naming my singleton function
GetSingleton(), I switch to Access().

So, long story short, once I finish a game project I'm going to be rewriting my GUI system (which I had planned on doing anyway.)

Engine Issues
I've been redoing my engine and I figured I'd list out some major issues that I ran into. For now, I'm just going to do the Graphics system since that's where the most of my issues were.

  • Texture tracking
  • I've made several comments that I didn't want to do something because it would screw up my texture tracking system. I was tracking textures by storing an array of 8 textures and then when SetTexture() was called (wrapped in my Graphics class) I would check to see if it was already set. Some of you may instantly see why this is a bad idea, but for some reason I didn't (even after I started running into the problem -_-;) For those of you that don't see it, there are several problems with this:
    • D3DX stuff might set a texture via the device and then you wouldn't reset the texture.

    • It's incompatible with stateblocks

    • It's incompatible with shaders

    • It's incompatible with external source

    So, all in all it's a very bad idea.

  • Resetting the device
  • This is one of the biggest problems. Not a single class that I did was setup to handle a device reset, which prevents anything like changing graphics-settings in-game and such.

  • Hardware enumeration
  • Although my engine supported hardware enumeration, it didn't allow any sort of interaction with it. So, the graphics class new what was available and that was about it.

I'm off to see if I can finish this project so that I can start anew.
Sign in to follow this  


Recommended Comments

Want my GUI library? Someone porting the rendering to DX would go a long way towards helping me figure out how to genericize it.

Share this comment

Link to comment
Original post by Deyja
Want my GUI library? Someone porting the rendering to DX would go a long way towards helping me figure out how to genericize it.

I'll still be making my own (I love GUI coding for some reason) but I'd certainly have no problem porting yours to DirectX for ya. Email me the files or PM/email me a link and I'll get right on it[smile].

Share this comment

Link to comment
Original post by Deyja
I'm not going to be responsible for giving you something else to work on.


Share this comment

Link to comment

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!