Discussion - Coding, SDL & DirectX

Archived discussions related to Transport Empire. Read-only access only.

Moderator: Transport Empire Moderators

Rapture
Engineer
Engineer
Posts: 47
Joined: 29 Aug 2005 19:16

Post by Rapture »

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. :shock:

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. :evil:

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
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus »

This topic has been totally about DirectX now but as the title read it should also discuss whether we keep or drop the SDL demos that are around? The meeting is due in 2 days so we would appreciate it if you folks can focus on this question now.
User avatar
PJayTycy
Route Supervisor
Route Supervisor
Posts: 429
Joined: 09 Mar 2004 20:30

Post by PJayTycy »

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.
On holiday from 16/07 till 31/07
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus »

I think you did understand it, Pjaytycy. If other people feel the same way we can ZIP them up and keep them somewere safe.
User avatar
ucho
Engineer
Engineer
Posts: 42
Joined: 05 May 2004 19:36
Location: 3city

Post by ucho »

I still dont get it - who needs DX support in game anyway? :D
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 .
User avatar
DominionSpy
Tycoon
Tycoon
Posts: 1429
Joined: 03 Oct 2003 23:59
Location: Lancashire, UK
Contact:

Post by DominionSpy »

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.
Image
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.
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

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:
  • 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)
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.
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
fujitsu
Engineer
Engineer
Posts: 32
Joined: 12 Jul 2005 08:14
Location: Melbourne suburbs, Victoria, Australia (GMT+10)

Post by fujitsu »

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.
Yes, exactly. However, considering that many people are not using Windows here, SDL+OpenGL should probably come first.
... 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)
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: 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.
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.

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.
Talroth
Engineer
Engineer
Posts: 44
Joined: 01 Jun 2003 01:54

Post by Talroth »

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, :twisted:


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.
fujitsu
Engineer
Engineer
Posts: 32
Joined: 12 Jul 2005 08:14
Location: Melbourne suburbs, Victoria, Australia (GMT+10)

Post by fujitsu »

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, :twisted:


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.
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?

Encapsulation is a Good Thing, and should be used to enable easy dropping in of DirectX/OpenGL/whatever modules.

William.
User avatar
charlieg
Transport Coordinator
Transport Coordinator
Posts: 323
Joined: 08 Oct 2003 14:07
Contact:

Post by charlieg »

fujitsu wrote:Yep, exactly. Of course, we should all use DirectX because the vast majority of the gaming community uses Windows...
(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?

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
benji147460127
Engineer
Engineer
Posts: 21
Joined: 03 Sep 2003 14:03
Skype: benjamingoodger
Location: Hertfordshire, UK

Post by benji147460127 »

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.
~Ben

Microsoft Visual Bios (C) 1984
Where will Bill have you dragged today?
Press CTRL-ALT-F1-END-ESC-INS for Visual Cmos setup.
Locked

Return to “Transport Empire Development Archive”

Who is online

Users browsing this forum: No registered users and 3 guests