gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Building pak/zip files

[Brian S. <bs...@mi...>]

Things like WinZip will (by default) try to compress everything, so you
would want to set command line flags to disable compression for
uncompressible things like sound files.

And I can't imagine a zip implementation that wouldn't add files to the
end of the zip in the order that you insert them, because the
alternative (shifting files down) would be so inefficient. =20

But the worst part of zip files is that the catalog lives at an
unspecified distance from the end of the file, so opening an archive
means seeking to somewhere near the end and walking around looking for
the catalog.  If you're really worried about speed, you probably want to
have a post-process step where you generate another copy of that catalog
in a spot where it can be loaded quickly...like placed on the DVD, right
in front of the zip archive.

--brian

-----Original Message-----
From: Thatcher Ulrich [mailto:tu...@tu...]=20
Sent: Thursday, December 06, 2001 6:21 AM
To: Tom Spilman
Cc: gam...@li...
Subject: Re: [GD-General] Building pak/zip files

On Dec 05, 2001 at 05:41 -0600, Tom Spilman wrote:
> > Zip file tools don't generally give you control over what
> > gets compressed and what doesn't(I think).
>=20
>     Actually i don't think this is necessarily true

It doesn't actually matter -- zip tools generally will choose the best
method of compression for each file, so .jpg's or .mpg's will be
stored uncompressed.

> nor that you cannot
> specify the order of the contents of the zip file.  Check out
> http://www.winzip.com/wzcline.htm which adds command line support to
WinZip.

Infozip's command-line zip apparently stores things in the order you
specify.  Also, it's open source under a X-style license, so you can
hack stuff in or incorporate the code in your project.  There's also
zlib from the same project, designed for embedding.  We use zlib at
Oddworld for unpacking resource files.

http://www.info-zip.org/
http://www.gzip.org/zlib/

--=20
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] Building pak/zip files

[Thatcher U. <tu...@tu...>]

On Dec 05, 2001 at 05:41 -0600, Tom Spilman wrote:
> > Zip file tools don't generally give you control over what
> > gets compressed and what doesn't(I think).
> 
>     Actually i don't think this is necessarily true

It doesn't actually matter -- zip tools generally will choose the best
method of compression for each file, so .jpg's or .mpg's will be
stored uncompressed.

> nor that you cannot
> specify the order of the contents of the zip file.  Check out
> http://www.winzip.com/wzcline.htm which adds command line support to WinZip.

Infozip's command-line zip apparently stores things in the order you
specify.  Also, it's open source under a X-style license, so you can
hack stuff in or incorporate the code in your project.  There's also
zlib from the same project, designed for embedding.  We use zlib at
Oddworld for unpacking resource files.

http://www.info-zip.org/
http://www.gzip.org/zlib/

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

Re: [GD-General] Building pak/zip files

[Tom S. <tsp...@mo...>]

> Zip file tools don't generally give you control over what
> gets compressed and what doesn't(I think).

    Actually i don't think this is necessarily true nor that you cannot
specify the order of the contents of the zip file.  Check out
http://www.winzip.com/wzcline.htm which adds command line support to WinZip.
I believe the default operation of in calling winzip via the command line is
to add files ( -a ) to an existing archive.  With this in mind i think that
adding the files to a zip one at a time with the compression options set to
your liking ( -e ) would do everything that's been discussed here.  The
performance may be poor calling winzip once for each file to be added, so if
this is a problem look into using "list files" to batch multiple adds into a
single call.  Tom

----- Original Message -----
From: "Chris Brodie" <Chr...@ma...>
To: <gam...@li...>
Sent: Wednesday, December 05, 2001 5:11 PM
Subject: RE: [GD-General] Building pak/zip files


