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

Re: [Super-tux-devel] bitmask

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

Ryan Flegel <rf...@gm...> writes:

> I just noticed we don't use bitmask.h/.cpp for collision detection any
> more. I suppose it would be okay to remove these now?

I wouldn't remove them, could be usefull in the future.

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

[Super-tux-devel] bitmask

[Ryan F. <rf...@gm...>]

Hey,

I just noticed we don't use bitmask.h/.cpp for collision detection any
more. I suppose it would be okay to remove these now?

-- 
Ryan

Re: [Super-tux-devel] Short note

[Ryan F. <rf...@gm...>]

Hey,

A few suggestions for the level editor.

It would be nice if when changing levels (PgUp/PgDown) the level name
would temporarily be displayed in a corner somewhere. Just for about a
second.

Also, when you select objects->badguys all the badguys are shown on
the right side. I think you should just show the first frame instead
of animating them. They are distracting and annoying (to me anyway :)
when you're trying to focus on the level.

Other than that, I'd have to say it looks really good. Nice work.

-- 
Ryan

Re: [Super-tux-devel] Short note

[Ryan F. <rf...@gm...>]

On Mon, 10 May 2004 01:16:46 +0200, Tobias Gl=E4=DFer <tob...@gm...> wro=
te:

> nobody should mess around in the CVS now, besides fixing of bugs, of
> course.

Now would be a good time to bring up any bugs that *need* to be fixed
before the next release.

--=20
Ryan

[Super-tux-devel] Short note

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

Hi all,

nobody should mess around in the CVS now, besides fixing of bugs, of
course.

Tomorrow I'll add some last final features to the editor and release
another SuperTux.

And now ... I'm sleeping deep. *tzzzz :)

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] Some small issues

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

Em Domingo, 9 de Maio de 2004 22:14, o Ryan Flegel escreveu:
> Hi,
>
> I installed SuperTux (Win32) for my sister the other weekend and I'm
> back home this weekend. I asked her if there were any things she
> didn't like about the game. Here are some of the things she mentioned.
>
> - After finishing a level Tux takes too long to get to the igloo.
> (maybe we could make him run?)
 Well, it takes awhile, and it can get boring, since it is just a penguin 
walking into his igloo...
 Anyway, in the future there could be bonuses and stuff (as in SMB3) at the 
end and maybe special effects (like fireworks...).

> - When opening up SuperTux in fullscreen it sometimes takes a little
> while (a minute?) before the screen changes from black to supertux.
 Currently, when fullscreen is selected, what we do is the same thing as if we 
were changing from SDL to OpenGL or vice-versa. We change the all video mode,  
besides we free and load all graphics again into the memory.

 There is a simple function in SDL called SDL_WM_ToggleFullScreen() that would 
make that faster. Anyway, it would not help your sis, since it only works in 
X11 ;)
 I would already have implemented that if I knew how to check (with ifdefs) if 
this is a X11 system or Linux or something... Anyone?

> - Jumping seems nonresponsive somtimes.
 That's due to the new auto-jump behavior...
(Personally, I don't like it much myself either...)

> - When selecting OpenGL in the options menu SuperTux crashes. (I'm
> sure I did this once before and it worked fine. Repeated attempts
> cause SuperTux to close but then it does not open back up in OpenGL
> mode)
>
 Hmmm, we need more Windows testing...

> - I noticed that when you hit a powerup box as BigTux a flower pops up
> but if you get hit and turn into SmallTux before getting the flower
> you still become SuperTux after getting the flower. IMO, this
> behaviour is okay, I just thought I'd bring it up.
>
 I also like the current behavior.

 About that, I would like to see an animation when Tux gets bigger or with 
fire power... I just think it looks bad that Tux gets grown up, just in a 
moment...
 If anyone is willing to make a few animation frames, I am willing to make the 
code for it ;)

> If she mentions anything else I'll be sure to post it here.

 I would like to say that now that SuperTux 0.1 has been released is now the 
time to start discussing new ideas and behavior improvements to the next 
Milestone ;) So, I really would like to see more discussions, regarding our 
Tux's future :)

Cheers,

 Ricardo Cruz

-- 
It's trivial to make fun of Microsoft products, but it takes a real man to
make them work, and a god to make them do anything useful.

