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

Re: [Super-tux-devel] Last meter to 0.0.6

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

Am Sa, den 13.03.2004 schrieb Martin Renold um 05:26:
> Hi,
> 
> On Sat, Mar 13, 2004 at 03:37:50AM -0500, Tobias Gläßer wrote:
> > - If you have low FPS (<~20) [...]
> > - Again, if you have low FPS (<~20) [...]
> 
> This patch makes sure the engine never runs slower than 50 fps (and never
> faster than 100 fps, as before). On my machine, the cost is that it slows
> the visible framerate from ~23fps down to ~19fps. I haven't tested it on
> a fast machine.
> 
> Maybe someone has a better solution ready?
> 
> bye,
> Martin

I tried your patch, but my FPS sunk in OpenGL mode from 100 to 65.
Moreover the game doesn't feel runny anymore.

Your solution is more a workaround than a real bug-fix.
It could be used in a peaked version thought.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] RE: level done, waiting feedback (Philippe Saint-Pierre)

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

Am Sa, den 13.03.2004 schrieb Duong-Khang NGUYEN um 05:28:
>    Hi there,
> 
>    Well done man ! However, it looks a bit thick in some parts when a lot of 
> ice block are used for example. I think it's better to make it thinner.
>    At the end, we can't see the flag on the top of the pole. And at the middle 
> of the level or something like that, there's the top of the pole (grey ball) 
> without the pole :)
> 
>    I vote for this level to be included in next release.

I gave Philippe Saint-Pierre the job to do this level for 0.0.6. So you
don't need to vote. :)

Greetz...

Tobias Gläßer

-- 

Re: [Super-tux-devel] level done, waiting feedback

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

"Philippe Saint-Pierre" <st...@li...> writes:

> Here is a level I done. 

Great work, I really like the multiple paths that one can take in many
situations and the level also managed to get its own look&feel with
all the water areas. The level could however be a bit longer (+ ~150)
and could also need some more difficulty (more holes in which one can
fall, more a few more enemies here and there), since its a bit to easy
to simple 'rush' through the level at the moment, but overall a great
level.

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

[Super-tux-devel] Errors in sound libs

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

   Hi Arjun Asthana,

   Try to call this at the prompt:

	/sbin/ldconfig -p | grep "libSDL_mixer"

   You should see something like this:

        libSDL_mixer.so (libc6) => /usr/lib/libSDL_mixer.so
        libSDL_mixer-1.2.so.0 (libc6) => /usr/lib/libSDL_mixer-1.2.so.0

   Otherwise I think that you need to do type "ldconfig" at the prompt as root

Cya.

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

[Super-tux-devel] RE: Last meter to 0.0.6

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

   Hi there,

   It seems that some big bugs were fixed. However since few CVS updates, tux 
can not move back to the left once tux jumped to the right. To do this, I 
need to release the Up button first then press Left button. I think that the 
original behaviour in SuperTux 0.0.5 is better and looks more like the SMB's 
behaviour.


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

[Super-tux-devel] RE: level done, waiting feedback (Philippe Saint-Pierre)

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

   Hi there,

   Well done man ! However, it looks a bit thick in some parts when a lot of 
ice block are used for example. I think it's better to make it thinner.
   At the end, we can't see the flag on the top of the pole. And at the middle 
of the level or something like that, there's the top of the pole (grey ball) 
without the pole :)

   I vote for this level to be included in next release.


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

Re: [Super-tux-devel] Last meter to 0.0.6

[Martin R. <mar...@gm...>]

Hi,

On Sat, Mar 13, 2004 at 03:37:50AM -0500, Tobias Gläßer wrote:
> - If you have low FPS (<~20) [...]
> - Again, if you have low FPS (<~20) [...]

This patch makes sure the engine never runs slower than 50 fps (and never
faster than 100 fps, as before). On my machine, the cost is that it slows
the visible framerate from ~23fps down to ~19fps. I haven't tested it on
a fast machine.

Maybe someone has a better solution ready?

bye,
Martin