> Elaborate? I'm not sure I follow.
>
> I'm a lone developer with no art team but I still try to work as if I was
a small team. As such a team would want independence between the art
packaging tools and the coder releases. Perhaps I've missed something
though.
>
> Some idea's I've had overnight about this topic:
>
> Zip file tools don't generally give you control over what gets compressed
and what doesn't(I think). This means that some things that you don't want
compressed such as jpeg's or mp3's will need to be double compressed,
slowing load times on these files.
> Then again you can store all files uncompressed, so the zip file acts like
a pak file. In this case some simple things like wav's or large xml
documents(my level files for example) won't be compressed.
>
> It seems the solution to this problem is in either creating(hopefully
finding) a custom zip packing tool that allows you to specify 'store' or
'compressed' on each file or to use a custom file format, which for now I'm
resisting.
>
> In both cases memory mapped files seem to be the best access method for
pakfile style access. I've heard that the combination of pakfiles + memory
mapped files can give you effective loading speed increases of nearly 200%
above the normal C\C++ std functions.
>
> Chris
>
> > -----Original Message-----
> > From: Brian Hook [mailto:bri...@py...]
> > Sent: Thursday, 6 December 2001 4:09 AM
> > To: gam...@li...
> > Subject: RE: [GD-General] Building pak/zip files
> >
> >
> > > I was going to start looking at zip files sooner or later as
> > > well. Currently I just use pkzip to batch build my release
> > > files, I was going to do the same thing with the resources as
> > > well. Just maintain the assets on the file system as the
> > > first search point. Then check in the zip file. Pretty simple.
> >
> > Right, this is what we plan on doing.  We have an abstract FileSystem
> > class, and derived from it are a DiskFileSystem, ZIPFileSystem and a
> > wrapper called a ChainedFileSystem.  The latter does the "Check disk,
> > then check ZIP" type thing (you register FileSystems with it
> > in order of
> > priority).
> >
> > The issue isn't the ZIP file itself, it's automating the
> > build.  I could
> > make a batch file or a make file that builds the appropriate
> > ZIP, but I
> > was hoping there was maybe a slightly more elaborate tool than just
> > doing a Custom Build step in MSDEV and calling a batch file =)
> >
> > Brian
> >
> >
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> >
>
>
> NOTICE
> This e-mail and any attachments are confidential and may contain copyright
material of Macquarie Bank or third parties. If you are not the intended
recipient of this email you should not read, print, re-transmit, store or
act in reliance on this e-mail or any attachments, and should destroy all
copies of them. Macquarie Bank does not guarantee the integrity of any
emails or any attached files. The views or opinions expressed are the
author's own and may not reflect the views or opinions of Macquarie Bank.
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Building pak/zip files

[Chris B. <Chr...@ma...>]

Elaborate? I'm not sure I follow. 

I'm a lone developer with no art team but I still try to work as if I was a small team. As such a team would want independence between the art packaging tools and the coder releases. Perhaps I've missed something though.

Some idea's I've had overnight about this topic:

Zip file tools don't generally give you control over what gets compressed and what doesn't(I think). This means that some things that you don't want compressed such as jpeg's or mp3's will need to be double compressed, slowing load times on these files. 
Then again you can store all files uncompressed, so the zip file acts like a pak file. In this case some simple things like wav's or large xml documents(my level files for example) won't be compressed. 

It seems the solution to this problem is in either creating(hopefully finding) a custom zip packing tool that allows you to specify 'store' or 'compressed' on each file or to use a custom file format, which for now I'm resisting.

In both cases memory mapped files seem to be the best access method for pakfile style access. I've heard that the combination of pakfiles + memory mapped files can give you effective loading speed increases of nearly 200% above the normal C\C++ std functions.

Chris

> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: Thursday, 6 December 2001 4:09 AM
> To: gam...@li...
> Subject: RE: [GD-General] Building pak/zip files
> 
> 
> > I was going to start looking at zip files sooner or later as 
> > well. Currently I just use pkzip to batch build my release 
> > files, I was going to do the same thing with the resources as 
> > well. Just maintain the assets on the file system as the 
> > first search point. Then check in the zip file. Pretty simple. 
> 
> Right, this is what we plan on doing.  We have an abstract FileSystem
> class, and derived from it are a DiskFileSystem, ZIPFileSystem and a
> wrapper called a ChainedFileSystem.  The latter does the "Check disk,
> then check ZIP" type thing (you register FileSystems with it 
> in order of
> priority).
> 
> The issue isn't the ZIP file itself, it's automating the 
> build.  I could
> make a batch file or a make file that builds the appropriate 
> ZIP, but I
> was hoping there was maybe a slightly more elaborate tool than just
> doing a Custom Build step in MSDEV and calling a batch file =)
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> 


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. 

RE: [GD-General] Building pak/zip files

[Grills, J. <jg...@so...>]