[Super-tux-devel] Some small issues

[Ryan F. <rf...@gm...>]

Hi,

I installed SuperTux (Win32) for my sister the other weekend and I'm
back home this weekend. I asked her if there were any things she
didn't like about the game. Here are some of the things she mentioned.

- After finishing a level Tux takes too long to get to the igloo.
(maybe we could make him run?)
- When opening up SuperTux in fullscreen it sometimes takes a little
while (a minute?) before the screen changes from black to supertux.
- Jumping seems nonresponsive somtimes.
- When selecting OpenGL in the options menu SuperTux crashes. (I'm
sure I did this once before and it worked fine. Repeated attempts
cause SuperTux to close but then it does not open back up in OpenGL
mode)

- I noticed that when you hit a powerup box as BigTux a flower pops up
but if you get hit and turn into SmallTux before getting the flower
you still become SuperTux after getting the flower. IMO, this
behaviour is okay, I just thought I'd bring it up.

If she mentions anything else I'll be sure to post it here.

-- 
Ryan

Re: [Super-tux-devel] supertux on ultrasparc (64bit, big endian, x w/ 24bpp)

[C R. <zra...@mi...>]

Hm... I'm on a 32-bit bigendian (G4 Mac) and don't have any problems=20
with colors... wonder if the G5 (64-bit bigendian) would have that=20
problem? Anyone have one to test that?

Ratchet

On May 9, 2004, at 6:48 AM, Tobias Gl=E4=DFer wrote:

> Am So, den 09.05.2004 um 13:24 Uhr +0200 schrieb G=FCrkan Seng=FCn:
>> has someone run SuperTux on a UltraSparc yet? i tried, but the
>> colors are wrong, it's a 64bit machine with Big Endian
>> the colors look psychodelic random
>> the game works fine otherwise, let me check what bpp i
>> configured
>> 24bpp
>>
>> g=FCrkan
>
>> =46rom the sources I can more or less guess where the problems is,
> but it would be damn cool to have a Big Endian machine and see myself.
>
> Greetz...
>
> Tobias Gl=E4=DFer (dreams...)
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
>
>
---

Are YOU a Good Person? Go here:=20
http://www.wayofthemaster.com/wotm_flash.html

[Super-tux-devel] Flying platform & checkboxes & my handwritten font

[Benjamin P. J. <bp...@gm...>]

Hi all,

I've done a prototype for a flying platform which might be useful someday.
--> http://www.phreakzone.com/tmp/index.html

I also redid (as requested) my checkboxes. They are slightly bigger now and
seem to fit better into the existing menus.

My handwritten font in the game seems look quite ok as far as I can see --
still the big font seem to be problematic -- I definately made some
very serious mistakes regarding grid-size of the letters..... OOooouch 
!!!! :-/
Also the small ATARI-like font has suffered quality-loss, I'm afraid.
I don't know how the original small font was done using the big one...
maybe someone could give me a hint ... ?



Benjamin

[Super-tux-devel] Please confirm your request to join emeditor

[Yahoo! G. <confirm-s2-tyDk4CU3IqSrWNX6u=Rg=dGHF64-super-tux-devel=<lis...@ya...>]

Hello sup...@li...,

We have received your request to join the emeditor 
group hosted by Yahoo! Groups, a free, easy-to-use community service.

This request will expire in 7 days.

TO BECOME A MEMBER OF THE GROUP: 

1) Go to the Yahoo! Groups site by clicking on this link:

   http://groups.yahoo.com/i?i=tyDk4CU3IqSrWNX6u-Rg-dGHF64&e=super-tux-devel%40lists%2Esourceforge%2Enet 

  (If clicking doesn't work, "Cut" and "Paste" the line above into your 
   Web browser's address bar.)

-OR-

2) REPLY to this email by clicking "Reply" and then "Send"
   in your email program

If you did not request, or do not want, a membership in the
emeditor group, please accept our apologies
and ignore this message.

Regards,

Yahoo! Groups Customer Care

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

 

Re: [Super-tux-devel] 800x600 resolution

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

