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

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

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

Am Di, den 27.01.2004 schrieb Bill Kendrick um 16:19:
> 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 machine I described is a 'high-end' one, of course. ;)

Greetz...

Tobias Gläßer

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

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

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!

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

[offipso <of...@ab...>]

What! Did you just call that low-end? Oh my, I feel ancient.

-Dan

On Fri, 2004-01-23 at 13:08, Tobias Gl=C3=A4=C3=9Fer wrote:
> Am Do, den 22.01.2004 schrieb Ricardo Cruz um 20:16:
> >  Well, I can't still play the game in my laptop. It is a bit slow (Pe=
ntium=20
> > Celeron), so the Tux isn't updated too often and takes off the screen=
...
>=20
> Hmm, I can't test the game on low-end machines currently. (AMD 2500+ ,
> NVIDIA GF4200TI, 256DDR)
> :(
> The game is currently optimized to "produce" as many frames per second
> as possible. (up to 100) In the old code 40 were the absolute maximum
> and probably never reached.
> I'll introduce an option (CLI and menu) to tune SuperTux for old
> machines. Stay tuned. :)
>=20
>=20
> >  I am not sure if these kind of code is making the slowness:
> > while (issolid(pplayer->base.x, pplayer->base.y + 31))
> >   {
> >   if (pplayer->base.ym < 0)
> >     pplayer->base.y++;
> >  else if (pplayer->base.ym > 0)
> >     pplayer->base.y--;
> >   }
> this code had been in the "old" SuperTux, too.
>=20
> >  Tobias, maybe we should focus in putting the game working. Look at w=
hat this=20
> I agree, but I don't want to announce a feature freze yet.
>=20
> > user got when running supertux in opengl mode with an ATI:
> > http://mysticaldream.sourceforge.net/crap/supertux-opengl.png
> I couldn't test with ATI cards. :( Moreover the OpenGL mode IS
> experimental! It's NOT our goal to get it stable and
> working on every thinkable computer for 0.0.6.
> SDL will be the default for 0.0.6.
>=20
> >=20
> >  I'll give you an hand after next week.
> Good news. :)
>=20
> > Good luck,
> >  Ricardo Cruz
>=20
> Greetz...
>=20
> Tobias Gl=C3=A4=C3=9Fer
>=20
>=20
>=20
> -------------------------------------------------------
> 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] random scribles

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

Ingo Ruhnke <gr...@gm...> writes:

> Just a bunch of random scribels, nothing really useble or great:
>
> http://pingus.seul.org/~grumbel/tmp/supertex.jpg

Some more stuff:

http://pingus.seul.org/~grumbel/tmp/actions.png

Since I am running a little dry on inspiration, how about a bit of
brainstorming about actions that Tux could do?

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

Re: [Super-tux-devel] SuperTux's 1st IRC Meeting

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

On Wed, Jan 21, 2004 at 07:18:30PM -0500, Tobias Gl=E4=DFer wrote:
> To be honest I believe an IRC meeting is good for brainstorming,
<snip>

Next Saturday, huh?  Yeah, I think I can make it. :)
(Been a bit out of the SuperTux loop lately, sorry!)

-bill!
bi...@ne...                           Got kids?  Get Tux Pa=
int!=20
http://newbreedsoftware.com/bill/       http://newbreedsoftware.com/tuxpa=
int/

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

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

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) :)
-- 

[Super-tux-devel] Keys handling patch

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

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.

 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 .


 It is noticable that the gameplay in OpenGL is different than in the SDL 
backend one. 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 
much better.

Ricardo Cruz

-- 
Boston State House is the hub of the Solar System.  You couldn't pry that out
of a Boston man if you had the tire of all creation straightened out for a
crowbar.
		-- Oliver Wendell Holmes

[Super-tux-devel] music patch

[Duong-Khang N. <neo...@us...>]

   Hi there,

Just a tiny patch. I feel sooo tired hunting
 bugs so I gave up for today :-(

adds: some docs for "timer.h". Try to comment
 a little bit your code guys ;-)

fixes: normal level song is not played
when the coffee effect goes away

fixes: uncorrect use of TIME_WARNING in player.c

changes: sound buffer is now 2048, it's better

bugs: MAX_JUMP_TIME 1000 is too big for my laptop
(P IV 2,4Ghz; ATI Radeon 9000M; DRI activated
with AGP 4x). 
I had to define it as 250 in order
to play correctly... However, tux doesn't move
quickly to the left while jumping, it's a bit
hard to jump over a money bag. The money bag now
does a tiny jump, about 3 squares high. It's a
little bit weird.

bug fix hint:

