• entries
707
1173
• views
435840

# R.I.P. dftGUI V.1

135 views

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 entireengine, but I did it using smart pointers.    I also started writing a bitmap font system, but it doesn't support alignmentand such at the moment. It also doesn't support measuring, so I would have had tochop out labels and cutting off the listbox items.    Another thing I changed was the fact that I was passing around my graphicssmart pointer instead of storing an instance of it in pool. This way I could usepool 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 functionGetSingleton(), 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 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.

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

Quote:
 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].

I'm not going to be responsible for giving you something else to work on.

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

rofl

## Create an account

Register a new account