Archived

This topic is now archived and is closed to further replies.

Some help to start designing my wrapper...

This topic is 6031 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

First of all hi everybody ! I''m designing a wrapper for DirectX 8 and I have some doubts to solve before starting... 1) Should I use multithreads for input and for other things like sound (like was said in TOTWGPG)? 2) I am going to have a kind of structure for Surfaces, should I create a class for it and put the functions that deal with the surface inside it or should I create only a struct and independent functions that use it ? 3) Which is best, to have only one .h file for all the wrapper like Wrapper.h and include it inside all the files or to have an .h file for each .cpp file like Graphic.h for Graphic.cpp ? 4) When I''m changing from Fullscreen mode to Windowed mode, if the color depths are differents (fullscreen: 16 bpp, desktop: 8 bpp as an example), what should I do ? Should I cancel the operation and show a warning that''s impossible to change because of the Windows Desktop screen resolution ? Should I transform all my surfaces to 8 bpp ? What ??? 5) When I change the mode (fullscreen and windowed) do I loose the surfaces informations ? 6) What means when I need to Restore a Surface ? Do I need to restore the data too, like loading the graphics file again or it''s just the pointer to the memory that got lost ? 7) Does it happen often ? 8) Am I being boring ? 9) Am I going to have problems if I name my programming group (not company, just for identification) of Redrum Games ? (do you remember The Shining (the movie), the word that appears in the wall ? I know this is a little out of subject but I think you could give me a clue) 10) Which is better, to use a lot of IFs or just one which statement ? And that''s all for now... sorry if this post is in the wrong place but it has some different information subjects and I didn''t know where exactly to put it... Thank you for any answer See you ! Nepheus

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Hmmm

seperate you classes in CGraphics, CInput, CSound etc.

Surfaces you don''t really need a structure for.

Have a .h for every file (reusability :D)

You could do either... having it transform to 8bpp would make it more polished... of course this would require some tricky palette manipulation to make it look good.

I''m not too sure. I just make it that you can specify windowed mode at startup or fullscreen at startup.

Generally you lose the front and back buffers (anything that''s in vmem) however the directx documentation is a bit scarce on info about this... so you could lose surfaces that are in system memory.

Only when the application loses focus.

uh... yeah

possibly... not too sure.

uh I think you mean the select command. I would personally prefer a select.

Share this post


Link to post
Share on other sites
That''s a lot of questions Here''s my attempt at answering them:

quote:

1) Should I use multithreads for input and for other things like sound (like was said in TOTWGPG)?



I would discourage this, as it adds a lot of complexity (what with locking structures and whatnot) and adds almost no benefits. In all likelyhood, your game would run slowers, since all the threads have to spend so much time synchronising. About the only thing I would consider putting in a separate thread is the networking code, but even that might be just as good in the main thread.

quote:

2) I am going to have a kind of structure for Surfaces, should I create a class for it and put the functions that deal with the surface inside it or should I create only a struct and independent functions that use it ?



If you''re using C++ then by all means make a class. Many people don''t realise but a struct is basically just a class where the default access mode is public, so you can add constructors and methods and all that to structs as well.

If you''re using C, then you don''t have a choice

quote:

3) Which is best, to have only one .h file for all the wrapper like Wrapper.h and include it inside all the files or to have an .h file for each .cpp file like Graphic.h for Graphic.cpp ?



Personally, I have one class per .h file. That way, I only include those classes I use in each .cpp file. This is really a matter of taste though. Since you can use a precompiled header if you put them all in one to get a speed boost (that is, you decrease the compile time. It doesn''t affect how fast your game runs)

quote:

4) When I''m changing from Fullscreen mode to Windowed mode, if the color depths are differents (fullscreen: 16 bpp, desktop: 8 bpp as an example), what should I do ? Should I cancel the operation and show a warning that''s impossible to change because of the Windows Desktop screen resolution ? Should I transform all my surfaces to 8 bpp ? What ???



Since you lose all your surfaces anyway, it doesn''t really matter if the bit depths are different, since you need to restore them all anyway. The only problem is if the desktop is 8 BPP, most hardware doesn''t accelerate paletted screens, so it won''t work anyway.

