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

Re: [Super-tux-devel] Release Schedule/Milestones/GotM

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

Tobias Gl=E4=DFer <tob...@gm...> writes:

> Hey, backscrolling _is_ already possible. ./supertux --debug-mode.

The question is not so much if backscrolling is possible, but more if
we want or need it. With vertical scrolling its a must have, but with
just horizontal scrolling its not really important and doesn't provide
much advantages.

> Well, there is much place for funky stuff and I rewrote much
> SuperTux so that adding them isn't that hard.

Yep, but funky stuff should be keep to a minimum, I would prefer to
get 0.1.0 fastly done and then move on, instead of simply adding lots
of stuff to the old codebase, that might later turn out to be useless.

>>  * create a little credits-screen/extro or something like that
> Dunno, if that's needed.

To make it short, its a must have. It doesn't has to be groundbreaking
or anything, but simply poping back to the start menu or something
like that after the last level looks just so damn broken.

>>  * time-frame for this should relativly short, something around one
>>    month, see also the discussion about "Game of the Month" at
>>    happypenguin[3]
>
> I don't think SuperTux is a good candidate for such a title atm.
> Wait until 0.1. I'm trying to make short cycled releases after 0.0.6.

I wouldn't do any official releases at all once SuperTux reached a
'useable' state (be that 0.0.6 or 0.0.7 or whatever). My suggestion
would be something like:

0.0.6 - fixup to get back to the state before the huge cleanup
0.0.x - more fixup, feature freeze, so that levels don't break due to
    newly added feature, at this point given a good ToDo it could
    become "Game of the Month"

[no releases for a while, but instead working on the content (levels,
gfx, etc)]

0.1.0 - release a fully playable SuperTux with something like 10
        levels or so, static-binary, etc.
0.1.1 - bugfixes for 0.1.0 only

0.2.x - changing the engine to handle features listed in the current
    Todo, break compability with 0.1.0 levels, basically creating a
    pretty different game.

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

Re: [Super-tux-devel] Release Schedule/Milestones/GotM

[Tobias <tob...@gm...>]

Hi all,

that's mostly the same as I planed and told you already. ;)

Am Mi, den 11.02.2004 schrieb Ingo Ruhnke um 07:35:
> Hi,
> 
> as it is today, SuperTux provides a more or less working MarioBros1
> style engine, but lacks levels, a readable font, graphics and other
> stuff like that.

That's the big problem and I hope to receive a bit more stuff _after_
the 0.0.6 release.

>  The current Todo[1] is very much focused on the far
> furture, basically going into a YoshiIsland/MarioBros3 direction,
> which would mean a huge change for the engine (backscrolling, vertical
> scrolling, different shaped tiles, an "Oberwelt"[2]). While that is

Hey, backscrolling _is_ already possible. ./supertux --debug-mode. ;)
Bill Kendrick has prepared the "Oberwelt" idea, so this is in the spirit
of SuperTux and therefore a must! :)

> good and fine to focus a bit on the far future, I would consider it a
> bit of a waste to simply throw the current working engine away. So my
> suggestion is that we:

Yep.

>  * fix up the current engine back into a usable state, ie. MarioBros1
>    like, no back-scrolling or other funky stuff that could get too
>    complicated

Well, there is much place for funky stuff and I rewrote much SuperTux so
that adding them isn't that hard.

>  * create new graphics or update the current ones where doable

Yep.

>  * create a handfull of levels and connect them to a playable game

Yep.

>  * create a little credits-screen/extro or something like that

Dunno, if that's needed.

>  * time-frame for this should relativly short, something around one
>    month, see also the discussion about "Game of the Month" at
>    happypenguin[3]

I don't think SuperTux is a good candidate for such a title atm.
Wait until 0.1. I'm trying to make short cycled releases after 0.0.6.

Greetz...

Tobias Gläßer
-- 

[Super-tux-devel] Release Schedule/Milestones/GotM

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

Hi,