Em Domingo, 9 de Maio de 2004 07:42, o Bill Kendrick escreveu:
> On Sat, May 08, 2004 at 11:05:56PM +0100, Ricardo Cruz wrote:
> >  Besides, I don't think it applies very well into games. I know there a=
re
> > some advantages, like the power of allowing resizing in real-time, but
> > don't forget that OpenGL has support for this stuff. Futhermore, expect
> > SVG real-time resizing to be slow as hell or at least not smooth.
>
> Well, we wouldn't need 'real-time' resizing, unless the user is constantly
> resizing their game window. ;^)  It would just render the SVG into a norm=
al
> SDL surface in the correct size and proportions for the window.
>
 We have already discussed in a meeting that it would be nice to support=20
sprite's resizing in-game, a l=E1 Yoshi's island.

Ricardo Cruz

=2D-=20
"When the only tool you have is a hammer, you tend to treat everything as if
it were a nail."
=2D- Abraham Maslow

Re: [Super-tux-devel] supertux on ultrasparc (64bit, big endian, x w/ 24bpp)

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

Am So, den 09.05.2004 um 13:24 Uhr +0200 schrieb Gürkan Sengün:
> has someone run SuperTux on a UltraSparc yet? i tried, but the
> colors are wrong, it's a 64bit machine with Big Endian
> the colors look psychodelic random
> the game works fine otherwise, let me check what bpp i
> configured
> 24bpp
> 
> gürkan

>From the sources I can more or less guess where the problems is,
but it would be damn cool to have a Big Endian machine and see myself.

Greetz...

Tobias Gläßer (dreams...)

[Super-tux-devel] supertux on ultrasparc (64bit, big endian, x w/ 24bpp)

[<gu...@li...>]

has someone run SuperTux on a UltraSparc yet? i tried, but the
colors are wrong, it's a 64bit machine with Big Endian
the colors look psychodelic random
the game works fine otherwise, let me check what bpp i
configured
24bpp

g=FCrkan

Re: [Super-tux-devel] 800x600 resolution

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

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

>> Screenshots please, my version here is KSokoban 0.4.2 (Using KDE
>> 3.2.2) and thats still pixel gfx.
>  For the record, KDE doesn't already use SVG everywhere. It already has 
> support for it and KSVG is getting mature, but it isn't quite ready.
>
>  According to kcontrol, I am using KDE 3.2 BRANCH >= 20040204 and the KSokoban 
> is 0.4.2 as well.
>  Here you have successive screenshots:
> http://rpmcruz.planetaclix.pt/trash/ksokoban1.png
> http://rpmcruz.planetaclix.pt/trash/ksokoban2.png
> http://rpmcruz.planetaclix.pt/trash/ksokoban3.png
>
>  As you can see, it sectreches. It wouldn't be possible otherwise - Believe 
> me, I already made games using Qt.

As said, it uses plain old pixel graphics, scale it up and you will
see how the pixel apear. If you still don't believe me and use the
source where you find the .pngs. The game just happens to use graphics
in a higher res the most normal people use it, that why you can scale
it up a little bit without noticing. Graphics itself are rendered by
povray, so it actually would be possible to scale them up seemlessly,
but not in the SVG kind of scense.

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

Re: [Super-tux-devel] 800x600 resolution

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

On Sun, May 09, 2004 at 02:04:46AM +0200, Ingo Ruhnke wrote:
> 800x600 has another very important advantage: my TV-Out and my TV can
> handle it, which isn't the case for larger resolutions and well,
> SuperTux like games are best enjoyed infront of a TV instead of a
> monitor.

Oooh!  One reason to keep 640x480...  That's as high as PDAs go.
Imagine Super Tux (maybe with parallax background turned off ;^) ) running
on the 640x480 model Sharp Zaurus PDAs! >:^)


<snip>
> Not really, Flash is already pretty dominant in that place :)

Well, even if there was a 'Flash' version of a Super Mario style game,
I doubt the tiles were vectors.  They would probably just use squares and
draw a pre-drawn bitmap onto them.  (e.g, if it scaled up, it would look
pixelated)

That's different from using SVG for the tile art itself. :^)


<snip>
> Well, the loss already is in the graphic itself. Doesn't really matter
> if you can scale losslessly when the source itself already is sucky,
> which is the case for most vector gfx after all, they just have this
> 'vectorish' look which you can't really escape.

