Thread: [Super-tux-devel] TODO 0.0.7
Brought to you by:
wkendrick
Menu
▾
▴
super-tux-devel
|
From: Tobias <tob...@gm...> - 2004-03-16 13:41:54
|
Hi all this is the official 0.0.7 TODO list: On the code site: - Integrate lisp(reader) parser into SuperTux and extend it (if there is a need). For example gunzip compression with zlib would be a nice feature. This parser will then be used for levels and any configuration files. - Improve the code reuse. We need a type that handles animations and actions for example. The aim is to make the engine more extendible, which goes along with the integration of the lispreader. - New and more flexible level-format using the lispreader. I'm sure discussions will take place about the exact needs, but as far as I can see the level-format for Milestone1 needs at least 3 layers. One for background tiles, which don't affect the gameplay. One for tiles, which build a map and don't move for example. And one for all special tiles (moving platforms) along with the bad guys. The idea is to give the level designer more freedom in the details, which means, that the level-format should be able to save the speed of a bad_guy for example or the direction a moving platform moves to. - Wheather effects. I think having wheather effects, which could be choosen by the level-designers, would be a great feature for SuperTux. It would make hand drawn clouds in the background unneccassary and provide a random and eyecandy behaviour. The first step is to create a special engine for effects in the background. For 0.0.7 clouds should be enough, but it is aimed to be easy extendible and things like dynamic rain, sunshine and storm could round up the feeling later. - The built-in level-editor should be able to save and load the new format, when 0.0.7 is released. Extend SuperTux's GUI for all upcoming needs. - Fix bugs. :) - Add comments to the sources. ;) On the artistic site: - Integrate new graphics and tiles into SuperTux and throw away old ones, which are seen as ugly by all parties. (However I don't think the old tiles are ugly, I only can't see them anymore ;) ) - Create new musics into SuperTux. We still need volunteers here. - Create sound effects for all kinds of bad_guys, screens and for the menu. This is the official 0.0.7 TODO list. Comments and further suggestions is appreciated. BUT keep in mind, that 0.0.7 is aimed to be a short cycled release, althought many new features are on this TODO list. Further wishes will have a hard time to be part of this TODO list and, if you want them to become true, you'll have to send patches for it. ;) Greetz... Tobias Gläßer -- |
|
From: Christopher A. W. <cr...@li...> - 2004-03-16 16:07:17
|
> - Wheather effects. > I think having wheather effects, which could be choosen by the > level-designers, would be a great feature for SuperTux. It would make > hand drawn clouds in the background unneccassary and provide a random > and eyecandy behaviour. The first step is to create a special > engine for effects in the background. For 0.0.7 clouds should be > enough, but it is aimed to be easy extendible and things like dynamic > rain, sunshine and storm could round up the feeling later. Ah, weather effects. I think I know how to pull that off. We should have an optional fourth layer on which rain animations can be run, or even allow for a scrolling foreground (like the plants on level 1-1 of yoshi's island.) What ya think? Finals will be over soon, and I'll have a lot more free time to work on the project. Cheers! Christopher Allan Webber | The bottom line |
|
From: Ricardo C. <ri...@ae...> - 2004-03-16 17:15:22
|
I don't think we need a fourth layer for rain implementation... Your idea about the scrolling foreground looks interesting, but I didn't=20 understood it very well, could you explain it a little further for us, that= =20 know nothing about Yoshi's? :) Ricardo Cruz Em Quarta, 16 de Mar=E7o de 2005 16:09, o Christopher A. Webber escreveu: > > - Wheather effects. > > I think having wheather effects, which could be choosen by the > > level-designers, would be a great feature for SuperTux. It would make > > hand drawn clouds in the background unneccassary and provide a random > > and eyecandy behaviour. The first step is to create a special > > engine for effects in the background. For 0.0.7 clouds should be > > enough, but it is aimed to be easy extendible and things like dynamic > > rain, sunshine and storm could round up the feeling later. > > Ah, weather effects. I think I know how to pull that off. We should > have an optional fourth layer on which rain animations can be run, or > even allow for a scrolling foreground (like the plants on level 1-1 of > yoshi's island.) What ya think? > Finals will be over soon, and I'll have a lot more free time to work on > the project. Cheers! > > Christopher Allan Webber > > > > The bottom line =2D-=20 honeymoon, n.: A short period of doting between dating and debting. -- Ray C. Bandy |
|
From: Bill K. <nb...@so...> - 2004-03-16 17:29:52
|
On Tue, Mar 16, 2004 at 05:16:45PM +0000, Ricardo Cruz wrote: > > I don't think we need a fourth layer for rain implementation... > Your idea about the scrolling foreground looks interesting, but I didn't > understood it very well, could you explain it a little further for us, that > know nothing about Yoshi's? :) In other words, you'd have larger 'foreground' objects (like plants, I guess) that scroll faster than the main 'layer' (where Tux and the enemies are). And, of course, the 'background' layer (with far-off stuff) scrolls slower than the main layer. As for rain, though... yeah, no need to do another layer. In "BoboBot", I did snow in the Iceman level by just drawing little sprites :^) -bill! |
|
From: Tobias <tob...@gm...> - 2004-03-16 17:31:00
|
Am Di, den 16.03.2004 schrieb Ricardo Cruz um 12:16: > I don't think we need a fourth layer for rain implementation... No, why should we need it? The layer I have spoken about are in the level ... that we need an additional "layer" for the wheather engine to render things is obvious. ;) > Your idea about the scrolling foreground looks interesting, but I didn't > understood it very well, could you explain it a little further for us, that > know nothing about Yoshi's? :) I also didn't understand, what he meant by scrolling foreground. :) If it was fort the wheather implementation he could mean fog for example, which makes parts of the screen invisible for a few seconds while "scrolling". But actually I didn't understand, what he wanted to state. Greetz... Tobias Gläßer > Em Quarta, 16 de Março de 2005 16:09, o Christopher A. Webber escreveu: > > > - Wheather effects. > > > I think having wheather effects, which could be choosen by the > > > level-designers, would be a great feature for SuperTux. It would make > > > hand drawn clouds in the background unneccassary and provide a random > > > and eyecandy behaviour. The first step is to create a special > > > engine for effects in the background. For 0.0.7 clouds should be > > > enough, but it is aimed to be easy extendible and things like dynamic > > > rain, sunshine and storm could round up the feeling later. > > > > Ah, weather effects. I think I know how to pull that off. We should > > have an optional fourth layer on which rain animations can be run, or > > even allow for a scrolling foreground (like the plants on level 1-1 of > > yoshi's island.) What ya think? > > Finals will be over soon, and I'll have a lot more free time to work on > > the project. Cheers! > > > > Christopher Allan Webber > > > > > > > > The bottom line -- |
|
From: Ricardo C. <ri...@ae...> - 2004-03-16 17:49:51
|
Oh! It looks like we are calling foreground for different things ;D Let me explain... in supertux, foregrounds are the tiles that the player h= as=20 interaction with, but you are right, foregrounds are nothing more than=20 backgrounds, but are just drawn over everything. So, what term should we us= e=20 instead? Ricardo Cruz Em Ter=E7a, 16 de Mar=E7o de 2004 17:29, o Bill Kendrick escreveu: > On Tue, Mar 16, 2004 at 05:16:45PM +0000, Ricardo Cruz wrote: > > I don't think we need a fourth layer for rain implementation... > > Your idea about the scrolling foreground looks interesting, but I didn= 't > > understood it very well, could you explain it a little further for us, > > that know nothing about Yoshi's? :) > > In other words, you'd have larger 'foreground' objects (like plants, I > guess) that scroll faster than the main 'layer' (where Tux and the enemies > are). > > And, of course, the 'background' layer (with far-off stuff) scrolls slower > than the main layer. > > As for rain, though... yeah, no need to do another layer. > > In "BoboBot", I did snow in the Iceman level by just drawing little sprit= es > > :^) > > -bill! > > =2D-=20 Men are always ready to respect anything that bores them. -- Marilyn Monroe |
|
From: Ricardo C. <ri...@ae...> - 2004-03-16 18:05:11
|
I replayed to this mail and when I was just about to send it, my machine=20
frozen :( Let me see if I can remember it correctly ;)
Hey! Nice to see that there is a plan already!
A few comments...
Em Ter=C3=A7a, 16 de Mar=C3=A7o de 2004 19:43, o Tobias Gl=C3=A4=C3=9Fer es=
creveu:
> Hi all
>
> this is the official 0.0.7 TODO list:
>
> On the code site:
>
> - Integrate lisp(reader) parser into SuperTux
> and extend it (if there is a need). For example
> gunzip compression with zlib would be a nice feature.
> This parser will then be used for levels and any configuration
> files.
>
I don't know anything about lisp (i learned Haskell at my college), does=20
anyone know a good (and simple :) ) documentation website about lisp? Thx.
Compressing seems useless for the levelset, since those are just plain asc=
ii=20
text files, but it would be of great use for tilesets. Anyway, currently,=20
network resources are ones that users lack the most, so let's try primary t=
o=20
keep our packages small, instead of small in the disk.
> - Improve the code reuse. We need a type that handles animations and
> actions for example. The aim is to make the engine more extendible,
> which goes along with the integration of the lispreader.
>
Well, c++ might be of good use for such thing. The current code is already=
=20
compilable in g++, so only a port of structs/funcs to class would be easy.=
=20
Really, an object oriented would allow much more flexible, while keeping t=
he=20
code more readable and so more easy and funnier to code.
> - New and more flexible level-format using the lispreader. I'm sure
> discussions will take place about the exact needs, but as far as I can
> see the level-format for Milestone1 needs at least 3 layers. One for
> background tiles, which don't affect the gameplay. One for tiles,
> which build a map and don't move for example. And one for all special
> tiles (moving platforms) along with the bad guys.
> The idea is to give the level designer more freedom in the details,
> which means, that the level-format should be able to save the speed of
> a bad_guy for example or the direction a moving platform moves to.
>
I don't get it why you manage to make moving platforms/bag guys as another=
=20
layer. They would need a different implementation from that.
> - Wheather effects.
> I think having wheather effects, which could be choosen by the
> level-designers, would be a great feature for SuperTux. It would make
> hand drawn clouds in the background unneccassary and provide a random
> and eyecandy behaviour. The first step is to create a special
> engine for effects in the background. For 0.0.7 clouds should be
> enough, but it is aimed to be easy extendible and things like dynamic
> rain, sunshine and storm could round up the feeling later.
>
Those sounds really great!
Would be cool to let the designer set the density and the desire area for =
the=20
effects.
> - Fix bugs. :)
>
> - Add comments to the sources. ;)
>
Would be cool to also agree on an indentation style ;)
I would go for something like this (using tabs, instead of two spaces):
void one_func()
{
int a, b;
a =3D rand() % 20;
b =3D rand() % 20;
if(a =3D=3D b)
{
printf("You won!\n");
if(a =3D=3D 0)
printf("Jackpot\n");
}
else
printf("Looooser\n");
}
Good work,
Ricardo Cruz
=2D-=20
You'll never be the man your mother was!
|
|
From: Bill K. <nb...@so...> - 2004-03-16 18:18:35
|
On Tue, Mar 16, 2004 at 06:06:37PM +0000, Ricardo Cruz wrote: > > I replayed to this mail and when I was just about to send it, my machine > frozen :( Let me see if I can remember it correctly ;) Nothing compared to me just now. :^) I thought my laptop had COMPLETELY died. (Wouldn't even flash a single light or show that the AC was plugged in). Well... the AC was plugged _in_... it was just the outlet was dead. (The strip's surge protection had tripped.) I almost drove 2hrs to meet with my boss to trade hardware. MAN was that dumb of me :^) -bill! |
|
From: Tobias <tob...@gm...> - 2004-03-16 18:48:22
|
Am Di, den 16.03.2004 schrieb Ricardo Cruz um 13:06: > I replayed to this mail and when I was just about to send it, my machine > frozen :( Let me see if I can remember it correctly ;) > > Hey! Nice to see that there is a plan already! > A few comments... > > Em Terça, 16 de Março de 2004 19:43, o Tobias Gläßer escreveu: > > Hi all > > > > this is the official 0.0.7 TODO list: > > > > On the code site: > > > > - Integrate lisp(reader) parser into SuperTux > > and extend it (if there is a need). For example > > gunzip compression with zlib would be a nice feature. > > This parser will then be used for levels and any configuration > > files. > > > I don't know anything about lisp (i learned Haskell at my college), does > anyone know a good (and simple :) ) documentation website about lisp? Thx. > > Compressing seems useless for the levelset, since those are just plain ascii > text files, but it would be of great use for tilesets. Anyway, currently, > network resources are ones that users lack the most, so let's try primary to > keep our packages small, instead of small in the disk. Inform yourself what a parser is and think about your comment again. ;( As for the compression, the new level-format will result in larger levels (in KBs) and ASCII is one of the things that are esspecially good for compression. Images on the other hand are very bad for compression, because they are already compressed (png, jpeg and the likes at least). > > - Improve the code reuse. We need a type that handles animations and > > actions for example. The aim is to make the engine more extendible, > > which goes along with the integration of the lispreader. > > > Well, c++ might be of good use for such thing. The current code is already > compilable in g++, so only a port of structs/funcs to class would be easy. > Really, an object oriented would allow much more flexible, while keeping the > code more readable and so more easy and funnier to code. Not everybody thinks C++ code == a class and a few class-members. A C++ port for me was a lot more. But it's currently the wrong time and simply too much work for a real C++ port. Remember, that 0.0.7 should be a short-cycled release. Using std::string instead of char* could be the way to go thought (to avoid buffer overflows for example) and switching to std::vector and the likes for arrays might be wise, too. > > - New and more flexible level-format using the lispreader. I'm sure > > discussions will take place about the exact needs, but as far as I can > > see the level-format for Milestone1 needs at least 3 layers. One for > > background tiles, which don't affect the gameplay. One for tiles, > > which build a map and don't move for example. And one for all special > > tiles (moving platforms) along with the bad guys. > > The idea is to give the level designer more freedom in the details, > > which means, that the level-format should be able to save the speed of > > a bad_guy for example or the direction a moving platform moves to. > > > I don't get it why you manage to make moving platforms/bag guys as another > layer. They would need a different implementation from that. I'm speaking about the internals of the level-file-format and not about layers in the engine. Althought they are similar. /me doesn't expect that you 'get' everything *kidding > > - Wheather effects. > > I think having wheather effects, which could be choosen by the > > level-designers, would be a great feature for SuperTux. It would make > > hand drawn clouds in the background unneccassary and provide a random > > and eyecandy behaviour. The first step is to create a special > > engine for effects in the background. For 0.0.7 clouds should be > > enough, but it is aimed to be easy extendible and things like dynamic > > rain, sunshine and storm could round up the feeling later. > > > Those sounds really great! > Would be cool to let the designer set the density and the desire area for the > effects. > > - Fix bugs. :) > > > > - Add comments to the sources. ;) > > > Would be cool to also agree on an indentation style ;) > I would go for something like this (using tabs, instead of two spaces): You have complained about that for several times now. GNU indentations are used in SuperTux and it will stay like that. Greetz... Tobias Gläßer -- |
|
From: Ricardo C. <ri...@ae...> - 2004-03-16 19:02:27
|
GNU indentations? Nooo, I prefer to be shoted ;D Really, those indentations are only used by those guys with big beards, a = la=20 Richmond and Raymond ;D Ricardo Cruz Em Quarta, 17 de Mar=C3=A7o de 2004 00:49, o Tobias Gl=C3=A4=C3=9Fer escrev= eu: > Am Di, den 16.03.2004 schrieb Ricardo Cruz um 13:06: > > > > > - Fix bugs. :) > > > > > > - Add comments to the sources. ;) > > > > Would be cool to also agree on an indentation style ;) > > I would go for something like this (using tabs, instead of two spaces): > > You have complained about that for several times now. GNU indentations > are used in SuperTux and it will stay like that. > > Greetz... > > Tobias Gl=C3=A4=C3=9Fer =2D-=20 It is not a good omen when goldfish commit suicide. |
|
From: Tobias <tob...@gm...> - 2004-03-16 19:10:36
|
Am Di, den 16.03.2004 schrieb Ricardo Cruz um 14:03: > GNU indentations? Nooo, I prefer to be shoted ;D A lot of projects use it. However I don't know of their suicide rate. :) > Really, those indentations are only used by those guys with big beards, a la > Richmond and Raymond ;D First of all they are called Richard and Eric and furthermore Eric would heavily refuse to use GNU indentations, because he is some sort of opponent(self-called leader of OpenSource*g) to Stallman(Free Software founder). ;D Greetz... Tobias Gläßer (ignoring Ricardo's irony completly ;) ) |
|
From: Bill K. <nb...@so...> - 2004-03-16 19:14:28
|
On Tue, Mar 16, 2004 at 08:11:43PM -0500, Tobias Gl=E4=DFer wrote: > > Richmond and Raymond ;D > First of all they are called Richard and Eric and furthermore Eric woul= d > heavily refuse to use GNU indentations, because he is some sort of > opponent(self-called leader of OpenSource*g) to Stallman(Free Software > founder). ;D Plus, ESR is clean-shaven. Careful, he likes guns ;) -bill! |
|
From: Christopher A. W. <cr...@li...> - 2004-03-17 02:29:35
|
On Tue, 2004-03-16 at 11:51, Ricardo Cruz wrote: > Oh! It looks like we are calling foreground for different things ;D > Let me explain... in supertux, foregrounds are the tiles that the player has > interaction with, but you are right, foregrounds are nothing more than > backgrounds, but are just drawn over everything. So, what term should we use > instead? > > Ricardo Cruz Ah, good point. Sorry I generated the confusion there. We could call it.... the effects layer? Heh, no, that's lame. Wait a minute... what about the forescreen? :) I've been taking exams and writing papers all day. I can't even tell if those are good ideas or bad ideas anymore! ^_^ Christopher Allan Webber | The bottom line |
|
From: settra <se...@fr...> - 2004-03-17 09:47:25
|
On Thu, 2005-03-17 at 03:32, Christopher A. Webber wrote: > Ah, good point. Sorry I generated the confusion there. > We could call it.... the effects layer? Heh, no, that's lame. > Wait a minute... what about the forescreen? :) > I've been taking exams and writing papers all day. I can't even tell if > those are good ideas or bad ideas anymore! ^_^ > > Christopher Allan Webber > > > | > The bottom line Hi everyone, i'm settra, it' s the 1st time i write the ML but some of you might have seen me on the irc channel. That was for the presentation :P I propose this (layers are in order of display): -background :displays the landscape / cave -static-playground :static tiles -dynamic-playground :dynamic tiles and enemies -foreground :displays the landscape / cave of course, background and foreground do not display the same thing, but both play the same role (make supertux a little bit nicer to the eye) background would display mountains whereas foreground would display bushes and things like that (it might be nice it could be blurred wich would require alpha-blending). |
|
From: Ricardo C. <ri...@ae...> - 2004-03-17 16:09:00
|
I would go with the following layers: =2D slower speed background (moving in a slower speed than the games one); =2D normal speed background (moving in normal speed); =2D normal tiles - the ones that Tux has interaction with; =2D normal speed foreground; =2D slower speed foreground. Maybe we could have 3 layers of backround and foreground. A part from this, there would be a static image or color for the backgroun= d=20 and the moving platforms and bad guys. Ricardo Cruz Em Quarta, 17 de Mar=E7o de 2004 09:47, o settra escreveu: > On Thu, 2005-03-17 at 03:32, Christopher A. Webber wrote: > > Ah, good point. Sorry I generated the confusion there. > > We could call it.... the effects layer? Heh, no, that's lame. > > Wait a minute... what about the forescreen? :) > > I've been taking exams and writing papers all day. I can't even tell if > > those are good ideas or bad ideas anymore! ^_^ > > > > Christopher Allan Webber > > > > > > > > The bottom line > > Hi everyone, i'm settra, it' s the 1st time i write the ML but some of > you might have seen me on the irc channel. > That was for the presentation :P > > > I propose this (layers are in order of display): > -background :displays the landscape / cave > -static-playground :static tiles > -dynamic-playground :dynamic tiles and enemies > -foreground :displays the landscape / cave > > of course, background and foreground do not display the same thing, but > both play the same role (make supertux a little bit nicer to the eye) > background would display mountains whereas foreground would display > bushes and things like that (it might be nice it could be blurred wich > would require alpha-blending). > > =2D-=20 You may already be a loser. -- Form letter received by Rodney Dangerfield. |
|
From: Ingo R. <gr...@gm...> - 2004-03-18 18:45:26
|
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 |
|
From: Ricardo C. <ri...@ae...> - 2004-03-17 18:24:51
|
Just to point out, that this would be the opportunity to define some deepe= r=20 changes in the level format and overall. Maybe we should use smaller tiles (20x20 ?) and resolution. Just a thought, Ricardo Cruz Em Quarta, 17 de Mar=E7o de 2004 16:10, o Ricardo Cruz escreveu: > 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. > > Maybe we could have 3 layers of backround and foreground. > A part from this, there would be a static image or color for the > background and the moving platforms and bad guys. > > Ricardo Cruz > > Em Quarta, 17 de Mar=E7o de 2004 09:47, o settra escreveu: > > On Thu, 2005-03-17 at 03:32, Christopher A. Webber wrote: > > > Ah, good point. Sorry I generated the confusion there. > > > We could call it.... the effects layer? Heh, no, that's lame. > > > Wait a minute... what about the forescreen? :) > > > I've been taking exams and writing papers all day. I can't even tell > > > if those are good ideas or bad ideas anymore! ^_^ > > > > > > Christopher Allan Webber > > > > > > > > > > > > The bottom line > > > > Hi everyone, i'm settra, it' s the 1st time i write the ML but some of > > you might have seen me on the irc channel. > > That was for the presentation :P > > > > > > I propose this (layers are in order of display): > > -background :displays the landscape / cave > > -static-playground :static tiles > > -dynamic-playground :dynamic tiles and enemies > > -foreground :displays the landscape / cave > > > > of course, background and foreground do not display the same thing, but > > both play the same role (make supertux a little bit nicer to the eye) > > background would display mountains whereas foreground would display > > bushes and things like that (it might be nice it could be blurred wich > > would require alpha-blending). =2D-=20 You will triumph over your enemy. |
|
From: Ingo R. <gr...@gm...> - 2004-03-18 16:05:30
|
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 |
|
From: Christopher A. W. <cr...@li...> - 2004-03-17 20:55:59
|
On Wed, 2004-03-17 at 10:10, Ricardo Cruz wrote: > 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. > > Maybe we could have 3 layers of backround and foreground. > A part from this, there would be a static image or color for the background > and the moving platforms and bad guys. I thought quite a bit a bout this, and I realized that we don't even need to set how many there are going to be. All we need to do is have two definite ones: background and foreground. Users can set on their levels extra layers that either fit between the background and the foreground or lie above the foreground. The speed on these should not be hard-coded, it should be set by the user. It might sound complicated, but it really isn't. Just have the layers work via a linked list and have each (besides the foreground) have its own variable for its relative moving speed. We can use this later to also add an extra layer where lightning effects and such are placed. Anyway, that's what I think would be best. Christopher Allan Webber | The bottom line |
|
From: Michael G. <mi...@ge...> - 2004-03-17 21:09:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher A. Webber wrote: | On Wed, 2004-03-17 at 10:10, Ricardo Cruz wrote: | |>/ 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. |> |> Maybe we could have 3 layers of backround and foreground. |> A part from this, there would be a static image or color for the background |>and the moving platforms and bad guys./ |> | | I thought quite a bit a bout this, and I realized that we don't even | need to set how many there are going to be. All we need to do is have | two definite ones: background and foreground. Users can set on their | levels extra layers that either fit between the background and the | foreground or lie above the foreground. The speed on these should not | be hard-coded, it should be set by the user. | It might sound complicated, but it really isn't. Just have the layers | work via a linked list and have each (besides the foreground) have its | own variable for its relative moving speed. | We can use this later to also add an extra layer where lightning effects | and such are placed. | Anyway, that's what I think would be best. | | Christopher Allan Webber | | | | | The bottom line I like this idea, but would like to add that a fore-fore-ground list is also necessary for some of the desired effects (stuff that isn't interactive, but is painted on top of the active layer). Also, are these layers going to be tile-based, or one big looong png file? I can certainly see advantages and disadvantages both ways. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAWL/KrJDiig1GCW0RAvzvAJ4mpN1k/hRsP8CwuGjusxUpIGUDjACfZOKq DOZLYRZG5gJ35VeNoiQmW+0= =WRMc -----END PGP SIGNATURE----- |
|
From: Ricardo C. <ri...@ae...> - 2004-03-17 22:29:29
|
Hi, The foreground is what you are referring, it doesn't interact with the use= r,=20 and i vote for 2/3 layers. The layers are tile-based. Easy to do, small size, fast to blit and flexib= le. Ricardo Cruz Em Quarta, 17 de Mar=E7o de 2004 21:14, o Michael George escreveu: > > I like this idea, but would like to add that a fore-fore-ground list is > also necessary for some of the desired effects (stuff that isn't > interactive, but is painted on top of the active layer). > > Also, are these layers going to be tile-based, or one big looong png > file? I can certainly see advantages and disadvantages both ways. > > - --Mike =2D-=20 Swerve me? The path to my fixed purpose is laid with iron rails, whereon my soul is grooved to run. Over unsounded gorges, through the rifled hearts of mountains, under torrents' beds, unerringly I rush! -- Captain Ahab, "Moby Dick" |
|
From: Christopher A. W. <cr...@li...> - 2004-03-17 23:00:28
|
I just wanted to note how pleased I am with the discussion going on in this project. When I first came in, chatting on IRC on that meeting date, I was a bit worried. There was a lot of arguing going on. I'm seeing more discussion now than I did then, and I think that's a good thing... and I really want to encourage that. I'm not very fond of debates... both sides try to fight for one idea and refuse to look at the side of the other. Thus, in a debate, you can't listen to the other side without "losing" or being "wrong." I don't think we want that to run in our group, and I'm glad to see that it isn't happening. Let's just try to keep it that way. Let us share not only our opinions but also our reasoning, and let's try to keep open, contemplative minds to each others' ideas. I think the project will move along much more smoothly this way. Christopher Allan Webber | The bottom line On Wed, 2004-03-17 at 16:31, Ricardo Cruz wrote: > Hi, > The foreground is what you are referring, it doesn't interact with the u= ser,=20 > and i vote for 2/3 layers. > The layers are tile-based. Easy to do, small size, fast to blit and flex= ible. >=20 > Ricardo Cruz >=20 > Em Quarta, 17 de Mar=E7o de 2004 21:14, o Michael George escreveu: > > > > I like this idea, but would like to add that a fore-fore-ground list is > > also necessary for some of the desired effects (stuff that isn't > > interactive, but is painted on top of the active layer). > > > > Also, are these layers going to be tile-based, or one big looong png > > file? I can certainly see advantages and disadvantages both ways. > > > > - --Mike |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X