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

[Super-tux-devel] Alternative keys to control the game

[Hernani M. M. <he...@tu...>]

Hello @ all.

Are there any objections against including the following key combinations
to control the game (as they are implemented in snes9x):

<GAMELOOP>
--- gameloop.c.orig	2004-02-21 22:51:50.000000000 +0100
+++ gameloop.c	2004-02-21 23:19:25.000000000 +0100
@@ -176,7 +176,7 @@
 
           key = event.key.keysym.sym;
 
-          if (key == SDLK_ESCAPE)
+          if (key == SDLK_ESCAPE || key == SDLK_q)
             {
               /* Escape: Open/Close the menu: */
               if(!game_pause)
@@ -187,23 +187,23 @@
                     show_menu = 1;
                 }
             }
-          else if (key == SDLK_RIGHT)
+          else if (key == SDLK_RIGHT || key == SDLK_k)
             {
               right = DOWN;
             }
-          else if (key == SDLK_LEFT)
+          else if (key == SDLK_LEFT || key == SDLK_h)
             {
               left = DOWN;
             }
-          else if (key == SDLK_UP)
+          else if (key == SDLK_UP || key == SDLK_c)
             {
               up = DOWN;
             }
-          else if (key == SDLK_DOWN)
+          else if (key == SDLK_DOWN || key == SDLK_j)
             {
               down = DOWN;
             }
-          else if (key == SDLK_LCTRL)
+          else if (key == SDLK_LCTRL || key == SDLK_e)
             {
               fire = DOWN;
             }
@@ -218,23 +218,23 @@
           if(show_menu)
             menu_event(key);
 
-          if (key == SDLK_RIGHT)
+          if (key == SDLK_RIGHT || key == SDLK_k)
             {
               right = UP;
             }
-          else if (key == SDLK_LEFT)
+          else if (key == SDLK_LEFT || key == SDLK_h)
             {
               left = UP;
             }
-          else if (key == SDLK_UP)
+          else if (key == SDLK_UP || key == SDLK_c)
             {
               up = UP;
             }
-          else if (key == SDLK_DOWN)
+          else if (key == SDLK_DOWN || key == SDLK_j)
             {
               down = UP;
             }
-          else if (key == SDLK_LCTRL)
+          else if (key == SDLK_LCTRL || key == SDLK_e)
             {
               fire = UP;
             }
