Discussion - Coding, SDL & DirectX
Moderator: Transport Empire Moderators
Here's a thought that occurs to me:
TE is planned to be an open source game. Therefore, it's most likely to appeal to those that already use open source software to some degree. There is most certainly a larger portion of open source software users working under non-Windows environments than there are non-OSS users working under non-Windows environments (if this makes sense). The net effect of this is that we're going to lose a very large part of our audience unless we make sure the thing works under environments that are not Windows, so supporting only Windows is not an option.
Following up on this, DirectX support is native only to this platform and will have a comparatively small (not insignificant, however) base of users - it might be more of a headache than it's worth to maintain a completely separate rendering engine that's only going to be used by part, not all, of our audience.
We'll have to start coding before we know whether or not this is the case, methinks.
TE is planned to be an open source game. Therefore, it's most likely to appeal to those that already use open source software to some degree. There is most certainly a larger portion of open source software users working under non-Windows environments than there are non-OSS users working under non-Windows environments (if this makes sense). The net effect of this is that we're going to lose a very large part of our audience unless we make sure the thing works under environments that are not Windows, so supporting only Windows is not an option.
Following up on this, DirectX support is native only to this platform and will have a comparatively small (not insignificant, however) base of users - it might be more of a headache than it's worth to maintain a completely separate rendering engine that's only going to be used by part, not all, of our audience.
We'll have to start coding before we know whether or not this is the case, methinks.
Grunt
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
- toholio
- Traffic Manager
- Posts: 216
- Joined: 20 Dec 2004 00:54
- Location: S37°56.286' E145°07.628'
- Contact:
Well, if you start with Direct X then only Windows users will be able to contribute initially. This will probably remove quite a few of the potential developers (none of the OpenTTD devs use Windows and it seems that only half of the patch devs do. YMMV).PJayTycy wrote: So, the only question that remains is: do we start with opengl or directx ? And I don't have a real opinion on that.
- toholio
- Traffic Manager
- Posts: 216
- Joined: 20 Dec 2004 00:54
- Location: S37°56.286' E145°07.628'
- Contact:
OK, I'll stop flaming.Hyronymus wrote:Well, here is something else for you to read in the morning, toholio. Bald statements alone aren't what we are looking for, neither some cheap flamewar. The project won't benefit from it.
My reasons for thinking D3D is a bad idea are:Hyronymus wrote:Please come with fundamental claims why D3D is worse than SDL. I hope you will do the same Uzurpator, perhaps my explaining this more:
- It's platform specific
- It's proprietary
- It's one more division/section that needs to be maintained and thought about.
- If it's used as a starting point then non Windows developers won't contribute.
The other one can be included but you start with the one that everyone can use and add support for the closed, platform specific tool later, not the other way around.Uzurpator wrote:The case is to use an universal interface (chosen on compile) to use either SDL or DX and now develop around what is easier to learn/use. The other one can always be included.
If you start with D3D you're cutting out potential contributors that may never come back.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Good point. Altho SDL is not the one that everyone can use that's why we need to seperate API from the game core. Simply to make it possible to port the game to SDL, DX ot whatever thing will come up next.toholio wrote:The other one can be included but you start with the one that everyone can use and add support for the closed, platform specific tool later, not the other way around.
If you start with D3D you're cutting out potential contributors that may never come back.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
webopedia wrote: Abbreviation of application program interface, a set of routines, protocols, and tools for building software applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer puts the blocks together.
DirectX and OpenGL are both API's. They are a set of functions you can call from a program. The operating system then desides what to do with them, normally directx and opengl functions are sent to the graphics card and not to the processor.
I don't know how similar the 2 api's are, but if they are very very similar, we can solve all this by defining our own "drawing" interface and create 2 instances, 1 who translates to directX commands and 1 who translates to opengl. The rest of the game only knows our own interface and doesn't care which instance is used. Ofcourse, this is the 100% ideal case, and I don't expect it to be really this simple. There will obviously be bigger differences that can't be solved by translating alone. If we want to get this really to work, we need to know the most important differences between opengl and directx. I don't know if we currently have anybody who has experience with both of them.
On holiday from 16/07 till 31/07
This is exactly what has been done in prior software that needs more than one rendering engine. Should we choose to write more than one engine, this is the route to take.PJayTycy wrote:
DirectX and OpenGL are both API's. They are a set of functions you can call from a program. The operating system then desides what to do with them, normally directx and opengl functions are sent to the graphics card and not to the processor.
I don't know how similar the 2 api's are, but if they are very very similar, we can solve all this by defining our own "drawing" interface and create 2 instances, 1 who translates to directX commands and 1 who translates to opengl. The rest of the game only knows our own interface and doesn't care which instance is used. Ofcourse, this is the 100% ideal case, and I don't expect it to be really this simple. There will obviously be bigger differences that can't be solved by translating alone. If we want to get this really to work, we need to know the most important differences between opengl and directx. I don't know if we currently have anybody who has experience with both of them.
Grunt
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
I am reading this forum for quite some while now. I am bit confused about this discussion because I don't understand the problems that you have. In the libsdl windows FAQ is written:
This is from general FAQ:SDL takes advantage of DirectX hardware acceleration when it is available, but falls back to the standard Win32 services if DirectX is not installed.
Hope I could help a bit with this information.The current version supports Linux, Windows, BeOS, MacOS, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX.
The code contains support for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, and SymbianOS, but these are not yet officially supported.
Well, it really depends what are you trying to do.
SDL has for 2D Operation a hardware acceleration via DirectX(To be precise DirectDraw, not Direct3D! )
Normally all 3D Stuff is done via OpenGL ...
And about seperation, well it's not so easy that you can simple exchange drawing commands, so you will write some abstraction class ...
SDL has for 2D Operation a hardware acceleration via DirectX(To be precise DirectDraw, not Direct3D! )
Normally all 3D Stuff is done via OpenGL ...
And about seperation, well it's not so easy that you can simple exchange drawing commands, so you will write some abstraction class ...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Perhaps you guys should look at using something like OGRE or Crystal Space or another tool that does all the hard rendering work for you. No point re-inventing the wheel, etc.
Open source tycoon games
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community
Well, most of these libs are designed for createing 3D shooters ... Less Objects, High vertices count per Object... and don't work very well by design for transport games (my opinion of them, if you find something suiteable let us know... )
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
AFAIK Ogre3d is suitable for 2D environements too, and it's ten times easier than Crystal Space, ihmo. As someone said, there's no point in reinventing the wheel.
If you want to go multi-platform (which i definitely suggest to), go for SDL. That's the most "safe" way to proceed.
And before anyone of you forget, even SDL (and OpenGL for that matter) are completely crossplatform compatible: some stuff will work on a platform and won't on another one, and vice-versa. Stupid example: try implementing GL_ARB_multitexture. It is supposed to work only on devices that support it. That's a correct assumption. But even on a card that has got it, this extension is going/not going to work depending on which compiler/language/library you use. At least, that's what happened to me.
If you want to go multi-platform (which i definitely suggest to), go for SDL. That's the most "safe" way to proceed.
And before anyone of you forget, even SDL (and OpenGL for that matter) are completely crossplatform compatible: some stuff will work on a platform and won't on another one, and vice-versa. Stupid example: try implementing GL_ARB_multitexture. It is supposed to work only on devices that support it. That's a correct assumption. But even on a card that has got it, this extension is going/not going to work depending on which compiler/language/library you use. At least, that's what happened to me.
There is a massive variety of projects using OGRE, only a handful of which are FPS games.eis_os wrote:Well, most of these libs are designed for createing 3D shooters ... and don't work very well by design for transport games
OGRE provides the rendering and scene management. It handles terrain especially well. Of course, it's not going to implement the 'transport' side of things, but that's what TE is about.
Open source tycoon games
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community
Terrains true, mostly as one unit or heightmap ... WinRT and TE have different needs of terrains ...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
About OGRE and the ability to go multiplatform:
OGRE fully supports Direct3d (better in Windows) and OpenGL (necessary for Linux). That's to say the engine itself already is multiplatform and any game pased on it also will be whilst using the OO interface of OGRE. Reference
OGRE fully supports Direct3d (better in Windows) and OpenGL (necessary for Linux). That's to say the engine itself already is multiplatform and any game pased on it also will be whilst using the OO interface of OGRE. Reference
\°| Greetz, TossIB |°/
That is "quite" correct. Basically SDl uses DirectX for 2D (OpenGL can do that too, but it's far too complicated) AND for everything related to user input: keyboard, mouse, joysticks, etc...Hyronymus wrote:Does this mean that SDL normally does everything in OpenGL but can do 2D stuff in DirectX too when necessary?
Who is online
Users browsing this forum: No registered users and 2 guests