DEBUG_MSG("FIXME - UNDER certain circumstances
 I'm hanging in a loop here!");
//the circumstances are:
//issolid() is true and base.ym == 0
//possible cause: use of floating point varibles
for base stuff introduce arithmetic problems while
"shape" casts them to "int"





-- 
Never say if I could turn back the time,
life is going on !

[Super-tux-devel] FPS

[Duong-Khang N. <neo...@us...>]

   Hi there,

I think there's really no need to go beyond 25 FPS. I don't know why people 
love produce more than 25 FPS. 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. The bad example is Super Methane Brothers: it eats 
all the CPU when you play. And I hate such a program.

> The game is currently optimized to "produce" as many frames per second
> as possible. (up to 100) In the old code 40 were the absolute maximum
> and probably never reached.

-- 
Never say if I could turn back the time,
life is going on !

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

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

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) :)
-- 

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

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

Em Sexta, 23 de Janeiro de 2004 18:08, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Am Do, den 22.01.2004 schrieb Ricardo Cruz um 20:16:
> >  Well, I can't still play the game in my laptop. It is a bit slow
> > (Pentium Celeron), so the Tux isn't updated too often and takes off the
> > screen...
>
> Hmm, I can't test the game on low-end machines currently. (AMD 2500+ ,
> NVIDIA GF4200TI, 256DDR)
>
> :(
>
> The game is currently optimized to "produce" as many frames per second
> as possible. (up to 100) In the old code 40 were the absolute maximum
> and probably never reached.
> I'll introduce an option (CLI and menu) to tune SuperTux for old
> machines. Stay tuned. :)
>
 i have made 3 snapshots to see what's the situation:
http://rpmcruz.planetaclix.pt/trash/supertux1.png
http://rpmcruz.planetaclix.pt/trash/supertux2.png
http://rpmcruz.planetaclix.pt/trash/supertux3.png

 Tux collision with bricks is not even tested, because it just "moves" way =
too=20
fast. Since the framerate is so low, the game makes Tux to move without=20
updating all positions.
 And many ppl still use Pentium 2.

> >  I am not sure if these kind of code is making the slowness:
> > while (issolid(pplayer->base.x, pplayer->base.y + 31))
> >   {
> >   if (pplayer->base.ym < 0)
> >     pplayer->base.y++;
> >  else if (pplayer->base.ym > 0)
> >     pplayer->base.y--;
> >   }
>
> this code had been in the "old" SuperTux, too.
>

 Didn't notice, the old gameloop was so huge :)
 Anyway, then it's the timer's fault.

Ricardo Cruz

=2D-=20
Help a swallow land at Capistrano.

Re: [Super-tux-devel] Leveleditor patch

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

Em Sexta, 23 de Janeiro de 2004 18:40, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> Am Do, den 22.01.2004 schrieb Ricardo Cruz um 20:40:
> > Hey there,
> >
> >  I have done a few changes in the leveleditor:
> > - added grid support (F9) - (added a fillrect func in screen.c, in Open=
GL
> > mode, it allways shows a black color, don't see what's the problem with
> > my code...);
>
> Your code isn't ready for the current CVS here, since the current CVS
> can be compiled completly without OpenGL support.
>
> Tobias Gl=C3=A4=C3=9Fer

 Okay, added the #ifndef NOOPENGL.

Ricardo Cruz

=2D-=20
"And kids... learn something from Susie and Eddie.
 If you think there's a maniacal psycho-geek in the
 basement:
    1)	Don't give him a chance to hit you on the
	head with an axe!
    2)	Flee the premises... even if you're in your
	underwear.
    3)	Warn the neighbors and call the police.
 But whatever else you do... DON'T GO DOWN IN THE DAMN BASEMENT!"
=2D- Saturday Night Live meets Friday the 13th

Re: [Super-tux-devel] Leveleditor patch

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

Am Do, den 22.01.2004 schrieb Ricardo Cruz um 20:40:
> Hey there,
> 
>  I have done a few changes in the leveleditor:
> - added grid support (F9) - (added a fillrect func in screen.c, in OpenGL 
> mode, it allways shows a black color, don't see what's the problem with my 
> code...);
Your code isn't ready for the current CVS here, since the current CVS
can be compiled completly without OpenGL support.
> - when, you put the cursor in a brick, you'll see what's inside (if anything);
> - PGDOWN and PGUP can be used to scroll in the level now.
I'll merge it.
> 
>  I have also added a keys.c file that would that a setkey and a getkey funcs 
> that would handle with keys, so that it would open the way for a dialog to 
> let the users change their keys. But when trying to merge, it doesn't work :(
>  I will send that later.
That seems to be a inefficient solution. If you have to get the keys
with getkey() everytime in the event-loop, we would have a major
bottleneck.  A better solution is to place the keys in a global keymap,
that can be manipulated by a function like setkey().

> Ricardo Cruz

Greetz...

Tobias Gläßer
-- 

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

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

