Discussion - Coding, SDL & DirectX
Moderator: Transport Empire Moderators
Greetings,
I myself have been programming in OpenGL and DirectX for quite some time. Let me clear up some confusion about both.
DirectX is a Windows only SDK (unless you are using an emulator). OpenGL is a multiplatform SDK. Both are about the same in speed and functionality. I know people who will argue that one is faster than the other, but I suppose a few milliseconds is really important to them.
Anyways, I suggest that if you want to go with multiplatform that you should stick with OpenGL or Native. You can always do OpenGL wrapped by DirectX (Counter Strike: Source does this), but that is a real pain and can lead to months of debugging.
OGRE is good too but it can be a bit taxing on older machines that have CPU bottlenecks (pre-2ghz intels and pre-athlon).
Maybe later I'll write a little article on rendering and creating textures.
That's all for now,
-Rapture
I myself have been programming in OpenGL and DirectX for quite some time. Let me clear up some confusion about both.
DirectX is a Windows only SDK (unless you are using an emulator). OpenGL is a multiplatform SDK. Both are about the same in speed and functionality. I know people who will argue that one is faster than the other, but I suppose a few milliseconds is really important to them.
Anyways, I suggest that if you want to go with multiplatform that you should stick with OpenGL or Native. You can always do OpenGL wrapped by DirectX (Counter Strike: Source does this), but that is a real pain and can lead to months of debugging.
OGRE is good too but it can be a bit taxing on older machines that have CPU bottlenecks (pre-2ghz intels and pre-athlon).
Maybe later I'll write a little article on rendering and creating textures.
That's all for now,
-Rapture
I don't really understand your question Hyronymous...
What would you want to keep or drop ??
=> Will we use any of these as a starting point for the game?
No, this has never been the intention. They were built to get experience with SDL and try out a few game ideas (ie: like the movement speed comparison)
=> So these demo's are completely useless now ?
No, we some people have more experience with SDL and we used them for better supported decisions.
=> But nobody will ever need to look at them again?
Mostly not, but maybe some might be used as a starting point to test something else before we have anything that looks like a game engine.
What would you want to keep or drop ??
=> Will we use any of these as a starting point for the game?
No, this has never been the intention. They were built to get experience with SDL and try out a few game ideas (ie: like the movement speed comparison)
=> So these demo's are completely useless now ?
No, we some people have more experience with SDL and we used them for better supported decisions.
=> But nobody will ever need to look at them again?
Mostly not, but maybe some might be used as a starting point to test something else before we have anything that looks like a game engine.
On holiday from 16/07 till 31/07
I still dont get it - who needs DX support in game anyway?
SDL + OGL is nice for multiplatform purposes - easy to use threads, easy to use network. Only other way to achieve multiplatform compability is to use gcc/mingw and libc . And using both SDL and "direct DX" is rather imposible .
Correct me if I said something wrong .
SDL + OGL is nice for multiplatform purposes - easy to use threads, easy to use network. Only other way to achieve multiplatform compability is to use gcc/mingw and libc . And using both SDL and "direct DX" is rather imposible .
Correct me if I said something wrong .
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
I personally think that SDL should be used at first, not necessarily to appeal to a larger audience, but for the coders sakes. I am using Windows, but some of the coders are using Linux.
It was mentioned before that the drawing could be separated from the game logic. This is standard practice and the usual route to take is the design pattern MVC (Model View Controller).
In this design pattern, the game logic would be the Model (or data), the SDL or DirectX routines would be part of the View, and input from the user (keyboard/mouse/joystick) would be handled in the Controller.
The way it works is that the Controller collects input from the user and modifies the data in the Model through an interface. This interface has model-specific methods such as gotoStation(station) which might make a train try to get to the specified station. With this setup, it doesn't make any difference to the game logic where the input comes from, for all it knows the instruction came as a command line input from telnet.
The View has access to read-only interfaces to the data in the Model with methods such as getX() to return the unit's x position in the world. The View can then interpret this in any way it so chooses and paint (or output text) to the screen. This means that the View has no effect on the game logic. Since the painting routines are accessed by the Model through an interface, it doesn't care what the View does with the information it's sending.
Using the MVC design pattern also means that the separate parts of the game can be worked on independently and have few dependancies (the only dependancies are the in structure of the interfaces).
If this is implemented with care it can make a very flexible framework for development and expansion.
It was mentioned before that the drawing could be separated from the game logic. This is standard practice and the usual route to take is the design pattern MVC (Model View Controller).
In this design pattern, the game logic would be the Model (or data), the SDL or DirectX routines would be part of the View, and input from the user (keyboard/mouse/joystick) would be handled in the Controller.
The way it works is that the Controller collects input from the user and modifies the data in the Model through an interface. This interface has model-specific methods such as gotoStation(station) which might make a train try to get to the specified station. With this setup, it doesn't make any difference to the game logic where the input comes from, for all it knows the instruction came as a command line input from telnet.
The View has access to read-only interfaces to the data in the Model with methods such as getX() to return the unit's x position in the world. The View can then interpret this in any way it so chooses and paint (or output text) to the screen. This means that the View has no effect on the game logic. Since the painting routines are accessed by the Model through an interface, it doesn't care what the View does with the information it's sending.
Using the MVC design pattern also means that the separate parts of the game can be worked on independently and have few dependancies (the only dependancies are the in structure of the interfaces).
If this is implemented with care it can make a very flexible framework for development and expansion.
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.
-
- Transport Empire Developer
- Posts: 699
- Joined: 03 Feb 2003 09:30
- Location: Back at the office
As far as a choice between D3D and OpenGL is concerned, I think we don't have to care which one is used. They're both suited for one and the same purpose: drawing triangles on a screen.
In fact, it can be as simple as this:
In fact, it can be as simple as this:
- We define an interface called Renderer. For laymen: an interface is a class without code. All the code is defined in the subclasses
- Renderer defines (among others) a method called "render", which has a parameter of the type Renderable.
- Renderable is also an interface, defining some required properties of a 3D model for rendering, like a list of vertices, polygons/triangles, textures, etc. All our models will implement the Renderable interface.
- We declare subclasses of the Renderer for D3D (e.g. RendererD3d) and OpenGL (e.g. RendererOpengl)
PJayTycy wrote: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.
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Code: Select all
+------------Oo.------+
| Transport Empire -> |
+---------------------+
Under construction...
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
Yes, exactly. However, considering that many people are not using Windows here, SDL+OpenGL should probably come first.Hellfire wrote:As far as a choice between D3D and OpenGL is concerned, I think we don't have to care which one is used. They're both suited for one and the same purpose: drawing triangles on a screen.
Exactly what I many, many, many other games do. It means that the bits can be worked on seperately, it can easily be ported to different things, without having to get into the internals of the simulation itself.... wrote: In fact, it can be as simple as this:
- We define an interface called Renderer. For laymen: an interface is a class without code. All the code is defined in the subclasses
- Renderer defines (among others) a method called "render", which has a parameter of the type Renderable.
- Renderable is also an interface, defining some required properties of a 3D model for rendering, like a list of vertices, polygons/triangles, textures, etc. All our models will implement the Renderable interface.
- We declare subclasses of the Renderer for D3D (e.g. RendererD3d) and OpenGL (e.g. RendererOpengl)
So, in conclusion, we can have as many interfaces to the simulation as we want, to run on every platform possible, without having any major implications on the code. And do we really want to fall into the trap that Micro$oft is laying for us? This is exactly what they are trying to do by crippling OpenGL in Windows Vista.... wrote: And as it turns out, PJayTycy has already suggested such a setup:PJayTycy wrote: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.
Does anybody want this to become yet another game that has been ensnared by Micro$oft's anti-competitive net? I, for one, do not want to see me being unable to play this game, just because some multi-billion-dollar company decides to cripple the primary cross-platform 3D API!
I don't want to be stuck playing OpenTTD for ever, when TE will be greatly superior, because I haven't got the money to fork out hundreds of dollars on a proprietary Microsoft operating system. Linux fulfills my needs perfectly, but Microsoft is trying to take away all possibility of games being ported here. Microsoft is a truly evil company, and they will always have a special place in my heart, as the most hated company of many people.
Anyway, the approach suggested by both Hellfire and PJayTycy should work fine, and avoid platform restrictions.
William.
Yes, if there is something you can pull apart and have it not care what other parts of your progarm are doing, it is MUCH better. (This is one of the key concepts in OO-programing)
If you have object A that does stuff and passes it on to Object B, idealy, you don't want object A or B caring how the other is doing it. While this does make coding harder than if you take shortcuts and tie everything in together, it makes things SO much easier when you decide to change a part.
Now, for the idea of windows getting rid of OGL, well, hopefully they're not that DUMB. Does anyone know the amount of software that runs on OGL now? Sure, lots of games run one, but there is a LOT of professonal software used in different industies that are OGL only. Lots of developers work in OGL, and one of the first rules is don't p*** off Devs. p***ing off people that know how to pick apart your stuff abuse nasty bugs is a BAD idea,
But really, most of this thread are really sad. "Most use this! we should too!!!" well, most people in Europe/north america that use handsaws use push saws. Those are great if you can stand over your work, but if you're cutting over your head, a pull saw is a hell of a lot better.
Why wouldn't you think what you NEED, not what everone else uses.
If you have object A that does stuff and passes it on to Object B, idealy, you don't want object A or B caring how the other is doing it. While this does make coding harder than if you take shortcuts and tie everything in together, it makes things SO much easier when you decide to change a part.
Now, for the idea of windows getting rid of OGL, well, hopefully they're not that DUMB. Does anyone know the amount of software that runs on OGL now? Sure, lots of games run one, but there is a LOT of professonal software used in different industies that are OGL only. Lots of developers work in OGL, and one of the first rules is don't p*** off Devs. p***ing off people that know how to pick apart your stuff abuse nasty bugs is a BAD idea,
But really, most of this thread are really sad. "Most use this! we should too!!!" well, most people in Europe/north america that use handsaws use push saws. Those are great if you can stand over your work, but if you're cutting over your head, a pull saw is a hell of a lot better.
Why wouldn't you think what you NEED, not what everone else uses.
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
Yep, exactly. Of course, we should all use DirectX because the vast majority of the gaming community uses Windows... Too bad if the balances are different here because it is Open Source. Why on earth would we want to cut the possibilities down, and do what M$ wants us to do?Talroth wrote:Yes, if there is something you can pull apart and have it not care what other parts of your progarm are doing, it is MUCH better. (This is one of the key concepts in OO-programing)
If you have object A that does stuff and passes it on to Object B, idealy, you don't want object A or B caring how the other is doing it. While this does make coding harder than if you take shortcuts and tie everything in together, it makes things SO much easier when you decide to change a part.
Now, for the idea of windows getting rid of OGL, well, hopefully they're not that DUMB. Does anyone know the amount of software that runs on OGL now? Sure, lots of games run one, but there is a LOT of professonal software used in different industies that are OGL only. Lots of developers work in OGL, and one of the first rules is don't p*** off Devs. p***ing off people that know how to pick apart your stuff abuse nasty bugs is a BAD idea,
But really, most of this thread are really sad. "Most use this! we should too!!!" well, most people in Europe/north america that use handsaws use push saws. Those are great if you can stand over your work, but if you're cutting over your head, a pull saw is a hell of a lot better.
Why wouldn't you think what you NEED, not what everone else uses.
Encapsulation is a Good Thing, and should be used to enable easy dropping in of DirectX/OpenGL/whatever modules.
William.
(Acknowledging the tongue-in-cheek nature of the quote) and also OpenGL works on Windows too, so why what exactly (other than mindshare) does DX have going for it?fujitsu wrote:Yep, exactly. Of course, we should all use DirectX because the vast majority of the gaming community uses Windows...
Personally I'd say use OGRE which is not as bad on pre-2ghz machines as Rapture makes out (actually it was rather good during my 800mhz GeForce2 testing but it was nothing taxing). Don't reinvent the wheel! Use a stable, fully featured 3d engine! Why invent your own interfaces when people have already done that work for you!?
I mean, you are talking about reprogramming the equivalent of OGRE here - this is exactly what OGRE does for you:
Hellfire wrote:
- We define an interface called Renderer. For laymen: an interface is a class without code. All the code is defined in the subclasses
- Renderer defines (among others) a method called "render", which has a parameter of the type Renderable.
- Renderable is also an interface, defining some required properties of a 3D model for rendering, like a list of vertices, polygons/triangles, textures, etc. All our models will implement the Renderable interface.
- We declare subclasses of the Renderer for D3D (e.g. RendererD3d) and OpenGL (e.g. RendererOpengl)
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
-
- Engineer
- Posts: 21
- Joined: 03 Sep 2003 14:03
- Skype: benjamingoodger
- Location: Hertfordshire, UK
A GPL game relying on Microsoft for its entire graphics capabilities is ludicrous. You'll be laughed at by every other OSS dev, the game will only run on Windows (or force people to buy Cedega) and Microsoft may decide that it wants you to pay at some point.
Go with OGRE, or CrystalSpace. That way, you can avoid mindlessly duplicating work which has been done (probably better) by others; you won't depend on DirectX; it runs on Unix; and the leet kiddiez who want to squeeze a few hundred extra FPS out of their pwnzoring DirectX-loving graphics cards will be satisfied.
I'd go for CrystalSpace, myself: OGRE's demos ran a tad suckily on my RADEON 9600.
Go with OGRE, or CrystalSpace. That way, you can avoid mindlessly duplicating work which has been done (probably better) by others; you won't depend on DirectX; it runs on Unix; and the leet kiddiez who want to squeeze a few hundred extra FPS out of their pwnzoring DirectX-loving graphics cards will be satisfied.
I'd go for CrystalSpace, myself: OGRE's demos ran a tad suckily on my RADEON 9600.
~Ben
Microsoft Visual Bios (C) 1984
Where will Bill have you dragged today?
Press CTRL-ALT-F1-END-ESC-INS for Visual Cmos setup.
Microsoft Visual Bios (C) 1984
Where will Bill have you dragged today?
Press CTRL-ALT-F1-END-ESC-INS for Visual Cmos setup.
Who is online
Users browsing this forum: No registered users and 3 guests