gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Eiffel

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

> What's the saying... "A poor craftsman blames his tools."  

True, but there's a wide spectrum here from making shitty software to
making good software to making good software quickly and robustly.
There are many examples of good software written using primitive tools.
I feel I can write good software with any language or tools presented; I
will rarely blame my tools for preventing me from getting the job done.

That said, I will always lust after the better set of tools that let me
get my job done better.  Les Claypool would sound great on a $99 pawn
shop bass, but probably would sound better and (at least to him) play
better on one of his fancy, one-of-a-kind instruments.

Cocoa and Obj-C were an epiphanous experience for me, because they made
programming a GUI application fun, interesting and not tedious.  It was
very eye opening.  I'd like to see that propagate over to general game
(or even software) development.

> But don't you think platform-specific integrated environments 
> encourage that behavior rather than discourage it?

Possibly, but I guess I'm thinking more along the lines of "tool is the
language is the environment", i.e. invent a _system_ of development, not
just the component pieces (no pun intended) and bolt them together.

> Well... the problem is, target environments vary.  The more 
> my tools know about Windows, the less well adapted they are 
> for Mac or PS2 or Palm.

That's not what I'm suggesting at all!  Choice of target environment
should be reasonably irrelevant (well, building code for PalmOS is going
to require more than just retargeting some compiler options), I'm
talking about choice of "source environment".

Whether your system outputs JVM, C, asm or obj code isn't particularly
relevant except as a deployment concern.  I'm only thinking about the
creation portion of the process.

I suppose you could make an Emacs set of bindings and modes that would
support all the things I'd like to see in such an environment, so I'll
just shut up now and say "Y'all Emacs people are all freaks!" =)

Brian

Re: [GD-General] Eiffel

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

On Dec 19, 2001 at 06:03 -0800, Brian Hook wrote:
> 
> Seriously though, I've known people that were crippled by not having
> their .el files, and basically wouldn't use a computer until A.) Emacs
> was installed and B.) they had their custom ELisp files loaded.  To me
> it's like a bassist saying "I can't play unless I have my Wal".  Tools
> matter, but they shouldn't matter so much that you're non-functional
> without your perfect choice of tool.

What's the saying... "A poor craftsman blames his tools."  But don't
you think platform-specific integrated environments encourage that
behavior rather than discourage it?

> A better way of putting what I'm thinking is that programming needs to
> become a more integrated process.  Radical disconnects between design,
> analysis, versioning, and authoring, even if they're patched together by
> the wonder that is Emacs =P, don't help.  It should become a process
> whereby the various tools can take advantage of domain-specific
> knowledge relating to the underlying language in use.
> 
> Ugh, I'm still saying this poorly -- how about this: programming should
> be moving outside the domain of a language/syntax and into the domain of
> a complete development process.

Well... the problem is, target environments vary.  The more my tools
know about Windows, the less well adapted they are for Mac or PS2 or
Palm.

One approach is to make everything in the world use a common run-time
--> e.g. Java and .NET.  Lots of the .NET verbage sounds like what
you're advocating.  It's sort of the Lisp Machine legacy... everything
understands the code, even our CPU, and the code is data.  And I don't
think it's necessarily a bad thing; lots of incompatibilities are
totally gratuitous and just get in the way.  Nevertheless, there are
real and legitimate forces that make one-size-fits-all very
difficult... like, devices are getting smaller (cellphones, yadda
yadda).

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

Re: [GD-General] Eiffel

[Ivan-Assen I. <as...@ha...>]

There are these guys who aggressively pimp their Smalltalk environment
http://www.genify.com/
as a vehicle for quick game-dev prototyping - they have extensive DX8 bindings.
There is a presentation on the Meltdown 2001 site
http://www.microsoft.com/mscorp/corpevents/meltdown2001/presentations.asp
Maybe somebody tried it out?

I personally have this problem with trying out languages in the real world: 
I work with a bunch of ultra-conservative colleagues
that are barely convinced that we should finally let go the "void *p, DWORD dwSize"-style code,
whine at the smallest mention of a template somewhere at the code
and tend to blame long STL compilation times personally on me :-)

RE: [GD-General] Eiffel

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

> Some people (that even I consider a little crazy) do 
> surprising things with emacs.  Like, did you know that emacs 
> (er, XEmacs anyway) is a graphical web browser?

M-x whatever-dude

=)

Seriously though, I've known people that were crippled by not having
their .el files, and basically wouldn't use a computer until A.) Emacs
was installed and B.) they had their custom ELisp files loaded.  To me
it's like a bassist saying "I can't play unless I have my Wal".  Tools
matter, but they shouldn't matter so much that you're non-functional
without your perfect choice of tool.

I have a way easier time understanding the vi freaks, but now we're
getting way off topic...

> I don't really see the difference... the filesystem *is* a 
> browsable database.

Hey, and "cat > main.c" is a text editor =P

> > The idea of manual comments becomes an artifact of a by-gone age. 
> > Documentation is necessary, but manual comments (comment == 
> "some text 
> > I put here to explain this bit of code") should be fairly rare.
> 
> Huh?  Code somehow becomes magically less complex?

No, but it becomes a bit more structured when the language itself
encourages/enforces at least a modicum of discipline.  Some call this
fascist, I consider it reasonable (and I'm sure when C compilers started
issuing more stringent warnings about type safety that people considered
that fascist also).

> In response to your general point, that good programming 
> environments enhance productivity -- I agree completely.  I 
> just disagree with all your examples :)

Fair enough, as long as you understand my point =)

A better way of putting what I'm thinking is that programming needs to
become a more integrated process.  Radical disconnects between design,
analysis, versioning, and authoring, even if they're patched together by
the wonder that is Emacs =P, don't help.  It should become a process
whereby the various tools can take advantage of domain-specific
knowledge relating to the underlying language in use.

Ugh, I'm still saying this poorly -- how about this: programming should
be moving outside the domain of a language/syntax and into the domain of
a complete development process.  And I'm not talking academic analysis
of the problem, but taking into account where the problems occur in the
real world.  Much of what I liked about Ian Joyner's paper was that he
emphasized "Here's a real problem, not a language lawyer issue".  For
example, small things like "modifier before identifier makes browsing a
pain in the ass":

a() int;
b() void *;
c() const char *;

Is easier for a human being to scan than:

int a();
void *b();
const char *c();

But I digress (again).  I'd like to see Extreme Programming as applied
to development environments/work flow, not just philosophy and the act
of typing in code.  I don't want to deal with header files, precompiled
headers, and all the ugliness of separate files for interface and
implementation.  I want the dependency analysis done by a custom tool.
I want the language to concentrate on structure, not details.  Yadda
yadda yadda.

Eiffel seems to promise a lot of this (which sparked this thread), but
I'm still suspicious of it because I've yet to see someone actually use
it then bag on it.  Seems too good to be true, much like Obj-C (which,
as I've stated, just plain rules all...on OS X).

As JC Lawrence mentioned, much of this is the argument of atomic vs.
monolithic, but in this case I'm arguing that monolithic is better
because the fundamental data has context that all the tools need to
access.  Yeah, I know, convert to XML and pipe it through the command
line in a form all the tools understand.  Bah.

Brian

 

Re: [GD-General] Eiffel

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

On Dec 19, 2001 at 04:13 -0800, Brian Hook wrote:
> > Well, there's my favorite IDE, emacs.  Supports every 
> > language you've ever heard of, and every feature (for better 
> > or worse).  Not very fun to learn, though.
> 
> Oooh, ooh, we're treading on dangerous ground here, so, um, I'll try to
> be polite =)
> 
> Emacs is great -- I used it exclusively from about 1991 to 1996.  In
> fact, I used OS/2 2.x ONLY because it had a good Emacs.
> 
> But in the end, Emacs is a text editor, and I think that modern
> programming is going to move us into custom tools, browsers, source code
> analyzers, design analyzers, and all manner of stuff that isn't going to
> be expressible as an Elisp function or an external command line tool.

Whoah, I beg to differ.  I mean, any computable function is
expressible in elisp or even a shell script.  I'm not saying it's the
best tool for every job... (well, I'm thinking that, but not saying it
out loud :)

>  I know that Emacs has managed to do much of this so far through the
> ingenuity of its design and its users, but I have this suspicion
> that going forward that the "text only" model isn't going to work.
> 
> For example, you can't build a Smalltalk like environment in Emacs
> (at least, I don't think you can, but hell, I'm sure someone will
> post a link to something similar =) ).

Heh, try "emacs smalltalk" in google...

Some people (that even I consider a little crazy) do surprising things
with emacs.  Like, did you know that emacs (er, XEmacs anyway) is a
graphical web browser?

> > I've heard this gripe a few times lately, and I really don't 
> > see it. What's wrong with files, really?  Isn't it really 
> > C++'s declare-before-use that's the problem?
> 
> The problem is more along the lines of a lack of global "see it all at
> once" analysis.  The in order parsing of various files, some with
> "declarations" and others with "definitions", is obsolete.  We have
> computers to take away this kind of tedious bookkeeping, but instead I'm
> the one that has to say "Oh, Foo is a class that I define elsewhere".
> 
> In an ideal world you have class definitions that are just in some
> browsable database.  You then fill in the blanks on what they do, the
> class invariants, preconditions, postconditions, etc. and then the tools
> should be able to spit out a complete specification based on your code.

I don't really see the difference... the filesystem *is* a browsable
database.  In a language like Java, the tools *do* spit out a complete
spec based on my code; in C++ I write the spec by hand, but as I see
it that's a language/compiler issue, independent of what text editor I
used or where the code is physically stored.

> The idea of manual comments becomes an artifact of a by-gone age.
> Documentation is necessary, but manual comments (comment == "some text I
> put here to explain this bit of code") should be fairly rare.

Huh?  Code somehow becomes magically less complex?

> The build environment can then parse your entire architecture and
> generate back end code, comments, dependency analysis, etc. all within
> the confines of one environment that UNDERSTANDS the language,
> frameworks and tools instead of just PARSING the language and its tools.
> Emacs can be made to work with a syntax, but it can't be made to
> understand what a language is trying to do.

Hm, sounds like Lisp.  If you just write everything in elisp, then
you've already got this magical environment :) I'm not seriously
saying that's the way to go (I'm not even thinking it this time :).

In response to your general point, that good programming environments
enhance productivity -- I agree completely.  I just disagree with all
your examples :)

> The common complaint against this is that people wedded to Emacs, make,
> grep, perl, etc. will find themselves at the mercy of whatever
> environment is provided.  I don't have a problem with this -- I'm
> completely comfortable in MSDEV, ProjectBuilder, etc.  I can make them
> do what I need them to do, warts and all.  But I do at least understand
> their concerns, even if I do find them misguided =)

I immersed myself in it a couple years ago, and still use it for some
things every day for work, but in my experience MSDEV is a step
backwards in a few critical areas.  And MSDEV is relatively good for a
GUI IDE, as far as I know.

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

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Wed, 19 Dec 2001 16:13:35 -0800 
Brian Hook <bri...@py...> wrote:

> The common complaint against this is that people wedded to Emacs,
> make, grep, perl, etc. will find themselves at the mercy of
> whatever environment is provided.  I don't have a problem with
> this -- I'm completely comfortable in MSDEV, ProjectBuilder, etc.
> I can make them do what I need them to do, warts and all.  But I
> do at least understand their concerns, even if I do find them
> misguided =)

Its the same argument that surrounds unified APIs versus atomic
approaches.  Some swear by unified APIs.  Some swear at them.  Some
grumble, and write atomic wrappers atop the unified API so they have
a system they feel they can work with.  Others grumble and write
unified APIs to wrap atomic function sets.

Its about levels of and tolerance for abstraction.

<<And yes, there have been Smalltalk-like modes for (X)Emacs as well
as having XEmacs integrated/embedded as an editor within Smalltalk
IDEs, but I'll leave that for another to post>>

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re[2]: [GD-General] Eiffel

[gabor f. <xl...@po...>]

well, i don't have much experience in large-scale development ( i'm
still studying ), but i think i'll share my opinions too...

warning, this will be long :-)

12/20/2001, 12:54 AM,Thatcher Ulrich wrote:
>> And I just find the whole notion of text files that store lines of code
>> horribly quaint.  It's the new millenium and we're still worrying about
>> things like forward declarations and circular dependencies.  I find that
>> amazing.