Index: src/gameloop.c
===================================================================
RCS file: /cvsroot/super-tux/supertux/src/gameloop.c,v
retrieving revision 1.55
diff -u -p -r1.55 gameloop.c
--- src/gameloop.c	9 Mar 2004 15:33:18 -0000	1.55
+++ src/gameloop.c	13 Mar 2004 09:50:25 -0000
@@ -54,8 +54,6 @@ static char level_subset[100];
 static char str[60];
 static float fps_fps;
 static int st_gl_mode;
-static unsigned int last_update_time;
-static unsigned int update_time;
 static int pause_menu_frame;
 
 /* Local function prototypes: */
@@ -92,7 +90,6 @@ void start_timers(void)
 {
   timer_start(&time_left,current_level.time_left*1000);
   st_pause_ticks_init();
-  update_time = st_get_ticks();
 }
 
 void activate_bad_guys(void)
@@ -561,7 +558,9 @@ void game_draw(void)
 
 int gameloop(char * subset, int levelnb, int mode)
 {
-  int fps_cnt, jump, done;
+  int fps_cnt, done, draw_frame;
+  double frames_left;
+  unsigned int update_time, last_update_time;
   timer_type fps_timer, frame_timer;
   timer_init(&fps_timer, YES);
   timer_init(&frame_timer, YES);
@@ -602,7 +601,8 @@ int gameloop(char * subset, int levelnb,
 
   /* --- MAIN GAME LOOP!!! --- */
 
-  jump = NO;
+  frames_left = 0.0;
+  update_time = st_get_ticks();
   done = 0;
   quit = 0;
   frame = 0;
@@ -622,10 +622,43 @@ int gameloop(char * subset, int levelnb,
   game_draw();
   do
     {
-      jump = NO;
-
       /* Calculate the movement-factor */
-      frame_ratio = ((double)(update_time-last_update_time))/((double)FRAME_RATE);
+      last_update_time = update_time;
+      update_time = st_get_ticks();
+      draw_frame = YES;
+      if(!game_pause && !show_menu)
+	{
+	  frames_left += ((double)(update_time-last_update_time))/((double)FRAME_DURATION);
+	  if(frames_left < 1.0)
+	    {
+	      /* running too fast */
+	      SDL_Delay(FRAME_DURATION / 2);
+	      continue;
+	    } 
+	  else if(frames_left < 2.0)
+	    {
+	      /* running normal */
+	      frame_ratio = frames_left;
+	      frames_left = 0.0;
+	    }
+	  else if(frames_left < 5000/FRAME_DURATION)
+	    {
+	      /* running too slow */
+	      frame_ratio = 2.0;
+	      frames_left -= 2.0;
+	      draw_frame = NO;
+	    }
+	  else
+	    {
+	      /* running way too slow */
+	      printf("Help! Can't even calculate the game in real time, expect bugs.\n");
+	      printf("(frames_left = %f)\n", frames_left);
+	      /* FIXME: slowdown buggy because the timers still tick in realtime */
+	      frame_ratio = 2.0;
+	      frames_left = 0.0;
+	      draw_frame = YES;
+	    }
+	}
 
       if(!timer_check(&frame_timer))
         {
@@ -696,15 +729,25 @@ int gameloop(char * subset, int levelnb,
       if(debug_mode && tux.input.down == DOWN)
         SDL_Delay(45);
 
-      /*Draw the current scene to the screen */
-      /*If the machine running the game is too slow
-        skip the drawing of the frame (so the calculations are more precise and
-      the FPS aren't affected).*/
-      /*if( ! fps_fps < 50.0 )
-      game_draw();
-      else
-      jump = YES;*/ /*FIXME: Implement this tweak right.*/
-      game_draw();
+      /* draw the current scene to the screen if the game is not running too slow */
+      if (draw_frame)
+	{
+	  game_draw();
+
+	  /* Calculate frames per second */
+	  if(show_fps)
+	    {
+	      ++fps_cnt;
+	      fps_fps = (1000.0 / (float)timer_get_gone(&fps_timer)) * (float)fps_cnt;
+	      
+	      if(!timer_check(&fps_timer))
+		{
+		  timer_start(&fps_timer,1000);
+		  fps_cnt = 0;
+		}
+	    }
+	}
+
 
       /* Time stops in pause mode */
       if(game_pause || show_menu )
@@ -712,20 +755,6 @@ int gameloop(char * subset, int levelnb,
           continue;
         }
 
-      /* Set the time the last update and the time of the current update */
-      last_update_time = update_time;
-      update_time = st_get_ticks();
-
-
-      /* Pause till next frame, if the machine running the game is too fast: */
-      /* FIXME: Works great for in OpenGl mode, where the CPU doesn't have to do that much. But
-                the results in SDL mode aren't perfect (thought the 100 FPS are reached), even on an AMD2500+. */
-      if(last_update_time >= update_time - 12 && jump != YES )
-        SDL_Delay(10);
-      /*if((update_time - last_update_time) < 10)
-          SDL_Delay((11 - (update_time - last_update_time))/2);*/
-
-
 
       /* Handle time: */
 
@@ -755,19 +784,6 @@ int gameloop(char * subset, int levelnb,
           play_current_music();
         }
 
-      /* Calculate frames per second */
-      if(show_fps)
-        {
-          ++fps_cnt;
-          fps_fps = (1000.0 / (float)timer_get_gone(&fps_timer)) * (float)fps_cnt;
-
-          if(!timer_check(&fps_timer))
-            {
-              timer_start(&fps_timer,1000);
-              fps_cnt = 0;
-            }
-        }
-
     }
   while (!done && !quit);
 
@@ -1792,7 +1808,6 @@ void loadgame(int slot)
       level_free_song();
       level_load_song(&current_level);
       levelintro();
-      update_time = st_get_ticks();
 
       fread(&score,sizeof(int),1,fi);
       fread(&distros,sizeof(int),1,fi);
Index: src/scene.h
===================================================================
RCS file: /cvsroot/super-tux/supertux/src/scene.h,v
retrieving revision 1.6
diff -u -p -r1.6 scene.h
--- src/scene.h	24 Feb 2004 15:34:00 -0000	1.6
+++ src/scene.h	13 Mar 2004 09:50:25 -0000
@@ -21,7 +21,7 @@
 #include "special.h"
 #include "level.h"
 
-#define FRAME_RATE 10 // 100 Frames per second (10ms)
+#define FRAME_DURATION 10 // 100 Frames per second (10ms)
 extern int score, distros, level, next_level, game_pause, quit, score_multiplier, endpos, counting_distros, distro_counter;
 extern timer_type  super_bkgd_timer;
 extern float scroll_x;

Re: [Super-tux-devel] level done, waiting feedback

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

Hey Philippe!

 Thanks, you were the first of (hopefully) a lot of others level's=20
contributors ;)
 Really, it is a fun and cool level, could be just a bit bigger (maybe 40=20
tiles). And it is really weird to see Tux under water, maybe we should get=
=20
him beach shorts :D

 Was it just me or you need to remove your home dir .supertux folder to add=
=20
another level to the main tree? Is it because of permissions in the level=20
editor?

Ricardo Cruz

Em S=E1bado, 13 de Mar=E7o de 2004 02:21, o Philippe Saint-Pierre escreveu:
> Here is a level I done.
>
> Thank you for your feedback
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Philippe Saint-Pierre
> st...@li...

=2D-=20
An authority is a person who can tell you more about something than you
really care to know.

[Super-tux-devel] Last meter to 0.0.6

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

Hi all,

0.0.6 will be a quality release. :)

There are three remaining bugs in CVS:

- If you have low FPS (<~20) Tux can hang on a wall and even fall under
the solids after a period of ca. 3 seconds.
 (player.c and collision.c)

- The laptops don't work fine. Compare it to 0.0.5 to know, how it
should work.
 (player.c and badguy.c)

- Again, if you have low FPS (<~20), it can happen that your jump on a
bad_guy is interpreted as if the player had run into it.
 (player.c and badguy.c)

- All other bugs seem to be of low priority. If you think differently,
your feedback is appreciated.

Greetz...

Tobias Gläßer
-- 

[Super-tux-devel] level done, waiting feedback

[Philippe Saint-P. <st...@li...>]

Here is a level I done. 
 
Thank you for your feedback 
 
 
====================================== 
Philippe Saint-Pierre 
st...@li... 
 
-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze

Re: [Super-tux-devel] Music approach [patch]

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

 Ooops, looks like there are another files messing up with the current_musi=
c=20
variable.
 Anyway, I've fixed that and made current_music to be only changed/getted b=
y=20
the use of functions. Using functions to change/obtain values from other=20
parts of code is a good programming practice, since it allows to make that=
=20
function printing output and so know if it is being written or used, in cas=
e=20
of debugging.
 Here goes a fresh patch.

Ricardo Cruz

Em S=C3=A1bado, 13 de Mar=C3=A7o de 2004 02:58, o Tobias Gl=C3=A4=C3=9Fer e=
screveu:
> Am Fr, den 12.03.2004 schrieb Ricardo Cruz um 14:07:
> > Hi,
> >  This patch just changed the way music is handled. Instead of telling
> > sdl_mixer to play music once and allways checking, in the gameloop, if =
it
> > is being played; this tells sdl_mixer to play it forever and
> > halts/restarts it when needed.
>
> I don't know why, but your patch is working. I hear the level music, but
> when the herring music or any other music gets invoked the first time
> all music is stopped forever.
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer

=2D-=20
I'm proud to be paying taxes in the United States.  The only thing is
=2D- I could be just as proud for half the money.
		-- Arthur Godfrey

Re: [Super-tux-devel] Music approach [patch]

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

Am Fr, den 12.03.2004 schrieb Tobias Gläßer um 21:58:
> Am Fr, den 12.03.2004 schrieb Ricardo Cruz um 14:07:
> > Hi, 
> >  This patch just changed the way music is handled. Instead of telling 
> > sdl_mixer to play music once and allways checking, in the gameloop, if it is 
> > being played; this tells sdl_mixer to play it forever and halts/restarts it 
> > when needed.
> 
> I don't know why, but your patch is working.
s/is/isn't :)

Greetz...

Tobias Gläßer

-- 

Re: [Super-tux-devel] Music approach [patch]

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

Am Fr, den 12.03.2004 schrieb Ricardo Cruz um 14:07:
> Hi, 
>  This patch just changed the way music is handled. Instead of telling 
> sdl_mixer to play music once and allways checking, in the gameloop, if it is 
> being played; this tells sdl_mixer to play it forever and halts/restarts it 
> when needed.

I don't know why, but your patch is working. I hear the level music, but
when the herring music or any other music gets invoked the first time
all music is stopped forever.

Greetz...

Tobias Gläßer
-- 

[Super-tux-devel] Music approach [patch]

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

Hi, 
 This patch just changed the way music is handled. Instead of telling 
sdl_mixer to play music once and allways checking, in the gameloop, if it is 
being played; this tells sdl_mixer to play it forever and halts/restarts it 
when needed.

Ricardo Cruz

-- 
A closed mouth gathers no foot.

Re: [Super-tux-devel] Errors in sound libs.

[Arjun A. <arj...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 10 March 2004 20:25, you wrote:
> On Wed, Mar 10, 2004 at 05:28:27PM +0530, Arjun Asthana wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wednesday 10 March 2004 15:50, you wrote:
> > > Sounds like an older version of SDL_Mixer is installed.
> >
> > I just downloaded it today!
>
> The latest, presumably? ;^)  From source?

$ sdl-config --version
1.2.7

SDL runtime and Devel both from rpm.

> Just asking! ;)
>
> -bill!


- -- 
Regards,
 Arjun Asthana
 arj...@gm...
Linux: Choose your freedom
- -#-#-
:
####[ GNU/Linux One Stanza Tip (LOST) ]#######################
  
Sub : Using Aliases (csh shell/ clones)              LOST #177

You can use aliases to  decrease the amount of typing you need
to do to get commands you commonly use. You can  place them in
your startup file (.login) as well. Under csh and tcsh: 
alias lf ls -FA
alias ll ls -lA

####[From : freebsd fortune]##################################
:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAUD6e9mAtgws7e1wRAki6AJ97EJ279TY6a5esudP9M15KV99+9ACfbjdE
S2PQQGEe2gxgyIngoylkW5I=
=cSzp
-----END PGP SIGNATURE-----

[Super-tux-devel] More amusing sketches.

[Christopher A. W. <cr...@li...>]

Nothing major, but you can see the progress I'm making on the wingling. 
There wasn't supposed to be this much work put into it, but apparently
there is :)  I'm making sure that the wings move smoothly.  The problem
with this is that the wings were not designed logically.... they
maintain an optical illusion of smoothness, but notice... you can't tell
if they're flat or thick in any area.  In fact, they are both at once.
The sane individual would just toss out the wings and redo them.  I'm
not sane.
Instead, I've developed a clever scheme on paper to figure out how I can
maintain this optical illusion and still make the wings flap in four
frames, as grumbel reccomended.  It's a bit like trying to rotate one of
Picasso's paintings, but I think I've gotten it to work.  You can look
at some of my sketches here:
http://www.lingocomic.com/gfx/goodies/supertux/wingling_concepts.xcf
Highlighted throughout all that is this really interesting skeletal
structure of the wingling.  Follows the wingling's design in everything
but the wings.
http://www.lingocomic.com/gfx/goodies/supertux/wingling_undead.png
The rest of the sprites I develop shouldn't take me nearly as long as
this one is.  Hope you enjoy!

Christopher Allan Webber


|
The bottom line

[Super-tux-devel] Configure errors in the latest CVS : No Makefile.in

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

   Hi,

The Makefile.in is automatically created by "automake" from Makefile.am, so I 
can say that it is not missing. However, I removed the configure script from 
the CVS so that ppl not familar with autoconf stuff won't try them. 

Please use

	make -f Makefile.cvs

to compile supertux, instead. 

Cya



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

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

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

On Thu, Mar 11, 2004 at 12:43:11PM +0000, Ricardo Cruz wrote:
>  Also everything using ifs to see what enemy kind is it, is not a good 
> programming practice, cases are faster and cheaper, in code lines, i mean.

Function pointers are faster. ;^)
Maybe we should look into that?