@@ -286,7 +286,7 @@
               /* Handle joystick for the menu */
               if(show_menu)
                 {
-                  if(down == DOWN)
+                  if(down == DOWN) 
                     menuaction = MN_DOWN;
                   else
                     menuaction = MN_UP;
@@ -2330,7 +2330,6 @@
 
 
   /* Load data file: */
-
   filename = (char *) malloc(sizeof(char) * (strlen(DATA_PREFIX) + 20));
   sprintf(filename, "%s/levels/level%d.dat", DATA_PREFIX, level);
   fi = fopen(filename, "r");
</GAMELOOP>

--

<MENU>
--- menu.c.orig	2004-02-21 22:51:57.000000000 +0100
+++ menu.c	2004-02-21 22:50:58.000000000 +0100
@@ -219,21 +219,21 @@
 {
 
 
-  if (key == SDLK_UP)
+  if (key == SDLK_UP || key == SDLK_u)
     {
       /* Menu Up */
 
       menuaction = MN_UP;
       menu_change = YES;
     }
-  else if (key == SDLK_DOWN)
+  else if (key == SDLK_DOWN || key == SDLK_j)
     {
       /* Menu Down */
 
       menuaction = MN_DOWN;
       menu_change = YES;
     }
-  else if (key == SDLK_SPACE || key == SDLK_RETURN)
+  else if (key == SDLK_SPACE || key == SDLK_RETURN || key == SDLK_c)
     {
       /* Menu Hit */
 </MENU>

Alternatively -- with low priority -- a menu item giving one the option to define
custom key combinations _could_ make this depreciated. Nevertheless I think that
having an additional standard set defined that 10 finger gamers could use
is not the baddest idea ;).

Hernani

 

Re: [Super-tux-devel] seg fault

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

ri...@ae... writes:

> http://rpmcruz.planetaclix.pt/repository/system/index.html#curdir 
>  
>  Tobias, what do you think? 

Changing current directory is kind of evil, better they where you are
and just open the files from whereever they are, the tricky part is
always to find out where they are, since programms in linux are very
often launched from PATH. Most programms use ugly evil hardcoded paths
in the binary. Luckily the /proc filesystem provides the absolute
location of an executable, so no need for hardcompiled stuff, code
looks like:

	char exe_file[PATH_MAX];
	if (readlink("/proc/self/exe", exe_file, PATH_MAX) < 0)
	{
		throw CL_Error(strerror(errno));
	}
	else
	{
		return std::string(dirname(exe_file)) + "/";
	}

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

Re: [Super-tux-devel] seg fault

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

Am Fr, den 20.02.2004 schrieb Tobias Gläßer um 00:15:
> Am Do, den 19.02.2004 schrieb Duong-Khang NGUYEN um 05:40:
> >    Hey,
> > 
> > What is going wrong with the current CVS ? I can't even launch the game, it 
> > crashes when I choose "start game". However when I try to play via Level 
> > Editor, it works.
> > 
> > I have just updated my working directory. It's 10:40 am GMT here.
> 
> This segfault should be fixed. I forgot to add a few files to the CVS.
> :(
> 
> Sorry ...
> 
> Additionally a new check ensures that a segfault is prevented.
> 
> Greetz...
> 
> Tobias Gläßer

Well, the code works properly for me but at least Ingo is reporting, that
it still doesn't work like expected.

There is no reason to send further bug reports on this matter, I'm on it.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] seg fault

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

Am Do, den 19.02.2004 schrieb Duong-Khang NGUYEN um 05:40:
>    Hey,
> 
> What is going wrong with the current CVS ? I can't even launch the game, it 
> crashes when I choose "start game". However when I try to play via Level 
> Editor, it works.
> 
> I have just updated my working directory. It's 10:40 am GMT here.

This segfault should be fixed. I forgot to add a few files to the CVS.
:(

Sorry ...

Additionally a new check ensures that a segfault is prevented.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] seg fault

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

Am Do, den 19.02.2004 schrieb Bill Kendrick um 17:39:
> On Thu, Feb 19, 2004 at 11:28:27PM -0500, Tobias Gläßer wrote:
> > > So ONLY if they compile it as root, will it install in /usr/local???
> > 
> > You are wrong Dot :)
> > 
> > If no PREFIX is set on the command line and you are ROOT then it will
> > automatically choose /usr/local, because only then a "User" is assumed
> > to have write-access to this directory.
> > In any other situation the $PWD is choosen.
> 
> Okay, sorry... "ONLY if they compile as root, OR remember to set PREFIX",
> it will want to install /usr/local
> 
> I think it should DEFAULT to /usr/local/ _UNLESS_ they override it.
> Otherwise, if they do this:
> 
>   $ make
>   $ su
>   # make install
> 
> as a normal person, who is used to configure scripts and other programs, would,
> it will simply try to 'install' back into $PWD
> 
> D'OH!
> 
> -bill!

Hmm, this is useful for development, because you don't need to change (set parameters in Makefile etc. )
anything and can directly try out your latest one liner.
I agree, for releases this should be changed. ;)

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] Possible first level background?

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

Am Mi, den 18.02.2004 schrieb offipso um 22:36:
> Hello, my friend and I made a replacement background for the first few
> levels, seeing as the previous one was sort of, er...lacking.
> 
> Tell us what you think, here are the links:
> 
> http://www.abeminds.com/arctic_background.png (640x480 PNG)
> http://www.abeminds.com/arctic_background.big.png (1024x768 PNG)
> 
> I haven't had the chance to try them in the current CVS Super Tux, as it
> doesn't work for me...but that's a topic for another thread.
> 
> -Dan Koestler
> Background drawn by Lawrence Burns

