[casual_games] Procedural rendering - again

[James C. Smith]

>> my tool chain uses zlib to compress everything 
>> and I think this is going to make sense for a 
>> lot of people on this forum.


Net necessarily.  If installed size is your concern then ZLIB will help but
if distribution size is your primary concern then ZLIB doesn't accomplish
much and may even hurt.  A good installer will usually get better
compression because it had a better compression algorithm than ZLIB and/or
because it cam compresses the whole application rather than each individual
asset or file.  But it is hard to recompress data that has already been
compressed. I wouldn't be surprised if your distribution size decreased if
you disabled all your ZLIB compression and let the installer do the
compression.

I prefer to let the game/tools chain do any lossy compress compression that
makes sense. But I leave lossless compression to the installer.


One point I want to make is that the JPEG compression I use is also part of
a tools chain.  Artists never save .JPEG files. They save everything as
.TGAs and TGAs are when we check into the version control system.  The tools
chain automatically converts them to the distribution format according to
compression setting stored in property files for each piece of art. In our
editor the artists can pull up any individual art asset, adjust it's
compression settings, and see the results in real time not just in an image
preview but in the game sprites themselves.  


-----Original Message-----
From: casual_games-bounces at igda.org [mailto:casual_games-bounces at igda.org]
On Behalf Of Lennard Feddersen
Sent: Tuesday, January 10, 2006 11:44 AM
To: Alex Saveliev; IGDA Casual Games SIG Mailing List
Subject: Re: [casual_games] Procedural rendering - again


I did some contract work last Summer for Artifex specifically to speed 
up Jasper - I expect they kicked the source back at some point so there 
should be a faster version of Jasper available if anybody is interested 
in going that route.  I can't remember what the #'s were but there was a 
low level bottleneck that got significantly faster.

I don't use lossy compression for my games, my tool chain uses zlib to 
compress everything and I think this is going to make sense for a lot of 
people on this forum.  Somebody yesterday mentioned 10% of their size 
was in the executable - maybe this was just a guess but if it isn't then 
they may want to make sure that they are decoupling their data and not 
shipping with debug info. on (obvious but worth mentioning if 10% was 
accurate).

"Of course I wouldn't recommend compressing all the textures in Half-Life 2
into JPEG2000 :) But for casual games it should be just fine."

3d games like HL2 are going to survive JP or JP2 better than casual market
games.  Casual market games are typically 2d, hand tweaked by pixel images
(I'm a big fan of gorgeous pixel art so applying lossy compression seems
unfortunate) that will be shown with no filtering, scaling or other blending
and lighting tweaks so that the artists work is shown unmodified.  HL2 is
going to be scaled, perspective corrected, lit, blended and pumped through a
half dozen other low level hardware tricks so I don't see how a misplaced
pixel or two makes any real difference.


My 2 cents,

Lennard Feddersen
CEO, Rusty Axe Games, Inc.
www.RustyAxe.com

Lennard at RustyAxe.com
P. 250-635-7623 F. 1-309-422-2466
3521 Dogwood, Terrace, BC, Canada, V8G-4Y7



Alex Saveliev wrote:

>Hello Ron,
>
>Tuesday, January 10, 2006, 9:31:12 PM, you wrote:
>
>R> It has also been my impression that decoding JPEG2000 is much much
>R> slower than JPG.  Is this true?  That is the thing that's kept me from
>R> investigating it much further.  Load speed is more important to me than
>R> download time or disk foot print.
>
>JPEG2000 is definitely slower than JPEG.
>When I started looking for JPEG2000 decoder I've tested Jasper and it 
>was way too slow. So I've created my own library :)
>
>J2K-Codec is somewhat 50 times faster than Jasper.
>So it decodes JPEG2000 5-6 times slower than the old JPEG.
>
>But this doesn't mean that your game will load 5-6 times slower. Old 
>JPEG is very, very, very fast, so 5-6 times slower than very, very, 
>very fast is still fast enough :)
>
>For example, 450x450 JPEG2000 image on my AthlonXP 2000 decodes in 67 
>milliseconds.
>
>Of course I wouldn't recommend compressing all the textures in 
>Half-Life 2 into JPEG2000 :) But for casual games it should be just 
>fine.
>
>  
>

-- 


_______________________________________________
Casual_Games mailing list
Casual_Games at igda.org
http://seven.pairlist.net/mailman/listinfo/casual_games