-bill!

Re: [Super-tux-devel] Stalactite bad guy [patch]

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

Em Quinta, 11 de Mar=E7o de 2004 11:05, o Bill Kendrick escreveu:
> On Thu, Mar 11, 2004 at 10:31:16AM +0000, Ricardo Cruz wrote:
> >  Yheaa, first time I thought about the stalactite I wanted to implement
> > that way. And does BoboBot make use of an animation or a particle syste=
m?
>
> You could think of it as a 'particle' system, I guess.
>
> When the stalactite hits the ground, four ice cube pieces are created.
> They act like the other objects in the game (player, enemies, bullets),
> in that they are animated each frame.
>
> I can't remember, but their lifespan might even be randomly-generated,
> meaning they might not all disappear at once.  There might one one left
> bouncing on the ground for a moment after the others have disappeared.
>
> It's rather simple coding/logic, but adds to the game nicely, because of
> this randomness.
>

 Maybe it could make use of broken_brick struct and funcs.

> (Also notice in BoboBot that when you jump out of the water, you drip
> randomly for a few seconds. ;^) )
>
>
> I'm honestly quite proud of BoboBot, so far as what the game looks like
> and feels like.  It's a shame that I didn't make it a scrolling game,
> wrote it in a hard-to-maintain way (Super Tux is a BIT better, so you can
> imagine how bad BoboBot is! :^) ), and never ported it from Xlib to SDL.
>

 I must congratulate you for it. It is really a cute game with a a pretty b=