as it is today, SuperTux provides a more or less working MarioBros1
style engine, but lacks levels, a readable font, graphics and other
stuff like that. The current Todo[1] is very much focused on the far
furture, basically going into a YoshiIsland/MarioBros3 direction,
which would mean a huge change for the engine (backscrolling, vertical
scrolling, different shaped tiles, an "Oberwelt"[2]). While that is
good and fine to focus a bit on the far future, I would consider it a
bit of a waste to simply throw the current working engine away. So my
suggestion is that we:

 * fix up the current engine back into a usable state, ie. MarioBros1
   like, no back-scrolling or other funky stuff that could get too
   complicated

 * create new graphics or update the current ones where doable

 * create a handfull of levels and connect them to a playable game

 * create a little credits-screen/extro or something like that

 * time-frame for this should relativly short, something around one
   month, see also the discussion about "Game of the Month" at
   happypenguin[3]

[1] http://super-tux.sourceforge.net/development/index.html
[2] The part of the game that are not the levels, but which connects
    them, also known as levelmap, not sure if there is a correct english
    term for it.
[3] http://www.happypenguin.org/forums/viewtopic.php?t=1156
-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] SuperTux IRC Meeting (don't miss)

[Bill K. <nb...@so...>]

On Sun, Feb 08, 2004 at 12:56:45PM -0500, Tobias Gl=E4=DFer wrote:
> Heyho,
>=20
> the meeting is over and here is the chatlog.

D'oh!  Sorry I missed it!  I slept in, went out of town to buy computer
parts, and have been putting together a PC for my dad.  Totally forgot IR=
C
meeting!!! :(

(Next time, I'll be sure to put an alarm in my Zaurus ;) )

-bill!
bi...@ne...           "Hey Shatner, ya remember that episod=
e of
http://newbreedsoftware.com/bill/   Space Trek where your show got cancel=
led?"

Re: [Super-tux-devel] SuperTux IRC Meeting (don't miss)

[Tobias <tob...@gm...>]

Heyho,

the meeting is over and here is the chatlog.

Greetz...

Tobias Gläßer

[Super-tux-devel] Re: CVS status update

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

 I forgot to mention that I enjoyed the introduced paralax view :) That would 
be really awesome if it supported something like 3 images (2 of them alpha 
blending, of course) to do the parallax. (In the level editor patch, parallax 
is also introduced).

 After I changed from Alsa to OSS, the sound stop working, some SDL related 
with the driver, now it is working fine. Was it thanks to Duong-Khang 
NGUYEN's patch?

Congrats,
 Ricardo

-- 
All wars are civil wars, because all men are brothers ... Each one owes
infinitely more to the human race than to the particular country in
which he was born.
		-- Francois Fenelon

[Super-tux-devel] Re: Update to 0.0.6 release plan

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

Hi,
 The plan seems pretty good and I really think this should be a 0.1 version ;)

>  -fixing bugs
> New bugs have been introduced, which
> want to be fixed. .)

 First of all, FPS calculation or whatever is making gameplay different in 
different cpu speeds should be prioritory.

>  -improving documentation
> The new features want to be documented, I think.

 When you say documentation, do you mean for the user or developer? I think 
the user only needs to know how to install it and the keys to control it. A 
README is nice, but this is 0.0.6 :)
A developer's doc could be helpfull to tell in what files is what, since some 
filenames are not really that intuitive.
For artists, I have already added a Level editor section to the level editing 
file, and I think that's enough.

>  -more levels, graphics and musics
> We have a huge lack here. :(

 Well, the patch I have sent should make leveleditor ready for level edition. 
Maybe we could wait for levels, after this 0.0.6 release, since artists could 
then make use of the leveleditor...
About the graphics, sure it would be cool to have really good looking ones, 
but those are just enough. About the music... I don't even remember it, I 
allways put my own playing :)

>  -reorganize game_action() and game_draw() code in
>   a "object orientated" way. Won't be easy and will
>   end in creating enemy.c and enemy.h for example.

 I think the code is much better than it was... Hey, and there already is a 
