Thread: [Super-tux-devel] SuperTux
Brought to you by:
wkendrick
Menu
▾
▴
super-tux-devel
|
From: <Pre...@ao...> - 2004-07-23 00:48:30
|
Hello, I just finished playing Milestone1 of SuperTux and I must say this game is great! I had tons of fun playing it. Please email me as soon as Milestone2 comes out so I can download it. Keep up the good work! |
|
From: Luke-Jr <lu...@da...> - 2005-03-28 16:23:53
|
Just noticed that plans are to be OpenGL-only in the future... Is there really a good reason for this? I have seen a few systems in which OpenGL mode is too slow to be playable, but software rendering is very good and smooth... |
|
From: S.Groundwater <sl...@gl...> - 2005-03-29 01:03:49
|
> Just noticed that plans are to be OpenGL-only in the future... Is there > really > a good reason for this? I have seen a few systems in which OpenGL mode is > too > slow to be playable, but software rendering is very good and smooth... I'm not writing the code for the game so I'm not sure about the OpenGL only stuff, But... Open GL seems like good stuff, if a box can't run Open GL why play graphic intensive games on it? I hear people say "Linux ain't got game". Open GL helps make games look creamy on the eyes, it gives us game. Then again, when my box can't cut it, I just go old school with the games I play: http://www.mame.net/downmisc.html Makes no difference to me, as long as it looks good and is fun to play.... :o |
|
From: Ingo R. <gr...@gm...> - 2005-03-29 02:09:37
|
Luke-Jr <lu...@da...> writes: > Just noticed that plans are to be OpenGL-only in the future... Is > there really a good reason for this? Yes, it allows us to do a whole bunch of effects that would be insanly slow without the use of hardware acceleration and thus OpenGL. Some of the possible effects can be seen at (SuperTux would of course not use all of them and/or different ones): * http://windstille.berlios.de/screenshots.html > I have seen a few systems in which OpenGL mode is too slow to be > playable, but software rendering is very good and smooth... Then either install the right drivers for your graphics card (both ATI and NVidia provide drivers OpenGL support), buy a new graphic card (50EUR Geforcefx card will do) or dual boot into a OS that has support for your graphics card (some laptop users might need to do that). Graphics card with reasonably good OpenGL support for SuperTux have been around for more then half a decade, there is really no good reason to not make use of them today. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Matze B. <ma...@br...> - 2005-03-29 15:48:19
|
On Mon, 28 Mar 2005, Luke-Jr wrote:
> Just noticed that plans are to be OpenGL-only in the future... Is there really
> a good reason for this? I have seen a few systems in which OpenGL mode is too
> slow to be playable, but software rendering is very good and smooth...
These slow systems have messed up their drivers and are using software
emulated opengl. But it should be possible in nearly all cases to fix
that.
As for game developers opengl has lots of advantages:
- Hardware acceleration for lots of things, so that you are several
magnitudes faster compared to software mode
- There are lots of nice effects possible that would just be too slow in
software mode. (advanced lighting, blending, rotating or even pixelshaders
which allow to run pixel based "filters" in realtime)
For supertux I can think of several nice effects:
- Add a bit of lighting to touch up the repetitive
background/tiles
- Having a sun with sunrays blending into the game
- Letting the screen "float" when swimming in water
- Fade out foreground layer when tux is hidden by these tiles
(when you find secrets...)
And despite of this opengl has not only technical advantages but also
makes life alot easier for coders:
- It has a nice clean and easy to use API
- The API does more things for you (storing a transformation stack,
automatic rotation, scaling)
In anyway what I don't like as a coder is maintaining our current wrapper
that supports opengl and software mode... I'd rather spend my time in
other parts of the game.
(However from a deployment point of view we can be sure to lock out some
of our userbase by going opengl only. Esp. on more exotic systems that
have no proper opengl support yet, or for people with really old hardware
- though for these people the game is unplayably slow anyway I guess...)
So we probably need some "market research" here to determine how many
people would really need software mode :) Is anyone here on the list who
would really need software mode and could explain why?
I know of ~20 people personally who play supertux and they all have
hardware that is able to handle opengl easily. (18 people on win32, 2 on
linux - worst of these systems is a 900Mhz Athlon with geforce 2 mx card).
Greetings,
Matze
|
|
From: Nathan <nat...@gm...> - 2005-03-29 17:31:17
|
I run supertux in OpenGl mode running on PIV 2.66 GHz, 512 RAM, nVidia Geforce 440 MX, linux 2.6 On Tue, 29 Mar 2005 17:48:02 +0200 (CEST), Matze Braun <ma...@br...> wrote: > So we probably need some "market research" here to determine how many > people would really need software mode :) Is anyone here on the list who > would really need software mode and could explain why? -- Who is not using the Fox Of Fire is not surfing the web, he is suffering it I'm currently using 15 MB (2%) of my 1000 MB. |
|
From: Ingo R. <gr...@gm...> - 2005-03-29 19:30:33
|
Matze Braun <ma...@br...> writes: > However from a deployment point of view we can be sure to lock out > some of our userbase by going opengl only. Esp. on more exotic > systems that have no proper opengl support yet, or for people with > really old hardware - though for these people the game is unplayably > slow anyway I guess...) Old hardware (<<1Ghz) won't work anyway in software, so thats out of the race. Most likly candidate for non-OpenGL machines are laptops with unsupported graphic chipsets, those however should have a few CPU cycles to spare in most cases, something to try out on them: open Window in 320x240, set glScaled(0.4, 0.4, 0.4), cross fingers that Mesa will be fast enough in that resolution. And there is already always the fallback of dual-booting, most laptop users will either have a Windows or MacOSX partition to boot into as alternative. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Christopher A. W. <cw...@du...> - 2005-03-29 23:34:53
|
Ingo Ruhnke <gr...@gm...> writes: > Old hardware (<<1Ghz) won't work anyway in software, so thats out of > the race. Most likly candidate for non-OpenGL machines are laptops > with unsupported graphic chipsets, those however should have a few CPU > cycles to spare in most cases, something to try out on them: 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. I loathed games with opengl-only support. However, shortly before getting my laptop (which is not my primary computer) my friend did give me an NVidia card which worked well with OpenGL. 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? Or is the real problem that this would prevent us, or slow us down, from adding new features to SuperTux? I could see how some gameplay elements might work right only with OpenGL.. perhaps like implementing the "sliding down the slope" Tux (which, when fying through the air, would probably have to rotate on a curve to look nice, right?).. Though I would prefer to see an option to keep an option to go without OpenGL support, if it holds back development, I can understand it being cut out. Christopher Allan Webber |
|
From: Ingo R. <gr...@gm...> - 2005-03-30 00:18:08
|
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. > 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. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Christopher A. W. <cw...@du...> - 2005-03-30 03:08:30
|
Ingo Ruhnke <gr...@gm...> writes: >> 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. Fair enough.. you've convinced me. |
|
From: Dennis W. <den...@vu...> - 2005-03-30 09:33:07
|
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 |
|
From: Ingo R. <gr...@gm...> - 2005-03-31 15:48:37
|
Dennis Wagelaar <den...@vu...> writes: > 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). If they can't affort 50EURs for a brand new card they should go with a used one. A used Geforce2MX or RivaTNT2 will probally sell for 5-10EUR or even less. Beside from that old hardware won't be able to run Supertux in software anyway, 800x600 in software consumes a hect of a lot CPU power, so going OpenGL only might actually LOWER the entrance barrier, since you need much less CPU and just a very cheap gfx card. > 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. SuperTux doesn't scale. Just because you can get something to compile, doesn't mean that its of any use. The controlls can be extremly tricky with most handhelds, RAM constrains may make actually running it impossible and last not least a jump'n run at 10fps or less is simply no fun. If you want SuperTux for handelds, you should write a SuperTux specifically for handhelds, take the gfx scale them down to suit 320x240 or something like that, kick out all those FX and probally replace some probally bloaty OOP code with some little hacks where needed. Since you can reuse levels, code and stuff as needed it should actually be not that difficult to start such a project. But it really needs to be a seperate thing, if you try to satisfy both at the same time, you will end up with something that doesn't look good on either them. > That gives you an edge over the mainstream games industry. No, really not. The mainstream game industry knows what they are doing, if they want game X on handheld Y, they port it, by restructuring the game to suit whatever is available, turning a 3D game into a 2D one and stuff like that is actually quite common (SplinterCell, TonyHawks). If you just take a game designed for PC and brute-force compile it for a completly different architecture you won't get something with which players will be much happy. > Then there's the gameplay issue: I thought only the physics system > determines the gameplay? The rendering is just the visual feedback. Um, well, graphic is of course visual feedback, but how to you expect the player to react to something which he can't see (sprite rotation not implement -> no sprite)? Go play some Yoshi's Island (1995, SNES) to see what kind of effects we are talking about and yep, even that game already used '3d acceleration' back than in form of the SFX2 chip. You will quickly find out that a lot of those effects are simply not doable in software in a useable fasion. > 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. Aehm, that is quite trivial. Scaling physics down to another CO is trivial and extremly cheap compared to the amount of work that the CPU needs to spend on GFX when OpenGL is not involved. > I hope you will reconsider your plans and keep the architecture of > SuperTux open. Nope. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: noah b. <noa...@gm...> - 2005-03-30 17:34:42
|
Opengl IS really slow if one does not have an accelerated graphics card... On Mon, 28 Mar 2005 10:23:23 -0600, Luke-Jr <lu...@da...> wrote: > Just noticed that plans are to be OpenGL-only in the future... Is there really > a good reason for this? I have seen a few systems in which OpenGL mode is too > slow to be playable, but software rendering is very good and smooth... > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Super-tux-devel mailing list > Sup...@li... > https://lists.sourceforge.net/lists/listinfo/super-tux-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X