And I do admit, I think 'vector' look that we'd get witht he current state
of SVG art tools and SVG rendering would be a step backwards from the
gorgeous art we have right now!


<snip>
> >  - being pioneers
> 
> See Flash.

See above. :^)


-bill!

Re: [Super-tux-devel] 800x600 resolution

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

On Sun, May 09, 2004 at 12:41:13AM +0200, Tobias Gl=E4=DFer wrote:
> Hi folks,
>=20
> no doubt 640x480 is just too less and I even think 800x600 is a bad
> joke, since I'm using a comfortable 1280x1024 desktop.
> If we switch to a fixed size again, 1024x768 is a wise choice IMHO.

I would like to provide options.  Sometimes I like to watch IRC while
playing a game, or pause and do other things without having a giant windo=
w
on the screen.

(okay, I'm ignoring 'minimize' ;^) heheheh)


-bill!

Re: [Super-tux-devel] 800x600 resolution

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

On Sat, May 08, 2004 at 11:05:56PM +0100, Ricardo Cruz wrote:
> graphics have two problems:
> - technically, SDL_svg is yet in a very immature stage;

I'd love to see SDL_svg get off the ground, so we could be a good 'push' for
its further development! >:^)


> - for artists, SVG tools are also immature, especially Linux ones.

Yeah. :^(


>  Besides, I don't think it applies very well into games. I know there are some 
> advantages, like the power of allowing resizing in real-time, but don't 
> forget that OpenGL has support for this stuff. Futhermore, expect SVG 
> real-time resizing to be slow as hell or at least not smooth.

Well, we wouldn't need 'real-time' resizing, unless the user is constantly
resizing their game window. ;^)  It would just render the SVG into a normal
SDL surface in the correct size and proportions for the window.

(e.g., number of tile rows/columns on the screen would always be the same,
but the SVGs would render into 32x32, 40x40, 64x64, etc., depending on the
size of the window, or screen resolution (if full-screen)) :^)


>  So, what do you think?
> 
>  For the record, this is only plans for mid-future, after the 0.1.x featuring 
> the level editor.

Definitely wait til later. ;^)

-bill!

Re: [Super-tux-devel] 800x600 resolution

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

Em Domingo, 9 de Maio de 2004 02:04, o Ingo Ruhnke escreveu:
> Tobias Gl=E4=DFer <tob...@gm...> writes:
> > Is there any mature free software game project out there discovering
> > vector graphics power?
>
> Pretty much everything that is 3D is using 'vectorgraphics', I just
> don't see much reason to use it for 2D beside the disk-space saving
> one.
>
 Truth, you can consider 3d graphical operation as vectorial ones. But it i=
s=20
in a completely different level from a real vectorial format.

> >> The version I tested here used still good old pixel graphics. Yes,
> >> one could scale it, but the graphics would just pixelade as
> >> expected.
> >
> > That's not the case for my version. Indeed in KDE3.2 the most icons
> > and gfx are rendered directly from SVG data. (KSVG)
>
> Screenshots please, my version here is KSokoban 0.4.2 (Using KDE
> 3.2.2) and thats still pixel gfx.
 For the record, KDE doesn't already use SVG everywhere. It already has=20
support for it and KSVG is getting mature, but it isn't quite ready.

 According to kcontrol, I am using KDE 3.2 BRANCH >=3D 20040204 and the KSo=
koban=20
is 0.4.2 as well.
 Here you have successive screenshots:
http://rpmcruz.planetaclix.pt/trash/ksokoban1.png
http://rpmcruz.planetaclix.pt/trash/ksokoban2.png
http://rpmcruz.planetaclix.pt/trash/ksokoban3.png

 As you can see, it sectreches. It wouldn't be possible otherwise - Believe=
=20
me, I already made games using Qt.

 Anyway, KSokoban is a pretty small game, so that's no example for anything.

Ricardo Cruz

=2D-=20
There is no sincerer love than the love of food.
		-- George Bernard Shaw

Re: [Super-tux-devel] LevelEditor Progress...

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

 Well, I've just tried my idea... and guess what... It worked :D
 It looks like we don't need the 300 lines afterall ;)

 I'll extend that support for the others draw_part() and alike functions.

 But it seems to have this problem; when an image has an alpha value betwee=