ig=20
range of different enemies, including bosses. ;)
 Since it has a few worlds, with much levels, it is an enjoyable game and a=
=20
must for every linuxer. :)

Ricardo Cruz

=2D-=20
People don't usually make the same mistake twice -- they make it three
times, four time, five times...

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

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

Em Quinta, 11 de Mar=E7o de 2004 09:51, o Ingo Ruhnke escreveu:
> Ricardo Cruz <ri...@ae...> writes:
> >  While implementing a new bad guy, I could see how much the code
> > sucks for extensability. Really, how do we expect to have scripting,
> > lots of great enemies and scoped tiles, if all stuff is hard coded!
>
> I don't think that scripting will ever be usefull for coding enemies.
> Scripting can however be very usefull to customize enemies (change
> there speed, etc.), but it becomes useless for coding them. After all
> an enemy can do all kinds of weird things in the engine when required,
> you can't get that from scripting unless you start to export every
> damn little bit of the engine, but then you spend much more time with
> wrappering than with scripting the enemies, so you'd better code them
> in C in the first place. I think scripting will mainly be usefull for
> custom events in the levels, ie. have dialog-boxed pop-up when the
> enemy approaches, for scripting little in-game cut-scenes and such
> stuff that can't be all that easily done in C and especially shouldn't
> be done in C, since its artistic content and doesn't belong in the
> core engine.
>

 I never meant to script the enemies, but you should edit only a couple of=
