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

Re: [Super-tux-devel] Date in source files

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

Am So, den 28.12.2003 schrieb Bill Kendrick um 02:31:
> When you guys see something like this:
> 
>   April 22, 2000 - July 15, 2002
> 
> 
> Would you mind updating the date when you change the source?  e.g.:
> 
>   April 22, 2000 - December 27, 2003
> 
> 
> :) Thx!

Maybe I'm a bit careless, but I think it is enough to remember this,
when preparing a new release? Ok, I'll be responsible for seeing that
from now on. :)

Greetz...

Tobias Gläßer

[Super-tux-devel] Commited!

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

Hi all,

the patches from Ricardo and DK have been commited to CVS.
Moreover the menu has been improved with Ricardo's help. .)

Note: I have changed some things in the level-editor and
marked the to features "Load Level" and "New Level" as FIXME,
because they aren't implemented. I'd like to see something like
a file-dialog to load a level and a possibility to specify the name
and some initial variables (length of the level for example) for
a new level.

Greetz...

Tobias Gläßer (expecting patches for the level-editor)
-- 

Re: [Super-tux-devel] stereo sound patch. Stereo effect issue

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

I agree with all Duong-Khang said. :)
Why? The results convinced me. ;) That's real stereo man.

Greetz...

Tobias Gläßer ( And no, I haven't a Home Threater System :( *cry )

Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 19:01:
> > Duong-Khang NGUYEN <neo...@us...> writes:
> > > 2. Adds: Stereo sound effects. In "gameloop.c" the kicked laptop now
> > > produces stereo sound depending on the position of SuperTux
> >
> > I don't think that the position of Tux itself should be used for
> > calculating the sound position, but instead the center of the
> > screen/camera. After all the view of the player and Tux are not really
> > the same, even so there are pretty close most of the time.
> 
> I don't agree with your opinion since in SuperTux, you have your eyes stuck on 
> Tux and it makes sense to calculate the sound panning from the tux's 
> position. Just imagine that you have your Tux at the left hand side on the 
> screen and there's a bad guy at your right hand side. However since the bad 
> guy is in the left half of the screen you play the sound at the left speaker 
> (IOW, all the panning effects to the left). The sound let you think that 
> there's another bad guy who is coming from the left of Tux whereas the bad 
> guy is just there at your right hand side. It will lead to confusion I think.
> 
> > > 3. Changes: "play_sound( Mix_Chunk * snd)"
> > >      now is "play_sound( Mix_Chunk * snd, enum Sound_Speaker whichSpeaker
> > > )" where whichSpeaker is
> > >                 SOUND_CENTER_SPEAKER,
> > >                 SOUND_LEFT_SPEAKER,
> > >                 SOUND_RIGHT_SPEAKER
> >
> > Why limit the sound to just three enums? Wouldn't it be better to have
> > a play_sound(Mix_Chunk* snd, float pos) and thus allow sound to be
> > positioned exactly, instead of being one speaker or the other
> 
> Why only three enums ? It's because the others are NOT really useful. Here are 
> the reasons: the panning effects are simulated by manipulating the left and 
> the right channel volumes. If you give the left volume 60% and the right 
> volume 40% of the total volume power in order to "position" exactly the 
> effects, the sound produced is not that stereo. In addition, with the music 
> turned on, you won't be able to distinguish obviously the effects. I've just 
> unplugged my laptop from the Home Threater System to test this and the 
> effects are nearly unrecognizable.
> 
> > (center
> > will never be reached, since tux_x won't be equal to bad_guy_x in
> > practice)?
> 
> Yes, but hardly. I didn't compare "tux_x" and "bad_guy_x" but "tux_x + 
> scroll_x" and "bad_guy_x". I think I'll put some toleration or interval for 
> the center panning to improve it.
> 
> I think you have some confusion between the sound panning effects and the 
> sound's attenuation effect. In fact, the sound panning plus the sound's 
> attenuation can help simulating the sound position. Currently, there's only 
> sound panning implemented. Maybe I'll combine the sound's attenuation effect 
> in the near future ...
> 
> > --
> > WWW:      http://pingus.seul.org/~grumbel/
> > JabberID: gr...@ja...
> > ICQ:      59461927
-- 

