Say someone wanted to port OpenMW (TES3 Morrowind), Xash3D (Half-Life engine + Mods), or OpenRW (GTA3) to Dreamcast. All of which are open sourced re-implementations of engines, but take advantage of the new power of today's hardware. What would be involved in successfully porting one of those to Dreamcast? "Downscaling" the visuals of the engines until the engine performed at decent framerate? Or is it deeper like porting all of the libraries used in the engine? Or rewriting the engine entirely?
I've found this subject very interesting but was never able to hear from people who actually know what would go into making this happen. This is all hypothetical of course
A serious discussion: porting open source engines to DC
-
- DCEmu Crazy Poster
- Posts: 35
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Sat Dec 27, 2014 11:17 pm
- Has thanked: 0
- Been thanked: 0
-
- DCEmu Fast Newbie
- Posts: 20
- Joined: Thu Mar 15, 2007 12:04 pm
- Has thanked: 0
- Been thanked: 1 time
Re: A serious discussion: porting open source engines to DC
in short
for all three of them - a hell of lot work.
I took a quick look at the code base and FAQs of all three
OpenMW:
Programming language: C++
Graphics: OpenSceneGraph (OSG)
Physics: Bullet
Sound: OpenAL
GUI: MyGUI
Input: SDL2
getting Bullet running fast enough on DC is hard. SDL2 isn't ported to DC and probably never will, but it's no big deal here - input is the easiest part here - but the game is made for keyboards and mouse. I would never touch anything on DC when it's not playable with the controller only. DC has keyboard and mouse peripherals but it's optionally. There are no ports of openal and mygui for DC. And the compiled version of OpenSceneGraph would be too much for DC. This one is a big dependency. I wouldn't use it even on PC.
OpenRW
bullet glm libsndfile mad openal-soft sdl2
bullet, openal, sdl2 - see above.
glm is math/matrix stuff. the used code could be rewritten to use own math-stuff. it's not that hard if you know that you are doing. personally i use my own math functions. libsndfile and mad are for mp3 playback.
the problem i see here is the use of more modern C++ style. boost is used in some files, as is the STL. Of course C++ can be used on DC, but it should be used with caution. I'm would prefer plain C here.
the compile times of openrw are relatively high on my PC and the resulting files are
librwengine.a - 2,9 mb
librwlib.a - 360 kb
rwgame - 1,8 mb
these are dynamically linked, so on DC you would have to add the sizes of the needed libs (bullet, sdl2 etc.) to it.
given that you only have 16 mb to work with - and these sizes are without any assets (maps, characters, sound files etc) loaded, that would be too much
Xash3D
i haven't looked very deep in the code, but it's looks like Quake1/Quake2 engine. More like Quake1 judging by file names alone. written in C. this might (!) be the best candidate for a port. But there are FAQs on this very site why Quake2 for DC isn't well suited - the same would apply here. Even if someone can port the engine on the DC, it doesn't mean you can get Half-Life/CS running without heavily modifiying it's assets...
=> it would be mostly rewriting the engines completely
for all three of them - a hell of lot work.
It's not only about "downscaling" the visuals. The engines may be reimplementations of old games, but they aren't written with really old hardware in mind (like the dreamcast is). all the needed libraries would be needed to port to dreamcast first (that alone is hard/impossible enough). the libraries they used aren't really suited for DC to begin with.Doctor Dan wrote:What would be involved in successfully porting one of those to Dreamcast? "Downscaling" the visuals of the engines until the engine performed at decent framerate? Or is it deeper like porting all of the libraries used in the engine? Or rewriting the engine entirely?
I've found this subject very interesting but was never able to hear from people who actually know what would go into making this happen. This is all hypothetical of course
I took a quick look at the code base and FAQs of all three
OpenMW:
Programming language: C++
Graphics: OpenSceneGraph (OSG)
Physics: Bullet
Sound: OpenAL
GUI: MyGUI
Input: SDL2
getting Bullet running fast enough on DC is hard. SDL2 isn't ported to DC and probably never will, but it's no big deal here - input is the easiest part here - but the game is made for keyboards and mouse. I would never touch anything on DC when it's not playable with the controller only. DC has keyboard and mouse peripherals but it's optionally. There are no ports of openal and mygui for DC. And the compiled version of OpenSceneGraph would be too much for DC. This one is a big dependency. I wouldn't use it even on PC.
OpenRW
bullet glm libsndfile mad openal-soft sdl2
bullet, openal, sdl2 - see above.
glm is math/matrix stuff. the used code could be rewritten to use own math-stuff. it's not that hard if you know that you are doing. personally i use my own math functions. libsndfile and mad are for mp3 playback.
the problem i see here is the use of more modern C++ style. boost is used in some files, as is the STL. Of course C++ can be used on DC, but it should be used with caution. I'm would prefer plain C here.
the compile times of openrw are relatively high on my PC and the resulting files are
librwengine.a - 2,9 mb
librwlib.a - 360 kb
rwgame - 1,8 mb
these are dynamically linked, so on DC you would have to add the sizes of the needed libs (bullet, sdl2 etc.) to it.
given that you only have 16 mb to work with - and these sizes are without any assets (maps, characters, sound files etc) loaded, that would be too much
Xash3D
i haven't looked very deep in the code, but it's looks like Quake1/Quake2 engine. More like Quake1 judging by file names alone. written in C. this might (!) be the best candidate for a port. But there are FAQs on this very site why Quake2 for DC isn't well suited - the same would apply here. Even if someone can port the engine on the DC, it doesn't mean you can get Half-Life/CS running without heavily modifiying it's assets...
=> it would be mostly rewriting the engines completely
-
- DC Developer
- Posts: 414
- Joined: Thu Aug 20, 2009 11:00 am
- Has thanked: 0
- Been thanked: 2 times
Re: A serious discussion: porting open source engines to DC
One of the biggest problems you see with open source ports of games is that they assume infinite memory. For example, nearly all Doom ports cache graphics, but don't release the graphics when memory gets low because they assume that can't happen. In fact, most now assume you can't run out of video memory, much less system memory. Ditto for the sound - caching without releasing the cache if memory is low.
Re: A serious discussion: porting open source engines to DC
The renderer also often assume shader support nowadays. So you would have to reimplement the entire renderer with fixed pipeline functionality.
And yeah, those engines are generally so incredibly bloated, the performance would suck anyway.
Google Mike Acton ogre node for example lol
And yeah, those engines are generally so incredibly bloated, the performance would suck anyway.
Google Mike Acton ogre node for example lol
Wiki & tutorials: http://dcemulation.org/?title=Development
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream
Wiki feedback: viewtopic.php?f=29&t=103940
My libgl playground (not for production): https://bitbucket.org/bogglez/libgl15
My lxdream fork (with small fixes): https://bitbucket.org/bogglez/lxdream