n 0=20
and 255, the colorkey also gets with alpha in that pixel and therefore it=20
blits that pixel into the screen. Not sure how this will be solved, anyway=
=20
this is really a small issue (at least for now...).


 Just one thing, regarding the level editor, I think that bad guys (and eve=
n=20
Tux) should get semi-transparent when Foreground and Background is selected=
=2E=20
It shouldn't be also possible to apply them then.

Ricardo Cruz

Em S=C3=A1bado, 8 de Maio de 2004 00:07, o Ricardo Cruz escreveu:
>  Anyway, it was working, couldn't we just port it again?
>
>  AFAIK, you just need to create another surface, blit the surface you want
> to blit into the screen into this one, apply alpha to the temp surf and
> then just blit the temp surf into the screen. It is nothing from another
> world :) I have made the current code, and I dunno why it isn't working...
>
>  In case it is too slow, we can allways get rid of it...
>
>  And this code that can be found at draw_bg, draw_part or draw_stretched:
>   if(alpha !=3D 255)
>     SDL_SetAlpha(sdl_surface ,SDL_SRCALPHA,alpha);
> will make the surface to have that alpha forever. This code should be
> removed.
>
> Ricardo Cruz
>
> Em S=C3=A1bado, 8 de Maio de 2004 00:03, o Tobias Gl=C3=A4=C3=9Fer escrev=
eu:
> > Am Sa, den 08.05.2004 schrieb Tobias Gl=C3=A4=C3=9Fer um 0:57:
> > > Am Sa, den 08.05.2004 schrieb Ricardo Cruz um 0:03:
> > > >  Those are great news.
> > > >  There is only this issue that I think that should get priority:
> > > > - the SDL frontend doesn't seem to support Alpha when blitting
> > > > surfaces. i think this worked before... anyway, when looking at
> > > > Background, for instance, the Foreground and Active stuff just
> > > > dissapears...
> > > >
> > > > Ricardo Cruz
> > >
> > > Actually, as I stated in another mail, SDL software rendering isn't
> > > able to do alpha on alpha surface blitting. :(
> > > For the same reason the minimap is a OpenGL only feature, too.
> > >
> > > Greetz...
> > >
> > > Tobias Gl=C3=A4=C3=9Fer
> >
> > Before another one comes up with it now. Yes, you could write your
> > own blitting method for this purpose. But on the on hand it's pretty
> > tough to write it. (Or wouldn't the SDL folks provide it in their
> > renderer, if it was easy to implement?) And on the other hand the
> > resulting blitting method would be a very slow one.
> >
> > Can someone think of an alternative solution for the editor?
> >
> > Greetz...
> >
> > Tobias Gl=C3=A4=C3=9Fer

=2D-=20
"Yo baby yo baby yo."
=2D- Eddie Murphy

Re: [Super-tux-devel] 800x600 resolution

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

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

>> Low as in very very low, once I have a HD-TV and my display resolution
>> is at 4000x3000 it might be worth to talk about it again, but until
>> then its pretty much just a waste of time. Well, and even then I
>> wouldn't go for SVG, but directly use the paint strokes that where
>> used to generate the pixel graphics.
>
>  What you just described are vectorial graphics ;D

Not really, at least not in the SVG kind of sense. SVG only knows
about plain lines, filled polygons and a handfull of fill-patterns, it
doesn't know anything about smooth brushes or smudge lines, but
without them you will never get away from this vectorish look.

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

Re: [Super-tux-devel] 800x600 resolution

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

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

> How often do you play SuperTux on your TV? :)

Often enough to care about it.

> Well, I did expect that there are games using vector graphics. In 20
> years of game development with thousands of games developed, it would
> be stupid to think noone of them used vector graphics.
>
> But on the free software side of things we would be pioneers?

Nope, AnotherWorld engine was recently ported/rewritten and released
as GPL, too late =3D:)

> Is there any mature free software game project out there discovering
> vector graphics power?

Pretty much everything that is 3D is using 'vectorgraphics', I just
don't see much reason to use it for 2D beside the disk-space saving
one.

> Well having realistic looking gfx isn't easy with SVG, but it might
> be the right think for a comic look? I could image that many
> comics are made using vector graphics today.

I doubt it. Even most stuff that uses comic-look for characters, still
has pretty much shaded/realistic backgrounds.

