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

Re: [Super-tux-devel] SuperTux design

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

Hi and welcome!

Am Do, den 18.03.2004 schrieb Eduardo Hernández um 18:32:
> Hey, I'm new here and never participated in an open source project before 
> but I feel like I want to help. I don't even know if the right way of using 
> a mailing list is sending an email to this address but I think it's worth a 
> shot.

Yeah, it is the right way.

> Anyways I wanted to say I think that a complete design of SuperTux should be 
> the first aim of the project first, with defined milestones and such. After 
> the design document is complete the game development should try to stick to 
> it even if a 'neat feature' is tought afterwards. I can help with design it 
> if that position is aviable.

I have seen a lot projects coming and going, which had nice design
documents with every little detail described.
A few of them actually fullfilled their wishes but the most of these
projects can be seen as dead ones.

SuperTux's development began with one person and that's Bill Kendrick.
I can't even say if he had a design idea, looking at the 0.0.4 sources
I think he just had much time and coded to see a game running. (Yes, it
was very basic, but many people including me liked it)

Many projects including Linux began with a code base like this
and it seems to be one of the ways to attract more developers.

I was attracted by the 'playable' 0.0.4 and wanted to fix some bugs and
extend the engine. This was the beginning of a new SuperTux era, since
Bill Kendrick moved the project to SourceForge after a few bullying
mailes from my side.

Until 0.0.6 a rather complete code rewrite took place and the
communication in the team was and IMHO still is very good.
And as it seems 0.0.6 attracted YOU! Had we written little nice
documents nobody would know about the project, besides two to three
people, and it was probably already dying, because the motivation to
release new versions wasn't that exciting.

> After the design coding should start and prelimirary multimedia just to test 
> the code should be made. I can help with C++ coding, not python tought I 
> think I can learn python in little time. After the game has all the code 
> complete, real levels, graphics, sound, music and levels should be included, 
> as defined in the design document. I can help with graphics but I'm not good 
> at sounds and music(at least not yet!).

SuperTux needs artists in the first place. I see a serious danger in too
many people working on a quite little free software project like this
one. It's no danger for the project, but it can easily happen that two
programmes pick the same code or want to fix the same bug.
Therefore the mailing-list is seen as central point for ALL patches and
bug-fixes.

> After the game is complete as the design document says it should, then new 
> ideas of any kind should be voted yes or no to include them.

The funny times when we can implement features easily, will be after
0.1. Voting on every little feature would slow down the project.

> Well that's at least my idea of how the game should be made. It just seems 
> to me like the project is rather deorganized and some persons don't know how 
> to do things coz it hasn't been defined yet.

This project is organized to 70% on this mailing-list, so you may want
to read the mailing-list archieve on sourceforge. Other 20% take place
in IRC and 10% on the project's homepage, which can be seen as a place
for collecting ideas.

> Also I don't know if who are the project administrators and who is the one 
> who has the vision of what should SuperTux be like. I'm interested in that 
> to talk with that person about the game design.

This 'visions' have been discussed with the 'community' in the so called
IRC meetings. I think you can find the logs in the mailing-list
archieves.
IMHO a free software project shouldn't only live from the aims of a 1.0
version, but it should constantly make little steps towards new versions
and clean up it's API as long as it can be consired as stable.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] exit menu on escape [patch]

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

On Thu, Mar 18, 2004 at 05:48:03PM -0500, Michael George wrote:
> Pressing escape in the main menu currently exits the game, even if 
> you're in a submenu like load or options.  I've attached a patch that 
> only exits if you're actually at the top level.

Sounds good to me! :^)  Thx!

-bill!

Re: [Super-tux-devel] SuperTux design

[Michael G. <mi...@ge...>]

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


|
|>Well that's at least my idea of how the game should be made. It just
|>seems to me like the project is rather deorganized and some persons
|>don't know how to do things coz it hasn't been defined yet.
|
|
| I don't know from where you get that expression, sure its not all
| perfect, but compared to a lot of other projects around its rather
| well organized. And anyway, this is a open source project mainly
| developed for fun, so no need to have a full fledged design document
| to collect publisher money. If you want to flesh out the current
| milestone1 docu and add stuff, go ahead.
|

Just my $.02 - It would be nice if the TODO list on the website had some
indication of what people are working on vs. what's unclaimed.  For
example, a couple of people have sent in small patches that were
rejected because the core team is already doing that stuff.  It's just a
little hard for people who want to be tangentially involved (for whom I
think gotm is a great project) to be able to pick up 1-2 hour tasks
without worrying about stepping on people's toes.

Maybe this goes on on IRC.

- --Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAWkSMrJDiig1GCW0RAhjOAKCJ4mnzMiBDSyFu/cHcp/cZC46zPwCffUte
xFbenNFJcT00apjJZ5NaViE=
=QgA0
-----END PGP SIGNATURE-----