quote:

5) When I change the mode (fullscreen and windowed) do I loose the surfaces informations ?



I haven''t used DirectX since DirectX 7, so I don''t know if this changed in version 8, but you need to reload all your surfaces whenever you application looses focus, or you want to change resolutions, or you destroy the window DirectX is attached to.

quote:

6) What means when I need to Restore a Surface ? Do I need to restore the data too, like loading the graphics file again or it''s just the pointer to the memory that got lost ?



As I said above, I belive you need to restore a surface whenever your application looses focus, or you destroy any of the main interfaces (i.e. IDirect3D when you want to change resolution)

quote:

8) Am I being boring ?



I refuse to answer this question on the grounds that my mother always taught me if I have nothing nice to say, not to say anything at all (j/k)

quote:

9) Am I going to have problems if I name my programming group (not company, just for identification) of Redrum Games ? (do you remember The Shining (the movie), the word that appears in the wall ? I know this is a little out of subject but I think you could give me a clue)



I don''t see why. People do this all the time. Unless Redrum is in some way copyrighted (perhaps it''s been taken).

quote:

10) Which is better, to use a lot of IFs or just one which statement ?



I guess you mean switch, not which. This is another matter of taste. It''s not really true that switch statements are faster, but they are more limiting. You can''t do inequalities with switches (i.e. you can say if( a < 10 ) with a switch). They are a bit more compact though. Just be wary of that break statement. If you leave it off, you can get some strange bugs

Hope this helped you!


War Worlds - A 3D Real-Time Strategy game in development.

Share this post


Link to post
Share on other sites
4) If you want you can change the bitdepth of the desktop to match the previous fullscreen mode and then restore the desktop bitdepth when your app closes (use the ChangeDisplaySettings() function).

5) possibly

6) You have to restore the data in the surface, because the memory that held it might have been deallocated/overwritten.

7) IIRC according to the docs it can happen at anytime. The reason surfaces are lost is that some other program needs the memory occupied by them. I should think though that apps with focus are prioritized. Also, I don''t think sysmem surfaces should be lost very often, though I suggest checking them when you check all other surfaces, since usually you won''t know which surfaces are in sysmem and which are in videomem. This should be a decision the driver makes.

10) usually a ''switch'' statement is more readable/cleaner than alot of ''if'' statements (there are exceptions of course).

Share this post


Link to post
Share on other sites
Hey, thank you all guys

I made so many questions about the mode changing because my problem is that i'm writing my own bitmap loading function so if the user changes the mode to Windowed and it's in a different color depth, i'll probably have to convert the bitmaps and reload them.

And the class thing is:
I'll have a structure but:

1) I can have a structure (or class) and functions to deal with it like:
int DoSomething(SURF *Surface);

2) I can have a class with THAT function in it, like:
class SURF {
int DoSomething();
}

My biggest doubt is: if I use the class way, will I waste some memory and loose velocity ? Just this...

But thanx !
See you guys

Nepheus

Edited by - Nepheus on June 8, 2001 12:06:20 AM

Share this post


Link to post
Share on other sites
If you write the class member function (or ''method'' as they''re often called) as you did above there will be no difference.

(ok, a slight difference at the assembly level, because the ''this''-pointer in a class (passed implicitly to every non-static member function) is passed in register CX, while the struct pointer/reference would be passed on the stack (most likely)).

But you can consider them equal in speed and memory requirements.

However, if you make the member function ''virtual'' there will be extra overhead in calling it.

i.e.
  
class SomeClass
{
virtual void DoSomething();
}


You should not need to make it virtual though.

Share this post


Link to post
Share on other sites
quote:

3) Which is best, to have only one .h file for all the wrapper like Wrapper.h and include it inside all the files or to have an .h file for each .cpp file like Graphic.h for Graphic.cpp ?


Or, if you wanna be super cool, you can create a DLL for the entire library and just have to use one header file, wrapper.h, and link one file, wrapper.lib, for every program that uses the program! Just my advanced suggestion!

Share this post


Link to post
Share on other sites