Thread: [Super-tux-devel] 800x600 resolution
Brought to you by:
wkendrick
Menu
▾
▴
super-tux-devel
|
From: Ricardo C. <ri...@ae...> - 2004-05-08 22:20:36
|
Hey there, It was already suggested by Ingo a resolution change to 800x600. In fact, IMO the 640x480 is too small and looks really bad when using fullscreen (especially in my monitor that uses a 1280x1024 resolution). If you agree, we could either add rows to levels or/and resize images. I would prefer this last solution and that would mean a change from 32x32 images into 40x40 pixels. A resize without interpolation and then polishment should work just fine... Tobias already discussed the hypotheses of using SVG graphics... IMO, these graphics have two problems: - technically, SDL_svg is yet in a very immature stage; - for artists, SVG tools are also immature, especially Linux ones. 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. So, what do you think? For the record, this is only plans for mid-future, after the 0.1.x featuring the level editor. Ricardo Cruz -- Better by far you should forget and smile than that you should remember and be sad. -- Christina Rossetti |
|
From: Tobias <tob...@gm...> - 2004-05-08 22:36:57
|
Hi folks,
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.
About the SVG thingy. There are very few 2d games using such a feature
currently. Therefore we could be pioneers in this field.
I don't want to convince you about it or persuade you I only want
to start a valueable discussion about the pros and cons.
This wouldn't mean we have to use the SVG approach throughout the whole
game.
Some advantages:
- resizing images with no loss
- change graphics/vectors in game ?
- easier creation of animations ?
- reusing of imageparts - merging of images
- being pioneers
Some disadvantages:
- 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)
- graphics designers do have less experience and
skills with vector graphics?
- our experiment could dramatically fail
Maybe someone of you had a look into KSVG, the KDE SVG engine.
SVGs are equally powerful as flashs with it, so I think it's
technically possible, which doesn't mean it's easy or the
tools/libs for this capabilities are already there.
But it would be awesome after all to have a option in our
option dialog where you can select nearly any screen resolution.
There are big changes and a high risk. No risk no fun? :)
(I feel, too many realists are hanging around here;) )
Greetz...
Tobias Gläßer
Am Sa, den 08.05.2004 um 23:05 Uhr +0100 schrieb Ricardo Cruz:
> Hey there,
>
> It was already suggested by Ingo a resolution change to 800x600. In fact, IMO
> the 640x480 is too small and looks really bad when using fullscreen
> (especially in my monitor that uses a 1280x1024 resolution).
>
> If you agree, we could either add rows to levels or/and resize images. I
> would prefer this last solution and that would mean a change from 32x32
> images into 40x40 pixels. A resize without interpolation and then polishment
> should work just fine...
>
> Tobias already discussed the hypotheses of using SVG graphics... IMO, these
> graphics have two problems:
> - technically, SDL_svg is yet in a very immature stage;
> - for artists, SVG tools are also immature, especially Linux ones.
> 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.
>
> So, what do you think?
>
> For the record, this is only plans for mid-future, after the 0.1.x featuring
> the level editor.
>
> Ricardo Cruz
>
> --
> Better by far you should forget and smile than that you should remember
> and be sad.
> -- Christina Rossetti
>
>
> -------------------------------------------------------
> 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=osdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
>
|
|
From: Tobias <tob...@gm...> - 2004-05-08 23:07:05
|
Hi, I surfed a bit around and googled about SDL/SVG issues. There are a few tries that don't seem to be straighforward to me. (rsvg etc.) But then I found cairo about wich I already heared much on slashdot and so on. I didn't know that you can use this SVG engine with SDL, but indeed there is an example in its CVS repository. Perhaps you want to take a look. http://freedesktop.org/cgi-bin/viewcvs.cgi/cairo/cairo-demo/sdl/ I think we could change the Surfaces to hold a svg_cairo_t structure additionally. This could be used as source for the actual surfaces/textures then. (For example if we want to change the resolution or draw a scaled image) After all the possible CPU and memory loads could be the biggest problems. I don't know benchmarks about it, do you? Maybe we could even port the current PNGs without much efforts to SVG, don't believe me? Then look at this project: http://delineate.sourceforge.net/ Ok, this conversion won't happen lossfree. Maybe the design would end more like in comics. (Good or Bad?) 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. I don't know what you think, but SVG is an exciting technology. Greetz... Tobias Gläßer Am So, den 09.05.2004 um 0:41 Uhr +0200 schrieb Tobias Gläßer: > Hi folks, > > 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. > > About the SVG thingy. There are very few 2d games using such a feature > currently. Therefore we could be pioneers in this field. > I don't want to convince you about it or persuade you I only want > to start a valueable discussion about the pros and cons. > > This wouldn't mean we have to use the SVG approach throughout the whole > game. > > Some advantages: > - resizing images with no loss > - change graphics/vectors in game ? > - easier creation of animations ? > - reusing of imageparts - merging of images > - being pioneers > > Some disadvantages: > - 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) > - graphics designers do have less experience and > skills with vector graphics? > - our experiment could dramatically fail > > Maybe someone of you had a look into KSVG, the KDE SVG engine. > SVGs are equally powerful as flashs with it, so I think it's > technically possible, which doesn't mean it's easy or the > tools/libs for this capabilities are already there. > > But it would be awesome after all to have a option in our > option dialog where you can select nearly any screen resolution. > There are big changes and a high risk. No risk no fun? :) > (I feel, too many realists are hanging around here;) ) > > Greetz... > > Tobias Gläßer > > Am Sa, den 08.05.2004 um 23:05 Uhr +0100 schrieb Ricardo Cruz: > > Hey there, > > > > It was already suggested by Ingo a resolution change to 800x600. In fact, IMO > > the 640x480 is too small and looks really bad when using fullscreen > > (especially in my monitor that uses a 1280x1024 resolution). > > > > If you agree, we could either add rows to levels or/and resize images. I > > would prefer this last solution and that would mean a change from 32x32 > > images into 40x40 pixels. A resize without interpolation and then polishment > > should work just fine... > > > > Tobias already discussed the hypotheses of using SVG graphics... IMO, these > > graphics have two problems: > > - technically, SDL_svg is yet in a very immature stage; > > - for artists, SVG tools are also immature, especially Linux ones. > > 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. > > > > So, what do you think? > > > > For the record, this is only plans for mid-future, after the 0.1.x featuring > > the level editor. > > > > Ricardo Cruz > > > > -- > > Better by far you should forget and smile than that you should remember > > and be sad. > > -- Christina Rossetti > > > > > > ------------------------------------------------------- > > 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=osdnemail3 > > _______________________________________________ > > Super-tux-devel mailing list > > Sup...@li... > > https://lists.sourceforge.net/lists/listinfo/super-tux-devel > > > > > > ------------------------------------------------------- > 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=osdnemail3 > _______________________________________________ > Super-tux-devel mailing list > Sup...@li... > https://lists.sourceforge.net/lists/listinfo/super-tux-devel > |
|
From: Ingo R. <gr...@gm...> - 2004-05-09 00:05:04
|
Tobias Gl=E4=DFer <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. 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. > 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. > Therefore we could be pioneers in this field. Not really, Flash is already pretty dominant in that place :) > 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. > - easier creation of animations ? If you do it in vectors or in pixels doesn't really matter. > - reusing of imageparts - merging of images Called copy&paste, works pretty well in pixel images. > - being pioneers See Flash. > - 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. > - 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. > 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. > 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. > 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. > 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. --=20 WWW: http://pingus.seul.org/~grumbel/=20 JabberID: gr...@ja...=20 ICQ: 59461927 |
|
From: Ricardo C. <ri...@ae...> - 2004-05-09 00:25:24
|
Em Domingo, 9 de Maio de 2004 01:04, o Ingo Ruhnke escreveu: > Tobias Gl=E4=DFer <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. > I agree with Ingo, 800x600 is good enough. > > 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. > > > Therefore we could be pioneers in this field. > > Not really, Flash is already pretty dominant in that place :) > Obviously, SuperTux wouldn't be the first using vector graphics... Even in= a=20 little game of mine, I use True Type Fonts ;) What Tobias meant is that SuperTux could be the first (or one of the first= s)=20 _big_ and _native_ games to use SVG. > > - our experiment could dramatically fail > > For sure they would. > Don't be such a pessimist :D > > 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. > What OpenGL do is just to resize them and thus loosing quality. A way to=20 avoid this could be to make graphics bigger, this way it would only had to= =20 resize them down... > > 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. > > > 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. > The one shipped with KDE 3.2 already uses SVG. In fact, Atlantik and maybe= a=20 couple of more games also use it. KDE goal is to start using SVG in the all desktop on 4.0 or maybe before. = As=20 a matter of fact, their policy is to only get graphics that also have a SVG= =20 version. (in fact, KDE 3.2 was delayed because Everaldo wouldn't release th= e=20 SVG, forcing other artists to mimic their graphics in SVG ;D) > > 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. Even if that's truth and SVG hasn't technically innovated anything. I call= =20 innovation to use existing technology, bringing it to the masses. Anyway, vectorial graphics are older than us :D. =2D-=20 A novice programmer was once assigned to code a simple financial package. The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, and artificial intelligence interface, but not the slightest mention of anything financial. When the master asked about this, the novice became indignant. "Don't be so impatient," he said, "I'll put the financial stuff in=20 eventually." -- Geoffrey James, "The Tao of Programming" |
|
From: Bill K. <nb...@so...> - 2004-05-09 06:51:24
|
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! |
|
From: Bill K. <nb...@so...> - 2004-05-09 06:44:33
|
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! |
|
From: Ricardo C. <ri...@ae...> - 2004-05-09 00:06:51
|
Hey, You kinda conviced me... But I still am afraid of artists lost and speed.= =20 Well, speed shouldn't be an issue as long as we loaded everything during th= e=20 video mode setup... It could turn into an issue, if we wanted stuff to be=20 resized in-game. Truth be told, I've never tested anything related with SVG (in fact, KSoko= ban=20 is really fast - it only has about six graphics anyway :D), but I am allway= s=20 suspicious about software rendering. And in case we don't also find a SVG=20 engine for OpenGL, SVG will have to be deal with by software-only. Anyway, I am willing to give it a try ;) (especially, because of that=20 png->svg converter) My proposal is that we, firstly, implemented a SVG engine into the Surface= =20 class (maybe Cairo - I think our choice should be not firstly based in the= =20 performance, but in dependencies and portability). After that, we would jus= t=20 convert the PNGs into SVGs. Only for testing, code can be all hacky and graphics really ugly :) Agree? Anyway, I think this should get low priority, maybe we could create= a=20 brunch or something like that, just to test it and not break anything.=20 Though, I am looking forward to learn more about SVG. Cheers, Ricardo =20 Em Domingo, 9 de Maio de 2004 00:11, o Tobias Gl=C3=A4=C3=9Fer escreveu: > Hi, > > I surfed a bit around and googled about SDL/SVG issues. > There are a few tries that don't seem to be straighforward to me. > (rsvg etc.) > > But then I found cairo about wich I already heared much on slashdot > and so on. I didn't know that you can use this SVG engine with SDL, > but indeed there is an example in its CVS repository. > Perhaps you want to take a look. > http://freedesktop.org/cgi-bin/viewcvs.cgi/cairo/cairo-demo/sdl/ > > I think we could change the Surfaces to hold a svg_cairo_t structure > additionally. This could be used as source for the actual > surfaces/textures then. (For example if we want to change the > resolution or draw a scaled image) > > After all the possible CPU and memory loads could be the biggest > problems. I don't know benchmarks about it, do you? > > Maybe we could even port the current PNGs without much efforts > to SVG, don't believe me? Then look at this project: > http://delineate.sourceforge.net/ > Ok, this conversion won't happen lossfree. Maybe the design would > end more like in comics. (Good or Bad?) > > 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. > > I don't know what you think, but SVG is an exciting technology. > > Greetz... > > Tobias Gl=C3=A4=C3=9Fer > > Am So, den 09.05.2004 um 0:41 Uhr +0200 schrieb Tobias Gl=C3=A4=C3=9Fer: > > Hi folks, > > > > 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. > > > > About the SVG thingy. There are very few 2d games using such a feature > > currently. Therefore we could be pioneers in this field. > > I don't want to convince you about it or persuade you I only want > > to start a valueable discussion about the pros and cons. > > > > This wouldn't mean we have to use the SVG approach throughout the whole > > game. > > > > Some advantages: > > - resizing images with no loss > > - change graphics/vectors in game ? > > - easier creation of animations ? > > - reusing of imageparts - merging of images > > - being pioneers > > > > Some disadvantages: > > - 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) > > - graphics designers do have less experience and > > skills with vector graphics? > > - our experiment could dramatically fail > > > > Maybe someone of you had a look into KSVG, the KDE SVG engine. > > SVGs are equally powerful as flashs with it, so I think it's > > technically possible, which doesn't mean it's easy or the > > tools/libs for this capabilities are already there. > > > > But it would be awesome after all to have a option in our > > option dialog where you can select nearly any screen resolution. > > There are big changes and a high risk. No risk no fun? :) > > (I feel, too many realists are hanging around here;) ) > > > > Greetz... > > > > Tobias Gl=C3=A4=C3=9Fer > > > > Am Sa, den 08.05.2004 um 23:05 Uhr +0100 schrieb Ricardo Cruz: > > > Hey there, > > > > > > It was already suggested by Ingo a resolution change to 800x600. In > > > fact, IMO the 640x480 is too small and looks really bad when using > > > fullscreen (especially in my monitor that uses a 1280x1024 resolution= ). > > > > > > If you agree, we could either add rows to levels or/and resize image= s. > > > I would prefer this last solution and that would mean a change from > > > 32x32 images into 40x40 pixels. A resize without interpolation and th= en > > > polishment should work just fine... > > > > > > Tobias already discussed the hypotheses of using SVG graphics... IMO, > > > these graphics have two problems: > > > - technically, SDL_svg is yet in a very immature stage; > > > - for artists, SVG tools are also immature, especially Linux ones. > > > 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. > > > > > > So, what do you think? > > > > > > For the record, this is only plans for mid-future, after the 0.1.x > > > featuring the level editor. > > > > > > Ricardo Cruz > > > > > > -- > > > Better by far you should forget and smile than that you should rememb= er > > > and be sad. > > > -- Christina Rossetti > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > ------------------------------------------------------- > > 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 > > ------------------------------------------------------- > 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 =2D-=20 Who is W.O. Baker, and why is he saying those terrible things about me? |
|
From: Ingo R. <gr...@gm...> - 2004-05-09 00:30:00
|
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 |
|
From: Tobias <tob...@gm...> - 2004-05-09 00:50:08
|
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 |
|
From: Tobias <tob...@gm...> - 2004-05-09 00:39:12
|
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 |
|
From: Ingo R. <gr...@gm...> - 2004-05-09 01:04:55
|
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 |
|
From: Ricardo C. <ri...@ae...> - 2004-05-09 01:37:17
|
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 |
|
From: Ingo R. <gr...@gm...> - 2004-05-09 10:17:12
|
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 |
|
From: Bill K. <nb...@so...> - 2004-05-09 06:42:34
|
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! |
|
From: Ricardo C. <ri...@ae...> - 2004-05-09 13:39:16
|
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 |
|
From: Christopher A. W. <cr...@li...> - 2004-05-10 13:00:07
|
Let me just make this clear: I am heavily opposed to moving toward SVG. Perhaps for some sprites, perhaps for some circumstances, but certainly not all. If you want to think of a good way to slow down our development cycle, making a transition to SVG is a good way of accomplishing that :P Not only that, but I've recently been working quite a bit with SVG for a project I got hired in. It takes a hell of a lot longer than making sprites does, and on top of that, the hand drawn feel of the game will be completely lost. I think that the 800x600 thing is a good idea, but I suggest we wait until we have full horizontal/verticall scrolling implemented. Then people will even be able to have the option of using either screen mode. CAW | The bottom line |
×
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