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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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?