Re: [Super-tux-devel] stereo sound patch. Stereo effect issue

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

> Duong-Khang NGUYEN <neo...@us...> writes:
> > 2. Adds: Stereo sound effects. In "gameloop.c" the kicked laptop now
> > produces stereo sound depending on the position of SuperTux
>
> I don't think that the position of Tux itself should be used for
> calculating the sound position, but instead the center of the
> screen/camera. After all the view of the player and Tux are not really
> the same, even so there are pretty close most of the time.

I don't agree with your opinion since in SuperTux, you have your eyes stuck on 
Tux and it makes sense to calculate the sound panning from the tux's 
position. Just imagine that you have your Tux at the left hand side on the 
screen and there's a bad guy at your right hand side. However since the bad 
guy is in the left half of the screen you play the sound at the left speaker 
(IOW, all the panning effects to the left). The sound let you think that 
there's another bad guy who is coming from the left of Tux whereas the bad 
guy is just there at your right hand side. It will lead to confusion I think.

> > 3. Changes: "play_sound( Mix_Chunk * snd)"
> >      now is "play_sound( Mix_Chunk * snd, enum Sound_Speaker whichSpeaker
> > )" where whichSpeaker is
> >                 SOUND_CENTER_SPEAKER,
> >                 SOUND_LEFT_SPEAKER,
> >                 SOUND_RIGHT_SPEAKER
>
> Why limit the sound to just three enums? Wouldn't it be better to have
> a play_sound(Mix_Chunk* snd, float pos) and thus allow sound to be
> positioned exactly, instead of being one speaker or the other

Why only three enums ? It's because the others are NOT really useful. Here are 
the reasons: the panning effects are simulated by manipulating the left and 
the right channel volumes. If you give the left volume 60% and the right 
volume 40% of the total volume power in order to "position" exactly the 
effects, the sound produced is not that stereo. In addition, with the music 
turned on, you won't be able to distinguish obviously the effects. I've just 
unplugged my laptop from the Home Threater System to test this and the 
effects are nearly unrecognizable.

> (center
> will never be reached, since tux_x won't be equal to bad_guy_x in
> practice)?

Yes, but hardly. I didn't compare "tux_x" and "bad_guy_x" but "tux_x + 
scroll_x" and "bad_guy_x". I think I'll put some toleration or interval for 
the center panning to improve it.

I think you have some confusion between the sound panning effects and the 
sound's attenuation effect. In fact, the sound panning plus the sound's 
attenuation can help simulating the sound position. Currently, there's only 
sound panning implemented. Maybe I'll combine the sound's attenuation effect 
in the near future ...

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


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

[Super-tux-devel] Graphics

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

Hi all,

I suggest following solution.
Let's have ONE really good (geek) level-set. (I doubt that there will be
enough good graphics-people joining this project)
But, if there exist a graphic with the same name in the leveltheme
(note: not a level-set), this graphic could be used instead.
This would be a simple and working solution.

Do you agree? :)

Greetz...

Tobias Gläßer

Am So, den 28.12.2003 schrieb Ingo Ruhnke um 15:19:
> Ricardo Cruz <ri...@ae...> writes:
> 
> >  I agree with you, but maybe the enemies could change according to
> > the colection of levels... It would be cool to have a geek, a candy,
> > a jugle, a marcian... worlds...
> 
> For the moment I would focus more on having one really good set of
> tiles, enemies, etc. instead of having all much different level sets.
> Over time one can still create additional levelsets, but for the
> beginning one really good set is much more important. With the enemies
> it is pretty much the same, having a solid basic set of enemies (all
> with different abilites) is much more important than having a wide
> verity of enemies different looking enemies, but with pretty much all
> the same behaviour. Even with just a simple basic set of enemies one
> can get quite a good level of variation by changing colors and
> behaviour a little bit (ie make them faster, larger, stronger, etc).
> PS: Would anybody care to set the list to automatically insert a
> 'reply-to' back to the list?
>  -> http://www.metasystema.net/essays/reply-to.mhtml
-- 

