Re: [Super-tux-devel] 800x600 resolution
Brought to you by:
wkendrick
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 > |