There is no doubt that you and your friend are very talented, respect.
I'm not sure, if the design/style fits to the other SuperTux graphics.
It could be an alternative background chooseable in the leveleditor,
when the leveleditor dialogs are ready.

We had a lack of this kind of contribution for a long time.
With grumbel's contributions and yours this clearly changed. :)

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] seg fault

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

On Thu, Feb 19, 2004 at 11:28:27PM -0500, Tobias Gl=E4=DFer wrote:
> > So ONLY if they compile it as root, will it install in /usr/local???
>=20
> You are wrong Dot :)
>=20
> If no PREFIX is set on the command line and you are ROOT then it will
> automatically choose /usr/local, because only then a "User" is assumed
> to have write-access to this directory.
> In any other situation the $PWD is choosen.

Okay, sorry... "ONLY if they compile as root, OR remember to set PREFIX",
it will want to install /usr/local

I think it should DEFAULT to /usr/local/ _UNLESS_ they override it.
Otherwise, if they do this:

  $ make
  $ su
  # make install

as a normal person, who is used to configure scripts and other programs, =
would,
it will simply try to 'install' back into $PWD

D'OH!

-bill!

Re: [Super-tux-devel] File format

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

Hi Ricardo,

I've already told you about my plans with scripting support in SuperTux
and the old levelformat would have to be dropped when this effort begins.

But until the 0.1 release ( 0.7-0.9 are supposed to have short release cycles)
we should keep it to have enough concistency, so that level creators and designers
don't think their work would be destroyed with every SuperTux version.

Greetz...


Tobias Gläßer

Re: [Super-tux-devel] seg fault

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

Am Do, den 19.02.2004 schrieb Bill Kendrick um 17:15:
> On Thu, Feb 19, 2004 at 05:07:03PM +0000, ri...@ae... wrote:
> >  Anyway, I don't like the way that the data directory is found... 
> > The data directory is setuped during the make, which is not that 
> > brilliant, since a simple move of the game makes it not to work. 
> >  I think that the installation directory should be setuped during 
> > the make process, but the current dir, when the game is not 
> > installed should use some hack like this one (from myself): 
> > http://rpmcruz.planetaclix.pt/repository/system/index.html#curdir
> 
> I just noticed this in Makefile, which is damned silly:
> 
> ifeq ($(PREFIX),)
> ifeq ($(USERNAME),root)
> PREFIX=/usr/local
> ...
> 
> 
> So ONLY if they compile it as root, will it install in /usr/local???

You are wrong Dot :)

If no PREFIX is set on the command line and you are ROOT then it will
automatically choose /usr/local, because only then a "User" is assumed
to have write-access to this directory.
In any other situation the $PWD is choosen.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] Possible first level background?

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

Hmm, the clarity of it is a good point, perhaps it would have been
better blurrier. I would hope the background would scroll, in fact with
multiple background layers. Also, I'll see if the artist (Lawrence
Burns) wants to draw more art for Super Tux, trying for the style that
the game currently has, or look into Tux Paint. 

-Dan Koestler

On Thu, 2004-02-19 at 16:58, Bill Kendrick wrote:
> On Thu, Feb 19, 2004 at 12:41:44PM +0100, Ingo Ruhnke wrote:
> > offipso <of...@ab...> writes:
> > 
> > > Tell us what you think, here are the links:
> > 
> > Even so the graphic looks pretty nice, I think it fits neither the
> > current graphic style nor the one that most likly will get used in the
> > 0.1 release (unless somebody of course comes up with something
> > better)[1].
> 
> I agree.  It's also a bit to crisp and clear, and would kind of interfere
> with the foreground graphics.  I also don't understand how or it the
> background would scroll.
> 
> OTOH, the art was great, so if the artist can help out somewhere else
> in this project (or on another project... say, Tux Paint? ;^) ), please
> encourage it! :^)
> 
> -bill!
> 

Re: [Super-tux-devel] seg fault

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