> I've heard this gripe a few times lately, and I really don't see it.
> What's wrong with files, really?  Isn't it really C++'s
> declare-before-use that's the problem?

the problem is that in c++ i'm creating objects.
i don't create text-files ( well, i'm creating them because i must,
and not because i like them )..

for example c++, templates...

because c++ programs are compiled on a per-file basis, the compiler
puts the code for vector<int> into every obj-file where i use them..

of course at link time he can remove the redundant ones, but still..

i don't remember but there was a problem with templates because of
that per-file-compiling, and the only compiler that had no problems
was ibm visualage because he doesn't work with files  ( actually i
didn't try it, i've read it .. )

so why can't we have in the development tool a database of objects?
i don't care about where he is on my hdd, i only want to get my exe
:-)

the languages i've met:

c++:
    most of time i use this one, and it's good for a lot of things (
    the second best language for everything )...
    but i find it too low-level.. i know that i have to pay the price
    for speed, but still..
    and templates.... they are a great thing for vector<int> and i
    don't want to touch ever a language without such constructs..
    but they are crazy things, and i don't think people will learn
    to use template-metaprogramming like it is in some books..
    yes, they are nice to look at... "wow, you can to THAT with
    templates", but to write them....
    and of course most of compilers don't support everything,
    and error-messages.... even for a simple vector<string>, if you
    make a mistake you get a 2000char long error message

    so simply i think c++ is too big ( i think bloated is the correct
    term ).. it has too many features and because of that it's hard
    to create compilers for that... i'm not an expert, but i think the
    "export" keyword is in the ansi standard and still noone
    implemented it..

java:
     when i've begun working with java, it looked so clean...
     clean i mean i was used to that in every c++ compiler i had to
     use macros, and all kind of ugly preprocessor directives..
     in java there was nothing like that..
     i could focus on my objects, if i wanted to use an another
     object,i simply used it and java found it ( or i had to import
     it,but it's still better than #include.. i hate #include )
     everything ( ok,nearly everything) was an object, i didn't have
     to write const Vertex& a all the time i could use simply Vertex
     a,
     but
     there were no templates.... i had to cast on every step when i
     wanted to insert/get something into/from a container...ugly...
     no operator overloading .... i don't want to read/write
     constructs like Vertex a,b,c; a = b.add(c.mul(d.sub(a,b),g.xor...

c#:
   it's the same as java, except they support operator overloading
   and it's more or less microsoft only ( actually at www.go-mono.com,
   they're trying to create an unix version )

lisp:
     i've met him at the university :-)... functional programming was
     very interesting... not so much practical but very interesting..
     you had to look at your problems from a completely different
     point of view... i recommend to everyone to try some functional
     languages... but i don't think in the near future we'll be
     creating graphics programs in ocaml..
python:
       super. python is the kind language i would like to use in the
       future.... high level... for example dictionaries are a basic
       data-type.. fully object-oriented... it doesn't have
       templates,but he doesn't need them, you can write like this:
       function add(a,b) { return a + b; }, and he checks everything
       but the best thing was that everything worked as i expected..
       i looked at some code and i could tell you what it is doing


i'll just stop now and wait for your opinions :-)

bye,
gabor

Re: [GD-General] Eiffel

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

On Dec 19, 2001 at 03:32 -0800, Brian Hook wrote:
> 
> I sort of disagree -- you need a languager AND an environment.
> Objective-C is a fine language, but what really puts it over the top is
> Cocoa and Interface Builder (and the other libraries like Core
> Foundation and AppKit).  Interface Builder is such a seamless
> integration into the development process (unlike AppWizard) that it
> pretty much has to be considered part of the language.
> 
> The best language in the world is worthless (to me) if it doesn't have
> supporting tools and environments that really target the language's
> strengths.  For example, the notion of a "generic environment" a la
> Emacs (or Visual Studio) is slowly going to become an arcane notion
> because separating the language from the build and analysis process will
> become less tenable.

Well, I think this is another way of expressing Kent's point about the
right tool for the job.  If you want to make a nice GUI in a hurry,
then Cocoa sounds like a really good tool.  If you want to glue a
webcam to a webpage in a customized way (something I fiddled with the
other day), thank god for Perl and various GNU/open-source stuff.  If
you want to make great-looking browser games, Flash w/ Actionscript
looks like a great tool (here's a set of great examples:
http://www.ferryhalim.com/orisinal/ ).  If you want to write an OS
kernel, then it's hard to argue with C.

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

RE: [GD-General] Eiffel

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

> Well, there's my favorite IDE, emacs.  Supports every 
> language you've ever heard of, and every feature (for better 
> or worse).  Not very fun to learn, though.

Oooh, ooh, we're treading on dangerous ground here, so, um, I'll try to
be polite =)

Emacs is great -- I used it exclusively from about 1991 to 1996.  In
fact, I used OS/2 2.x ONLY because it had a good Emacs.

But in the end, Emacs is a text editor, and I think that modern
programming is going to move us into custom tools, browsers, source code
analyzers, design analyzers, and all manner of stuff that isn't going to
be expressible as an Elisp function or an external command line tool.  I
know that Emacs has managed to do much of this so far through the
ingenuity of its design and its users, but I have this suspicion that
going forward that the "text only" model isn't going to work.

For example, you can't build a Smalltalk like environment in Emacs (at
least, I don't think you can, but hell, I'm sure someone will post a
link to something similar =) ).

> Cool... I take it Cocoa is what used to be NextStep...

Yep.

> Hm, well, that kind of thing sounds like a bug in the garbage 
> collector, or a crummy allocator.  A practical problem, nonetheless.

In the case of Obj-C, there is GC built into the language itself.  Cocoa
frameworks has a ref counting system (autorelease pools) that is better
than nothing, but not a true behind-the-back GC.  Eiffel implementations
have pluggable GC implementations, so you can choose which one makes
sense for you.  I think C++ and Obj-C are far more susceptible to memory
fragmentation problems (because they expose this information) than, say,
Java and Eiffel.

So I'm glad you pointed that out, because fragmentation shouldn't be a
problem on a closed system that doesn't expose the memory subsystem's
guts.

There's also the difference between "fast enough" and "as fast as
possible".  Games are always striving for the latter, but I think that a
large class of applications need "fast enough" for 95% of their code and
"as fast as possible" for the remainder.  People used to complain that
Obj-C's message passing (or even C++'s virtual functions or C's vararg
functions) were "too slow".  But computers are a bit faster than the
68040/25 machines that NextStep shipped on, so I'm not convinced that
some of the slowness of SmallTalk is still THAT slow =)