One thing we've found is that if you can order the data files in the ZIP in
the same order as your game will load them (at least when that order is
known, like during application start up or level-based games), you can
significantly decrease the startup time of your application.  This assumes
your table-of-contents is preloaded so you don't have to seek to it between
files.  Unfortunately, I don't know of any tools to let you tweak ZIP files
in this manner, so we have our own format and tools.  Another advantage we
get with our own format is we may be able to duplicate data files within our
ZIP-like file in multiple places to further decrease load time by seeking to
the nearest one in the ZIP.  However, we haven't spent the time to write
nice GUI tools like WinZip, which I would really like.

I would also suggest supporting an arbitrary set of directories and ZIP
files to search.  That way you never need to make ZIP files during
development, and can release new ZIP files to patch data without
differential patching the original ZIP.

Jeff Grills
Star Wars Galaxies
Technical Director, Austin Studio
Sony Online Entertainment Inc.


-----Original Message-----
From: Brian Hook [mailto:bri...@py...]
Sent: Tuesday, December 04, 2001 8:26 PM
To: gam...@li...
Subject: [GD-General] Building pak/zip files


I'm looking into a way to automate the build of our asset files, which
will probably just be in good old ZIP file format.  Currently I'm
storing everything in my EXE as a resource (don't ask), primarily
because I can change what I build into my EXE (e.g. for demo or full
versions) by a simple change of a resource symbol.

However, for obvious reasons I'd like to move to a ZIP file that stores
this information, and building one in a relatively error free way seems
like the way to go.  I'll likely rename the ZIP file just to avoid any
obvious tinkering, but otherwise I'm generally unconcerned by tweaking
of the assets.

The obvious thing to do is to run make with various parameters, e.g.
"make demo" or "make full" to build the various ZIPs.  Is this what
others are doing, or are any of you folks doing something spiffier?

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Building pak/zip files

[Brian H. <bri...@py...>]

> I was going to start looking at zip files sooner or later as 
> well. Currently I just use pkzip to batch build my release 
> files, I was going to do the same thing with the resources as 
> well. Just maintain the assets on the file system as the 
> first search point. Then check in the zip file. Pretty simple. 

Right, this is what we plan on doing.  We have an abstract FileSystem
class, and derived from it are a DiskFileSystem, ZIPFileSystem and a
wrapper called a ChainedFileSystem.  The latter does the "Check disk,
then check ZIP" type thing (you register FileSystems with it in order of
priority).

The issue isn't the ZIP file itself, it's automating the build.  I could
make a batch file or a make file that builds the appropriate ZIP, but I
was hoping there was maybe a slightly more elaborate tool than just
doing a Custom Build step in MSDEV and calling a batch file =)

Brian

Re: [GD-General] Building pak/zip files

[Thatcher U. <tu...@tu...>]

On Dec 04, 2001 at 06:25 -0800, Brian Hook wrote:
> 
> The obvious thing to do is to run make with various parameters, e.g.
> "make demo" or "make full" to build the various ZIPs.  Is this what
> others are doing, or are any of you folks doing something spiffier?

If you decide to go one step further, and generate a Windows
self-installer, I can heartily recommend the Nullsoft installer:
http://www.nullsoft.com/free/nsis .  It's a free, open-source Windows
installer that

  * stores everything using a .zip-derived format (but not quite
    compatible with .zip)

  * is scriptable!

For Slingshot's Virtual Resorts stuff, I have a makefile and a helper
Perl program which takes a file list of resources, and generates a
self-installing .exe.  I'm fairly happy with it -- it beats the hell
out of clicking through InstallShield's GUI every time I need to make
a release.  I can post the scripts somewhere if there's interest.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

RE: [GD-General] Building pak/zip files

[Chris B. <Chr...@ma...>]

I might not have understood your specific problem but...

I was going to start looking at zip files sooner or later as well. Currently I just use pkzip to batch build my release files, I was going to do the same thing with the resources as well. Just maintain the assets on the file system as the first search point. Then check in the zip file. Pretty simple. 

The power is in from code checking the file system first to get more recently updated files, then check the zip file if it doesn't exist on the file system. Doing it this way means your artists won't have to specifically add a file to the zip archive to test it in game. Then each night \ build \ whatever, just add all the updated\new files in to the zip file and delete them from the file system, which can be done in a batch manner with pkzip.

I've also written a small tool to rename files to their original name + the date\time so I can keep previous version of the file. This has been invaluable in reverting to previous working versions of things. Let me know if you want this tool \ source etc. It's very simple of course.