badguy.c and badguy.h ...

>  -Leveleditor.
> Isn't complete. We need to think about a GUI for SuperTux. We could 
> take a look at picogui or we write the essential GUI components
> ourselves.

 The level format is very basic right now... In the future there can be a 
separation between background and playable tiles, but even then I don't see 
the need for a the use of a gui library.
 I was think in something like having a few buttons in the right (or another) 
side of the screen. There were the top level buttons that would be used for 
selecting background tiles, real tiles, bricks, badguys... And then there 
were the tiles or bricks or whatever with a picture of them. There would be a 
Plus button to scrolling, if needed.
The interface should also be of easy access with the keyboard.

Ricardo 

-- 
I argue very well.  Ask any of my remaining friends.  I can win an argument on
any topic, against any opponent.  People know this, and steer clear of me at
parties.  Often, as a sign of their great respect, they don't even invite me.
		-- Dave Barry

[Super-tux-devel] Patch with Leveleditor improvements

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

Hey there,

 I've finally managed to put all those level editor menus working.
 Now you can (using the menu):
- Add new levels (it will look for existing levels and add after the last. The 
level number is displayed in the screen);
- Load an existing level (in future, it will just display a list of existing 
levels);
- Test a level (press Esc to come back to the level editor);
- Edit level header settings and change stuff like the width (doing a realloc 
of the level). The menu code of this is huge! There are two ways to short it:
1. just make lesser options (aka hack)...
2. improve menu. The menu should have a funcs that would get the entries and 
would display them correctly and return the selected one... as i explained in 
a mail sometime ago.

 It also asks the user to Save, when a modification has been made, and the 
user wants to Exit, Load/Add another level or test the level.

This patch also modifies the following:
- gameloop now receives the level number and if the game is in test mode or 
not (for the level editor testing);
- leveleditor also receives the level number to edit as an argument (not sure 
if it is usefull, but...);
- now, the loadlevel() func doesn't exit if a level file could not be red or 
is corrupt. It just returns 1 or -1. Currently, all the calls of loadlevel() 
end with an exit(), but in the future we should just come back to the main 
menu;
- make use of atexit(), as someone already suggested here. atexit() will call 
st_shutdown when any exit() is called or the end of main is reached, so we 
don't have to care about quiting SDL and audio;
- Title.c had a duplication of the HighScore display code. This could be fixed 
by making the menu_change variable has NO, in the menu_init().

Cheers,
 Ricardo
(meet you at the meeting ;) )



-- 
All God's children are not beautiful.  Most of God's children are, in fact,
barely presentable.
		-- Fran Lebowitz, "Metropolitan Life"

Re: [Super-tux-devel] CVS status update

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

=20
Hey Tobias,=20
=20
Great work!=20
It's soo cool to see that OpenGL is finally working properly! :)=20
Though, in the level editor, when you press F9 (to show grid), the=20
grid is not drawn with the right color. I dunno why, it just uses=20
fillrect.=20
I red the SDL docs and was going to replace my hack in the menu and=20
make use of unicode, but it looks like you have made my homework ;)=20
=20
You say you have improved FPS, but the fact is that gameplay still=20
isn't working well, and I think it got worse... I had to change the=20
values, so i could play it, in my laptop...=20
And it is also not a good idea to print FPS to stdout cause it is=20
damn slow, use the display instead.=20
=20
Anyway, good work!=20
=20
Cheers,=20
 Ricardo=20
=20
=20
Citando Tobias Gl=E4=DFer <tob...@gm...>:=20
=20
> Hi all,=20
>=20
> I've made a big commit a few minutes ago.=20
> Everybody is invited to help fixing the FIXMEs and get=20
> SuperTux more stable. We are steering in the direction of=20
> new release. (This doesn't necessarly mean a release will be made=20
soon)=20
>=20
> Take a look into the ChangeLog, if you want to know the changes.=20
;)=20
>=20
> I'll put my most efforts in performance tuning and FPS balancing=20
from=20
> now on.=20
>=20
> Greetz...=20
>=20
> Tobias Gl=C3=A4=C3=9Fer=20
>=20
> --=20
>=20
> =20
_________________________________________________________
Acesso Gr=E1tis =E0 Internet do AEIOU:
Sem formul=E1rios, sem password, ligue-se j=E1!
http://acesso.aeiou.pt