> I've heard this gripe a few times lately, and I really don't 
> see it. What's wrong with files, really?  Isn't it really 
> C++'s declare-before-use that's the problem?

The problem is more along the lines of a lack of global "see it all at
once" analysis.  The in order parsing of various files, some with
"declarations" and others with "definitions", is obsolete.  We have
computers to take away this kind of tedious bookkeeping, but instead I'm
the one that has to say "Oh, Foo is a class that I define elsewhere".

In an ideal world you have class definitions that are just in some
browsable database.  You then fill in the blanks on what they do, the
class invariants, preconditions, postconditions, etc. and then the tools
should be able to spit out a complete specification based on your code.
The idea of manual comments becomes an artifact of a by-gone age.
Documentation is necessary, but manual comments (comment == "some text I
put here to explain this bit of code") should be fairly rare.

The build environment can then parse your entire architecture and
generate back end code, comments, dependency analysis, etc. all within
the confines of one environment that UNDERSTANDS the language,
frameworks and tools instead of just PARSING the language and its tools.
Emacs can be made to work with a syntax, but it can't be made to
understand what a language is trying to do.

The common complaint against this is that people wedded to Emacs, make,
grep, perl, etc. will find themselves at the mercy of whatever
environment is provided.  I don't have a problem with this -- I'm
completely comfortable in MSDEV, ProjectBuilder, etc.  I can make them
do what I need them to do, warts and all.  But I do at least understand
their concerns, even if I do find them misguided =)

Brian

Re: [GD-General] Eiffel

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

On Dec 19, 2001 at 03:09 -0800, Brian Hook wrote:
> 
> >I'm full of opinions and theories, like everyone else I'm sure.  My
> >semi-educated impression is that OCaml is the paragon of advanced
> >features, Dylan is the modern heir to the Common Lisp heritage,
> >Haskell is hardcore functional, Eiffel is hardcore OO, and Java/C#
> >is > the half-measure we're all going to be using instead.
> 
> I'm shying away from experimental languages that don't have
> comprehensive IDEs.  I'm firmly of the belief that a solid
> development environment is PART of the language, not an add on,
> because the language is strictly a syntax, which is only part of the
> equation.

Well, there's my favorite IDE, emacs.  Supports every language you've
ever heard of, and every feature (for better or worse).  Not very fun
to learn, though.

> My productivity when writing tools with Obj-C/Cocoa is roughly 5-10x
> that of using MFC/C++.

Cool... I take it Cocoa is what used to be NextStep...

> The fundamental problem with using something like Obj-C, SmallTalk
> or Eiffel is that they're so detached from the hardware that getting
> high performance is fairly difficult.  Not only that, but things
> like memory management can't be ignored, especially issues like
> memory fragmentation.  I've heard of MUD servers that can run for
> two days then grind to a halt; not because of a leak, but because
> their address space has become so fragmented from numerous small
> allocations and deletions.

Hm, well, that kind of thing sounds like a bug in the garbage
collector, or a crummy allocator.  A practical problem, nonetheless.

> I just don't think C++'s compromising straddle
> of the no-man's land between "close to the metal" and "high level
> abstractions" makes much sense, not for large scale projects that
> typically don't NEED to get close to the metal.

Agreed; although performance does matter, *especially* for large-scale
projects.  C++ has good compilers and discourages the use of
high-level stuff; unfortunately it punishes us programmers.  In theory
OCaml should be able to make better code than C++ just about always,
but in practice I'm sure it often doesn't.

> And I just find the whole notion of text files that store lines of code
> horribly quaint.  It's the new millenium and we're still worrying about
> things like forward declarations and circular dependencies.  I find that
> amazing.

I've heard this gripe a few times lately, and I really don't see it.
What's wrong with files, really?  Isn't it really C++'s
declare-before-use that's the problem?

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

RE: [GD-General] Eiffel

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

> Thanks for the link. I haven't finished it yet, but what I've 
> read so far is interesting, intelligent and well-reasoned 
> (unlike most rants about C++ or other languages).

I can also highly recommend Joyner's book "Objects Unencapsulated".

> So the question revolves around choosing a language that can 
> meet your needs for a particular project.

I sort of disagree -- you need a languager AND an environment.
Objective-C is a fine language, but what really puts it over the top is
Cocoa and Interface Builder (and the other libraries like Core
Foundation and AppKit).  Interface Builder is such a seamless
integration into the development process (unlike AppWizard) that it
pretty much has to be considered part of the language.

The best language in the world is worthless (to me) if it doesn't have
supporting tools and environments that really target the language's
strengths.  For example, the notion of a "generic environment" a la
Emacs (or Visual Studio) is slowly going to become an arcane notion
because separating the language from the build and analysis process will
become less tenable.

> C++ is by no means the perfect language. But it supports large-scale
> programming, high-end data abstractions, and high-end code 
> abstractions (the STL is sheer brilliance, IMO, and while 
> it's a bit more cumbersome than I'd like, I don't want a 
> language that doesn't support that kind of programming).

I'll just have to disagree.  C++ is fine if you're an expert C++
programmer, and but there are so few TRUE expert C++ programmers out
there that this is meaningless.  The vast majority of C++ programmers
are average, and as such don't understand all the odd rules and
workarounds for the language's deficiencies.  I'll defer to Joyner's
treatise on the subject, but from my point of view C++ is attempting is
an answer to a question only Bjarne asked =)

> I've used Java for a lot of things recently, and there's a 
> lot to like about it. But it doesn't support the higher-level 
> abstractions.

Java is clearly superior to C++ as a language, but it really was just an
evolutionary step.  It removed a lot of the baggage that C++ had due to
its near religious belief in "no new keywords" and "maintain C
compatibility".  But, by the same token, it still wanted

> But Eiffel seems a bit too much like a religion -- it's 
> Pascal and Modula-3 taken to the next step, and I have always 
> found that school of language design to be a bit too 
> cumbersome.

Well, one reason I'm asking here about Eiffel is because I haven't made
the commitment to learn it.  On paper, it sounds fantastic.  I can't see
any glaring holes in it.