Chris Brodie


> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: Wednesday, 5 December 2001 1:26 PM
> To: gam...@li...
> Subject: [GD-General] Building pak/zip files
> 
> 
> I'm looking into a way to automate the build of our asset files, which
> will probably just be in good old ZIP file format.  Currently I'm
> storing everything in my EXE as a resource (don't ask), primarily
> because I can change what I build into my EXE (e.g. for demo or full
> versions) by a simple change of a resource symbol.
> 
> However, for obvious reasons I'd like to move to a ZIP file 
> that stores
> this information, and building one in a relatively error free 
> way seems
> like the way to go.  I'll likely rename the ZIP file just to avoid any
> obvious tinkering, but otherwise I'm generally unconcerned by tweaking
> of the assets.
> 
> The obvious thing to do is to run make with various parameters, e.g.
> "make demo" or "make full" to build the various ZIPs.  Is this what
> others are doing, or are any of you folks doing something spiffier?
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> 


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. 

[GD-General] Building pak/zip files

[Brian H. <bri...@py...>]

I'm looking into a way to automate the build of our asset files, which
will probably just be in good old ZIP file format.  Currently I'm
storing everything in my EXE as a resource (don't ask), primarily
because I can change what I build into my EXE (e.g. for demo or full
versions) by a simple change of a resource symbol.

However, for obvious reasons I'd like to move to a ZIP file that stores
this information, and building one in a relatively error free way seems
like the way to go.  I'll likely rename the ZIP file just to avoid any
obvious tinkering, but otherwise I'm generally unconcerned by tweaking
of the assets.

The obvious thing to do is to run make with various parameters, e.g.
"make demo" or "make full" to build the various ZIPs.  Is this what
others are doing, or are any of you folks doing something spiffier?

Brian

RE: [GD-General] Re: JPG libs

[<phi...@pl...>]

TiVo provide the patches they made to linux on their web-site somewhere.
The actual TiVo application is entirely closed though (which is completely
legit AFAIAA, given that IANAL ;)

Also note that if you don't ship the LGPL JPEG loading code in your game,
but only use it in your internal conversion tools, you don't have to worry
about this at all.





                                                                                                                  
                    "Daniel Vogel" <vo...@ep...>                                                          
                    Sent by:                                      To:     "Thatcher Ulrich" <tu...@tu...>      
                    gam...@li...urc        cc:                                             
                    eforge.net                                    <gam...@li...>    
                                                                  Subject:     RE: [GD-General] Re: JPG libs      
                                                                                                                  
                    11/08/2001 08:08 PM                                                                           
                                                                                                                  
                                                                                                                  




> Hm, the minimal requirement of the LGPL is that the end-user can
> re-link with a different version of the lib, right?  So using a DLL on

This rules out static linking.


> some type of computer is OK... are you thinking about consoles?

Don't get me started on LGPL and consoles/ embedded systems ;)


> Didn't Indrema officially establish that they could ship GPL'd
> software in their planned console?

Of course they could've done that. They just would have had to provide the
source. Anyways, Indrema is not a good example as they were Vaporware. BTW,
I don't think it would've been legal for them to ship with LGPLed software
due to the re-link requirement.


> And what about all those embedded apps that use Linux?
> Is the TiVo source code available?

I bet if you snail mail them they'll provide you with the Linux source code
they use and I doubt they made many changes to the kernel. Keep in mind
that
binary only kernel modules are possible so they could extend the kernel
without much hassle. They also don't have to provide the source to their
app
running on the OS. That's like saying we had to disclose the source to
Unreal Tournament just because it runs on Linux ;-)


> The legalities are too much for my tiny brain, but it seems this
> question will probably come up again now that SDL runs on the PS2.

SDL only runs on the PS2s that run Linux.


- Daniel Vogel, Programmer, Epic Games Inc.


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] JPG libs

[Brian H. <bri...@py...>]

I ended up using the IJG code as well.  It compiles cleanly.  It's
fairly old, but it has very good documentation (in Word DOC form,
unfortunately).  It took me about an hour to integrate.  I basically I
went through FILELIST.DOC and copied over the set of files I thought I
would need.  You have to rename one file appropriately, and include
another file as appropriate for memory management.  In tried and true
opensource fashion, I tossed them all into the same directory and
compiled.  Found a couple missing files, added those, and it worked
fine.