Re: [Super-tux-devel] file-structure

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

If nobody responses, I'll interpret this as a 'Yes, we agree all!'. :)

Greetz...

Tobias Gläßer

Am So, den 28.12.2003 schrieb Tobias Gläßer um 19:11:
> Hi all,
> 
> let's expect that the most users will use a installed supertux.
> 
> /usr/local/games/supertux <-
> 
> A user without root-privileges could not make levels in this case.
> Therefore a suggest the following extension:
> 
> ~/.supertux/levels
> ~/.supertux/themes(/mynewtheme)
> ~/.supertux/music
> 
> Greetz...
> 
> Tobias Gläßer
-- 

Re: [Super-tux-devel] indentations

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

>  Tobias, in the menu.c, you should replace all NO_UPDATE by UPDATE and then 
> remove the SDL_Flip(screen); line. This is the cause of the menu flickering, 
> because the background is being drawn by intro.c or gameloop.c, the text 
> entries are only drawn after and repeat the screen blitting, that was done 
> before.
>  Another solution would be to disable UPDATE in the intro.c and gameloop.c and 
> keep the rest as it is.

Thanks for your hint. :)

> Anxious to see my level editor in the cvs :),
>  Ricardo

Please be patient. ;)

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] indentations

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

 Well, I think that Tabs should be used at the begging of the line and spaces 
between stuff. Just like a document, where the 1st line is more inside than 
the rest of the paragraph.
 Comments and inside stuff should go for spaces.

--

 Tobias, in the menu.c, you should replace all NO_UPDATE by UPDATE and then 
remove the SDL_Flip(screen); line. This is the cause of the menu flickering, 
because the background is being drawn by intro.c or gameloop.c, the text 
entries are only drawn after and repeat the screen blitting, that was done 
before.
 Another solution would be to disable UPDATE in the intro.c and gameloop.c and 
keep the rest as it is.

Anxious to see my level editor in the cvs :),
 Ricardo

Em Domingo, 28 de Dezembro de 2003 19:55, o Ingo Ruhnke escreveu:
> Ricardo Cruz <ri...@ae...> writes:
> > Anyway, I keep thinking why are ppl so scared of the Tabs! Really,
> > tabs are the best thing since sliced bread.
>
> The problem with tabs is that many 'clever' text-editors are just a
> bit too clever handling them, ie. Emacs converts tabs and spaces from
> one to another pretty much randomly (have a tab and go backspace ->
> you get 7 spaces instead of removing the tab), resulting in a huge
> mess if viewed in another editor or with anotehr tab-width. One can
> fix Emacs to not do that, but its really far from streight forward.
> After all the easiest way to 'fix' this is to completly avoid tabs and
> use spaces always, this of course removes the freedom to use another
> tab width, but ensures that the sources looks everywhere the same
> (which is good or bad, depending on if you like the source look).

-- 
Brain damage is all in your head.
-- Karl Lehenbauer

Re: [Super-tux-devel] indentations

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

Em Domingo, 28 de Dezembro de 2003 19:24, o Ingo Ruhnke escreveu:
> Tobias Gl=E4=DFer <tob...@gm...> writes:
> > The indentations I use are so called GNU indentations. I have a
> > program, wich "reformats" the sources to GNU indentations (used in
> > the Linux kernel AFAIK) automatically and I usually do this before
> > commiting to CVS.
>
> Don't let Linus hear that, GNU and Linux indentation style is quite
> differnt:
>
> http://pantransit.reptiles.org/prog/CodingStyle.html

 Wow! Nice to see a celebrity around ;)
 Anyway, I keep thinking why are ppl so scared of the Tabs! Really, tabs ar=
e=20
the best thing since sliced bread.

Ricardo

=2D-=20
An artist should be fit for the best society and keep out of it.

Re: [Super-tux-devel] Leveleditor first release

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

(the dumb kmail was replying only to the person that send the mail to the=20
list, so i am resending this mail to the all list)

Hey all,