> It's also single-source, isn't it? I wouldn't 
> mind being proven wrong -- but paying $2000-3000 to find out 
> seems a bit steep. Are there multiple implementations of Eiffel?

There are at least four major implementations of Eiffel that I'm aware
of: ISE's Eiffel Studio (the "official" one from Meyer's company);
Object Tools' "Visual Eiffel"; Halstenbach's ISS; and the GNU
SmallEiffel implementation which is free.

I've yet to see a thorough comparison of the above, but they all offer
some type of free/trial/lite version, and the home editions are in the
$100-200 range which isn't much.  And I don't mind paying $1500 for a
development tool (hell, VStudio + MSDN Library is that much almost) if
it makes me even 20% more productive.

I'm probably going to read Meyer's book before making a decision on the
plunge, but after having witnessed the radical productivity gains you
can make by changing environments, tools and language, I'm a lot more
open minded than I used to be.

Brian

Re: [GD-General] Eiffel

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

On Dec 19, 2001 at 06:09 -0500, Kent Quirk wrote:

> But Eiffel seems a bit too much like a religion -- it's Pascal and
> Modula-3 taken to the next step, and I have always found that school of
> language design to be a bit too cumbersome. It's also single-source,
> isn't it? I wouldn't mind being proven wrong -- but paying $2000-3000 to
> find out seems a bit steep. Are there multiple implementations of
> Eiffel?

I just downloaded and compiled SmallEiffel, "The GNU Eiffel Compiler":

http://www.loria.fr/projets/SmallEiffel/

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

Re: [GD-General] Eiffel

[Kent Q. <ken...@co...>]