Re: [Super-tux-devel] fun little level, simple cave background

[Michael G. <mi...@ge...>]

It's a totally deliberate trick: you have to jump back to the platform
above before you can make it over.

--Mike



Ricardo Cruz wrote:
 >  Great level, but I had to edit it, in order to jump to those high 
brick at
 > the begining... Did you been able to make the jump?
 >  Anyway, it would be cool to make jump behaving correctly and even to 
jump
 > higher when the Power key is pressed as described here (in Jumps):
 > http://super-tux.sourceforge.net/milestone1/gameplay.html
 >
 > Ricardo Cruz
 >
 > Em Quinta, 18 de Março de 2004 01:25, o Michael George escreveu:
 >
 >>attached
 >
 >

Re: [Super-tux-devel] SuperTux design

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

Eduardo Hern=C3=A1ndez <cos...@ho...> writes:

> Anyways I wanted to say I think that a complete design of SuperTux
> should be the first aim of the project first, with defined
> milestones and such. After the design document is complete the game
> development should try to stick to it even if a 'neat feature' is
> tought afterwards. I can help with design it if that position is
> aviable.

Goals for Milestone1 are documented at:

 * http://super-tux.sourceforge.net/milestone1/

Planing much further then milestone1 however is relativly useless,
since one first needs to know how milestone1 turned out, what worked
and what didn't, etc.

> Well that's at least my idea of how the game should be made. It just
> seems to me like the project is rather deorganized and some persons
> don't know how to do things coz it hasn't been defined yet.

I don't know from where you get that expression, sure its not all
perfect, but compared to a lot of other projects around its rather
well organized. And anyway, this is a open source project mainly
developed for fun, so no need to have a full fledged design document
to collect publisher money. If you want to flesh out the current
milestone1 docu and add stuff, go ahead.

> Also I don't know if who are the project administrators and who is
> the one who has the vision of what should SuperTux be like. I'm
> interested in that to talk with that person about the game design.

Join IRC, #supertux, irc.freenode.net, most people involved with the
game hang out there.

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

Re: [Super-tux-devel] quick cursor

[settra <se...@fr...>]

Or it could be viewed from the side, wich would give something like that

ps: for both post, do not think they are the final cursors, they are
just ideas :D

> > Super-tux-devel mailing list
> > Sup...@li...
> > https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> > 
> 

Re: [Super-tux-devel] quick cursor

[settra <se...@fr...>]

I tried a quicky one, just to get some opinions,

normal state: tux slightly turns the head as if to say no (no selection)
link state: tux stops saying no
clicked state: tux opens the mouse  and looks at the user smiling (or
something like that)

if it receives good critics, i'll work more on it.

On Fri, 2004-03-19 at 04:58, Tobias Gl=E4=DFer wrote:
> I'd like to point out, that I encourage this effort!
> At all artists listening, please help us!
> The mouse cursor implementation is no problem, if
> you give as the cursors.
>=20
> Greetz...
>=20
> Tobias Gl=E4=DFer

> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
>=20

[Super-tux-devel] SuperTux design

[<cos...@ho...>]

Hey, I'm new here and never participated in an open source project before 
but I feel like I want to help. I don't even know if the right way of using 
a mailing list is sending an email to this address but I think it's worth a 
shot.

Anyways I wanted to say I think that a complete design of SuperTux should be 
the first aim of the project first, with defined milestones and such. After 
the design document is complete the game development should try to stick to 
it even if a 'neat feature' is tought afterwards. I can help with design it 
if that position is aviable.

After the design coding should start and prelimirary multimedia just to test 
the code should be made. I can help with C++ coding, not python tought I 
think I can learn python in little time. After the game has all the code 
complete, real levels, graphics, sound, music and levels should be included, 
as defined in the design document. I can help with graphics but I'm not good 
at sounds and music(at least not yet!).

After the game is complete as the design document says it should, then new 
ideas of any kind should be voted yes or no to include them.

Well that's at least my idea of how the game should be made. It just seems 
to me like the project is rather deorganized and some persons don't know how 
to do things coz it hasn't been defined yet.

Also I don't know if who are the project administrators and who is the one 
who has the vision of what should SuperTux be like. I'm interested in that 
to talk with that person about the game design.

-Coz

_________________________________________________________________
MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/

Re: [Super-tux-devel] fun little level, simple cave background

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

 Great level, but I had to edit it, in order to jump to those high brick at=
=20
the begining... Did you been able to make the jump?
 Anyway, it would be cool to make jump behaving correctly and even to jump=
=20
higher when the Power key is pressed as described here (in Jumps):
http://super-tux.sourceforge.net/milestone1/gameplay.html

Ricardo Cruz