Em Domingo, 28 de Dezembro de 2003 16:20, o Duong-Khang NGUYEN escreveu:
> Le Dimanche 28 D=E9cembre 2003 12:46, vous avez =E9crit :
> >  This game will be played by very little children, so a built-in editor
> > would be much easier to use for those.
>
> By stand-alone I mean there's the game "supertux" and another executable
> file "supertuxle" or something like that. It's as easy to use as the
> builtin editor I believe
>

 As Tobias mentioned, it would be cool to have a test option. Could be easi=
ly=20
implemented in an internal editor.
 Futhermore, different executables could be easy to use for us, but not for=
 a=20
child.

> >  Did you find the code to be too straight? If you didn't like this, you
> > probabily had an heart attack when looking at the old gameloop function.
> > ;P I could put the key events in a different function, I just didn't
> > because I don't like global variables that much.
>
> I don't like the way you use the global variables and the way you call the
> function from gameloop.c. I think that functions from gameloop.c are not
> for external use. And last but not least, the way you manipulate pointers
> don't fit me much.
>

 I would like to know more about what you find wrong in my pointers=20
manipulation... Really, I am not an experienced programmer and I am comited=
=20
to improve my coding.
 Anyway, about the =ABfunctions from gameloop.c are not for external use=BB.

 Tobias said:
> Moreover maintaining the level-editor seperate would be a bad idea IMHO,
> because both could share some code. (remember encapsulation)
> Give it a chance. If you still think it is that bad, when I've commited
> it, then we can still create a seperate level-editor.

 What do you guys think it would be better, that the level editor called=20
gameloop functions or not?
 Currently, 6 gameloop funcs are called and 2 were forked. I had to fork th=
em=20
because they have some stuff that had to be different, but these two could =
be=20
easily changed in gameloop, in order to level editor call them from there.

 Anyway, I think a level editor should be internal, since it wouldn't spend=
=20
much code (2 files) and integration is very cool.
 Now, should it use gameloop functions or not? Using them would lead to=20
simpler code in the leveleditors files, at the same time, it would lead to=
=20
harder code to debug and a change in gameloop could break or, even worse,=20
create nasty and not right way visible bugs in the level editor.

Regards,
 Ricardo

=2D-=20
Tact, n.:
	The unsaid part of what you're thinking.

Re: [Super-tux-devel] Comminting the level editor

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

(the dumb kmail was replying only to the person that send the mail to the=20
list, so i am resending this mail to the all list)

Hey folks,

 Tobias, that's fine. I'll then send you a patch to add support for frames.=
=20
I've used the same method as the gameloop.. Not bad to add some delays, or=
=20
else the cpu would had to be allways working for it...
 Maybe you could give me access to cvs... (my nick at sourceforge is rmcruz=
).

 Anyway, as soon as the cvs comes out, I would like you guys to complain if=
=20
some key is not work (as I explained in a previous mail).
 I would also like to get ideas about a possible interface. I think I might=
=20
start working on it, while i am at holidays...

See you,
 Ricardo

Em Domingo, 28 de Dezembro de 2003 19:21, o Tobias Gl=C3=A4=C3=9Fer escreve=
u:
> Hi,
>
> I'm currently integrating your Level-Editor into Supertux.
> This will take 1 or 2 days, stays tuned. :)
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
>
> Am So, den 28.12.2003 schrieb Ricardo Cruz um 06:05:
> > Hey,
> >
> >  As Tobias Gl=C3=A4=C3=9Fer told me to, I've outputed 'cvs diff' to a f=
ile (patch),
> > here it goes. Seems like the new files were not added to it, so I'm also
> > appending them.
> >  I suggest the image to be placed in a data/images/leveleditor director=
y.
> > But if you want to change, edit leveleditor.c (line 84) to relflect the
> > new directory.
> >
> >   I've noticed that you've updated LEVELDESIGN, and so I've also added
> > support to add bad guys.
> >
> >  Please, tell me if all the keys are working (press F1 to see all keys),
> > because SDL doesn't allow me to know if a person is pressing '$', for
> > instance. In this case, I would have to ask if '4' is being pressed and
> > if the Shift modifier is active. In some keyboards '$' could be in top =
of
> > another key...
> >
> > Good work,
> >  Ricardo Cruz