Re: [Super-tux-devel] Update to 0.0.6 release plan

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

Tobias Gl=E4=DFer <tob...@gm...> writes:

> Release plan for 0.0.6:
>
>  -fixing bugs
> New bugs have been introduced, which
> want to be fixed. .)

Yep, might be good to at least get back to the playabilty before
reorganizing the beast.

>  -improving documentation
> The new features want to be documented, I think.

A bit docu can't be bad, especially docu on what should be done.
However documenting the currenty stage of the game itself shouldn't be
needed much at all, since lots of it might change in the future.

>  -load/save feature
> Very experimental.

I wouldn't care about it as this stage all that much, after all it
depends quite a bit on the whole structure of the game what needs to
be saved an what not (do we have just linear levels or a large
non-linear world, do we have an inventory, etc.). Beside that with
just one or two levels nobody will miss a save button.

>  -more levels, graphics and musics
> We have a huge lack here. :(

Would help to actually know in with direction the game will be heading
before such stuff could start comming in.

>  -reorganize game_action() and game_draw() code in
>   a "object orientated" way. Won't be easy and will
>   end in creating enemy.c and enemy.h for example.
> DONE / Fix bugs in it.
> Ok, to be honest, there is never a real end for a rewrite. :)

While at that just switch to C++, don't see much point in emulating OO
in C the hard way.

> !NEW
>  -OpenGL mode
> It's not that experimental anymore, but not complete at all.

Seems to work rather well so far, the real question is if OpenGL
should just be a nice add-on or if it should be the primiary rendering
target.

>  -Leveleditor.
> Isn't complete. We need to think about a GUI for SuperTux. We could=20
> take a look at picogui or we write the essential GUI components
> ourselves.

An already existing gui toolkit/library should be used, no need in
reinventing the wheel.

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

[Super-tux-devel] SuperTux IRC Meeting (don't miss)

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

Since, there were no objections, the meeting will be setted this=20
Saturday (7 Febrary) at 21:00 (GMT).=20
=20
The announcement:=20
http://happypenguin.org/forums/viewtopic.php?p=3D7430#7430=20
=20
Don't miss it! :)=20
=20
Ricardo Cruz=20
_________________________________________________________
Vem experimentar jogos gr=E1tis: http://freegames.online.pt

[Super-tux-devel] Update to 0.0.6 release plan

[Tobias <tob...@gm...>]

Hi all,

Release plan for 0.0.6:

 -fixing bugs
New bugs have been introduced, which
want to be fixed. .)
 -improving documentation
The new features want to be documented, I think.
 -load/save feature
Very experimental.
 -more levels, graphics and musics
We have a huge lack here. :(
 -reorganize game_action() and game_draw() code in
  a "object orientated" way. Won't be easy and will
  end in creating enemy.c and enemy.h for example.
DONE / Fix bugs in it.
Ok, to be honest, there is never a real end for a rewrite. :)

!NEW
 -OpenGL mode
It's not that experimental anymore, but not complete at all.
 Testing is required.
 -FPS issues.
Have to be fixed.
 -Leveleditor.
Isn't complete. We need to think about a GUI for SuperTux. We could 
take a look at picogui or we write the essential GUI components
ourselves.
 -Directory structure.
Not completed yet. Look into my previous mails about this issue for more
details.

This is a weird list which is supposed to give you an impression about
the current development status.

I appreciate every comment and further suggestions. :)

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] CVS status update

[Tobias <tob...@gm...>]