The only gotcha was that they didn't bother to do:

#ifdef __cplusplus
extern "C" {
#endif

So I just had to bracket all the headers with that to link properly.
It's only about 30 lines of code to process a JPG (a lot fewer if you're
just reading from STDIO, I had to write my own data source functions to
handle reading from an in-memory buffer).

Brian

RE: [GD-General] JPG libs

[Warrick B. <War...@po...>]

I can recommend "Independent JPEG Group" libjpeg as mentioned already.  It's
easy to get up and running, portable and most importantly free!  I've never
had any problems with it.

Warrick.

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]
Sent: 08 November 2001 19:42
To: gam...@li...
Subject: [GD-General] JPG libs


Anyone using a simple, clean general purpose JPG loading library they
can recommend?

Thanks,

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Re: JPG libs

[Daniel V. <vo...@ep...>]

> Hm, the minimal requirement of the LGPL is that the end-user can
> re-link with a different version of the lib, right?  So using a DLL on

This rules out static linking.


> some type of computer is OK... are you thinking about consoles?

Don't get me started on LGPL and consoles/ embedded systems ;)


> Didn't Indrema officially establish that they could ship GPL'd
> software in their planned console?

Of course they could've done that. They just would have had to provide the
source. Anyways, Indrema is not a good example as they were Vaporware. BTW,
I don't think it would've been legal for them to ship with LGPLed software
due to the re-link requirement.


> And what about all those embedded apps that use Linux?
> Is the TiVo source code available?

I bet if you snail mail them they'll provide you with the Linux source code
they use and I doubt they made many changes to the kernel. Keep in mind that
binary only kernel modules are possible so they could extend the kernel
without much hassle. They also don't have to provide the source to their app
running on the OS. That's like saying we had to disclose the source to
Unreal Tournament just because it runs on Linux ;-)


> The legalities are too much for my tiny brain, but it seems this
> question will probably come up again now that SDL runs on the PS2.

SDL only runs on the PS2s that run Linux.


- Daniel Vogel, Programmer, Epic Games Inc.

RE: [GD-General] Re: JPG libs

[Thatcher U. <tu...@tu...>]

On Thu, 8 Nov 2001, Daniel Vogel wrote:

> [Re SDL]
> It's LGPL. I wish more libraries used something along the lines of the BSD
> license.

Hm, the minimal requirement of the LGPL is that the end-user can
re-link with a different version of the lib, right?  So using a DLL on
some type of computer is OK... are you thinking about consoles?
Didn't Indrema officially establish that they could ship GPL'd
software in their planned console?  And what about all those embedded
apps that use Linux?  Is the TiVo source code available?

The legalities are too much for my tiny brain, but it seems this
question will probably come up again now that SDL runs on the PS2.

-Thatcher

RE: [GD-General] Re: JPG libs

[Brian S. <bs...@mi...>]

I hate to sound like a broken record, but I'll repeat the magic words
"Independent JPEG Group".  It's what SDL uses, it's what everything
uses.

http://www.ijg.org

-----Original Message-----
From: Thatcher Ulrich [mailto:tu...@tu...]=20
Sent: Thursday, November 08, 2001 5:51 PM
To: pu...@py...
Cc: gam...@li...
Subject: RE: [GD-General] Re: JPG libs

On Thu, 8 Nov 2001, Brian Hook wrote:

> I need something that is portable and with full source code (I need to
> support, for example, Macintosh).

I'm very partial to the SDL libs for cross-platform stuff.  SDL_image
will load jpg's and many other image types.  Although I think the
actual jpeg library they use might come from an outside source.
Anyway, if you're thinking Mac and other platforms, you should check
out SDL anyway.

http://www.libsdl.org

-Thatcher


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Re: JPG libs

[Daniel V. <vo...@ep...>]

It's LGPL. I wish more libraries used something along the lines of the BSD
license.

- Daniel Vogel, Programmer, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Thatcher Ulrich
> Sent: Thursday, November 08, 2001 8:51 PM
> To: pu...@py...
> Cc: gam...@li...
> Subject: RE: [GD-General] Re: JPG libs
>
>
> On Thu, 8 Nov 2001, Brian Hook wrote:
>
> > I need something that is portable and with full source code (I need to
> > support, for example, Macintosh).
>
> I'm very partial to the SDL libs for cross-platform stuff.  SDL_image
> will load jpg's and many other image types.  Although I think the
> actual jpeg library they use might come from an outside source.
> Anyway, if you're thinking Mac and other platforms, you should check
> out SDL anyway.
>
> http://www.libsdl.org
>
> -Thatcher
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>

