Cross-Platform Architecture

Started by
23 comments, last by JorenJoestar 16 years ago
Hey, I'm going to write a new graphics engine, after having experimented for some years with some little game projects... I'd like to build a multi-platform and multi-api ( only in compiling ) architecture but writing only the PC/DX10 part.. ( Abstraction could be useful in future ). I've never written a multi-platform engine, and i would like to present my idea to know if i'm working well or if there're better methods to do abstraction. In my little test project i've done it this way: This is the Core class, it should be the main class of the engine, the one which has pointers to the other classes ( Renderer, etc ) and which inits the Window and the Render abstract classes with their os-specific implementation: class Core { public: Core( const char* title, short width, short height, bool windowed ); ~Core(); }; Core::Core( const char* title, short width, short height, bool windowed ) { #if EPLATFORM = EWIN32 mWindow = new WindowWin32( title, width, height, windowed ); #endif } This is the Window class: class Window { protected: Window( const char* title, short width, short height, bool windowed ); ~Window(); }; This is a Win32 Window implementation: class WindowWin32 : public Window { protected: Window( const char* title, short width, short height, bool windowed ); ~Window(); }; WindowWin32::WindowWin32( const char* title, short width, short height, bool windowed ) : Window( title, width, height, windowed ) { /** Inits the Window. **/ } Main.cpp: INT WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, INT nCmdShow ) { Core* Application = new Core( "Test Application", 640, 480, true ); //** etc etc... **/ } I don't like the fact that Core accepts some parameters for the construction of the window and it passes them to the Window class, I think it's not a clean way and there're better ones :) Please, could you help me to improve or my architecture or to write a better one ? Thanks, Bye! :)
Advertisement
Hey, I've though some consolles don't have ( of course ) a window...
Could be a good idea to unify renderer and window ? ( so renderer could init the window, too )
1) This is a big undertaking.

2) Use the Pimpl idiom, it will make your days sunny where they would otherwise be not. You'll need a well setup file-structure (file-system) to make things easy, although this step isn't too hard.

3) Seriously, this is a big undertaking. Different platforms do things differently, and your "abstract architecture" may work with WIN32 lovely, but as soon as you write the Wii implementation (or heaven forbid the DS one), you'll run into problems as soon as you try and implement the "window" class, and realise such a thing is a foreign concept to said platforms. Furthermore, different platforms require different compilers, and not all are as forgiving (or conforming) as MSVC. Whilst fixing things in your code that MSVC leniently accepts isn't much trouble (and indeed is a good thing), restructuring your code to work on CodeWarrior can be a pain. User input is also drastically different (think Wii/DS, or even a controller vs. mouse and keyboard). Keep these things in mind.

4) You're going to have to re-implement a few things from the standard library. Such a sacrosanct thing such as std::string will require rewriting for the DS to use string-tables internally to cut down on memory, as it's very limited. This is one of the few instances where reinventing the wheel is necessary. Overloading the global new and delete may also be necessary (although probably not).

5) Be really careful about how large the stack is for your platforms. This is a worser problem than dynamic memory allocation.


6) Oh, you wanted to talk about writing an abstract graphics API too? [grin]
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]
Hey, thanks for your answer!
So, what do you suggest ? How could i write the abstract architeecture ? :S
If this problem were so easy, it would have been solved ages ago. I'm not entirely certain you realize the infeasibility of the project you are trying to tackle.
Making a cross-platform graphic engine from scratch is extremely tough to only one developer. I suggest you join an existing project such as CrystalSpace and Irrlicht or just study their architecture via reading their source code.
Thanks for the answers.
So do you suggest writing a PC-only engine ?
My original idea was to write only the PC part, but abstracting and giving the possibility of writing other implementations in the future ? Is too complex for two coders ?
Quote:Original post by jwein
Thanks for the answers.
So do you suggest writing a PC-only engine ?
My original idea was to write only the PC part, but abstracting and giving the possibility of writing other implementations in the future ? Is too complex for two coders ?


You could support Win32 and OSX. That would be a good introduction to cross-platform problems and their solutions.
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]
Hey, i'm going to write only the PC part but i've decided to try to mantain abstraction for some classes...
Please, how should i write the Window Class ? It doesn't exist in the consolles ( obviously ), so... Do you have some ideas ?
Thanks :)
Quote:Original post by jwein
Hey, i'm going to write only the PC part but i've decided to try to mantain abstraction for some classes...
Please, how should i write the Window Class ? It doesn't exist in the consolles ( obviously ), so... Do you have some ideas ?
Thanks :)


To be honest, if you can get a well-working cross-platform architecture on WIN32 and OSX (and for bonus points, Posix-conforming Linux), alongside a well-working graphics API abstraction, you're doing better than 90%* of people who try. And if you actually make a game with it, well that's better than 99.9999%* of people. Maybe you should disregard console support for the first four years.



*Note: Numbers are estimates and are not based upon fact
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]

This topic is closed to new replies.

Advertisement