Brian Hook wrote:
> (quick note: if you have an interest C++'s weaknesses, please check out
> Ian Joyner's fantabulous paper on the subject at:
> http://www.elj.com/cppcv3/ ).

Thanks for the link. I haven't finished it yet, but what I've read so
far is interesting, intelligent and well-reasoned (unlike most rants
about C++ or other languages).

> I won't bore you folks with my typical rant about how languages kinda
> suck, and development environments suck even worse, and how the two
> really need to be the same thing (yeah, I know, SmallTalk...), but
> instead I'll just ask: anyone here actually use Eiffel relatively
> recently for any projects, and if so, what did you think about it?

Can I attempt to summarize?

Some languages are good at expressing really powerful data abstractions:
I'd include most of the OO languages in this space, including C++, Java,
Smalltalk, Eiffel.

Some languages are good at expressing really powerful programming
abstractions, such as template programming, reflection, lambda calculus,
and the like. I'd include here C++, Smalltalk, Java, Python, Objective
Caml, Haskell.

Some languages are supported by a wide range of platforms and compilers.
Among these are C, C++, Java, Fortran, Perl, Python, and BASIC (although
the different versions of BASIC are so different that code is rarely
ported).

Some languages are known for good performance, particularly for
performance-sensitive environments. Among these are C, C++, Java, and
Fortran.

Some languages support an extensible, fast turnaround, high-performance
development environment. I'm going to define this to mean that if the
time from edit to running the edited code is more than a couple of
seconds, it's too long. I personally include Java in this list and
exclude C++, but YMMV.

Some languages have a broad base of support in a particular industry:
clearly C++, Java, Perl fit this mold.


So the question revolves around choosing a language that can meet your
needs for a particular project. The bigger the project, the larger the
team, the more likely you are to need such things as performance and
broad-based industry support.

I'd really rather work in some other language than C++. I spent a while
trying to use Smalltalk as a production language, and while I love it, I
came to the conclusion that at least at that time, it wasn't an
appropriate way to roll out a commercial product. 

C++ is by no means the perfect language. But it supports large-scale
programming, high-end data abstractions, and high-end code abstractions
(the STL is sheer brilliance, IMO, and while it's a bit more cumbersome
than I'd like, I don't want a language that doesn't support that kind of
programming).

And I've been looking around to see what else might work. I've used Java
for a lot of things recently, and there's a lot to like about it. But it
doesn't support the higher-level abstractions. I definitely want to look
into OCaml some more. 

But Eiffel seems a bit too much like a religion -- it's Pascal and
Modula-3 taken to the next step, and I have always found that school of
language design to be a bit too cumbersome. It's also single-source,
isn't it? I wouldn't mind being proven wrong -- but paying $2000-3000 to
find out seems a bit steep. Are there multiple implementations of
Eiffel?

	Kent


-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________

RE: [GD-General] Eiffel

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

>I'm full of opinions and theories, like everyone else I'm sure.  My
semi-educated impression is that 
>OCaml is the paragon of advanced features, Dylan is the modern heir to
the Common Lisp heritage,
>Haskell is hardcore functional, Eiffel is hardcore OO, and Java/C# is
the half-measure we're all going 
>to be using instead.

I'm shying away from experimental languages that don't have
comprehensive IDEs.  I'm firmly of the belief that a solid development
environment is PART of the language, not an add on, because the language
is strictly a syntax, which is only part of the equation.

This is one reason I haven't really looked too hard at, say, Sather and
OCaml, although they may be far more advanced than the last time I
looked at them (18 months ago?).

Eiffel popped up on my radar when I read Ian Joyner's "Critique of C++"
(and I'm now reading his book, "Objects Unecapsulated").  I became more
interested in the overall subject of tools/languages as an impediment to
programmer productivity after I started using Obj-C (and Cocoa).

My productivity when writing tools with Obj-C/Cocoa is roughly 5-10x
that of using MFC/C++.  I can put together a reasonably competent OpenGL
in an hour, and that's with the completely crappy docs that Apple forces
us to sift through.  After using Obj-C (which is, to paraphrase a friend
of mine, "C with Smalltalk shoved up its ass"), I was thinking "Holy
crap, there IS a better way, and this is it!".  I guess Carmack was way,
WAY ahead of his time, given his use of Obj-C and NextStep some 9 years
ago.  Eiffel feels to me like a slightly better, more advanced version
of Obj-C (er, or Smalltalk) that eschews Obj-C's desire to maintain C
syntax compatibility and instead tries to implement ideas like
design-by-contract to promote better software engineering.

The fundamental problem with using something like Obj-C, SmallTalk or
Eiffel is that they're so detached from the hardware that getting high
performance is fairly difficult.  Not only that, but things like memory
management can't be ignored, especially issues like memory
fragmentation.  I've heard of MUD servers that can run for two days then
grind to a halt; not because of a leak, but because their address space
has become so fragmented from numerous small allocations and deletions.

So C is still important because it lets you manage things very
precisely.  C++ as a "better C" probably serves a purpose.  But for tool
development, e.g. landscape editors and things like that, the higher
level languages (and environments -- this is absolutely key) see to
provide a much faster way to develop real, robust applications that are
also easy to maintain.  I just don't think C++'s compromising straddle
of the no-man's land between "close to the metal" and "high level
abstractions" makes much sense, not for large scale projects that
typically don't NEED to get close to the metal.

And I just find the whole notion of text files that store lines of code
horribly quaint.  It's the new millenium and we're still worrying about
things like forward declarations and circular dependencies.  I find that
amazing.

Brian

Re: [GD-General] Eiffel

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

On Dec 19, 2001 at 01:04 -0800, Brian Hook wrote:
> 
> I won't bore you folks with my typical rant about how languages kinda
> suck, and development environments suck even worse, and how the two
> really need to be the same thing (yeah, I know, SmallTalk...), but
> instead I'll just ask: anyone here actually use Eiffel relatively
> recently for any projects, and if so, what did you think about it?

You probably have these links already, but:

Somebody using Eiffel for games (I just downloaded and built it, but
the samples are super basic; none of them is an actual game):
http://jegl.sourceforge.net/

A student game-development contest at Stanford; the third-place
project used OCaml, and maybe there are some other oddball languages
in there:
http://graphics.stanford.edu/courses/cs248-videogame-competition/cs248-00/

SDL has a lot of different language bindings, so you might find some
interesting stuff in these links:
http://www.libsdl.org/languages.html

> I don't want this to become a flame fest about languages, but I'm not
> averse to intelligent discussion on the pros/cons of choosing a language
> and environment to enhance software robustness, stability and
> maintainability.

I'm full of opinions and theories, like everyone else I'm sure.  My
semi-educated impression is that OCaml is the paragon of advanced
features, Dylan is the modern heir to the Common Lisp heritage,
Haskell is hardcore functional, Eiffel is hardcore OO, and Java/C# is
the half-measure we're all going to be using instead.

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

[GD-General] Eiffel

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

So whilst engaged in yet another C/C++ flame fest on another mailing
list, I ran into the subject of Eiffel.

(quick note: if you have an interest C++'s weaknesses, please check out
Ian Joyner's fantabulous paper on the subject at:
http://www.elj.com/cppcv3/ ).

I won't bore you folks with my typical rant about how languages kinda
suck, and development environments suck even worse, and how the two
really need to be the same thing (yeah, I know, SmallTalk...), but
instead I'll just ask: anyone here actually use Eiffel relatively
recently for any projects, and if so, what did you think about it?

I don't want this to become a flame fest about languages, but I'm not
averse to intelligent discussion on the pros/cons of choosing a language
and environment to enhance software robustness, stability and
maintainability.

Brian

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

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

At 06:11 PM 12/13/2001 +1100, Chris Brodie wrote:
>I thought zlib just did the decompression \ compression and your 
>responsible for the data source, in this case zip files.

Yes, but you're only responsible for the WHOLE ZIP file, you don't have to 
do any seeking at all.  Just download ZLIB and look at the sample unzip 
utilities.

Brian

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

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

I thought zlib just did the decompression \ compression and your responsible for the data source, in this case zip files. I think I need to locate a memory block (pointer+size) to hand over to zlib. I was actually planning on using zlib, one I can locate the memory block that the file is in.

Is this assumption wrong?

> Dumb question -- why aren't you using zlib?
> 
> Brian


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

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

At 05:20 PM 12/13/2001 +1100, Chris Brodie wrote:
>I'm currently coding up a zip loader myself.

Dumb question -- why aren't you using zlib?

Brian

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

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

I'm currently coding up a zip loader myself. I've been reading over the pkware docs, however I'm finding their descriptions to be difficult to nut out in some cases. I turned to some sample implementations on the net and now it's even more confused.

The first thing I read was to walk the whole file, reading the local file descriptors as you go : http://epicboy.flipcode.com/tutorials_ZIP.htm   eeek, I can't imagine this scaling to a large resource file!

Then after reading the pkware docs, and using a little wisdom it seems more likely that the Central Directory is what I should be using.

My intention is the build an STL map that maps file names to data offsets. To do this I need to find the beginning of the central directory, something which seems a little difficult. The only way I've found to do this so far is to jump back about 65k(assuming the file is that big) and then start reading forward comparing each byte to the header 0x02014b50. This might be a bit faster if I knew the tag was 4 byte aligned, but it still seems a little silly to find the main table by a random scan like this. 

Is there a better way?

Many thanks

Chris

No picking on the disclaimer, it's added at the server. :)


-----Original Message-----
From: Gareth Lewin [mailto:GL...@cl...]
Sent: Friday, 7 December 2001 7:49 AM
To: gam...@li...
Subject: RE: [GD-General] Building pak/zip files


Hmm, you might want to look at the zip file definition again (http://www.pkware.com/support/appnote.html). 
If you seek to the end of the file, make sure you don't have comments or Zip64 code ( Both a logical requirement for a game based zip file ) then the last 16 bytes will be:
<quote> 
number of this disk: (2 bytes) 
The number of this disk, which contains central directory end record. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field.
number of the disk with the start of the central directory: (2 bytes) 
The number of the disk on which the central directory starts. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field.
total number of entries in the central dir on this disk: (2 bytes) 
The number of central directory entries on this disk. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field.
total number of entries in the central dir: (2 bytes) 
The total number of files in the .ZIP file. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field.
size of the central directory: (4 bytes) 
The size (in bytes) of the entire central directory. If an archive is in zip64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field.
offset of start of central directory with respect to the starting disk number: (4 bytes) 
Offset of the start of the central directory on the disk on which the central directory starts. If an archive is in zip64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field.
</quote> 
Also you should be able to assume that you don't use multidisk spanning. 
_____________________ 
Regards, Gareth Lewin 
Lead Programmer 
Climax Development 
Fareham Heights 
Standard Way 
Fareham 
P016 8XT 


> -----Original Message----- 
> From: Brian Sharon [mailto:bs...@mi...] 
> Sent: 06 December 2001 18:47 
> To: Thatcher Ulrich; Tom Spilman 
> Cc: gam...@li... 
> Subject: RE: [GD-General] Building pak/zip files 
> 
> 
> 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.  
> 
> 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...] 
> 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). 
> > 
> >     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 
> 
> _______________________________________________ 
> 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 
> 


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] Art Questions:

[Scott B. <gas...@nw...>]

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

That's one of the goofiest disclaimer sig's I've ever seen. I rate it
8.5 out of 10.

[GD-General] Art Questions:

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

I'm a sole developer working on source and artwork. I'm using 2 year old Photoshop and Lightwave versions for my artwork. As a code developer I'd love to get stuck in to some s3tc coding as this seems pretty cool for things like conserving  texture memory and increasing load speed. 

However, I'm concerned about art specific standard not supporting these coder friendly formats. I know that there is a plugin for Photoshop to allow creation \ editing of .dds files. I'm curious however about things like using this format with things like Lightwave. Does anyone here have coders using s3tc within Lightwave, or would I need to write a plugin to allow it to 'see' s3tc bitmap's?

Many thanks

Chris


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

[Roland <ro...@wi...>]

Hey ZIP gurus out there....

I wrote some of these 'file-system-in-a-zip' classes myself, but one
thing bothered me a bit: according to the AppNote.txt there are
several compression methods which could potentially be used by WinZip
(et altera). The most common apparently are 0 (no compression) and 8
(deflate). What about the others? Is there code available which deals
with them? Is it necessary to deal with them?

I'm asserting wildly if the method is unknown (other than 0 or 8) and
before I use a resource ZIP/PAK in release mode, I verify each file to
be accessible. Of course this could all be avoided if I would generate
the ZIP/PAK file myself and make sure that only 0 and 8 are used...
which would mean YATTW (yet another tool to write)...

What are you guys doing?

cu
roland



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On
> Behalf Of
> Brian Sharon
> Sent: Thursday, December 06, 2001 2:04 PM
> To: Gareth Lewin; gam...@li...
> Subject: RE: [GD-General] Building pak/zip files
>
>
> Ooops, you're right, I was going off the code in "unzip.c"
> that ships with zlib (in the contrib\minizip directory) -
> it seeks backwards because it's assuming that there might
> be a comment field.  But like you say, you should be able
> to assume that you don't have comments in a game-based zip.
>
> --brian
>
> -----Original Message-----
> From: Gareth Lewin [mailto:GL...@cl...]
> Sent: Thursday, December 06, 2001 12:49 PM
> To: gam...@li...
> Subject: RE: [GD-General] Building pak/zip files
>
> Hmm, you might want to look at the zip file definition
> again (http://www.pkware.com/support/appnote.html).
> If you seek to the end of the file, make sure you don't
> have comments or Zip64 code ( Both a logical requirement
> for a game based zip file ) then the last 16 bytes will be:
> <quote>
> number of this disk: (2 bytes)
> The number of this disk, which contains central directory
> end record. If an archive is in zip64 format and the value
> in this field is 0xFFFF, the size will be in the
> corresponding 4 byte zip64 end of central directory field.
> number of the disk with the start of the central directory:
> (2 bytes)
> The number of the disk on which the central directory
> starts. If an archive is in zip64 format and the value in
> this field is 0xFFFF, the size will be in the corresponding
> 4 byte zip64 end of central directory field.
> total number of entries in the central dir on this disk: (2 bytes)
> The number of central directory entries on this disk. If an
> archive is in zip64 format and the value in this field is
> 0xFFFF, the size will be in the corresponding 8 byte zip64
> end of central directory field.
> total number of entries in the central dir: (2 bytes)
> The total number of files in the .ZIP file. If an archive
> is in zip64 format and the value in this field is 0xFFFF,
> the size will be in the corresponding 8 byte zip64 end of
> central directory field.
> size of the central directory: (4 bytes)
> The size (in bytes) of the entire central directory. If an
> archive is in zip64 format and the value in this field is
> 0xFFFFFFFF, the size will be in the corresponding 8 byte
> zip64 end of central directory field.
> offset of start of central directory with respect to the
> starting disk number: (4 bytes)
> Offset of the start of the central directory on the disk on
> which the central directory starts. If an archive is in
> zip64 format and the value in this field is 0xFFFFFFFF, the
> size will be in the corresponding 8 byte zip64 end of
> central directory field.
> </quote>
> Also you should be able to assume that you don't use
> multidisk spanning.
> _____________________
> Regards, Gareth Lewin
> Lead Programmer
> Climax Development
> Fareham Heights
> Standard Way
> Fareham
> P016 8XT
>
> > -----Original Message-----
> > From: Brian Sharon [mailto:bs...@mi...]
> > Sent: 06 December 2001 18:47
> > To: Thatcher Ulrich; Tom Spilman
> > Cc: gam...@li...
> > Subject: RE: [GD-General] Building pak/zip files
> >
> >
> > 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. 
> >
> > 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...]
> > 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).
> > >
> > >     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
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

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

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

