super-tux-devel — Development mailing list for Super Tux

Re: [Super-tux-devel] Announcing meeting on LGT?

[Ingo R. <gr...@gm...>]

Christopher Allan Webber <cw...@du...> writes:

> Just a quick thought... would it perhaps be a wise idea to announce
> our meeting this Saturday on the Linux Game Tome?

I wrote a little post to the forums about it.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] SuperTux Resolution

[Ingo R. <gr...@gm...>]

John-Michael Mulesa <mac...@sb...> writes:

> I didn't use to mind, but I recently got an LCD and I'd like to play
> SuperTux in my native resolution (1280x1024) Could you implement
> this in the next version?

Yep, we'll add that, should be pretty trivial todo with OpenGL, just
some different parameters when setting the initial matrix.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] Re: [Super-tux-commit] supertux/data/images supertux.xpm,1.3,1.4 SuperTux.xpm,1.1,NONE

[Ryan F. <rf...@gm...>]

On Thu, 31 Mar 2005 18:15:36 +0200, Marek M. <wa...@gm...> wrote:
> Ryan Flegel wrote:
> 
> >Update of /cvsroot/super-tux/supertux/data/images
> >In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6813
> >
> >Added Files:
> >       supertux.xpm
> >Removed Files:
> >       SuperTux.xpm
> >Log Message:
> >Fixed case on file. Please try to keep things lowercase.. remember that most
> >operating systems are case sensitive.
> >
> >
> >
> I changed it to contain uppercase characters because on my system,
> SuperTux crashed because it couldn't find the file when it was all
> lowercase. The savegame folder in the home directory also needs to
> contain uppercase characters, not sure why.

Interesting.. my supertux crashed because it was looking for
"supertux.xpm" not "SuperTux.xpm". I guess we should look further into
the problem :) I think we should keep all files lowercase, though,
since it is consistent and should prevent errors like this from
happening. It's probably something in the source, but I'm at work
right now so I can't take a look. I'll try to remember for when I get
home.

-- 
Ryan

[Super-tux-devel] Re: [Super-tux-commit] supertux/data/images supertux.xpm,1.3,1.4 SuperTux.xpm,1.1,NONE

[Marek M. <wa...@gm...>]

Ryan Flegel wrote:

>Update of /cvsroot/super-tux/supertux/data/images
>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6813
>
>Added Files:
>	supertux.xpm 
>Removed Files:
>	SuperTux.xpm 
>Log Message:
>Fixed case on file. Please try to keep things lowercase.. remember that most
>operating systems are case sensitive.
>
>  
>
I changed it to contain uppercase characters because on my system, 
SuperTux crashed because it couldn't find the file when it was all 
lowercase. The savegame folder in the home directory also needs to 
contain uppercase characters, not sure why.

    Marek

Re: [Super-tux-devel] SuperTux

[Ingo R. <gr...@gm...>]

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

Re: [Super-tux-devel] missing objects

[Matze B. <ma...@br...>]

Am Donnerstag, den 31.03.2005, 09:45 -0500 schrieb S.Groundwater:
> hello.
> 
> Just curious, is anyone working on or does anyone have the proper files to
> fix?
> 
> No factory for object 'fish' found.
> No factory for object 'stalactite' found.
> No factory for object 'stalactite' found.
> No factory for object 'laptop' found.
> No factory for object 'trampoline' found.

Well fish, stlactite and trampoline haven't been fixed after the big
collision detection rewrites.
Laptop is the old name of MrIceBlock you should better fix the level in
this case.

Greetings,
	Matze

[Super-tux-devel] missing objects

[S.Groundwater <sl...@gl...>]

hello.

Just curious, is anyone working on or does anyone have the proper files to
fix?

No factory for object 'fish' found.
No factory for object 'stalactite' found.
No factory for object 'stalactite' found.
No factory for object 'laptop' found.
No factory for object 'trampoline' found.

Big Thanks

[Super-tux-devel] Re: [Super-tux-commit] supertux/data/images supertux.xpm,1.3,1.4 SuperTux.xpm,1.1,NONE

[Ricardo C. <ri...@ae...>]

 Lol.
 Some filesystems do not support case sensitive filenames, but that doesn't=
=20
have anything to do with the files content. A XPM file is a plain ASCII tex=
t=20
file, a-z have different codes from A-Z.
 Seriously, what was the problem?

Cheers,
 Ricardo