On Thu, Feb 19, 2004 at 05:07:03PM +0000, ri...@ae... wrote:
>  Anyway, I don't like the way that the data directory is found... 
> The data directory is setuped during the make, which is not that 
> brilliant, since a simple move of the game makes it not to work. 
>  I think that the installation directory should be setuped during 
> the make process, but the current dir, when the game is not 
> installed should use some hack like this one (from myself): 
> http://rpmcruz.planetaclix.pt/repository/system/index.html#curdir 

I just noticed this in Makefile, which is damned silly:

ifeq ($(PREFIX),)
ifeq ($(USERNAME),root)
PREFIX=/usr/local
...


So ONLY if they compile it as root, will it install in /usr/local???

I NEVER compile stuff as root!  I always do:

  $ ./configure             <-- if necessary
  $ make
  $ su
  # make install
  # exit
  $ 


I'm sure in the original 0.0.4/0.0.5 Super Tux, I was doing my stupid old
system where it ASSUMED you were installing into your home dir, or just
running out of the untar'd directory.

I've learned, since then, that it's best to let the user CHOOSE to do this,
but DEFAULT to install in /usr/local/


So now, things like Tux Paint will ASSUME data will be stored in,
say, "/usr/local/share/tuxpaint/" or some-such, and the user must then
do a "make install" as root to get the Makefile to copy data to there.


-bill!

Re: [Super-tux-devel] File format

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

On Thu, Feb 19, 2004 at 07:33:43PM +0100, Ingo Ruhnke wrote:
> My biggest complains about the current format are basically that
> something like name=value looks a lot nicer then deriving the meaning
> of a value simply by its position and that there is a simple character
> to tile mapping, which limits the number of available tiles character
> pretty much (something like 80 when one wants to use just printable
> ASCII).

Heh, yeah, that's the way I often do it.  Sorry :^)

It's for a couple of reasons:

  1. I'm not usually interested in making a level editor for my games,
     so I just hand-code the levels using Emacs ;)

  2. My background is from the Atari 8-bit.  I would often just create
     a special character set ('font') which had the different shapes
     mapped to characters in the ATASCII character set, and then literally
     type them into my code or into a data file.

     Much like I did for BoboBot and SuperTux, except I'm limited to
     printable ASCII, rather than nearly 256 easily-typed and
     easily-printed ATASCII on the Atari ;)

-bill!

Re: [Super-tux-devel] Possible first level background?

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

On Thu, Feb 19, 2004 at 12:41:44PM +0100, Ingo Ruhnke wrote:
> offipso <of...@ab...> writes:
> 
> > Tell us what you think, here are the links:
> 
> Even so the graphic looks pretty nice, I think it fits neither the
> current graphic style nor the one that most likly will get used in the
> 0.1 release (unless somebody of course comes up with something
> better)[1].

I agree.  It's also a bit to crisp and clear, and would kind of interfere
with the foreground graphics.  I also don't understand how or it the
background would scroll.

OTOH, the art was great, so if the artist can help out somewhere else
in this project (or on another project... say, Tux Paint? ;^) ), please
encourage it! :^)

-bill!

Re: [Super-tux-devel] File format

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

ri...@ae... writes:

>  To implement tiles like the ones decribed in the development page, 
> I think we need to: 
> - create a config file with all the tiles and the information about
> them;
> - make tiles code flexible; 

Yep, tile-id to filename mapping and collision behaviour of a tile
should be configurable via file and not hardcoded as it is now, would
make it quite a bit easier to add new tiles.

>  My point is that we need a file format, since the level and 
> highscore ones should be more flexible and use a common system to 
> read them. 
>  In my opinion, we don't need a very complex file format, so I vote 
> for a kde/windows (.ini) like file format. 

.ini is as far as I know pretty much unstructured (beside the group
headings of course), its fine for simple name -> value mappings, but
for a level format a little bit more structure is needed. I vote for
.xml, s-expressions (aka lisp stuff) or something based on a scripting
language we use (ie a python list or something like that). In
Windstille my levels currently look kind of like this:

