I know... But I don't want to add consolle support...
I want to add the possibility of future consolle support making the engine modular ...
I think it's different :)
Cross-Platform Architecture
Quote:Original post by jweinI think one of the points people are trying to make here is that in order to leave open the possibility of support for platform X in the future, you have to have enough of an understanding of platform X that you can pull out the 'common denominators', as it were, and build them into your engine's interface from the beginning.
I know... But I don't want to add consolle support...
I want to add the possibility of future consolle support making the engine modular ...
I think it's different :)
Anyway, I don't know that people are going to be able to tell you 'how to write the Window class', etc. This is a hard task you have in mind, one that requires a great deal of experience in software design and with the particulars of each of the platforms you wish to support.
If you're intent on it though, you might look at some existing cross-platform renderers (e.g. Ogre) and see if you can pick up a few ideas that way.
@jwein
What's wrong with Agar? Currently only that it is built upon SDL and OpenGL and only works on platforms that support them. Version 1.4 may fix that but still you're left with the problem that there is no DirectX support except that which is provided with SDL.
You could also look into using developer tools other than Visual Studio or the Express Editions since their manifests are totally unportable to other platforms.
Cross-platform is not just a bolt-on feature for an engine. It has to be designed with cross-platform compatibility built in from the start. You should be familiar with non-PC platforms from the start if you want to design a cross-platform engine.
Also, keep track of endianness of variables that get loaded from and saved to disk accesses so that it will work on PowerPC as well as Intel/AMD.
Post back here when you have looked at some other cross-platform code.
What's wrong with Agar? Currently only that it is built upon SDL and OpenGL and only works on platforms that support them. Version 1.4 may fix that but still you're left with the problem that there is no DirectX support except that which is provided with SDL.
You could also look into using developer tools other than Visual Studio or the Express Editions since their manifests are totally unportable to other platforms.
Cross-platform is not just a bolt-on feature for an engine. It has to be designed with cross-platform compatibility built in from the start. You should be familiar with non-PC platforms from the start if you want to design a cross-platform engine.
Also, keep track of endianness of variables that get loaded from and saved to disk accesses so that it will work on PowerPC as well as Intel/AMD.
Post back here when you have looked at some other cross-platform code.
Author
Hey, Thanks for the answers...
I think i'll drop the consolle support and i'll write a PC only engine ( Windows, Linux, MacOs ) writing only the PC part...
I've seen the code of ogre, but i don't understand where it switches the rendersystem specific implementations...
My problem now is that i should pass the parameters between Core and Window two times ( i've explained in the first post of this thread )...
Is there a better solution ?
PS: I' ll wrote something using templates instead of bridge, because i need it at compile time and I know the code i've written is not efficient.
I think i'll drop the consolle support and i'll write a PC only engine ( Windows, Linux, MacOs ) writing only the PC part...
I've seen the code of ogre, but i don't understand where it switches the rendersystem specific implementations...
My problem now is that i should pass the parameters between Core and Window two times ( i've explained in the first post of this thread )...
Is there a better solution ?
PS: I' ll wrote something using templates instead of bridge, because i need it at compile time and I know the code i've written is not efficient.
Author
Hey, I've though i could do something similar...
ECore* Engine = new ECore()
EWindow* Window = new EWindowWin32()
Window = Engine->createWindow( parameters )
In this way the game coder could deicide what Window Implementation he want...
Is it correct ?
I' ve tried studying ogre and irrlicht but they are too complex, i want to build a smaller engine.
ECore* Engine = new ECore()
EWindow* Window = new EWindowWin32()
Window = Engine->createWindow( parameters )
In this way the game coder could deicide what Window Implementation he want...
Is it correct ?
I' ve tried studying ogre and irrlicht but they are too complex, i want to build a smaller engine.
Quote:Original post by jwein
I' ve tried studying ogre and irrlicht but they are too complex, i want to build a smaller engine.
If you cut through the all the cruft on top, the core engine of either Ogre or IrrLicht is quite simple. All IrrLicht provides at a basic level is abstractions for the Window (including input), the Renderer (clears the buffer, renders triangles, sets lights), and a partial Materials/Shaders abstraction. If that sounds too complicated, then you should be using an existing engine, not making a new one.
Author
Yes, I' ve seen Irrlicht and now I understand it, but I don't like the fact that Irrlicht asks for window size, etc in the main function of the device ( createDevice )... I'd like to abstract the window from the engine...
I designed a cross-platform graphics engine once. I didn't really know what I was doing when I started, so I made some mistakes. But it's been used in 5 shipped games (and counting) on every console platform of this and last generation except the DS, so I guess I did a few things right.
As for abstracting things across platforms... I did it in a way that I didn't always like, but it more or less worked. We had special folders for each platform that would only compile on that platform. So you would have two interfaces... Graphics and PlatformGraphics. The original idea was that the PlatformGraphics interface would remain the same for every platform, but the implementation would change and you'd end up with one PlatformGraphics C++ file in each of the platform subfolders. Graphics would contain stuff that didn't need to be different per-platform and would often be the only thing making calls into PlatformGraphics.
I did this with a few different classes, and what ended up happening is that a lot of platform-specific changes were made to the interface via #ifdefs. This was half sloppiness on our part and half a result of designing without forethought, but some classes ended up very very messy... because it turns out that the PSP is very different from Xbox 360 and needs to interact with things in a very different way.
An inheritance system might enforce a little cleaner interaction with your system, but you always know the platform you're working with at the time so you don't specifically need virtual function calls.
After a few years of working with that I have some better ideas for if I ever have to write another cross-platform graphics engine. But unlike some of the posters above I'm going to advise that you do try to write your own. There's no better learning experience than using something you designed and realizing exactly where it fails. Just realize that it can be very time consuming. When I wrote the first version of mine it was up and working on Xbox in a little over 200 hours of work by just one person, but we were always trying to add missing features and improve the pipeline as things came up for different games.
As for where to start abstracting, I'd say your most important abstract concept is Camera... that is a unit containing a list of meshes to draw, a unique render target, and a unique projection matrix and scissor space. The engine I work with now calls this a Scene rather than a Camera. For meshes there are a lot of important things to consider, especially how you separate things that are totally opaque and things with alpha.
As for abstracting things across platforms... I did it in a way that I didn't always like, but it more or less worked. We had special folders for each platform that would only compile on that platform. So you would have two interfaces... Graphics and PlatformGraphics. The original idea was that the PlatformGraphics interface would remain the same for every platform, but the implementation would change and you'd end up with one PlatformGraphics C++ file in each of the platform subfolders. Graphics would contain stuff that didn't need to be different per-platform and would often be the only thing making calls into PlatformGraphics.
I did this with a few different classes, and what ended up happening is that a lot of platform-specific changes were made to the interface via #ifdefs. This was half sloppiness on our part and half a result of designing without forethought, but some classes ended up very very messy... because it turns out that the PSP is very different from Xbox 360 and needs to interact with things in a very different way.
An inheritance system might enforce a little cleaner interaction with your system, but you always know the platform you're working with at the time so you don't specifically need virtual function calls.
After a few years of working with that I have some better ideas for if I ever have to write another cross-platform graphics engine. But unlike some of the posters above I'm going to advise that you do try to write your own. There's no better learning experience than using something you designed and realizing exactly where it fails. Just realize that it can be very time consuming. When I wrote the first version of mine it was up and working on Xbox in a little over 200 hours of work by just one person, but we were always trying to add missing features and improve the pipeline as things came up for different games.
As for where to start abstracting, I'd say your most important abstract concept is Camera... that is a unit containing a list of meshes to draw, a unique render target, and a unique projection matrix and scissor space. The engine I work with now calls this a Scene rather than a Camera. For meshes there are a lot of important things to consider, especially how you separate things that are totally opaque and things with alpha.
Author
Hi, thanks for the answer...
I'm going to write a better architecture and almost any problem is solved ( for now, i know others will came :P )..
Please, could you tell me how to manage the Window in a cross-platform engine ?
My problem is consoles don't have a Window and I would like to solve the problem in an elegant way...
Thanks, Bye!
I'm going to write a better architecture and almost any problem is solved ( for now, i know others will came :P )..
Please, could you tell me how to manage the Window in a cross-platform engine ?
My problem is consoles don't have a Window and I would like to solve the problem in an elegant way...
Thanks, Bye!
Author
Hey, I've though of a solution...
I could put in the Engine class a pointer to the other classes ( ex. Scene, Renderer, Window, etc... ) and some functions to init them...
Then, when i use the engine, i could do something similar in main:
Engine* engine = new Engine()
Window* window = new Window()
window = engine->create( ... )
... for PC platforms, and something similar:
Engine* engine = new Engine()
... without initializing the Window class, for consoles...
Window class is a typedef which come from some ifdefs of the different implementations...
Could this method work ?
I could put in the Engine class a pointer to the other classes ( ex. Scene, Renderer, Window, etc... ) and some functions to init them...
Then, when i use the engine, i could do something similar in main:
Engine* engine = new Engine()
Window* window = new Window()
window = engine->create( ... )
... for PC platforms, and something similar:
Engine* engine = new Engine()
... without initializing the Window class, for consoles...
Window class is a typedef which come from some ifdefs of the different implementations...
Could this method work ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