Em Quinta, 31 de Mar=E7o de 2005 00:30, o Ryan Flegel escreveu:
> Update of /cvsroot/super-tux/supertux/data/images
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6813
>
> Added Files:
> 	supertux.xpm
> Removed Files:
> 	SuperTux.xpm
> Log Message:
> Fixed case on file. Please try to keep things lowercase.. remember that
> most operating systems are case sensitive.
>
>
> --- NEW FILE: supertux.xpm ---
> /* XPM */
> static char * supertux_xpm[] =3D {
> "32 32 65 1",
> " 	c None",
> ".	c #020400",
> "+	c #10120F",
> "@	c #1E1D02",
> "#	c #1A1B19",
> "$	c #262827",
> "%	c #333534",
> "&	c #413517",
> "*	c #3C342A",
> "=3D	c #424341",
> "-	c #514714",
> ";	c #52492B",
> ">	c #444A4F",
> ",	c #3D4D60",
> "'	c #51524F",
> ")	c #5C5E5B",
> "!	c #5A646F",
> "~	c #696648",
> "{	c #7A6A1D",
> "]	c #55708B",
> "^	c #8E6635",
> "/	c #7D7232",
> "(	c #70716E",
> "_	c #597E9E",
> ":	c #978123",
> "<	c #908234",
> "[	c #6D8297",
> "}	c #A3783C",
> "|	c #838481",
> "1	c #9C8E14",
> "2	c #9A9072",
> "3	c #BF8940",
> "4	c #939490",
> "5	c #A79D3A",
> "6	c #929799",
> "7	c #84A2BB",
> "8	c #72A6DC",
> "9	c #AC9B7E",
> "0	c #6BA7F2",
> "a	c #BFA525",
> "b	c #6DB1F1",
> "c	c #B9A960",
> "d	c #A7A7A1",
> "e	c #8AB7E1",
> "f	c #A1BBA6",
> "g	c #88BBF1",
> "h	c #DFB23E",
> "i	c #9EB9CE",
> "j	c #D3C30E",
> "k	c #CEBE46",
> "l	c #B3C396",
> "m	c #DAC437",
> "n	c #C2C985",
> "o	c #C0C2BF",
> "p	c #A2CBF4",
> "q	c #ECCB2C",
> "r	c #E5DA1D",
> "s	c #CDCDB4",
> "t	c #B7D4ED",
> "u	c #D0D2CF",
> "v	c #D3DAE1",
> "w	c #C7E2F7",
> "x	c #DFE1DD",
> "y	c #EAECE9",
> "z	c #FAFCF9",
> "                                ",
> "               gg               ",
> "              gppg              ",
> "             eppeeg             ",
> "            e7[!,]_8            ",
> "           ])'=3D%#..$,           ",
> "          [>)'=3D$+++.._          ",
> "         7!''=3D%#%|6!.,8         ",
> "        p!>)>=3D$$>v|.+#78        ",
> "       pi%=3D''=3D%#'u..&:knlf      ",
> "      pw7$=3D>=3D>%##'%:amqqqmmm    ",
> "     ptt]#%=3D%%$...+^3hhqhhhk    ",
> "    twt7%#%%$.#....*^}}9di7g    ",
> "   pwwt,#%=3D%$.......#*'ebbbb0   ",
> "  twwt6$$>%$#......=3D|d67ggbgb0  ",
> " twww7,%=3D=3D=3D%#.....$4vzzxegbbbb0 ",
> " pwww[$=3D>=3D=3D$#..+#=3D|xzzzzvebbbb0 ",
> "  twv>%=3D'=3D%$...$'4uyzzzzzi8bb0  ",
> "   pt,%'>=3D%#...#>|vyzzzzziei8   ",
> "   ps~%''%$######$(yzzzzzunrk   ",
> "    ch/''=3D$###$$$##6yzzzzsmj1   ",
> "    cam^'%%##.#)!)=3D6vyzzzdk:    ",
> "     <ah/=3D%$#..(oooovxyyx2<     ",
> "     ;/am^=3D%$..!douvouvvu2      ",
> "    .#;<am<%#..$6vuuvuuu2       ",
> "    .+$-:qr{-@..$(ddd4d4        ",
> "     ..#-:ajjm1...##$*;         ",
> "         {{:11<[]]'&-{          ",
> "             gppppg             ",
> "              gppg              ",
> "               gg               ",
> "                                "};
>
> --- SuperTux.xpm DELETED ---
>
=2D-=20
Tomorrow, you can be anywhere.

[Super-tux-devel] Announcing meeting on LGT?

[Christopher A. W. <cw...@du...>]

Just a quick thought... would it perhaps be a wise idea to announce
our meeting this Saturday on the Linux Game Tome?

[Super-tux-devel] SuperTux Resolution

[John-Michael M. <mac...@sb...>]