> I claim that animating with a tool like Macromedia flash etc. is
> much easier than pixel-by-pixel hand editing.

What makes you believe so? Either you get the walk cycle right or not,
a tool can't help there much, unless of course you go 3d and just
apply some skeletal animation, but that won't work for 2d.

> You can't copy&paste parts of the image that aren't in the foreground
> for example with pixel images.

Thats what multiple layers are for.

> Flash is successful.

Flash is successful because of 'zero install', just click'n run and
because of the stupid games, most are just single click games with a
bit of timing, nothing more. I havn't seen Flash being espcially
successfull for 'serious' games.

> I respect your realism. But if all people back in the day thought
> like you do in this case many "innovations" (the most innovations
> aren't totally new) wouldn't exist.

There are a lot of 'innovations' that I would really not miss.
Something isn't good, just because its hip and new.

> With OpenGL your hardware does its best to resize pixel-image, which
> leads to similar results as you would get with Gimp. I mean that's
> good but it's not optimal.

Give OpenGL the pixel image with two times the size and scale down,
results will be better then anything you get with vector stuff.

>> The version I tested here used still good old pixel graphics. Yes,
>> one could scale it, but the graphics would just pixelade as
>> expected.
>
> That's not the case for my version. Indeed in KDE3.2 the most icons
> and gfx are rendered directly from SVG data. (KSVG)

Screenshots please, my version here is KSokoban 0.4.2 (Using KDE
3.2.2) and thats still pixel gfx.

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

Re: [Super-tux-devel] 800x600 resolution

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

Em Domingo, 9 de Maio de 2004 01:29, o Ingo Ruhnke escreveu:
> Ricardo Cruz <ri...@ae...> writes:
> > And in case we don't also find a SVG engine for OpenGL, SVG will
> > have to be deal with by software-only.
>
> That would render SVG pretty much useless.
>
 I meant for loading...
 The SVG SDL engine would just import SVG graphics as SDL_Surfaces structs and 
OpenGL would just use them...

> >  Anyway, I am willing to give it a try ;) (especially, because of that
> > png->svg converter)
>
> Forget that converter please, it will NOT work.
>
 I meant for the testing... Man, that was part of some line related with that.
 Of course, I am also pretty sure that the result will not be that famous ;)

> > Anyway, I think this should get low priority,
>
> Low as in very very low, once I have a HD-TV and my display resolution
> is at 4000x3000 it might be worth to talk about it again, but until
> then its pretty much just a waste of time. Well, and even then I
> wouldn't go for SVG, but directly use the paint strokes that where
> used to generate the pixel graphics.

 What you just described are vectorial graphics ;D

Ricardo Cruz

-- 
Look afar and see the end from the beginning.

Re: [Super-tux-devel] 800x600 resolution

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

Am So, den 09.05.2004 um 2:29 Uhr +0200 schrieb Ingo Ruhnke:
> Ricardo Cruz <ri...@ae...> writes:
> 
> >  You kinda conviced me... But I still am afraid of artists lost and
> > speed. Well, speed shouldn't be an issue as long as we loaded
> > everything during the video mode setup... It could turn into an
> > issue, if we wanted stuff to be resized in-game.
> 
> OpenGL can do resizing without a problem, software is to slow anyway
> if you want larger resolutions than 800x600.

As stated in another mail the solution would be to have a Surface
structure that saves the svg source, the sdl_surface the results from
it and the open_gl texture, which in turn results from the sdl_surface.

The speed would be the same as in the current engine only with a longer
startup time.
If we want to print the image scaled it would have to created on demand
from the stored svg source. (using cairo)

> >  Truth be told, I've never tested anything related with SVG (in
> > fact, KSokoban is really fast - it only has about six graphics
> > anyway :D)
> 
> KSokoban also has a pretty steady screen, so its easy to optimize.
> With paralax scrolling layers like in SuperTux however you can't
> really optimize anything, OpenGL is the only hope for fast framerates.

Yep, OpenGL and SVG don't exclude each other and I think THAT WOULD BE
something innovative!

> > And in case we don't also find a SVG engine for OpenGL, SVG will
> > have to be deal with by software-only.
> 
> That would render SVG pretty much useless.

Look above.