(windstille-level
 (properties
  (name "Hello World"))

 (scripts "level_script.scm")

 (objects
  (igel (pos 10 20)
        (direction left)))

 (tilemap
  (width 10) (height 20)
  (data 
   0  0  0  0  0  0  0  0  0  0
   0  0  0  0  0  0  0  0  0  0
   0  0  0  0  0  0  0  0  0  0
   ...
   8  8  8  8  8  8  8  8  8  8)))

My biggest complains about the current format are basically that
something like name=value looks a lot nicer then deriving the meaning
of a value simply by its position and that there is a simple character
to tile mapping, which limits the number of available tiles character
pretty much (something like 80 when one wants to use just printable
ASCII). It might not be a problem for the 0.1 release, but for later
versions it will become problematic. Currently I have already 44 tiles
and thats just one theme and without much background or variation in
the tiles, so the final number will easily be ten times larger.

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

Re: [Super-tux-devel] 2 player mode

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

ri...@ae... writes:

> Anyway, for now, a 2p cooperative gameplay is possible and in the
> future, special levelsets for co-2p should be created.

Yep.
 
>  About the respawn, I think that when a player dies, the other
> should be able to keep playing, and when both dies, the level should
> be reseted. Lives should be kept separated.
  
I don't think thats a good idea, I am more thinking of having special
respawn points/blocks for the second player or automatic respawn and
such, lives should also be split across the players and similar things
that keep both players alive as long as possible. After all there is
nothing more boring in a coop-game than actually not being able to
play.

>  This can be easily done... As Tobias said, let's wait for the 0.0.6
> release before implementing this.

I guess its better to wait with this after the 0.1 release, after all
single player will already be enough of work to get right and fun.
Multiplayer will make this just quite a bit more complicated, due to
the interaction of the two players.

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

[Super-tux-devel] File format

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

Hey there,=20
=20
 To implement tiles like the ones decribed in the development page,=20
I think we need to:=20
- create a config file with all the tiles and the information about=20
them;=20
- make tiles code flexible;=20
- improve collisions between tiles and the player.=20
=20
=20
 My point is that we need a file format, since the level and=20
highscore ones should be more flexible and use a common system to=20
read them.=20
 In my opinion, we don't need a very complex file format, so I vote=20
for a kde/windows (.ini) like file format.=20
 This is how my BobbleBubble game levels looks like:=20
=20
=AB=20
[LEVELS]=20
totallevels=3D3;=20
=20
[LEVEL1]=20
tile=3Ddata/pattern1.bmp;=20
redshadow=3D240;=20
greenshadow=3D80;=20
blueshadow=3D220;=20
redbackclr=3D0;=20
greenbackclr=3D255;=20
bluebackclr=3D255;=20
pla1-row=3D10;=20
pla1-col=3D3;=20
pla2-row=3D10;=20
pla2-col=3D19;=20
row 0=3D11111111111111111111111111;=20
row 1=3D10000000000000000000011111;=20
row 2=3D10000000000000000000011111;=20
(....)=20
row27=3D11111111111111111111111111;=20
=BB=20
=20
 And this is a function that reds an entry, by feeding it with the=20