=20
file, instead of opening the all code.
 C'mon, there should be a define with the number of different enemies and t=
he=20
level editor should use that number to add them automatically. You should n=
ot=20
be forced to add a button for every of them.
 Their graphics should not be loaded in the middle of some other file... An=
d=20
they should have the info for the number of frames and size, instead of bei=
ng=20
everything hard coded.
 Also everything using ifs to see what enemy kind is it, is not a good=20
programming practice, cases are faster and cheaper, in code lines, i mean.

> >  It took me half an hour just to add a basic bad guy.
>
> Half an hour doesn't sound that bad.
>

 I mean, half an hour just to make a badguy's skeleton.

> >  Tobias told me in the IRC that he was not thinking about a C++
> > port.
>
> At this current point it would really makes no sense to port to C++,
> the engine is up an running (well, almost) and we should care about
> content, levels and getting the gameplay right, not about which
> languaged was used to implement the stuff.
>

 I just think that a C++ port would be a pretty banal thing to do, with the=
=20
only expense of time (not much if it was a team effort) and it would surely=
=20
improve the design overall.

> > That was my last hope for a redesign of SuperTux and I really felt
> > like abandoning the boat.
>
> After milestone1 we can do whatever we want, we can throw the whole
> engine away and use wolfman8k's python engine or reuse the windstille
> engine (which btw. is from a gameplay point of view far behind
> Supertux) or recode supertux in C++ or whatever, but that is something
> to decide after milestone1, not right now.
>
> If somebody wants to just compile with C++ and use std::string instead
> of frickling around with char* I am all for it, but that something
> else then rewriting everything as classes.
>

 Have a look at a few code, like the menu.*, and you'll notice that it=20