Hi, I have a question about resolution in SuperTux. Currently it's only 
640x480 and there is no way to change it (that I know of.) I've heard 
CVS improves this, but from what I've heard, it only changes it to 
800x600 and still doesn't give you an option of changing this. I didn't 
use to mind, but I recently got an LCD and I'd like to play SuperTux in 
my native resolution (1280x1024) Could you implement this in the next 
version?

Thanks,
John-Michael

Re: [Super-tux-devel] SuperTux

[noah b. <noa...@gm...>]

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
>

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

[Super-tux-devel] Back in Action

[Marek <wa...@gm...>]

Hi Guys!
Just wanted to say that I'm glad to see you all back in action. I came 
home from the "Breakpoint 2005" demoscene party yesterday; I thought I 
had a little time to work on SuperTux there, but I realized that this 
was a foolish idea. :-) Anyway, today I'll be on the way to enjoy some 
free days at my parents' home which I dedicated to doing some work on 
SuperTux.
See you then!
    Marek

Re: [Super-tux-devel] SuperTux

[Christopher A. W. <cw...@du...>]

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.

Re: [Super-tux-devel] SuperTux

[Ingo R. <gr...@gm...>]

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

Re: [Super-tux-devel] Graphical Software and Tutorials

[S.Groundwater <sl...@gl...>]

>> If you wanna help with graphics you should learn how to draw,

.. oh yeah, that helps too :)

Speaking of graphics Grumbel, the new walking tree drawing in wiki is very
nice.

I could see a Tux butt jump breaking that thing down into a bunch of mean
logs, or maybe you have to throw things at it to bust it up.  Like throw a
rock, one section pops out, then you bust a jump on the carzy log. It
would be cool to see this with the walking totem idea as well.

I've been thinking of a big (non-movable) tree that drops badguys, like
fruit or nuts with attitude.

For moving platforms, I've been thinking a waterfall/river that you work
your way up, vertical path, maybe with the rolling log idea thrown in.
Frogger-ish gameplay maybe.

But for now I'm working on a mysterious reset point animation idea and
Mr.SnowSnail, the flip & kick hooligan that has been seen recently with
those ice block guys.

Re: [Super-tux-devel] SuperTux

[Christopher A. W. <cw...@du...>]

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

Re: [Super-tux-devel] Graphical Software and Tutorials

[Ingo R. <gr...@gm...>]

Nabil Stendardo <nab...@bl...> writes:

> I would like to help the development of such a good game, and for
> that I would like to know which software you use for the graphics.
> Can you also write tutorials about techniques you use to make them.

If you wanna help with graphics you should learn how to draw, the
graphic package really doesn't matter much at all for that, good old
pen&paper will be far better. Some books to recomment would be:

The New Drawing on the Right Side of the Brain, Betty Edwards
The Animator's Survival Kit, Richard Williams

Some tutorials found on the net might help too.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] SuperTux

[Ingo R. <gr...@gm...>]

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

Re: [Super-tux-devel] SuperTux

[Nathan <nat...@gm...>]

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.

Re: [Super-tux-devel] SuperTux

[Matze B. <ma...@br...>]

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

Re: [Super-tux-devel] SuperTux

[Ingo R. <gr...@gm...>]

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

[Super-tux-devel] Super Tux

[Andrew <sor...@po...>]

Hello
I am a super tux fan and I heard of the up coming milestone and I have an 
idea. 

You know when super tux turns red he can shot things well I thought it'd be 
good if he could turn other coluors after he turned red and shot differant 
things.

Andrew.

Re: [Super-tux-devel] SuperTux

[S.Groundwater <sl...@gl...>]

> 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

Re: [Super-tux-devel] Graphical Software and Tutorials

[S.Groundwater <sl...@gl...>]

> Hi, I'm new here.
> I would like to help the development of such a good game, and for that I
> would like to know which software you use for the graphics. Can you also
> write tutorials about techniques you use to make them.
> Thanks in advance.
> Nabil Stendardo

My favorite software packages are: Gimp, Sodipodi, Inkscape and Blender
These are all high quality Free/Open Source applications.
Linux makes possible GREAT graphic workstations these days.

My suggestion if you want to make graphics for SuperTux is to read the
wiki, - to get an idea of what is needed.

http://netpanzer.berlios.de/supertux/

There is a good graphic tutorial by Grumble in the wiki. Also, get a CVS
copy of the game and look through everything so you are familiar with how
things work.

I got started by creating graphics I thought would look good in the game,
then I uploaded them to my website and posted a links back to this mailing
list.  If the developers like your work, and you agree to have it included
in a GPL package, then they may put it in the game for you.  If the
developer like your work enough, then they may make you a developer as
well.

It's pretty easy and the people around here are a good bunch, so welcome
to the list.

- Go Tux