[casual_games] Procedural rendering - again

[Lennard Feddersen]

That's an interesting thought, since I create a single binary file and 
my executable I haven't bothered with installers for my PC products, 
just zip'em and ship'em.  All the data sits, compressed, in a single 
binary file on the users hard disk and is uncompressed at run time.  
This may change with some updates that are coming with Battle Castles as 
I may be dropping some things into the registry so an uninstaller starts 
to make more sense.

My tool chain allows me to compress on an individual file basis so it 
would be easy to turn it all off, create an uncompressed binary and then 
run it through a different installer to test the idea.  What compression 
technology does the Reflexive installer use and does it generally beat 
WinZip?

BTW, distro size, for the PC at least, is more important to me than 
installed size - hard drives are big and cheap when we are talking about 
<10MB files.

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



James C. Smith wrote:

>>>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.
>>
>> 
>>
>>    
>>
>
>  
>

--