=2D-=20
Never worry about theory as long as the machinery does what it's supposed t=
o=20
do.
		-- R. A. Heinlein

Re: [Super-tux-devel] Firey Tux

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

(the dumb kmail was replying only to the person that send the mail to the=20
list, so i am resending this mail to the all list)

Hey grumbel,

 I agree with you, but maybe the enemies could change according to the=20
colection of levels... It would be cool to have a geek, a candy, a jugle, a=
=20
marcian... worlds...
 Ingo, what do you think about this?

Ricardo

Em Domingo, 28 de Dezembro de 2003 19:48, o Ingo Ruhnke escreveu:
> Tobias Gl=E4=DFer <tob...@gm...> writes:
> > Hmm, its better than before at least. But wouldn't it be better, if Tux
> > actually had something in his hands you can shoot with? Something like a
> > gun for geeks and nerds? A KEYBOARD? *eh
>
> How about something non-real-world based? My biggest complaint about
> SuperTux and quite a few other Tux based games is the complete lack of
> originality. Just using Tux and adding a bunch of computers, Windows
> logos and geek stuff does really not make a good looking game, no
> matter how good the graphics are. After all having a believable and
> consistend game world is important and I don't really see how that
> could ever be created buy a bunch of laptops and cups of coffe. Beside
> that the laptop has the problem of not having a well defined upper
> side, so it doesn't really offer all that much space to jump on from a
> players point of view.

=2D-=20
Do something unusual today.  Pay a bill.

Re: [Super-tux-devel] Leveleditor first release -> Ricardo Cruz, Bill & Tobias

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

(the dumb kmail was replying only to the person that send the mail to the=20
list, so i am resending this mail to the all list)

Hi,

Em S=E1bado, 27 de Dezembro de 2003 10:49, o Duong-Khang NGUYEN escreveu:
> >  As I told you, I was doing a built-in level editor for SuperTux.
> >  I have not been able to develop much (Christmas time ;) ), but I have
> > finally managed to complete a workable version.
>
> As Bill, I prefer a seperate level editor ! Any different vote for this ?
>

 This game will be played by very little children, so a built-in editor wou=
ld=20
be much easier to use for those.

> >  I noticed, that a file called enemy.h has been added, I advice you to
> > use the same nomenclature, so you should call it badguy.h . And are you
> > thinking in turning SuperTux in C++?
>
> I'll declare war to anyone who want to turn SuperTux into C++ ! Originall=
y,
> SuperTux is written in C by Bill, and he thought it in C. If anyone want =
to
> write SuperTux in C++, he must start from scratch and think in C++ way.
> We're going to vote for this (ah long life to the Democracy). However, if
> you guys really want to write things in C++, I suggest to break the curre=
nt
> CVS tree into 2 different CVS trees: the C++ and the old C one. And I'll =
be
> voluntary to maintain the so old C source tree of course. IMHO, in order =
to
> program WELL in C++, we need a lot of work !

 Well, I just asked this because the world.h, badguy.h and player.h have a=
=20
line saying 'C++ Interface:'.
 I've also found some comments using //. Is this already ANSI C and/or can =
I=20
use it (/* */ are annoying :P)?

