OS separation and OOP forward thinking
Author
I''ve been thinking in the process of the design of my (dare I say the words) game engine and the first major bridge that I''m havig to cross is the decision to either split off windows specific code (WinMain and WGL stuff) to all of the main ''game'' code.
Obviously I get the benefits from both sides of the argument since I''d not be having this debate with myself otherwise.
I just wondered if I''m taking on more than I need to for the sake of being overly religious to OOP.
Frankly I can''t ever see the engine (since it''s my first) ever getting to the stage where a final product could be released, certainly not to the point where I''ll be thinking cross-platform.
Your thoughts?
quote:Original post by Juicy
I just wondered if I''m taking on more than I need to for the sake of being overly religious to OOP.
Frankly I can''t ever see the engine (since it''s my first) ever getting to the stage where a final product could be released, certainly not to the point where I''ll be thinking cross-platform.
My thought would be, any time you can try to make something more OOP or cross-platform, it''s a good exercise. I can''t count the number of times I''ve seen code that had no REAL use for platform specific code in places that it had it. Go for it...but then again I''m a dork like that.
- sighuh?
Author
Of course you do realise the impending number of questions I''ll barrage the forum with regarding splitting win32 and oGL.
I''ve read Code on the cob. It''s got some interesting things such as setting up function pointers to winmain() and the window class function. But It''s not very logical when you see bits of windows specific code appearing in his game system only modules.
Is there a good, practical way to split up the code?
I''ve read Code on the cob. It''s got some interesting things such as setting up function pointers to winmain() and the window class function. But It''s not very logical when you see bits of windows specific code appearing in his game system only modules.
Is there a good, practical way to split up the code?
Yes, you should keep all of your os dependent code away from your engine as much as possible. Sure you may never go anywheres with you this engine, but it will be second nature when it comes time to write somethign that is production quality. I''m still semi-newbie myself (on my second game). In the first one I had everything set up in classes, but they wern''t very well thought out. Now it''s round 2, and my engine is one module, which is os independant, and the front end does all of the os dependant code. I''ve actually got my engine in a dll and the front end just makes calls to the dll. Right now it''s just a console based app, but once I know my engine works well, I will just hook the engine up to an openGL front end.
I too have had these issues with my code. I want OOP and Cross-Platform. Its is defiantly more work to create a cross-platform engine. Not only is this true in design but in the increased lines of code for the other platform''s code. For me, even if my code is never used on another platform I would still like to make simple port it. To make things worse, if you write your program in MSVC and want to port it to linux you also need to make your program cross-compiler and split out your compiler specific code. This can usually be done with separate header files and is less daunting than the doing the cross-platform stuff
Good luck.
Journal
Good luck.
Journal
I wouldnt use any win$h!t stuff at all. Infact I would never. You code to OGL anything win uses will limit you to OGL1.1. Try SDL this way even for the sound you wont have to call win$h!t. With the hole OOP thing I code to OOP but I do break a few rules, so thats what I suggest you do.
Author
SDL is all fine and funky, but in all honesty I''d much rather have complete control over what goes on.
When playing with SDL their blitting was slow and the API felt overprotective.
When playing with SDL their blitting was slow and the API felt overprotective.
When I was first writing my wrapper, I also was going for complete seperation of OS dependant and independant code, but eventually just restarted integrating win32 and the engine. The reasons were efficency and clarity. I had a generic "window" class which would reference the screen area, etc... But then came problems. If you have a generic window class, then you already have one level of indirection every time you call your implemented window class to handle messages.
I also originally wanted to support openGL or DirectX seamlessly, so again I had yet another generic class-- a graphics class, of which I had a DirectXGraphics and an OpenGlGraphics class implementing, and yet again we have another level of indirection each time you want to begin a scene, add a triangle strip, etc..
I felt everything was going pretty well, that was until I started adding support for music/input/etc to my program. Music/sound is almost definately going to be DirectX referenced. Input is also more than likely going to be DirectInput. Now you''re faced with implementing yet another generic input system and extending it for DirectInput, etc.
It just started getting rediculous. I was running at about 65 FPS with a handful of poly''s on the screen using this setup.
I decided to completely rewrite the engine, and now it is almost completely OS dependant, but the only major derefencing involved being the logical GraphicObject, with TriList, etc implementing it.
I now am running at 73-74 FPS (Monitor refresh 75) for the same scene with the newly written engine. Not to mention the speed and ease of implementation of new aspects of the engine. The difference with VSync disabled was obviously much larger as well, though I don''t have the specific numbers.
Of course its all your decision, but I would suggest going OS dependant first and getting through an entire basic engine then go for OS independant if you''re so inclined. Its much easier and quicker going OS dependant. I just decided to ignore other OS''s in the end. The users of my program will be Windows users.
I also originally wanted to support openGL or DirectX seamlessly, so again I had yet another generic class-- a graphics class, of which I had a DirectXGraphics and an OpenGlGraphics class implementing, and yet again we have another level of indirection each time you want to begin a scene, add a triangle strip, etc..
I felt everything was going pretty well, that was until I started adding support for music/input/etc to my program. Music/sound is almost definately going to be DirectX referenced. Input is also more than likely going to be DirectInput. Now you''re faced with implementing yet another generic input system and extending it for DirectInput, etc.
It just started getting rediculous. I was running at about 65 FPS with a handful of poly''s on the screen using this setup.
I decided to completely rewrite the engine, and now it is almost completely OS dependant, but the only major derefencing involved being the logical GraphicObject, with TriList, etc implementing it.
I now am running at 73-74 FPS (Monitor refresh 75) for the same scene with the newly written engine. Not to mention the speed and ease of implementation of new aspects of the engine. The difference with VSync disabled was obviously much larger as well, though I don''t have the specific numbers.
Of course its all your decision, but I would suggest going OS dependant first and getting through an entire basic engine then go for OS independant if you''re so inclined. Its much easier and quicker going OS dependant. I just decided to ignore other OS''s in the end. The users of my program will be Windows users.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