Em Quinta, 18 de Mar=E7o de 2004 01:25, o Michael George escreveu:
> attached

=2D-=20
War is never imperative.
		-- McCoy, "Balance of Terror", stardate 1709.2

[Super-tux-devel] exit menu on escape [patch]

[Michael G. <mi...@ge...>]

Pressing escape in the main menu currently exits the game, even if 
you're in a submenu like load or options.  I've attached a patch that 
only exits if you're actually at the top level.

I'm not sure if you think it's worthwhile to always treat the escape key 
like a "back" button rather than a "close menu" button, but if you want 
me to I can change this to be the behavior for all of the menus.

--Mike

Re: [Super-tux-devel] Configure isn't working here

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

 Dunno why, but it is working fine now.

Ricardo Cruz

Em Quinta, 18 de Mar=E7o de 2004 15:05, o Ricardo Cruz escreveu:
> Hi,
>  I get the following output when I run configure:
>
> [rick2@docelar supertux]$ sh configure
> configure: error: cannot run /bin/sh ./config.sub
>
>  What's the prob?
>
> Ricardo Cruz

=2D-=20
"And they told us, what they wanted...
 Was a sound that could kill some-one, from a distance." -- Kate Bush

Re: [Super-tux-devel] remove the cursor [patch]

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

Am Di, den 16.03.2004 schrieb Ricardo Cruz um 04:28:
>  While that's a good idea, I think we should commit that along with our own 
> mouse cursor implementation. In X11 systems (with the expection of nvidia 
> drivers), the mouse cursor is badly synchronized with the screen refresh, 
> resulting in flickering.
>  I already post an implementation for that. I can improve it, but firstly we 
> would need graphics for mouse cursors (states: normal, link, click, 
> scroll...). They can have animations and use alpha.

I'd like to point out, that I encourage this effort!
At all artists listening, please help us!
The mouse cursor implementation is no problem, if
you give as the cursors.

Greetz...

Tobias Gläßer

[Super-tux-devel] New level-format

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

Hi all,

after the 0.0.7 TODO list was postet a nice discussion
about the new level-format took place, but accomplishing every
wish is impossible. ;)

Here is my probably final implementation idea:

[Background tiles]         // with optional paralax scrolling
[Static tiles]             // Tiles tux can collide with and which have
a static place in the map
[Enemy/Dynamic 'tiles']    // bad_guys and moving platforms are examples
[Foreground tiles]         // no interaction with tux, it's only for
eyecandy and above the other 'layers' - again with optional parallax
scrolling

- A level itsself will have the possibility to set much more details
like gravity etc. (the old format already had such options, but they
were unextendible without breaking old levels)

- A level maker can load as many tilesets (formely known as themes) as
he/she wants and new/old tilesets itsself can be added/extended very
easily with special configuration files and structures. You'll see it.
;)

- To implement all this the lispreader will be used, which can be seen
in CVS now. Lispreader is only a parser and not a lisp interpreter.

Having multiple layers for parallax effects is surplus for the
Milestone1 goals.
Furthermore features like the already implemented background image and
the coming wheather effects will provide enough eyecandy for 0.1.

I want to remember all people, who don't like this plan,
that the Milestone1's aim is mainly to create _a better_ SMB1 clone and
not to create the "next generation" of Jump'N'Run games.
We have to reach the big 1.0 goals step by step and the keyword is
evolution. If new people to SuperTux development took a look into the
0.0.5 sources, they would agree that SuperTux is on the right track. :)

Greetz...

Tobias Gläßer





-- 

[Super-tux-devel] 0.0.6 debian release

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

Hi all,

https://sourceforge.net/project/showfiles.php?group_id=69183

you can find a debian i386 release for 0.0.6 on the SF file server now.
:)
I'd like to encourage you to make a SuperTux package for your favourite
distribution.

Thanks to
wickey <wi...@gm...>

Greetz...

Tobias Gläßer
-- 

Re: [Super-tux-devel] TODO 0.0.7

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

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

>  I would go with the following layers:
>
> - slower speed background (moving in a slower speed than the games one);
> - normal speed background (moving in normal speed);
> - normal tiles - the ones that Tux has interaction with;
> - normal speed foreground;
> - slower speed foreground.

We only need two basic layers: background and foreground, both scroll
the same speed, Tux and objects are draw inbetween them most of the
time:

[more paralax layers]
[Foreground]
[Tux]
[Background]
[more paralax layers]

Above and below these basic layers you can add as much paralax
scrolling backgrounds as you like, no need to limit them. Only
question is if foreground or background or both become the layer that
is used for collision detection.

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

Re: Re: [Super-tux-devel] TODO 0.0.7

[<mi...@ge...>]