file path, group and entry name:=20
=AB=20
char* filemanager(const char *path, const char *group, const char=20
*entry)=20
{=20
FILE *file =3D fopen(path, "r");=20
if (file =3D=3D NULL)=20
	{=20
	cerr << "File: " << path << " couldn't be open\n";=20
	return NULL;=20
	}=20
=20
char buffer[1024];=20
static char entryvalue[1024];=20
char *ptr;=20
char *entryptr;=20
bool groupFound =3D false;=20
bool entryFound =3D false;=20
=20
while ((ptr =3D fgets(buffer, sizeof(buffer), file)) !=3D NULL)=20
	{=20
	if (ptr[0] =3D=3D '#')	// comment=20
		continue;=20
=20
	if((groupFound =3D=3D true) && ((entryptr =3D strstr(ptr, entry))=20
!=3D NULL))=20
		{=20
		entryptr +=3D strlen(entry);=20
=20
		char *semicolonptr;		// will point to ;=20
		strcpy(entryvalue, entryptr);=20
=20
		if ((semicolonptr =3D strchr(entryvalue, ';')) =3D=3D=20
NULL)=20
			cerr << "ERROR: ; is missing in line: " <<=20
ptr << endl;=20
		else=20
			*semicolonptr =3D '\0';=20
		entryFound =3D true;=20
=20
		break;=20
		}=20
	if (ptr[0] =3D=3D '[')	// group symbol: [=20
		{=20
		groupFound =3D false;=20
		if (strstr(ptr, group) !=3D NULL)=20
			groupFound =3D true;=20
		}=20
	}=20
fclose(file);=20
if (entryFound =3D=3D false)=20
	{=20
	cerr << "ERROR: the " << entry << " entry was not found on "=20
<< group << " group in the file " << path << " ." << endl;=20
	return NULL;=20
	}=20
return entryvalue;=20
=20
// example:=20
//filemanager("/home/rick2/.kde/share/config/kppprc", "[Account1]",=20
"Password=3D");=20
}=20
=BB=20
=20
 What do you think?=20
=20
Ricardo Cruz=20
_________________________________________________________
Screensavers e wallpapers gr=E1tis: http://freegames.online.pt

Re: [Super-tux-devel] seg fault

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

=20
Hi,=20
=20
 This leads to a question, is SuperTux ready for the 0.0.6?=20
 C'mon, all the gameplay is screwed up and now this...=20
=20
 Anyway, I don't like the way that the data directory is found...=20
The data directory is setuped during the make, which is not that=20
brilliant, since a simple move of the game makes it not to work.=20
 I think that the installation directory should be setuped during=20
the make process, but the current dir, when the game is not=20
installed should use some hack like this one (from myself):=20
http://rpmcruz.planetaclix.pt/repository/system/index.html#curdir=20
=20
 Tobias, what do you think?=20
=20
Ricardo Cruz=20
=20
Citando Duong-Khang NGUYEN <neo...@us...>:=20
=20
>    Hey,=20
> =20
> What is going wrong with the current CVS ? I can't even launch the=20
game, it=20
> =20
> crashes when I choose "start game". However when I try to play via=20
Level =20
> Editor, it works.=20
> =20
> I have just updated my working directory. It's 10:40 am GMT here.=20
> =20
> =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=20
> [neurone@Neo workst]$ ./supertux=20
> Warning: No joysticks are available.=20
> name found=20
> Fatal signal: Segmentation Fault (SDL Parachute Deployed)=20
> =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=20
> =20
> =20
_________________________________________________________
Screensavers e wallpapers gr=E1tis: http://freegames.online.pt

Re: [Super-tux-devel] 2 player mode

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

=20
Hi,=20
=20
 You're right, Ingo, I've not thought about levels that can have a=20
path that is impossible for two players...=20
 Anyway, for now, a 2p cooperative gameplay is possible and in the=20
future, special levelsets for co-2p should be created.=20
=20
 I don't like screen spliting that much, this way would be pretty=20
cool.=20
 About the respawn, I think that when a player dies, the other=20
should be able to keep playing, and when both dies, the level should=20
be reseted. Lives should be kept separated.=20
=20
 This can be easily done... As Tobias said, let's wait for the 0.0.6=20