> >  Anyway, I am willing to give it a try ;) (especially, because of that 
> > png->svg converter)
> 
> Forget that converter please, it will NOT work.

Not 1:1.

> >  My proposal is that we, firstly, implemented a SVG engine into
> > the...
> 
> My proposal is that we quickly completly forget about this SVG thingy
> please. There are currently neither the tools nor libraries around to
> make it much usefull, not even Mozilla has support for SVG at the
> moment and until you will get useable animation support in sodipodi
> there will go a few years into the land. 

You don't have to help in our experiment. But you can't forbid me to
test something out.

> >  Agree?
> 
> No, really not.

There is nothing to lose. If it fails, I and others still learned
something about vector graphics programming.

> > Anyway, I think this should get low priority,
> 
> Low as in very very low, once I have a HD-TV and my display resolution
> is at 4000x3000 it might be worth to talk about it again, but until
> then its pretty much just a waste of time. Well, and even then I
> wouldn't go for SVG, but directly use the paint strokes that where
> used to generate the pixel graphics.

I can think of other areas than screen resolution, where SVG could make
life easier. Don't have the time to write it down now, because
my bed is crying for me.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] 800x600 resolution

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

Am So, den 09.05.2004 um 2:04 Uhr +0200 schrieb Ingo Ruhnke:
> Tobias Gläßer <tob...@gm...> writes:
> 
> > no doubt 640x480 is just too less and I even think 800x600 is a bad
> > joke, since I'm using a comfortable 1280x1024 desktop.
> > If we switch to a fixed size again, 1024x768 is a wise choice IMHO.
> 
> I am personally very happy with 800x600, its pretty much enough for
> everything and low enough to not waste too much space and resources.
> Especially when it comes to pixeled graphics there is little chance to
> fill the screen with a size of 1024x768. Just having a larger
> resolution is worth nothing if there is nobody to fill in all the
> details. Just a little math 800x600 has 1.56 times as many pixels as
> 640x480, 1024x768 already has 2.56 times as many pixels as we
> currently have, so software rendering is really a no-go for 1024x768.

We speak about SuperTux 0.2x+, it's possible that we drop software
rendering. Future X-Servers (like the fd.org one) are based on OpenGL
and so we can expect our users to have this requirements, too.
You are right, there isn't much gained if nobody fills in the resulting
increase in pixels.

> 800x600 has another very important advantage: my TV-Out and my TV can
> handle it, which isn't the case for larger resolutions and well,
> SuperTux like games are best enjoyed infront of a TV instead of a
> monitor. If one goes for OpenGL only one could of course provide a way
> to scale the viewport back to 800x600, even if the gfx itself have a
> higherres.

How often do you play SuperTux on your TV? :) No big issue, esspecially
with OpenGL downscaling is a non-issue.

> > About the SVG thingy. There are very few 2d games using such a
> > feature currently.
> 
> Pretty much all Flash games out there on the Internet use Vector
> graphics, while it isn't SVG, its still pretty much the same. If you
> want to get even more back in time, look at AnotherWorld, used fully
> vector based gfx back then in 1992. Many of the old Sierra adventure
> games also used vector graphics to save some diskspace.

Well, I did expect that there are games using vector graphics. In 20
years of game development with thousands of games developed, it would
be stupid to think noone of them used vector graphics.

But on the free software side of things we would be pioneers?
Is there any mature free software game project out there discovering
vector graphics power?

> > Therefore we could be pioneers in this field.
> 
> Not really, Flash is already pretty dominant in that place :)

Let's rock the flash baby games away. ;)

> > Some advantages:
> >  - resizing images with no loss
> 
> Well, the loss already is in the graphic itself. Doesn't really matter
> if you can scale losslessly when the source itself already is sucky,
> which is the case for most vector gfx after all, they just have this
> 'vectorish' look which you can't really escape.

Well having realistic looking gfx isn't easy with SVG, but it might
be the right think for a comic look? I could image that many
comics are made using vector graphics today.

> >  - easier creation of animations ?
> 
> If you do it in vectors or in pixels doesn't really matter.

I claim that animating with a tool like Macromedia flash etc. is much
easier than pixel-by-pixel hand editing. Unfortunately there isn't
a free software SVG animating tool out there, is it?

