Re: [Super-tux-devel] SuperTux

[Dennis W. <den...@vu...>]

On Wednesday 30 March 2005 02:17, Ingo Ruhnke wrote:
> Christopher Allan Webber <cw...@du...> writes:
> > I dunno.. I used to have an ATI Rage 128 card in my old 600 mhz
> > computer, and it could run games just fine as long as they did not
> > use opengl.
>
> ATI Rage128 already was almost unusable for gaming as it was released
> (win32 drivers extremly buggy and never fixed). And as said, a brand
> *new* pixel-shader capable card cost 50EUR. Something used on ebay
> will probally sell for quite a bit less. So for desktop users there is
> a simple solution, if you want to play games, buy hardware that is
> capable of running them.

Hmm, that doesn't sound so right.. Whereas I agree that it's a shame *not* to 
use all that great hardware that most of us have anyway, I don't see why 
poorer people have to be locked out (yes, there are people with old hardware 
who *don't* have 50 euros to spare). Also, a brand new graphics card only 
works properly in a relatively new pc, so one may not get there with one 
upgrade only.

Also, it's a pity that handheld devices are ignored.. It would be great to 
have a game that scales over such a wide variety of computing hardware as 
SuperTux 0.1.2 does. That gives you an edge over the mainstream games 
industry.

That said, I also agree that supporting all these platforms requires extra 
maintenance. There are some programming techniques you can use to reduce this 
maintenance and keep the architecture open for adding new platform support. 
More on this below...

>
> > My laptop works well enough with OpenGL.  Still, I have to
> > wonder... how much extra coding effort would it take to make effects
> > which are OpenGL only (like the sunbeams on water... which doesn't
> > seem really necessary, but would look nice) just not display with
> > OpenGL disabled?
>
> A lot, since you would need to scatter the code with #ifdef's write
> additional wrapper mechanics and basically have to think at least
> twice for every graphic thing you write (will it work in software?
> will it be fast enough? will it make any sense gameplaywise?). This
> whole discussion already is slowing us down and there will likly be
> more and more of that as soon as there are gameplay relevant effects
> that don't work in software. If we go OpenGL only it will simply be
> 'end-of-discussion' and no more time wasted.

#ifdefs are only necessary if you want to avoid C++, i.e. use only C and 
macros. In C++ it is possible to use the Strategy design pattern to program 
all code against an abstract rendering class. Then you can make two concrete 
classes that implement the rendering for either SDL or OpenGL. Only one 
#ifdef is needed to enable/disable the entire OpenGL class (all OpenGL code 
is localised to this class).

Now you can separately maintain SDL and OpenGL code. The only problem left is 
who's going to maintain the SDL counterpart of the OpenGL-based functions. 
Perhaps you can go for an abstract rendering class and an OpenGL 
implementation only, so that if someone feels urged to implement the SDL 
counterpart, they can go ahead.

Another option is to just go ahead and use the OpenGL API directly, like you 
planned. Then it might be possible to add glue code later for translating 
OpenGL functions to SDL functions. It may be hard, however, to figure out 
which OpenGL functions will need to be ported/stubbed, since these functions 
will be called from all over the code. #ifdefs will also become necessary to 
select the correct OpenGL library to compile against.

Then there's the gameplay issue: I thought only the physics system determines 
the gameplay? The rendering is just the visual feedback. The only problem 
with the physics system is that the coordinate system is currently aligned to 
the physical amount of pixels used in the game (e.g. 800x600). Since 
coordinate scaling by a software rendering engine is not feasible (too many 
in-game calculations), it might be an idea to create a lookup table for all 
the physics constants used in the game. The level loader can also be adapted 
to convert the standard coordinates to whatever is physically available. 
These are all load-time calculations and shouldn't impair gameplay.

Finally there's the issue of using floating point, but I won't give you a 
headache over *that* ;-). Suffice to say that it's a *terrible* job to 
convert code from floating point to fixed point, but I'm willing to do it, 
providing that SuperTux will run on lower screen resolutions as well.

I hope you will reconsider your plans and keep the architecture of SuperTux 
open.
--
Cheers,
Dennis