release before implementing this.=20
=20
Ricardo Cruz=20
=20
Citando Ingo Ruhnke <gr...@gm...>:=20
=20
> ri...@ae... writes:=20
> =20
> >  Tobias mentioned that the code is written in a object oriented=20
way=20
> > and implementing a 2players mode would be trivial... Guess what,=20
it=20
> > is :) Here you have a screenshot.=20
> =20
> Well, codewise a 2 player mode is relativly simple, gameplay wise=20
> however it is not. With SuperTux0.1 it might be doable, since it=20
will=20
> be a linear game, no backscrolling, levels of limited height, etc.=20
But=20
> as soon as it would get backscrolling, levels with multiple=20
possible=20
> paths, etc. 2d player mode becomes quite difficult to manage from=20
a=20
> gameplay point of view. With just a single screen one would have=20
> massive problems coordinating both players to walk the same path,=20
> respawning and stuff like that, splitscreen can help, but limits=20
the=20
> visible area quite a bit and spoils a lot of the fun. A normal=20
> singleplayer level (even a simple 0.1 one) can also feature lots=20
of=20
> situations that are only walkable once, ie jump on a enemy to=20
cross an=20
> hole, donut blocks, and similar stuff, so once the first player as=20
> walked the path, it gets unwalkable for the second player.=20
Basically,=20
> the normal single player levels wouldn't work well for=20
multiplayer,=20
> some might be completly unplayable.=20
> =20
> I am not saying that a two player mode wouldn't be worth to have,=20
just=20
> that simply adding another human controllable sprite to the screen=20
> alone won't be a complete 2 player mode. A 2 player mode would=20
pretty=20
> much need a completly different set of levels and different=20
enemies or=20
> enemy behaviour to be really fun.=20
> =20
> It might be a nice idea to provide something similar like the=20
original=20
> MarioBros (the non-scrolling one) for Supertux:=20
> =20
> http://www.atarihq.com/museum/5200/games/screen/mario3.jpg=20
> =20
> -- =20
> WWW:      http://pingus.seul.org/~grumbel/ =20
> JabberID: gr...@ja... =20
> ICQ:      59461927=20
> =20
> =20
> -------------------------------------------------------=20
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.=20
> Build and deploy apps & Web services for Linux with=20
> a free DVD software kit from IBM. Click Now!=20
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick=20
> _______________________________________________=20
> Super-tux-devel mailing list=20
> Sup...@li...=20
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel=20
> =20
_________________________________________________________
Screensavers e wallpapers gr=E1tis: http://freegames.online.pt

[Super-tux-devel] A few patches

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

   =20
Hey there,   =20
   =20
 These are some hack that I was working on... I've merged them and   =20
here they go.   =20
   =20
icon-xpm.patch (and icon.xpm)   =20
Currently SuperTux uses the png format for the icon. PNG is a   =20
non-native X11 format and so needs a mask to be made. XPM is much   =20
more flexible for artists, allowing transparencies to be easily made   =20
without having to make a mask. Use the icon, I appended or just   =20
convert the current one to xpm.   =20
This also makes seticon() to be called before the text load that   =20
takes awhile.   =20
   =20
lettersloadspeedup.patch   =20
Each character is currently kept in a array, which makes it to be   =20
pretty slow to be load during the startup (15 seconds in my laptop).   =20
This keeps the fonts in a texture and then just blits a part of it.   =20
(takes 2 seconds to load).   =20
Tobias, this doesn't break your work with the spliting of numerical  =20
fonts with the others.   =20
It also fixes the erase_text functions, that were making letters to   =20
be badly removed in the intro, and moves them to text.c.   =20
   =20
(Tobias, what about putting all gfx related files in a directory   =20
together?)   =20
   =20
leveleditor-changes.patch (and highlight.png)   =20
This fixes level editor scrolling. There is a little issue, when   =20
pressing a key, the mouse motion value gets equal to the ascii value   =20
of the key pressed. It's surely a SDL issue, my version is 1.2.5...   =20
Does this happens in yours? (an hack can be made to work around   =20
this). =20
Now, user has to press to select a tile and selection of multiple   =20
tiles is possible. This will be usefull when the interface is ready.   =20
   =20
videomodechange.patch   =20
This makes an option to change from OpenGL and SDL frontends in the=20
menu by restarting the apps and returning to the main menu.   =20
This option should be disabled during the game (I can't run the   =20
game, so...). It also should display a 'are you sure' dialog, saying=20
that opengl could be damn slow in non-accel cards.=20
It also removes unecessary (highscore drawing duplicated) code from   =20
title.c   =20
   =20