wouldn't be hard, in fact, you can currently kind of program like if it was=
=20
C++.
 But there a few things, especially code readability and interaction betwee=
n=20
objects, that would benefit much more from a C++ design.

> >  These months are crucial for SuperTux, if it doesn't improve it
> > will probably die. I don't think there is anyone willing to start it
> > over and over again. In my opinion, we should focus our attention in
> > releasing the next version by putting the gameplay as it was before
> > and adding a few levels.
>
> Yep, exactly, we should focus to get the basic gameplay right now, not
> about how we can extent the engine with some super-duper-thingy which
> I can't currently even think of. As far as it looks like for me at the
> moment all enemies planed for Milestone1 should be doable with the
> current engine, after all, most of them are pretty similar to the
> current ones, just with little modifications in the behaviour and the
> look. My only goal at the moment is to get milestone1 good enough, if
> after that all people agree that the codebase is unusable for
> extension we have to find a solution, but we aren't there yet, so we
> should better stop discussion this and get back to work.

 SuperTux is really polished right now; the menu is really shining, the lev=
el=20
editor works like a champ and we have two frontends.
 But this is a game and the fact is that the main game code has much less=20
quality than the rest.
 And I don't mean just that fps bug, have a look at the collision.c file, f=
or=20
instance. The test for checking if a player is bumping into a enemy is to=20
look if the Y speed velocity is superior to zero! This is obviously=20
non-sense, since you can be both falling and you just need to go into it. I=
=20
don't really know any better way, but I am sure there are, like having also=
=20
positions into consideration.

Ricardo Cruz


=2D-=20
Pretend to spank me -- I'm a pseudo-masochist!

Re: [Super-tux-devel] Stalactite bad guy [patch]

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

On Thu, Mar 11, 2004 at 03:05:26AM -0800, Bill Kendrick wrote:
> 
> I think I'll make something in Gimp to explain what I'm talking about.

Hehe, and I did.  Enjoy!

  http://www.newbreedsoftware.com/bill/photos/junk/stalactite/

-bill!
bi...@ne...           "Hey Shatner, ya remember that episode of
http://newbreedsoftware.com/bill/   Space Trek where your show got cancelled?"

Re: [Super-tux-devel] Stalactite bad guy [patch]

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