Em S=E1bado, 27 de Dezembro de 2003 12:07, o Duong-Khang NGUYEN escreveu:
>     I've just tried out the leveleditor codes and I have some kind of BAD
> impression! I don't want to be harmful but I seriously think that your
> works will be more appreciable as a stand-alone leveleditor.
>    What do you think Tobias & Bill ?
>
> Duong-Khang NGUYEN (who looks like an evil devil at the moment >:-( )

 Did you find the code to be too straight? If you didn't like this, you=20
probabily had an heart attack when looking at the old gameloop function. ;P
 I could put the key events in a different function, I just didn't because =
I=20
don't like global variables that much. I'm also not very used to write in C.

 I think the code is too simple and at the same time it outputs a very easy=
 to=20
use level editor. A mouse-driven interface is obviously needed, I could wor=
k=20
on this, but I would like you guys to suggest the layout...


 I also didn't like (neither understood) the identation you have used in th=
e=20
game.
 Firstly, I think tabs should be used at the beggining of the line, since=20
everyone can setup tabs (mine is settuped to be 2 spaces) and so it doesn't=
=20
make as much mess as spaces do (you don't have to care).
 I'm also very used to this type of identation:
if(bad_guy.alive)
<TAB>{
<TAB>kill_the_bastard();
<TAB>if(screen.update =3D=3D false)
<TAB><TAB>refresh();
<TAB>}

 Of course, I will use the identation you find more appropriate...


 I almost forgot to mention (you will notice! :)) that there is a bug: when=
=20
pressing some keys, the screen scrolls back.
 I think it is being caused by the mouse keys code:
x =3D event.motion.x;
if(x < MOUSE_LEFT_MARGIN)
   pos_x -=3D MOUSE_POS_SPEED;
else if(x > MOUSE_RIGHT_MARGIN)
   pos_x +=3D MOUSE_POS_SPEED;

 Is this wrong or isn't SDL giving event.motion.x right...

Cya,
 Ricardo

=2D-=20
In 1880 the French captured Detroit but gave it back ... they couldn't
get parts.

Re: [Super-tux-devel] Firey Tux

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

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

>  I agree with you, but maybe the enemies could change according to
> the colection of levels... It would be cool to have a geek, a candy,
> a jugle, a marcian... worlds...

For the moment I would focus more on having one really good set of
tiles, enemies, etc. instead of having all much different level sets.
Over time one can still create additional levelsets, but for the
beginning one really good set is much more important. With the enemies
it is pretty much the same, having a solid basic set of enemies (all
with different abilites) is much more important than having a wide
verity of enemies different looking enemies, but with pretty much all
the same behaviour. Even with just a simple basic set of enemies one
can get quite a good level of variation by changing colors and
behaviour a little bit (ie make them faster, larger, stronger, etc).

PS: Would anybody care to set the list to automatically insert a
'reply-to' back to the list?
 -> http://www.metasystema.net/essays/reply-to.mhtml

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

Re: [Super-tux-devel] indentations

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

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

> Anyway, I keep thinking why are ppl so scared of the Tabs! Really,
> tabs are the best thing since sliced bread.

The problem with tabs is that many 'clever' text-editors are just a
bit too clever handling them, ie. Emacs converts tabs and spaces from
one to another pretty much randomly (have a tab and go backspace ->
you get 7 spaces instead of removing the tab), resulting in a huge
mess if viewed in another editor or with anotehr tab-width. One can
fix Emacs to not do that, but its really far from streight forward.
After all the easiest way to 'fix' this is to completly avoid tabs and
use spaces always, this of course removes the freedom to use another
tab width, but ensures that the sources looks everywhere the same
(which is good or bad, depending on if you like the source look).

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

Re: [Super-tux-devel] Firey Tux

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

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

> Hmm, its better than before at least. But wouldn't it be better, if Tux
> actually had something in his hands you can shoot with? Something like a
> gun for geeks and nerds? A KEYBOARD? *eh

How about something non-real-world based? My biggest complaint about
SuperTux and quite a few other Tux based games is the complete lack of
originality. Just using Tux and adding a bunch of computers, Windows
logos and geek stuff does really not make a good looking game, no
matter how good the graphics are. After all having a believable and
consistend game world is important and I don't really see how that
could ever be created buy a bunch of laptops and cups of coffe. Beside
that the laptop has the problem of not having a well defined upper
side, so it doesn't really offer all that much space to jump on from a
players point of view.

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

Re: [Super-tux-devel] stereo sound patch

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

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

> 2. Adds: Stereo sound effects. In "gameloop.c" the kicked laptop now produces 
> stereo sound depending on the position of SuperTux

I don't think that the position of Tux itself should be used for
calculating the sound position, but instead the center of the
screen/camera. After all the view of the player and Tux are not really
the same, even so there are pretty close most of the time.

> 3. Changes: "play_sound( Mix_Chunk * snd)"
>      now is "play_sound( Mix_Chunk * snd, enum Sound_Speaker whichSpeaker )"
>      where whichSpeaker is
>                 SOUND_CENTER_SPEAKER,
>                 SOUND_LEFT_SPEAKER,
>                 SOUND_RIGHT_SPEAKER

Why limit the sound to just three enums? Wouldn't it be better to have
a play_sound(Mix_Chunk* snd, float pos) and thus allow sound to be
positioned exactly, instead of being one speaker or the other (center
will never be reached, since tux_x won't be equal to bad_guy_x in
practice)?

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

Re: [Super-tux-devel] indentations

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

Am So, den 28.12.2003 schrieb Ingo Ruhnke um 14:24:
> Tobias Gläßer <tob...@gm...> writes:
> 
> > The indentations I use are so called GNU indentations. I have a
> > program, wich "reformats" the sources to GNU indentations (used in
> > the Linux kernel AFAIK) automatically and I usually do this before
> > commiting to CVS.
> 
> Don't let Linus hear that, GNU and Linux indentation style is quite
> differnt:
> 
> http://pantransit.reptiles.org/prog/CodingStyle.html

You are right. I now saw, that KDevelop3 can format the source for GNU
or for Linux style. I selected the style, wich is closest to Bill's
coding style and this is indeed the GNU style.

Greetz...

Tobias Gläßer

-- 

Re: [Super-tux-devel] indentations

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

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

> The indentations I use are so called GNU indentations. I have a
> program, wich "reformats" the sources to GNU indentations (used in
> the Linux kernel AFAIK) automatically and I usually do this before
> commiting to CVS.

Don't let Linus hear that, GNU and Linux indentation style is quite
differnt:

http://pantransit.reptiles.org/prog/CodingStyle.html

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

[Super-tux-devel] file-structure

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

Hi all,

let's expect that the most users will use a installed supertux.

/usr/local/games/supertux <-

A user without root-privileges could not make levels in this case.
Therefore a suggest the following extension:

~/.supertux/levels
~/.supertux/themes(/mynewtheme)
~/.supertux/music

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] Leveleditor first release

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

Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 11:20:
> Le Dimanche 28 Décembre 2003 12:46, vous avez écrit :
> >  This game will be played by very little children, so a built-in editor
> > would be much easier to use for those.
> 
> By stand-alone I mean there's the game "supertux" and another executable file
> "supertuxle" or something like that. It's as easy to use as the builtin
> editor I believe