Cheers,   =20
 Ricardo Cruz   =20
_________________________________________________________
Vem experimentar jogos gr=E1tis: http://freegames.online.pt

Re: [Super-tux-devel] FPS issue

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

Am Do, den 19.02.2004 schrieb Duong-Khang NGUYEN um 05:49:
>     Hi,
> 
>    This message is especially for Tobias. I think I can get rid of the current 
> bad bugs. However, the problem is that you calculate the "frame_ratio" during 
> the game. It's better that you calculate its average during the first 
> 10seconds for example and stop playing with it later. As Ingo said, I think 
> that we should stick with a fix FPS. Another problem is the movement of tux 
> now depends on the "frame_ratio". That's why tux moves weirdly. And the old 
> codes will work perfectly if you put 4 roundf() in "player.c"

I'll send a detailed CVS status report tonight. I'm afraid that I
haven't found the time yet.

The method you described could be a solution.

As I stated in another mail the current movement code of Tux is
"completely" destroyed (I was it) for a few reasons (to make it better
:) ) and we'll hopefully see the best SuperTux ever after that is
resolved.

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] Possible first level background?

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

offipso <of...@ab...> writes:

> Tell us what you think, here are the links:

Even so the graphic looks pretty nice, I think it fits neither the
current graphic style nor the one that most likly will get used in the
0.1 release (unless somebody of course comes up with something
better)[1]. It might also be worth to do the background itself as a
tilemap, instead of one huge bitmap, thus leading to more freedom on
the leveldesigners side.

[1] http://pingus.seul.org/~grumbel/tmp/windstille-tux2.jpg
    http://pingus.seul.org/~grumbel/tmp/windstille-tux4.jpg
    http://pingus.seul.org/~grumbel/tmp/windstille-tux3.jpg
-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

[Super-tux-devel] FPS issue

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

    Hi,

   This message is especially for Tobias. I think I can get rid of the current 
bad bugs. However, the problem is that you calculate the "frame_ratio" during 
the game. It's better that you calculate its average during the first 
10seconds for example and stop playing with it later. As Ingo said, I think 
that we should stick with a fix FPS. Another problem is the movement of tux 
now depends on the "frame_ratio". That's why tux moves weirdly. And the old 
codes will work perfectly if you put 4 roundf() in "player.c"


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

[Super-tux-devel] seg fault

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

   Hey,

What is going wrong with the current CVS ? I can't even launch the game, it 
crashes when I choose "start game". However when I try to play via Level 
Editor, it works.

I have just updated my working directory. It's 10:40 am GMT here.

======================================
[neurone@Neo workst]$ ./supertux
Warning: No joysticks are available.
name found
Fatal signal: Segmentation Fault (SDL Parachute Deployed)
======================================

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

[Super-tux-devel] Possible first level background?

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

Hello, my friend and I made a replacement background for the first few
levels, seeing as the previous one was sort of, er...lacking.

Tell us what you think, here are the links:

http://www.abeminds.com/arctic_background.png (640x480 PNG)
http://www.abeminds.com/arctic_background.big.png (1024x768 PNG)

I haven't had the chance to try them in the current CVS Super Tux, as it
doesn't work for me...but that's a topic for another thread.

-Dan Koestler
Background drawn by Lawrence Burns

[Super-tux-devel] Lidl CVS status update

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

Hi all,

I finally commited the stuff.

But...

there is still a lot to be finish in the leveleditor.

and...

the player's collision detections with the world and the player's
physics are completely broken. So it's a known "bug".
The physics of bad guys are better than ever on the other hand. :)

A few 0.0.6 features aren't implemented yet, but
should be relativly trivial to implement, esspecially the LOAD/SAVE
feature,
because the most code for it is in place.

This mail is too short to give you a good overview about the current
CVS status and I'll have to send a detailed report after I come back
from school tomorrow. :)

Greetz...

Tobias Gläßer

--