Am So, den 01.02.2004 schrieb Bill Kendrick um 18:47:
> On Sun, Feb 01, 2004 at 11:43:00PM -0500, Tobias Gläßer wrote:
> > Hi all,
> > 
> > I've made a big commit a few minutes ago.
> > Everybody is invited to help fixing the FIXMEs and get
> > SuperTux more stable. We are steering in the direction of
> > new release. (This doesn't necessarly mean a release will be made soon)
> 
> Thanks!  First time I've 'cvs update'd in a while.  Been busy and sick on
> and off. :(
> 
> BTW, I note this when I run make, however:
> 
> src/leveleditor.c: In function `leveleditor':
> src/leveleditor.c:461: parse error before `int'
> src/leveleditor.c:462: `cursor_tile' undeclared (first use in this function)
> src/leveleditor.c:462: (Each undeclared identifier is reported only once
> src/leveleditor.c:462: for each function it appears in.)
> src/leveleditor.c:465: warning: unreachable code at beginning of switch statement
> src/leveleditor.c: In function `showhelp':
> src/leveleditor.c:643: parse error before `int'
> src/leveleditor.c:644: `i' undeclared (first use in this function)
> make: *** [obj/leveleditor.o] Error 1
> 
> 
> Seems someone is using the non-C-syntax of...
> 
>   function ()
>   {
>     type var;
>     type var;
> 
>     some code;
>     some code;
> 
>     type var;   /*  YOU CANNOT DO THIS IN REGULAR C!!! */
> 
>     more code;
>   }
> 
> 
> All variable declarations need to be done at the top of the function
> (or, at least, at the beginning of a block, right after the "{", but before
> any statements)
> 
> I can look and fix, if you want me to...
> 
> 
> -bill

Thanks Bill. I'll fix it, thought my C compiler (gcc) doesn't worry
about those things. :)
Get well soon!

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] CVS status update

[Bill K. <nb...@so...>]

On Sun, Feb 01, 2004 at 11:43:00PM -0500, Tobias Gl=E4=DFer wrote:
> Hi all,
>=20
> I've made a big commit a few minutes ago.
> Everybody is invited to help fixing the FIXMEs and get
> SuperTux more stable. We are steering in the direction of
> new release. (This doesn't necessarly mean a release will be made soon)

Thanks!  First time I've 'cvs update'd in a while.  Been busy and sick on
and off. :(

BTW, I note this when I run make, however:

src/leveleditor.c: In function `leveleditor':
src/leveleditor.c:461: parse error before `int'
src/leveleditor.c:462: `cursor_tile' undeclared (first use in this functi=
on)
src/leveleditor.c:462: (Each undeclared identifier is reported only once
src/leveleditor.c:462: for each function it appears in.)
src/leveleditor.c:465: warning: unreachable code at beginning of switch s=
tatement
src/leveleditor.c: In function `showhelp':
src/leveleditor.c:643: parse error before `int'
src/leveleditor.c:644: `i' undeclared (first use in this function)
make: *** [obj/leveleditor.o] Error 1


Seems someone is using the non-C-syntax of...

  function ()
  {
    type var;
    type var;

    some code;
    some code;

    type var;   /*  YOU CANNOT DO THIS IN REGULAR C!!! */

    more code;
  }


All variable declarations need to be done at the top of the function
(or, at least, at the beginning of a block, right after the "{", but befo=
re
any statements)

I can look and fix, if you want me to...


-bill!

[Super-tux-devel] CVS status update

[Tobias <tob...@gm...>]

Hi all,

I've made a big commit a few minutes ago.
Everybody is invited to help fixing the FIXMEs and get
SuperTux more stable. We are steering in the direction of
new release. (This doesn't necessarly mean a release will be made soon)

Take a look into the ChangeLog, if you want to know the changes. ;)

I'll put my most efforts in performance tuning and FPS balancing from
now on.

Greetz...

Tobias Gläßer

-- 

[Super-tux-devel] Development Webpage

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

Hi,

I have started to create a development webpage for SuperTux, its
lookeded at:

http://super-tux.sourceforge.net/development/

Sourcecode for the webpage is in the CVS module 'htdocs'. 

The webpage is currently just a place for brainstorming, so nothing on
it should be taken as final. So far it contains a few actions and
enemies.

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

[Super-tux-devel] test

[Tobias <tob...@gm...>]

test mail for Ricardo. :)

Greetz...

Tobias Gläßer
-- 

[Super-tux-devel] CVS update coming soon

[Tobias <tob...@gm...>]

Hi all,

a big merge containing my recent work and the patches from
Ricardo and DK will be commited to CVS soon.

You can expect a cool new eyecandy feature. :)

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] FPS debug