> >  Just to point out, that this would be the opportunity to define some deeper 
> > changes in the level format and overall.
> >  Maybe we should use smaller tiles (20x20 ?) and resolution.
> 
> What should smaller tiles be good for? I wouldn't mind to have larger
> tiles (40x40) if the resolution would be 800x600, but with 640x480
> 32x32 is a pretty nice size.
> 

It would be nice for adding more detail to a level, although I think a better way to acheive this would be through more tiles (thus allowing more detail).  One feature I think would be nice (although probably only in the editor, not the level format) would be to allow large tile groups, to make big objects (more than one or two tiles) easily.

This would be implemented entirely in the editor, but there would need to be a way in the tile collection to create these prefabs.  This is probably a post-milestone feature, but might be worth considering while constructing the tile-group-format.

--Mike

Re: [Super-tux-devel] TODO 0.0.7

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

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

>  Just to point out, that this would be the opportunity to define some deeper 
> changes in the level format and overall.
>  Maybe we should use smaller tiles (20x20 ?) and resolution.

What should smaller tiles be good for? I wouldn't mind to have larger
tiles (40x40) if the resolution would be 800x600, but with 640x480
32x32 is a pretty nice size.

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

[Super-tux-devel] Configure isn't working here

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

Hi,
 I get the following output when I run configure:

[rick2@docelar supertux]$ sh configure
configure: error: cannot run /bin/sh ./config.sub

 What's the prob?

Ricardo Cruz

-- 
The Shuttle is now going five times the sound of speed.
		-- Dan Rather, first landing of Columbia

Re: [Super-tux-devel] [patch] lispreader compilation

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

 Sorry for disappointing you, but I've already corrected that in cvs ;)
 Anyway, don't give up and start sending patches :)

Ricardo Cruz

Em Quinta, 18 de Mar=E7o de 2004 12:38, o Olivier FAURAX escreveu:
> My first patch ;)
>
> Hope this help

=2D-=20
Good day to avoid cops.  Crawl to school.

[Super-tux-devel] [patch] lispreader compilation

[Olivier F. <oli...@es...>]

My first patch ;)

Hope this help

-- 
"Vous avez la tête dure." Mr H. au sujet de la pénétration des ondes
sonores dans la boite cranienne.
Olivier Faurax, Elève ESIL Dpt Informatique (Promo 2004)
http://www.esil.univ-mrs.fr/~ofaurax

[Super-tux-devel] new level for 0.0.6 release

[Matze B. <ma...@br...>]

Hi,

I just tried the 0.0.6 release of supertux. It's getting very nice.

I also tried the internal level editor and created a new level. It's 
attached to this mail. Hope you can use it.

Greetings,
	Matze

Re: [Super-tux-devel] Collisions bug [patch]

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

 Just had a look at badguy_collision() and the lines that write to base.y=20
should be removed.

Ricardo Cruz

Em Quarta, 17 de Mar=E7o de 2004 17:19, o Ricardo Cruz escreveu:
> Hey,
>
>  As you may have noticed there is a bug in the collisions system that mak=
es
> when player jumps into the laptop to be reported more than one.
>
>  I finally squished it, since I was adding the line before the
> badguy_collisions() and it looks like that base.y is overwritten in there.
>
> Ricardo Cruz

=2D-=20
Any time things appear to be going better, you have overlooked something.

[Super-tux-devel] Boss

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

Here a little sketch of a possible final boss:

http://pingus.seul.org/~grumbel/tmp/supertux-boss.jpg

Behaviour would be relativly simply, the Evilpenguin walks a bit
forward and backward on his three tiles and shoots eggs or snowballs
in the direction of Tux, Tux has to collect them, jump on the
wooden-platform, which might be moving and shoot them back at the
Evilpenguin. Eggs could be implemented the same has the laptops which
one can carry arround currently.

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

[Super-tux-devel] fun little level, simple cave background

[Michael G. <mi...@ge...>]

attached

Re: [Super-tux-devel] Clear screen bug in OpenGL mode

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

 I am not as stupid as I sound ;D I've tried that already.
 It looks like we need to disable something...

Ricardo Cruz

Em Quarta, 17 de Mar=E7o de 2004 22:29, o Bill Kendrick escreveu:
> On Wed, Mar 17, 2004 at 10:26:21PM +0000, Ricardo Cruz wrote:
> > Hey there,
> >
> >  In the OpenGL mode, the screen is not being corrected cleared, the code
> > is the following:
> >   glClearColor(r/256, g/256, b/256, 1.0);
> >   glClear(GL_COLOR_BUFFER_BIT);
>
> Hum... maybe 'promote' r g and b to float during the division, like so?
>
>   r/256.0
>
> or:
>
>   ((float) r) / 256.0
>
>
> ???
>
> -bill!
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel

=2D-=20
When neither their poverty nor their honor is touched, the majority of men
live content.
		-- Niccolo Machiavelli