Am Do, den 22.01.2004 schrieb Ricardo Cruz um 20:16:
>  Well, I can't still play the game in my laptop. It is a bit slow (Pentium 
> Celeron), so the Tux isn't updated too often and takes off the screen...

Hmm, I can't test the game on low-end machines currently. (AMD 2500+ ,
NVIDIA GF4200TI, 256DDR)
:(
The game is currently optimized to "produce" as many frames per second
as possible. (up to 100) In the old code 40 were the absolute maximum
and probably never reached.
I'll introduce an option (CLI and menu) to tune SuperTux for old
machines. Stay tuned. :)


>  I am not sure if these kind of code is making the slowness:
> while (issolid(pplayer->base.x, pplayer->base.y + 31))
>   {
>   if (pplayer->base.ym < 0)
>     pplayer->base.y++;
>  else if (pplayer->base.ym > 0)
>     pplayer->base.y--;
>   }
this code had been in the "old" SuperTux, too.

>  Tobias, maybe we should focus in putting the game working. Look at what this 
I agree, but I don't want to announce a feature freze yet.

> user got when running supertux in opengl mode with an ATI:
> http://mysticaldream.sourceforge.net/crap/supertux-opengl.png
I couldn't test with ATI cards. :( Moreover the OpenGL mode IS
experimental! It's NOT our goal to get it stable and
working on every thinkable computer for 0.0.6.
SDL will be the default for 0.0.6.

> 
>  I'll give you an hand after next week.
Good news. :)

> Good luck,
>  Ricardo Cruz

Greetz...

Tobias Gläßer

[Super-tux-devel] Leveleditor patch

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

Hey there,

 I have done a few changes in the leveleditor:
- added grid support (F9) - (added a fillrect func in screen.c, in OpenGL 
mode, it allways shows a black color, don't see what's the problem with my 
code...);
- when, you put the cursor in a brick, you'll see what's inside (if anything);
- PGDOWN and PGUP can be used to scroll in the level now.


 I have also added a keys.c file that would that a setkey and a getkey funcs 
that would handle with keys, so that it would open the way for a dialog to 
let the users change their keys. But when trying to merge, it doesn't work :(
 I will send that later.

Ricardo Cruz

-- 
My family history begins with me, but yours ends with you.
		-- Iphicrates

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

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

Hey Tobias,

 Dynamic arrays is nice for bad_guys and stuff, but there should be a maxim=
um=20
for bullets, right? What about 3 (like before) or even 2?
 Nice to see that you also added support for this in the leveleditor.

Ricardo Cruz


Em Quarta, 21 de Janeiro de 2004 04:34, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> hi all,
>
> I fixed a few bugs, so that it's possible to play a bit again.
> The most hated bug stays. :)
>
> More important is the removal of static sized arrays and the
> replacement with dynamic arrays (a very simple implementation doing it's
> job :) ).
> This means, that we can have an unlimited number of bad guys in a level
> for example and if there are only 7 badguys in a level, only the space
> for 7 badguy objects will be allocated. These things can change on
> demand now.
>
> Moreover I did a few code cleanups. Here is still MUCH to do.
> The most noticeable one is the launch of the base_type, which
> makes all types using it suitable for certain functions.
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer

=2D-=20
Great minds run in great circles.

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

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

 Well, I can't still play the game in my laptop. It is a bit slow (Pentium=
=20
Celeron), so the Tux isn't updated too often and takes off the screen...

 I am not sure if these kind of code is making the slowness:
while (issolid(pplayer->base.x, pplayer->base.y + 31))
  {
  if (pplayer->base.ym < 0)
    pplayer->base.y++;
 else if (pplayer->base.ym > 0)
    pplayer->base.y--;
  }

 Tobias, maybe we should focus in putting the game working. Look at what th=
is=20
user got when running supertux in opengl mode with an ATI:
http://mysticaldream.sourceforge.net/crap/supertux-opengl.png

 I'll give you an hand after next week.

Good luck,
 Ricardo Cruz

Em Quinta, 22 de Janeiro de 2004 04:56, o Tobias Gl=C3=A4=C3=9Fer escreveu:
> hi all,
>
> I made more code cleanups and fixed a few bugs, so
> that you can nearly play the game now.
> The biggest bug isn't fixed yet. ;)
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer

=2D-=20
Good evening, gentlemen.  I am a HAL 9000 computer.  I became operational
at the HAL plant in Urbana, Illinois, on January 11th, nineteen hundred
ninety-five.  My supervisor was Mr. Langley, and he taught me to sing a
song.  If you would like, I could sing it for you.

Re: [Super-tux-devel] Use_GL

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

I wanted to commit it, but sourceforge CVS is on strike again. :(
Thanks for your bug report thought. ;)

Greetz...

Tobias Gläßer