[Tobias <tob...@gm...>]

Am Do, den 29.01.2004 schrieb Ricardo Cruz um 17:52:
> Hey,
>  The game is producing differences in the gameplay between machines that can 
> keep different FPS, it is even noticeable the difference in the gameplay 
> between the GL and SDL backends.
>  I hope this little patch can help in the debugging. Use the Q and S keys to 
> decrease the FPS (with the --debug-mode parameter).
> 
>  Anyway, I've already tried to hack in the source to make Tux movements to 
> obey to the differences in the FPS. The position of Tux is calculated by:
> 
> pplayer->base.x= pplayer->base.x+ pplayer->base.xm * frame_ratio;
> pplayer->base.y = pplayer->base.y + pplayer->base.ym * frame_ratio;
> 
> being x/y, the current position and xm/ym, the current velocity. frame_ratio 
> is the result of get_frame_ratio(&pplayer->base);
> 
>  This is fine, but the velocity calculation is made by:
> pplayer->base.xm = pplayer->base.xm + WALK_SPEED;
>  Shouldn't it be something like:
> pplayer->base.xm = pplayer->base.xm + WALK_SPEED * frame_ratio;
> ?

I've already fixed many of the FPS problems. Please stay tuned. ;)
The concept is fine, but it needs a lot of fine tuning to work perfectly
on different systems.

Your patch is a hack IMHO. ;)

> 
> Just wondering...
> Ricardo Cruz
-- 

[Super-tux-devel] FPS debug

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

Hey,
 The game is producing differences in the gameplay between machines that can 
keep different FPS, it is even noticeable the difference in the gameplay 
between the GL and SDL backends.
 I hope this little patch can help in the debugging. Use the Q and S keys to 
decrease the FPS (with the --debug-mode parameter).

 Anyway, I've already tried to hack in the source to make Tux movements to 
obey to the differences in the FPS. The position of Tux is calculated by:

pplayer->base.x= pplayer->base.x+ pplayer->base.xm * frame_ratio;
pplayer->base.y = pplayer->base.y + pplayer->base.ym * frame_ratio;

being x/y, the current position and xm/ym, the current velocity. frame_ratio 
is the result of get_frame_ratio(&pplayer->base);

 This is fine, but the velocity calculation is made by:
pplayer->base.xm = pplayer->base.xm + WALK_SPEED;
 Shouldn't it be something like:
pplayer->base.xm = pplayer->base.xm + WALK_SPEED * frame_ratio;
?

Just wondering...
Ricardo Cruz

-- 
The first sign of maturity is the discovery that the volume knob also turns to 
the left.

[Super-tux-devel] 1st SuperTux IRC meeting (delay)

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

Hey there,

 Sorry, but could the meeting be delayed to the Saturday after?
 If there are no objections, meet you in 5 February (Saturday) at 8:00 (GMT).
 I will publish the announcement in the Linux Game Tome forums.

See ya,
 Ricardo Cruz

-- 
If you live to the age of a hundred you have it made because very few
people die past the age of a hundred.
		-- George Burns

[Super-tux-devel] Menu handling input

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

Hey,

 I've made highscores to save also player's name by making menu to support 
input. The player's name dialog is a bit ugly, but i think it's acceptable... 
:)
 The goal of this patch is to make the level editor able to use the menu to 
ask the name of the level and others settings.

Ricardo Cruz

(hope the mail is received by the mailing list...)