RE: [GD-General] Re: JPG libs

[Thatcher U. <tu...@tu...>]

On Thu, 8 Nov 2001, Brian Hook wrote:

> I need something that is portable and with full source code (I need to
> support, for example, Macintosh).

I'm very partial to the SDL libs for cross-platform stuff.  SDL_image
will load jpg's and many other image types.  Although I think the
actual jpeg library they use might come from an outside source.
Anyway, if you're thinking Mac and other platforms, you should check
out SDL anyway.

http://www.libsdl.org

-Thatcher

RE: [GD-General] Re: JPG libs

[Brian S. <bs...@mi...>]

Search on Google for "Independent JPEG Group".

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Thursday, November 08, 2001 12:32 PM
To: gam...@li...
Subject: RE: [GD-General] Re: JPG libs

I need something that is portable and with full source code (I need to
support, for example, Macintosh).

Thanks anyway,

Brian


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Re: JPG libs

[Brian H. <bri...@py...>]

I need something that is portable and with full source code (I need to
support, for example, Macintosh).

Thanks anyway,

Brian

[GD-General] Re: JPG libs

[Parveen K. <pk...@sf...>]

Try the Intel jpeg library.  This is what we used to use at work.  I can't 
tell you about the details though since I didn't write the texture manager.

Parveen

http://developer.intel.com/software/products/perflib/ijl/index.htm

>Date: Thu, 08 Nov 2001 11:41:36 -0800
>From: Brian Hook <bri...@py...>
>To: gam...@li...
>Reply-to: pu...@py...
>Organization: Pyrogon, Inc.
>Subject: [GD-General] JPG libs
>
>Anyone using a simple, clean general purpose JPG loading library they
>can recommend?
>
>Thanks,
>
>Brian

[GD-General] JPG libs

[Brian H. <bri...@py...>]

Anyone using a simple, clean general purpose JPG loading library they
can recommend?

Thanks,

Brian

[GD-General] vtune question

[Tugkan <tu...@in...>]

I am trying to make a dynamic analysis at some part of my code.Problem =
is that
entry and exit points do not appear where I put them ( in assembly view =
).
First i thought that there is a particular problem with that source file =
but=20
some of functions in it accept my choices whereas in others vtune insert =
entry and=20
exit points somewhere outside of the function ( mostly somewhere in =
other functions ).
What may be the reason and how can i solve the priblem?

Thanks in advance.


/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tugkan Calapoglu            tu...@in...
Software Engineer

info(+)TRON, Turkey
Tel: +90 216 4921002, Ext 138
Fax: +90 216 3432132
Http://www.infotron.com.tr
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/

Re: [GD-General] Architecture Design

[Brooks B. <br...@on...>]

>You mean, like Michelangelo?  :)  (Isn't he the one who described his
>process that way?)

In the Smithsonian there is a "cartoon" done by Michelangelo (I 
think...maybe it was Rafael?).  Cartoons are design sketches done by the 
artist prior to beginning an actual painting.  The sketch is worked over 
heavily - things are erased and moved around until the artist is happy 
with the final design.  The cartoon is very messy.

At that point the artist punches holes all along the outlines of the 
cartoon.  They then attach the cartoon to the final media (wall for a 
mural, canvas for a painting) and throw charcoal dust on it.   The 
charcoal goes through the holes and leaves a connect-the-dot framework 
that the artist then paints on.

Sooooo....  there is some level of framework design in paintings of the 
masters.  I was really suprised - I just thought they were so good they 
just winged it.  (Also, since the cartoons were destroyed usually, they 
are incredibly valuable today).

>Back on topic, the bad pitfall I've seen in detailed top-down engine
>designs, is when you break things down into sensible pieces with sensible
>interfaces, and some of the boxes implicitly contain things like "robust
>rigid and soft body physics solver", "automatic all-purpose 3rd person
>cinematic camera", "human-like real-time learning neural net AI".
>

I call this the fractal code coastline problem.   You can keep breaking 
things down. But you can't see the total detail until you have broken it 
down to the atomic level of code.  