> >  - reusing of imageparts - merging of images
> 
> Called copy&paste, works pretty well in pixel images.

You can't copy&paste parts of the image that aren't in the foreground
for example with pixel images.
But I agree, it's not a problem with either of the methods.

> >  - being pioneers
> 
> See Flash.

Flash is successful.

> >  - the tools/libs for using SVG inside games and esspecially with
> >  SDL are not very mature (but perhaps we can help in their
> >  development, just like planeshift for example helps crystal space
> >  with stuff they need)
> 
> Just for the record, the SVG tools we currently have are easily 5-10
> years behind the stuff that you have on the windows side. And I
> personally consider sodipodi completly unusable, while inkscape has a
> much better interface, it still lacks a whole lot of features.

Actually I talked about the coder's side of things. :)
But actually cairo seems to be a promising candidate.

> >  - graphics designers do have less experience and skills with vector
> >  graphics?
> 
> No, vector graphics helps you with getting a smooth curve, it doesn't
> help you to get the curve into the right spot.

> >  - our experiment could dramatically fail
> 
> For sure they would.

I respect your realism. But if all people back in the day thought like
you do in this case many "innovations" (the most innovations aren't
totally new) wouldn't exist.

> 
> > But it would be awesome after all to have a option in our option
> >dialog where you can select nearly any screen resolution.
> 
> Trivial todo with Opengl already.

With OpenGL your hardware does its best to resize pixel-image, which
leads to similar results as you would get with Gimp. I mean that's
good but it's not optimal.

> > Maybe we could even port the current PNGs without much efforts
> > to SVG, don't believe me? Then look at this project:
> 
> You can't convert shaded pixel gfx into vector graphics without
> loosing *a lot* of quality, it only works well for simple black&white
> outlines and such.

That's true. With SVG we had to go for another graphics style.

> > A game I found using SVG is KSokoban. That's not THE killer game ;),
> > but it's awesome that you can resize it to every size without loss
> > and its tiles don't look bad (quite good) IMHO.
> 
> The version I tested here used still good old pixel graphics. Yes, one
> could scale it, but the graphics would just pixelade as expected.

That's not the case for my version. Indeed in KDE3.2 the most icons and
gfx are rendered directly from SVG data. (KSVG)

> > I don't know what you think, but SVG is an exciting technology.
> 
> Not really. Vector graphic is pretty old technology and has been
> around for ages. SVG is just a new name and a bloated XML format
> wrapped around it. Vector graphics are nice if you want to print to
> paper, but I havn't found them really usefull for on screen display.

The age has pretty much nothing to some about its excitement IMHO.

Greetz...

Tobias Gläßer

Re: [Super-tux-devel] 800x600 resolution

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

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

>  You kinda conviced me... But I still am afraid of artists lost and
> speed. Well, speed shouldn't be an issue as long as we loaded
> everything during the video mode setup... It could turn into an
> issue, if we wanted stuff to be resized in-game.

OpenGL can do resizing without a problem, software is to slow anyway
if you want larger resolutions than 800x600.

>  Truth be told, I've never tested anything related with SVG (in
> fact, KSokoban is really fast - it only has about six graphics
> anyway :D)

KSokoban also has a pretty steady screen, so its easy to optimize.
With paralax scrolling layers like in SuperTux however you can't
really optimize anything, OpenGL is the only hope for fast framerates.

> And in case we don't also find a SVG engine for OpenGL, SVG will
> have to be deal with by software-only.

That would render SVG pretty much useless.

>  Anyway, I am willing to give it a try ;) (especially, because of that 
> png->svg converter)

Forget that converter please, it will NOT work.

>  My proposal is that we, firstly, implemented a SVG engine into
> the...

My proposal is that we quickly completly forget about this SVG thingy
please. There are currently neither the tools nor libraries around to
make it much usefull, not even Mozilla has support for SVG at the
moment and until you will get useable animation support in sodipodi
there will go a few years into the land. 

>  Agree?

No, really not.

> Anyway, I think this should get low priority,

Low as in very very low, once I have a HD-TV and my display resolution
is at 4000x3000 it might be worth to talk about it again, but until
then its pretty much just a waste of time. Well, and even then I
wouldn't go for SVG, but directly use the paint strokes that where
used to generate the pixel graphics.

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