On Thu, Mar 11, 2004 at 10:31:16AM +0000, Ricardo Cruz wrote:
>  Yheaa, first time I thought about the stalactite I wanted to implement that 
> way. And does BoboBot make use of an animation or a particle system?

You could think of it as a 'particle' system, I guess.

When the stalactite hits the ground, four ice cube pieces are created.
They act like the other objects in the game (player, enemies, bullets),
in that they are animated each frame.

I can't remember, but their lifespan might even be randomly-generated,
meaning they might not all disappear at once.  There might one one left
bouncing on the ground for a moment after the others have disappeared.

It's rather simple coding/logic, but adds to the game nicely, because of
this randomness.

(Also notice in BoboBot that when you jump out of the water, you drip
randomly for a few seconds. ;^) )


I'm honestly quite proud of BoboBot, so far as what the game looks like
and feels like.  It's a shame that I didn't make it a scrolling game,
wrote it in a hard-to-maintain way (Super Tux is a BIT better, so you can
imagine how bad BoboBot is! :^) ), and never ported it from Xlib to SDL.

I tried rewriting it twice, but Super Tux was my best attempt at doing
a scroller game.  BoboBot might not look like much, but what's there is
fairly fun and cute. ;^)


<snip>
> > If we were being REALLY fancy, we could hand-code a blur routine that would
> > actually give more of a glass effect.  But, since the graphics will be
> > relatively small, blurring is relatively expensive, and it will eventually
> > all be moving so fast, I don't think it's worth it...
> 
>  Not sure what you meant, but SuperTux has OpenGL support...

As an option, I hope. ;^)  I reinstalled my Debian system recently and
only have software GL support right now, for example. ;^)  It == SLOW!

The gist of the idea is that instead of simply being see-through, or
tinting the background, the ice could actually affect the clarity of
the background behind it.

I suppose one way to do it would be to:

  1. Do a general blur of the area the stalactite takes (using a
     mask to determine which pixels we should blur, so that we don't
     waste time doing the full rectangular area around the object).

e.g., using this mask:

     #####
     -###-
     -###-
     -###-
     -##--
     --#--
     --#--

...look at the pixels in the background (before drawing any part of the
stalactite) and combine them to blur it.  E.g., if the background looked
like this:

     #--#-
     -----
     #--#-
     -----
     #--#-
     -----
     #--#-

...we'd now have a bitmap that looks like this:

     ::-::
     ?'-'?
     ?:-:?
     ?'-'?
     ?:-??
     ??-??
     ??-??

(Where "??" is bits we don't even care about... consider it 100% transparent)


If we were to blit that back onto the screen, it would look like a weird
blurred splotch on the background.  That's a start, but now we can use
a transparency mask to determine how MUCH of that blurry background to
draw back onto the screen.  (e.g., it would be very blurry on the edges,
and less blurry in the center, where the stalactite is pretty much
a cylinder.)


Mix the current background, with this alpha-masked blurred version and
NOW, we have a cool "invisible Predator" style effect!

Finally, we can draw the stalactite itself.  In the center (where the
stalactite looks mostly like see-through glass), we would simply
tint the slightly-blurred background... say, blue.

On the edges, it would be less see-through.  Perhaps with a 100%-opaque
black outline on the edges, for a cartoon effect.


I think I'll make something in Gimp to explain what I'm talking about.


At this point, I'm just kinda bored and wasting time talking about this.
I doubt we'll go into this 'blur' effect any time soon, if EVER, in
Super Tux. :^)


It sure is fun to think about, though! ;^)


-bill!

Re: [Super-tux-devel] Stalactite bad guy [patch]

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