The worst thing about design work is that it is tempting (for management) 
to look at all those boxes and assign times to them to arrive at a final 
schedule.   But you can't tell how long the boxes take unless you break 
them all the way down to code again.  So you miss the fractal multiplier 
that should be applied. 

>think about it this way, the russians were 20 years ahead of the americans
>at designing rocket boosters, but their designs took longer to implement, so
>whilst the americans went to the moon, the russians didnt

One of the more interesting aspects of the American effort is that Von 
Braun and company skipped the detailed QA cycle.  They were so confident 
in their design, and time was so short, that they simply test fired the 
final completed Saturn rocket.  It worked. This saved a tremendous amount 
of time.  Had the rocket failed it would have been a huge setback.  

The Russian designs did not work out of the gate.  So in a way the speed 
of the US program is probably more a result of careful conservative 
design than of aggresive forward thinking design.  

RE: [GD-General] Architecture Design

[neo b. <ne...@mw...>]

I divide it up into macro and micro design.

Macro design is the overall interaction of everything.

We will have 3D, we will have physics, we will have arguments ;>

Then I go off and code tons of test apps which implement/test ideas, etc
and give me an idea of what it is exactly I'm dealing with. Once I've hacked
it do death, played with it and broken it, I have a much clearer
understanding
of what it involves. Then it becomes a 'design' with specific interfaces and
capabilities, and I know sorta how to keep it open enough.

That's basically the middle way which brings together my inherent urge for
purity and simplicity stewed with real world ingredients.

And of course this is recursive.

Hack in slash in the backyard, then clean it up for inside the house...

layder
neo


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Evil Kosh
Sent: 08 October 2001 07:48
To: GameDev General ML
Subject: Re: [GD-General] Architecture Design


fly by the seat of your pants is something I'm used to !

I try to design stuff logically, I think about what I would need to get a
base working, then I extend it to support stuff I want, say 3d, or 2d, then
I just add more and more until I have the system I want, it's evolutionary
design and it usually gives the best designs, it's the same technique the
russians used in designing their rockets in the race to the moon, it takes
longer to implement something than a clear cut, on paper design, but the
designs are usually (depending on the design team) better...

think about it this way, the russians were 20 years ahead of the americans
at designing rocket boosters, but their designs took longer to implement, so
whilst the americans went to the moon, the russians didnt, that was in
1970s, in the 1990 americans were entering russia and hearing about MK33
rockets and how amazing they were, by now a 20 year old design, guess what?
they outperformed american technology of the 1990's, even with the americans
improving their designs over the last 20 years and are now the base of many
rockets that were designed after their discovery by the americans :)

so, evolutionary design, if you can afford more time and dont mind flying by
the seat of your pants, this is what I would suggest

kosh


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] Architecture Design

[Drew, A. <ri...@ho...>]

I seem to come from a slightly different perspective.

I'm currently in the process of writing my first game with a group of
friends. I've seen other groups attempt this task and fail and in the cases
I have seen it has always failed due to lack of good communication.

We have spent a great deal of time ensuring that each member of our group
has a clear understanding of the task we're trying to undertake. This has
been done at all levels, from high-level conceptual and gameplay levels down
to subsystem and even class interaction diagrams (primarily written
informally in UML). This information represents the core of our game, both
conceptually and technically and while it may change as time goes on, we
can't afford to loose focus of it.

There are, and will continue to be, holes in our design up until the time
we've finished implementing everything. We are still learning a great deal
and running into snags that I'm sure nearly all of you have hit before. But
I see the design documentation we have as an integral ingredient in our
success.

This might not be exactly the case for those with prior experience in this
field. I can understand how someone could go out and code an entire
rendering system without any formal documentation if:
    a. They have done it before; or
    b. They have had prior experience with similar systems before.
Technical subsystems such as these can be largely defined through feature
sets and other specs that don't need excessive documentation.

Please fire back at will. I enjoy different perspectives on topics such as
this.

Regards,
Aaron

----- Original Message -----
From: "David Hunt" <da...@hu...>
To: <gam...@li...>
Sent: Tuesday, October 09, 2001 3:56 AM
Subject: Re: [GD-General] Architecture Design