Ooops, you're right, I was going off the code in "unzip.c" that ships =
with zlib (in the contrib\minizip directory) - it seeks backwards =
because it's assuming that there might be a comment field.  But like you =
say, you should be able to assume that you don't have comments in a =
game-based zip.

--brian

-----Original Message-----
From: Gareth Lewin [mailto:GL...@cl...]=20
Sent: Thursday, December 06, 2001 12:49 PM
To: gam...@li...
Subject: RE: [GD-General] Building pak/zip files

Hmm, you might want to look at the zip file definition again =
(http://www.pkware.com/support/appnote.html).=20
If you seek to the end of the file, make sure you don't have comments or =
Zip64 code ( Both a logical requirement for a game based zip file ) then =
the last 16 bytes will be:
<quote>=20
number of this disk: (2 bytes)=20
The number of this disk, which contains central directory end record. If =
an archive is in zip64 format and the value in this field is 0xFFFF, the =
size will be in the corresponding 4 byte zip64 end of central directory =
field.
number of the disk with the start of the central directory: (2 bytes)=20
The number of the disk on which the central directory starts. If an =
archive is in zip64 format and the value in this field is 0xFFFF, the =
size will be in the corresponding 4 byte zip64 end of central directory =
field.
total number of entries in the central dir on this disk: (2 bytes)=20
The number of central directory entries on this disk. If an archive is =
in zip64 format and the value in this field is 0xFFFF, the size will be =
in the corresponding 8 byte zip64 end of central directory field.
total number of entries in the central dir: (2 bytes)=20
The total number of files in the .ZIP file. If an archive is in zip64 =
format and the value in this field is 0xFFFF, the size will be in the =
corresponding 8 byte zip64 end of central directory field.
size of the central directory: (4 bytes)=20
The size (in bytes) of the entire central directory. If an archive is in =
zip64 format and the value in this field is 0xFFFFFFFF, the size will be =
in the corresponding 8 byte zip64 end of central directory field.
offset of start of central directory with respect to the starting disk =
number: (4 bytes)=20
Offset of the start of the central directory on the disk on which the =
central directory starts. If an archive is in zip64 format and the value =
in this field is 0xFFFFFFFF, the size will be in the corresponding 8 =
byte zip64 end of central directory field.
</quote>=20
Also you should be able to assume that you don't use multidisk spanning. =

_____________________=20
Regards, Gareth Lewin=20
Lead Programmer=20
Climax Development=20
Fareham Heights=20
Standard Way=20
Fareham=20
P016 8XT=20

> -----Original Message-----=20
> From: Brian Sharon [mailto:bs...@mi...]=20
> Sent: 06 December 2001 18:47=20
> To: Thatcher Ulrich; Tom Spilman=20
> Cc: gam...@li...=20
> Subject: RE: [GD-General] Building pak/zip files=20
>=20
>=20
> Things like WinZip will (by default) try to compress=20
> everything, so you=20
> would want to set command line flags to disable compression for=20
> uncompressible things like sound files.=20
>=20
> And I can't imagine a zip implementation that wouldn't add=20
> files to the=20
> end of the zip in the order that you insert them, because the=20
> alternative (shifting files down) would be so inefficient.=A0=20
>=20
> But the worst part of zip files is that the catalog lives at an=20
> unspecified distance from the end of the file, so opening an archive=20
> means seeking to somewhere near the end and walking around looking for =

> the catalog.=A0 If you're really worried about speed, you=20
> probably want to=20
> have a post-process step where you generate another copy of=20
> that catalog=20
> in a spot where it can be loaded quickly...like placed on the=20
> DVD, right=20
> in front of the zip archive.=20
>=20
> --brian=20
>=20
> -----Original Message-----=20
> From: Thatcher Ulrich [mailto:tu...@tu...]=20
> Sent: Thursday, December 06, 2001 6:21 AM=20
> To: Tom Spilman=20
> Cc: gam...@li...=20
> Subject: Re: [GD-General] Building pak/zip files=20
>=20
> On Dec 05, 2001 at 05:41 -0600, Tom Spilman wrote:=20
> > > Zip file tools don't generally give you control over what=20
> > > gets compressed and what doesn't(I think).=20
> >=20
> >=A0=A0=A0=A0 Actually i don't think this is necessarily true=20
>=20
> 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=20
> stored uncompressed.=20
>=20
> > nor that you cannot=20
> > specify the order of the contents of the zip file.=A0 Check out=20
> > http://www.winzip.com/wzcline.htm which adds command line support to =

> WinZip.=20
>=20
> Infozip's command-line zip apparently stores things in the order you=20
> specify.=A0 Also, it's open source under a X-style license, so you can =

> hack stuff in or incorporate the code in your project.=A0 There's also =

> zlib from the same project, designed for embedding.=A0 We use zlib at=20
> Oddworld for unpacking resource files.=20
>=20
> http://www.info-zip.org/=20
> http://www.gzip.org/zlib/=20
>=20
> --=20
> Thatcher Ulrich <tu...@tu...>=20
> http://tulrich.com=20
>=20
> _______________________________________________=20
> Gamedevlists-general mailing list=20
> Gam...@li...=20
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general=20
>=20
> _______________________________________________=20
> Gamedevlists-general mailing list=20
> Gam...@li...=20
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general=20
>=20

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

[Gareth L. <GL...@cl...>]

Hmm, you might want to look at the zip file definition again
(http://www.pkware.com/support/appnote.html).

If you seek to the end of the file, make sure you don't have comments or
Zip64 code ( Both a logical requirement for a game based zip file ) then the
last 16 bytes will be:

<quote>
number of this disk: (2 bytes)
The number of this disk, which contains central directory end record. If an
archive is in zip64 format and the value in this field is 0xFFFF, the size
will be in the corresponding 4 byte zip64 end of central directory field.

number of the disk with the start of the central directory: (2 bytes) 
The number of the disk on which the central directory starts. If an archive
is in zip64 format and the value in this field is 0xFFFF, the size will be
in the corresponding 4 byte zip64 end of central directory field.

total number of entries in the central dir on this disk: (2 bytes)
The number of central directory entries on this disk. If an archive is in
zip64 format and the value in this field is 0xFFFF, the size will be in the
corresponding 8 byte zip64 end of central directory field.

total number of entries in the central dir: (2 bytes)
The total number of files in the .ZIP file. If an archive is in zip64 format
and the value in this field is 0xFFFF, the size will be in the corresponding
8 byte zip64 end of central directory field.

size of the central directory: (4 bytes)
The size (in bytes) of the entire central directory. If an archive is in
zip64 format and the value in this field is 0xFFFFFFFF, the size will be in
the corresponding 8 byte zip64 end of central directory field.

offset of start of central directory with respect to the starting disk
number: (4 bytes) 
Offset of the start of the central directory on the disk on which the
central directory starts. If an archive is in zip64 format and the value in
this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64
end of central directory field.
</quote>

Also you should be able to assume that you don't use multidisk spanning.

_____________________
Regards, Gareth Lewin 
Lead Programmer
Climax Development 
Fareham Heights
Standard Way 
Fareham
P016 8XT


> -----Original Message-----
> From: Brian Sharon [mailto:bs...@mi...]
> Sent: 06 December 2001 18:47
> To: Thatcher Ulrich; Tom Spilman
> Cc: gam...@li...
> Subject: RE: [GD-General] Building pak/zip files
> 
> 
> 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.  
> 
> 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...] 
> 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).
> > 
> >     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
> 
> _______________________________________________
> 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
>