Em Quinta, 11 de Mar=E7o de 2004 08:00, o Bill Kendrick escreveu:
> On Thu, Mar 11, 2004 at 03:35:54AM +0000, Ricardo Cruz wrote:
> > When the stalactites hit the ground, maybe there should be an animation,
> > not just a static image. Should be added in future for all bad guys.
>
> In BoboBot, I also have a stalactite enemy (it doesn't shake, though).
> When it hits the ground, it shatters into little ice-cube fragments.
>
> Imagine if it were made of glass, it would do the same.
>

 Yheaa, first time I thought about the stalactite I wanted to implement tha=
t=20
way. And does BoboBot make use of an animation or a particle system?

>
> I haven't looked, but I'd like to suggest that the stalactite (and broken
> ice) images have some level of transparency (more towards the center, none
> on the "V"-shaped edges), which would allow the background to show throug=
h.
>
>
> If we were being REALLY fancy, we could hand-code a blur routine that wou=
ld
> actually give more of a glass effect.  But, since the graphics will be
> relatively small, blurring is relatively expensive, and it will eventually
> all be moving so fast, I don't think it's worth it...
>

 Not sure what you meant, but SuperTux has OpenGL support...


Ricardo Cruz

=2D-=20
Some performers on television appear to be horrible people, but when
you finally get to know them in person, they turn out to be even worse.
		-- Avery

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

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

Ricardo Cruz <ri...@ae...> writes:

>  While implementing a new bad guy, I could see how much the code
> sucks for extensability. Really, how do we expect to have scripting,
> lots of great enemies and scoped tiles, if all stuff is hard coded!

I don't think that scripting will ever be usefull for coding enemies.
Scripting can however be very usefull to customize enemies (change
there speed, etc.), but it becomes useless for coding them. After all
an enemy can do all kinds of weird things in the engine when required,
you can't get that from scripting unless you start to export every
damn little bit of the engine, but then you spend much more time with
wrappering than with scripting the enemies, so you'd better code them
in C in the first place. I think scripting will mainly be usefull for
custom events in the levels, ie. have dialog-boxed pop-up when the
enemy approaches, for scripting little in-game cut-scenes and such
stuff that can't be all that easily done in C and especially shouldn't
be done in C, since its artistic content and doesn't belong in the
core engine. 

>  It took me half an hour just to add a basic bad guy.

Half an hour doesn't sound that bad.

>  Tobias told me in the IRC that he was not thinking about a C++
> port.

At this current point it would really makes no sense to port to C++,
the engine is up an running (well, almost) and we should care about
content, levels and getting the gameplay right, not about which
languaged was used to implement the stuff.

> That was my last hope for a redesign of SuperTux and I really felt
> like abandoning the boat. 

After milestone1 we can do whatever we want, we can throw the whole
engine away and use wolfman8k's python engine or reuse the windstille
engine (which btw. is from a gameplay point of view far behind
Supertux) or recode supertux in C++ or whatever, but that is something
to decide after milestone1, not right now.

If somebody wants to just compile with C++ and use std::string instead
of frickling around with char* I am all for it, but that something
else then rewriting everything as classes.

>  These months are crucial for SuperTux, if it doesn't improve it
> will probably die. I don't think there is anyone willing to start it
> over and over again. In my opinion, we should focus our attention in
> releasing the next version by putting the gameplay as it was before
> and adding a few levels.

Yep, exactly, we should focus to get the basic gameplay right now, not
about how we can extent the engine with some super-duper-thingy which
I can't currently even think of. As far as it looks like for me at the
moment all enemies planed for Milestone1 should be doable with the
current engine, after all, most of them are pretty similar to the
current ones, just with little modifications in the behaviour and the
look. My only goal at the moment is to get milestone1 good enough, if
after that all people agree that the codebase is unusable for
extension we have to find a solution, but we aren't there yet, so we
should better stop discussion this and get back to work.

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

Re: [Super-tux-devel] Stalactite bad guy [patch]

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

On Thu, Mar 11, 2004 at 03:35:54AM +0000, Ricardo Cruz wrote:
> When the stalactites hit the ground, maybe there should be an animation, not 
> just a static image. Should be added in future for all bad guys.

In BoboBot, I also have a stalactite enemy (it doesn't shake, though).
When it hits the ground, it shatters into little ice-cube fragments.

Imagine if it were made of glass, it would do the same.


I haven't looked, but I'd like to suggest that the stalactite (and broken
ice) images have some level of transparency (more towards the center, none
on the "V"-shaped edges), which would allow the background to show through.


If we were being REALLY fancy, we could hand-code a blur routine that would
actually give more of a glass effect.  But, since the graphics will be
relatively small, blurring is relatively expensive, and it will eventually
all be moving so fast, I don't think it's worth it...

-bill!
bi...@ne...           "Hey Shatner, ya remember that episode of
http://newbreedsoftware.com/bill/   Space Trek where your show got cancelled?"