> Good answers and I do have an open mind about all this and I suspect we do
> under-design sometimes, however even at our current level of design I find
> myself removing over-engineered bits that nobody uses months later. Eg.
Our
> scriptables all intercommunicate through message passing. All messages go
> through a messaging hub that routes them. When I initially wrote the hub I
> allowed for many hubs to be connected together the idea being that certain
> script classes would naturally use Hub A and others would use Hub b - thus
> all characters on the same hub get faster communication. However 6 months
> later nobody used this feature so I took the technology out as it
obfuscated
> the design and we now have a single monolithic hub.
> I suspect we're actually probably in the same ballpark in reality - your
> methodology is a bit more formal than I prefer - I think with experience
> writing stuff off the top of your head is nearly the same as working from
a
> design, given that complex tasks need discussion with other team members
> regardless of design strategy and all tasks are ultimately derived from
the
> game design document.
> I'm not totally convinced by your point about documentation exposing flaws
> in the design - I think the worst design flaws are the ones that nobody
> however carefully they've worked through it would have discovered until
they
> got down to coding it. But thats just my opinion.
>
>
> David
>
> I think at its worst lack of design is like the sculptor who sculpts by
> chipping off all the bits that don't look like a head - hopefully none of
us
> do this.
>
> > > As far as code re-use goes - who really honestly ever gets to the end
of
> a
> > > project with an engine clean enough that they want to re-use it in its
> > > entirety - little bits maybe but not a whole engine.
> >
> > Perhaps if it was designed up front... :)
> >
> > > Just out of interest Philip when you said "Invariably the code is then
> > > revised and expanded as the project's needs are really understood." -
> does
> > > large scale formal design mitigate this at all? Do you find that a
> proper
> > > formal design makes things revision-proof?
> >
> > No I don't think it does make things revision-*proof*, you can't do
that.
> > Your Donkey example is a change in the requirements and no matter how
good
> > the design it's still possible to change the requirements sufficiently
to
> > break it. However, I have found that by designing code up front you get
> code
> > which survives changes in requirements much better than code just hacked
> > together and even if things change a lot you can reuse much larger
> portions
> > of systems in the new project.
> >
> > The main benefit though is that you refine the ideas in the design
without
> > spending time coding it up and testing it. The understanding process
takes
> > place before coding rather than during. I've found that three things
> > regularly happen when a design is documented:
> >
> > 1) You realise that everyone had a slightly different view of the
design.
> >
> > 2) You find some holes, something that seemed like a good idea but once
> > it's written down it doesn't seem so good or just isn't required.
> >
> > 3) You see a much cleaner way of organising things.
> >
> > Chances are you would have seen them as you coded your original idea but
> by
> > then of course you've already written all that code :(
> >
> > The argument that games change too quickly to do design just doesn't
hold
> > any water as far as I'm concerned, a well designed piece of code will
> > survive changes far better than something written off the top of your
> head.
> >
> > I'd certainly not call what we do formal though, UML is only used as a
> > standardised notation so that everyone understands the squiggles on the
> > board. Designing the networking system for the RTS I worked on took a
> couple
> > of days. A few hours discussing it, an afternoon writing up a
description
> of
> > the system plus another day circulating the doc and revising it. More
> > importantly, it worked but only because we threw out the design we'd all
> be
> > assuming we were going to use. When we were discussing the design it
> became
> > obvious that it wasn't going to work so we changed it. Had I gone away
and
> > coded the initial design I'd have wasted a lot of time finding out it
> wasn't
> > good enough.
> >
> > Two points.
> >
> > Firstly, I'm not claiming it's a silver bullet. You still have to throw
> > systems away sometimes because the game has changed too much but the
time
> > 'lost' to design is paid back many many times in the systems that don't
> have
> > to be thrown away and that work more reliably and can accomodate changes
> in
> > the requirements.
> >
> > Secondly, you still have to be a good programmer, just designing the
code
> > doesn't work, you have to create a good design. A key factor in this is
> > knowing when to stop, it's very easy to carried away designing a no
holds
> > barred all singing all dancing system when it isn't what you need. It's
a
> > classic schoolboy error.
> >
> > > As a little anecdote.
> > > C++ versions  - except this time it took them 6 months. Most of them
> moved
> > > out of the games industry soon after that. Now perhaps they were
> >
> > I would have thought that says more about their abilities as C++
> programmers
> > than anything about design in general. :)
> >
> > Philip Harris
> >
> >
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>
>