Am Do, den 22.01.2004 schrieb Duong-Khang NGUYEN um 08:51:
>    Hi there,
> 
> I think "use_gl" is not processed correctly in "setup.c". Someone should add 
> "use_gl = NO" at the beginning of "void parseargs(int argc, char * argv[])". 
> It's not worth patching :-D However when I use "--opengl" in this case, I 
> can't even launch supertux, here is the output:
> 
> [neurone@Neo workst]$ ./supertux --opengl
> Loading required GL library /usr/X11R6/lib/libGL.so.1.2
> Warning: No joysticks are available.
> supertux: r200_cmdbuf.c:301: r200EmitBlit: Assertion `(src_offset & 1023) == 
> 0' failed.
> Aborted
-- 

[Super-tux-devel] Use_GL

[Duong-Khang N. <neo...@us...>]

   Hi there,

I think "use_gl" is not processed correctly in "setup.c". Someone should add 
"use_gl = NO" at the beginning of "void parseargs(int argc, char * argv[])". 
It's not worth patching :-D However when I use "--opengl" in this case, I 
can't even launch supertux, here is the output:

[neurone@Neo workst]$ ./supertux --opengl
Loading required GL library /usr/X11R6/lib/libGL.so.1.2
Warning: No joysticks are available.
supertux: r200_cmdbuf.c:301: r200EmitBlit: Assertion `(src_offset & 1023) == 
0' failed.
Aborted

-- 
Never say if I could turn back the time,
life is going on !

[Super-tux-devel] IRC meeting

[Duong-Khang N. <neo...@us...>]

Cool,
NeoNeurone will be there !

Cya

>Server: irc.freenode.net
>Chanel: #supertux
>Day: 31 - January (Saturday)
>Time: 8:00 GMT
>Topic: SuperTux guidelines (mimic SM1 or SM3? If not, suggestions of
>behaver)

-- 
Never say if I could turn back the time,
life is going on !

Re: [Super-tux-devel] Homepage

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

Am Mi, den 21.01.2004 schrieb ri...@ae... um 12:58:
> Hey Tobias, 
>  Put a page like the appended in the sourceforge webserver, so that 
> when someone goes to super-tux.sf.net be directed to the real one. 
>  

Done, Sir. ;)

Greetz...

Tobias Gläßer

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

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

hi all,

I made more code cleanups and fixed a few bugs, so
that you can nearly play the game now.
The biggest bug isn't fixed yet. ;)

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] SuperTux's 1st IRC Meeting

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

Am Mi, den 21.01.2004 schrieb ri...@ae... um 13:08:
> Hey folks, 
>  
>  Let's mark a date for an irc meeting, and if someone disagrees, 
> reply a suggestion for another. In case, nobody replies, this will 
> be posted in the Forums at happypenguin.org. 
>  
> Server: irc.freenode.net 
> Chanel: #supertux 
> Day: 31 - January (Saturday) 
> Time: 8:00 GMT 
> Topic: SuperTux guidelines (mimic SM1 or SM3? If not, suggestions of 
> behaver) 
> Target: developers and users 
> IRC Client: any, but mirc ;) 
>  
>  Tobias and Bill Kendrick, please tell if you are going to be 
> present. 
>  
> See ya, 
>  Ricardo Cruz 

To be honest I believe an IRC meeting is good for brainstorming,
but not for long term (code & game) design decisions.
I'll suggest a few things on this mailing-list the next days and
announce my further plans for the next SuperTux releases.
I expect the ML to stay THE communication tool of SuperTux developers.
However I'm present in #supertux. :)

Greetz...

Tobias Gläßer

[Super-tux-devel] SuperTux's 1st IRC Meeting

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

Hey folks,=20
=20
 Let's mark a date for an irc meeting, and if someone disagrees,=20
reply a suggestion for another. In case, nobody replies, this will=20
be posted in the Forums at happypenguin.org.=20
=20
Server: irc.freenode.net=20
Chanel: #supertux=20
Day: 31 - January (Saturday)=20
Time: 8:00 GMT=20
Topic: SuperTux guidelines (mimic SM1 or SM3? If not, suggestions of=20
behaver)=20
Target: developers and users=20
IRC Client: any, but mirc ;)=20
=20
 Tobias and Bill Kendrick, please tell if you are going to be=20
present.=20
=20
See ya,=20
 Ricardo Cruz=20
_________________________________________________________
Acesso Gr=E1tis =E0 Internet do AEIOU:
Sem formul=E1rios, sem password, ligue-se j=E1!
http://acesso.aeiou.pt

[Super-tux-devel] Homepage

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

Hey Tobias,=20
 Put a page like the appended in the sourceforge webserver, so that=20
when someone goes to super-tux.sf.net be directed to the real one.=20
=20
Ricardo Cruz=20
_________________________________________________________
Acesso Gr=E1tis =E0 Internet do AEIOU:
Sem formul=E1rios, sem password, ligue-se j=E1!
http://acesso.aeiou.pt