I know what you mean. I've played similar games, which used a built in
editor and this had some key advantages.
- Directly testing the new level by hitting a key for example.
- Seeing the level like it looks in the game.

Moreover maintaining the level-editor seperate would be a bad idea IMHO,
because both could share some code. (remember encapsulation)
Give it a chance. If you still think it is that bad, when I've commited
it, then we can still create a seperate level-editor.

> >  Well, I just asked this because the world.h, badguy.h and player.h have a
> > line saying 'C++ Interface:'.
> >  I've also found some comments using //. Is this already ANSI C and/or can
> > I use it (/* */ are annoying :P)?
> 
> I think we can use "//" for fast commenting :-). I agree that it's not really
> C but /**/ takes 235 ms more to write :-D I use /**/ for multiple line
> comments and oneline comment as much as I can

The 'C++ Interface' thingy was simply a copy+paste mistake. :)

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] stereo sound patch

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

Your patch is already merged, I'll commit it together with the
leveleditor.

Greetz...

Tobias Gläßer

Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 11:16:
> Changes, Fixes, Adds:
> 
> 1. PLEASE keep spaces & empty lines while patching CVS since I used them to 
> improve sources reading !
> 
> 2. Adds: Stereo sound effects. In "gameloop.c" the kicked laptop now produces 
> stereo sound depending on the position of SuperTux
> 
> 3. Changes: "play_sound( Mix_Chunk * snd)"
>      now is "play_sound( Mix_Chunk * snd, enum Sound_Speaker whichSpeaker )"
>      where whichSpeaker is
>                 SOUND_CENTER_SPEAKER,
>                 SOUND_LEFT_SPEAKER,
>                 SOUND_RIGHT_SPEAKER
> 
> 4. Adds: "void close_audio(void)". Why has it not been here for a while ? ;-) 
> "st_shutdown()" now calls "close_audio"
> 
> 5. Bugs report: sometimes, two bad guys get stuck
> 
> 6. Fixes: "static char * soundfilenames" is no more "static". No warning with 
> "unused variable" is allowed !
> 
> 7. modified Makefile
> 
> 8. added "supertux.h" If it is not in the diff, please look at the attached 
> file
-- 