-- 
To be intoxicated is to feel sophisticated but not be able to say it.

Re: [Super-tux-devel] today's CVS commit

[Chris S. <csp...@ca...>]

I have a dual proc Pentium Pro 180mhz with a complete piece of junk
video card and my other system is a Pentium 2 233mhz with a decent
NVidia video card 64MB video ram...

However most of the time I use my work notebook (P4-1.6Ghz, some Nvidia
64MB card) or my wifes notebook (P3-1Ghz, crappy integrated video card
with shared memory)

My daughter (who plays super tux because she thinks it's fun) is pretty
much stuck the the P2 though so I would be happy to test on that.

-Chris

On Tue, 2004-01-27 at 15:19, Bill Kendrick wrote:
> On Sat, Jan 24, 2004 at 03:44:11PM -0500, offipso wrote:
> > What! Did you just call that low-end? Oh my, I feel ancient.
> 
> My 'high-end' machine is a 300MHz Celeron, overclocked to 450MHz, with a
> Voodoo 3 2000 video card.
> 
> I think my wife's laptop is a little faster, but I don't think we ever looked
> into whether it could do accelerated 3D...
> 
> -bill!
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> 

Re: [Super-tux-devel] FPS

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

Duong-Khang NGUYEN <neo...@us...> writes:

> I think there's really no need to go beyond 25 FPS. I don't know why
> people love produce more than 25 FPS.

Because there is a quite good visible difference between 25fps and
50fps. Sure once you are at 100fps it gets more or less pointless to
go further, since not even your monitor can keep up with screen
refreshes, but between 25fps and 50fps there is a visible difference,
especially when it comes to fast scrolling action games. And since
already many 16bit systems, like the Amiga, would often run at 50fps,
I don't see much reason to scale that down on todays even faster
systems. However it is often better to keep the frame-rate constant,
then to go as fast as possible, so limiting to 60fps or to the refresh
rate of the monitor might be a good idea.

> In my own project, the screen is even not updated if there's no
> change from last frame. CPU time should be kept available for other
> tasks.

If the game looks good enough to justify using the whole CPU time I
see nothing wrong with that, games have after all done that basically
forever, they simply aren't really meant for multi-tasking. But sure,
pointlessly busy-looping without actually doing anything visible for
the player should be avoided. Anyway, with OpenGL one can get the CPU
usage pretty much down to zero or at least pretty close to that, since
the bottleneck is really just the graphic operations. With software
rendering you will on the other side always have a very hard time
getting useable framerates in larger resolutions.

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

[Super-tux-devel] Re: Keys handling patch

[Tobias <tob...@gm...>]

I hope this mail finally finds its way into the mailing list. ;)

Am Sa, den 24.01.2004 schrieb Ricardo Cruz um 19:28:
> Hey there,
> 
>  As I said before, I've made a keys.c file that would allow the change of the 
> keys in the run-time. Since Tobias didn't seem to like that way, I've now 
> putted that in the player's type.
>  Unfortanely, we have to go back for the use of the ifs, instead of switches.

I used your implementation as inspiration. ;) Look into the CVS.

>  The other patch fixes a bug when an upgrade is killed; its size was not being 
> in account. It also changes the -g parameter to -gl .

I already merged it.

>  It is noticable that the gameplay in OpenGL is different than in the SDL 
> backend one.
Because the drawing happens faster in OpenGL and therefore more frames
per second are reached. In theory the current implemenation should
calculate correctly and frame-rate independant movements. But
unfortunately the CPU-Ticks aren't precise enough. I'll go into detail
in a further mail.

>  This is surely a timer issue and this should get priority, since 
> it may affect gameplay in different computers with different fps.
>  i haven't yet really looked at the timer code, but it seems that player has 
> its own timer, right? If yes, I think a global timer implemention would be 
The timer doesn't implement a REAL timer. It only handles timing.
> much better.
> 
> Ricardo Cruz

Greetz...

Tobias Gläßer (Going to bed after his last CVS commit today) :)
--