Re: [Super-tux-devel] stereo sound patch

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

Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 11:16:
> Changes, Fixes, Adds:
> 
> 1. PLEASE keep spaces & empty lines while patching CVS since I used them to 
> improve sources reading !

Read my mail about indentations.

> 2. Adds: Stereo sound effects. In "gameloop.c" the kicked laptop now produces 
> stereo sound depending on the position of SuperTux

Very very cool. ! :) You receive 99 distros from me. :)

> 3. Changes: "play_sound( Mix_Chunk * snd)"
>      now is "play_sound( Mix_Chunk * snd, enum Sound_Speaker whichSpeaker )"
>      where whichSpeaker is
>                 SOUND_CENTER_SPEAKER,
>                 SOUND_LEFT_SPEAKER,
>                 SOUND_RIGHT_SPEAKER

good work.

> 4. Adds: "void close_audio(void)". Why has it not been here for a while ? ;-) 
> "st_shutdown()" now calls "close_audio"

yo.

> 5. Bugs report: sometimes, two bad guys get stuck
> 6. Fixes: "static char * soundfilenames" is no more "static". No warning with 
> "unused variable" is allowed !
> 
> 7. modified Makefile
> 
> 8. added "supertux.h" If it is not in the diff, please look at the attached 
> file

I'll merge this together with the new leveleditor feature. Please stay
tuned. There is no need to be in a hurry. ;)

Greetz...

Tobias Gläßer
-- 

[Super-tux-devel] indentations

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

Ok guys, 

I have to clarify something. :)

The indentations I use are so called GNU indentations.
I have a program, wich "reformats" the sources to
GNU indentations (used in the Linux kernel AFAIK) automatically
and I usually do this before commiting to CVS.

So there is no need for you to worry about indentations.

You want to know which program? KDevelop3, I'm involved there.
I believe this is also possible with emacs.

Greetz...

Tobias Gläßer

Am So, den 28.12.2003 schrieb Duong-Khang NGUYEN um 11:20:
> Le Dimanche 28 Décembre 2003 12:46, vous avez écrit :
> >  This game will be played by very little children, so a built-in editor
> > would be much easier to use for those.
> 
> By stand-alone I mean there's the game "supertux" and another executable file
> "supertuxle" or something like that. It's as easy to use as the builtin
> editor I believe
> 
> >  Well, I just asked this because the world.h, badguy.h and player.h have a
> > line saying 'C++ Interface:'.
> >  I've also found some comments using //. Is this already ANSI C and/or can
> > I use it (/* */ are annoying :P)?
> 
> I think we can use "//" for fast commenting :-). I agree that it's not really
> C but /**/ takes 235 ms more to write :-D I use /**/ for multiple line
> comments and oneline comment as much as I can
> 
> >  Did you find the code to be too straight? If you didn't like this, you
> > probabily had an heart attack when looking at the old gameloop function. ;P
> >  I could put the key events in a different function, I just didn't because
> > I don't like global variables that much.
> 
> I don't like the way you use the global variables and the way you call the
> function from gameloop.c. I think that functions from gameloop.c are not for
> external use. And last but not least, the way you manipulate pointers don't
> fit me much.
> 
> >I'm also not very used to write in C.
> 
> I code in C++ too, but I keep it apart in my mind while programming in C
> 
> >  I also didn't like (neither understood) the identation you have used in
> > the game.
> 
> You should ask Tobias for this :-) Maybe we have to vote for a common coding
> and identation style.
> 
> > Cya,
> >  Ricardo

[Super-tux-devel] Re: Laptop gfx

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

>
>
> I've drawn a new laptop bad guy.  I think he looks much better. :)
>
> I'm also about to make a sound effect for when you stomp him.  It doesn't
> make sense that it's silent!
>

   The new laptop looks better I think. However the way it moves looks like a 
crab :-D
-- 
Never say if I could turn back the time,
life is going on !