gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Text file parsing

[Paul B. <pa...@mi...>]

> -----Original Message-----
> From: Ed Sinjiashvili [mailto:ed...@sw...]=20
> Subject: Re: [GD-General] Text file parsing
>
> Most people mentioned XML. But if you ask a Lua fan - he'll tell ya
> that Lua is XML with a human face ;)=20

Having used both for some time, I would suggest that the decision
between lua and XML is more one of whether you *need* procedural
data description. =20

We use XML for data in our game with the exception of render meshes,
physics data, and one other piece of data (see below).  Being able to=20
use off-the-shelf tools/technologies like XML Schema, Schematron,=20
XML Parsers (we use a C one for the game runtime and the .NET one=20
for most tools), and decent grid-based editors has been invaluable=20
for cranking out simple (sometimes single purpose) tools.

Our only non-XML, text based data are script files for our in-game
cinematics system.  The runtime for this system uses Lua files for
its file format.  The original intent was that we would/could stuff
procedural elements in the cinematic scripts by saving them off as
Lua functions. =20

As it turns out, we never really found the procedural element useful
and/or usable for our game.  So, in the end, our Lua script files end
up being simple table definitions of entity/event pairs.  Because
of the limited usefullness of Lua (in this case) we would be better off
moving those scripts to XML data so they can take advantage of the
in-place data validation mechanisms we have in place.

One of the largest complaints I hear against XML is the verbosity of
the syntax.  Good tools (most off-the-shelf, some home grown) generally
remove the syntax as an issue (no one on our team or outside of our team
that comes in contact with our data complains).  The other complaint is=20
parse time.  We ignore parse time issues in our tools (overall we gain=20
in being able to manipulate the data on a large scale with standard
tools)=20
and use a non-dataloss compiled XML format for the final shipping build=20
to remove parse time issues (our load times are acceptable to everyone
who
has played the game).

Now, given the work that we've done to use XML (which we think has paid
itself off), one thing we've noticed is that we (more or less) built a
pretty simple database system that uses XML for its datastore.  At that
point whether to use an actual DBMS becomes an interesting question.

Paul

Re: [GD-General] Text file parsing

[Ed S. <ed...@sw...>]

"Marc Fascia" <mf...@pu...> writes:
> I wonder how people handle file parsing in their projects.
Here's the excerpt from the gloriuos Scripting thread:

[Evan Bell]
  To avoid creating Yet Another Crappy Parser I used flex & bison to do 
  the hard work of creating the script compiler.

[Brian Hook]
  Eewww.  I'm leaning towards just using Lua as my syntax for, er, 
  everything, and letting it handle the heavy lifting.


Most people mentioned XML. But if you ask a Lua fan - he'll tell ya
that Lua is XML with a human face ;) 

-- Ed

RE: [GD-General] Compile times

[Matt N. <mat...@ni...>]

> -----Original Message-----
> From: Donavon Keithley [mailto:kei...@ea...]=20
> Sent: 11 December 2002 06:40
> To: gam...@li...
> Subject: RE: [GD-General] Compile times
>
> But is C# viable for real game development?  Hard to say=20
> until somebody actually does it.  Phil Taylor has claimed=20
> that the Managed DirectX examples will run 98% as fast as the=20
> C++ examples.  That's bold, and promising.  (Incidentally,=20
> Managed D3D is much cleaner and easier to work with than=20
> regular old D3D.)  Still, it may be that you'd want your=20
> low-level stuff in C/C++, and watch out for chatty interfaces.
>=20

Is there a decent profiler for C#? I would be a lot more comfortable =
about trying it out if I knew that I had a good profiler so I could =
quickly spot any areas which might be candidates for replacement with =
C++ code. If something with similar functionality to VTune is available =
for C# (as far as I know VTune itself is not?) then performance concerns =
would be easier to address.

Matt.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.423 / Virus Database: 238 - Release Date: 25/11/2002
=20

Re: [GD-General] Text file parsing

[Noel L. <ll...@co...>]

On Wed, 11 Dec 2002 12:16:35 +0100
Javier Arevalo <ja...@py...> wrote:

> If you're starting fresh, I would recommend using XML for structured text
> files. You can use TinyXML to read them (use google to locate it).

Yes, I was going to suggest XML as well. It's simple enough to replace
ini-like files, and complex enough that you can easily represent
hierarchical structures (very important for hierarchy/geometry
information).

I'm about to start looking into it more seriously for our next project,
so I don' t have any specific recommendations now.

I did use TinyXML for The Bidding Imp (http://www.convexhull.com/bidimp)
and it worked just fine. It has no data validation though (through DTD)
and that's something I think I would like to have, at least in the tool
side. Ideally, I'd like a parser that does both, and I can choose
whether to enable it or not. Still, it was certainly small enough (about
100KB) and it worked perfectly well just for saving/reading data.


--Noel
ll...@co...

RE: [GD-General] Text file parsing

[Awen L. <ali...@ed...>]

I warmly recommend the XML option as a text file. Very smart, even if you're
using only its simplest functionnalitites (tag enclosure and hierarchy save
you a lot of further format maintenance time). And maybe there are now some
recommendations ready concerning Scene/Mesh 3D. If it could help you...
Awen

-----Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
Javier Arevalo
Envoyé : mercredi 11 décembre 2002 12:17
À : gam...@li...
Objet : Re: [GD-General] Text file parsing


We use a structure very similar to ASE for our data definition files.
Writing the parser for it was about a couple hours.

If you're starting fresh, I would recommend using XML for structured text
files. You can use TinyXML to read them (use google to locate it).

Marc Fascia <mf...@pu...> wrote:
> Hello,
>
> I'm currently writing a toolkit that will be used as a basis for my
> next game engine. It will feature one or several editing tools for
> content creation, as one of the objective is to be data-driven. In
> the process, I plan to use some intermediate text-based file formats,
> such as ASE for meshes (easy to export from any modelling packages),
> text shaders/material files and so on.
>
> My question is about the best way of writing file-parsers for these
> files. I can see currently 2 options
>
> 1) use some tools like Lex&Yacc
> - Pros : easy to use, fast development time, easy to make the grammar
> evolve
> - Cons : for now, I was unable to make Lex&Yacc create some nice C++
> parser class that can be embedded in my tools.
>
> 2) write my own from scratch, maybe first writing a DumbParser class
> that just provides with a bunch of basic string function, acting like
> a Lexer and derive the different needed parsers from that, embedding
> the grammar inside
> - Pros : full control on the design and the implementation, in
> comparison to the obfuscated code from Ley/Yacc
> - Cons : more development time, grammar kind of hardcoded so not
> easily maintainable, I'm not very experienced in writing text parsers
> :)
>
> I wonder how people handle file parsing in their projects.
> Thanks for your help.
>
> -Marc


  Javier Arevalo
  Pyro Studios




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

Re: [GD-General] Text file parsing

[Achim M. <amu...@is...>]

Didn't try it myself, but http://www.irule.be/bvh/c++/olex/ pretends to
be: "olex is an easy to use LL(1) parser generator in C++, generating
C++ code."

-achim

> Marc Fascia wrote:
> 
> Hello,
> 
> I'm currently writing a toolkit that will be used as a basis for my
> next game engine. It will feature one or several editing tools for
> content creation, as one of the objective is to be data-driven. In the
> process, I plan to use some intermediate text-based file formats, such
> as ASE for meshes (easy to export from any modelling packages), text
> shaders/material files and so on.
> 
> My question is about the best way of writing file-parsers for these
> files. I can see currently 2 options
> 
> 1) use some tools like Lex&Yacc
> - Pros : easy to use, fast development time, easy to make the grammar
> evolve
> - Cons : for now, I was unable to make Lex&Yacc create some nice C++
> parser class that can be embedded in my tools.
> 
> 2) write my own from scratch, maybe first writing a DumbParser class
> that just provides with a bunch of basic string function, acting like
> a Lexer and derive the different needed parsers from that, embedding
> the grammar inside
> 
> - Pros : full control on the design and the implementation, in
> comparison to the obfuscated code from Ley/Yacc
> - Cons : more development time, grammar kind of hardcoded so not
> easily maintainable, I'm not very experienced in writing text parsers
> :)
> 
> I wonder how people handle file parsing in their projects.
> Thanks for your help.
> 
> -Marc
>

Re: [GD-General] Text file parsing

[Javier A. <ja...@py...>]

We use a structure very similar to ASE for our data definition files.
Writing the parser for it was about a couple hours.

If you're starting fresh, I would recommend using XML for structured text
files. You can use TinyXML to read them (use google to locate it).

Marc Fascia <mf...@pu...> wrote:
> Hello,
>
> I'm currently writing a toolkit that will be used as a basis for my
> next game engine. It will feature one or several editing tools for
> content creation, as one of the objective is to be data-driven. In
> the process, I plan to use some intermediate text-based file formats,
> such as ASE for meshes (easy to export from any modelling packages),
> text shaders/material files and so on.
>
> My question is about the best way of writing file-parsers for these
> files. I can see currently 2 options
>
> 1) use some tools like Lex&Yacc
> - Pros : easy to use, fast development time, easy to make the grammar
> evolve
> - Cons : for now, I was unable to make Lex&Yacc create some nice C++
> parser class that can be embedded in my tools.
>
> 2) write my own from scratch, maybe first writing a DumbParser class
> that just provides with a bunch of basic string function, acting like
> a Lexer and derive the different needed parsers from that, embedding
> the grammar inside
> - Pros : full control on the design and the implementation, in
> comparison to the obfuscated code from Ley/Yacc
> - Cons : more development time, grammar kind of hardcoded so not
> easily maintainable, I'm not very experienced in writing text parsers
> :)
>
> I wonder how people handle file parsing in their projects.
> Thanks for your help.
>
> -Marc


  Javier Arevalo
  Pyro Studios

[GD-General] Text file parsing

[Marc F. <mf...@pu...>]

Hello,

I'm currently writing a toolkit that will be used as a basis for my next
game engine. It will feature one or several editing tools for content
creation, as one of the objective is to be data-driven. In the process,
I plan to use some intermediate text-based file formats, such as ASE for
meshes (easy to export from any modelling packages), text
shaders/material files and so on.

My question is about the best way of writing file-parsers for these
files. I can see currently 2 options 

1) use some tools like Lex&Yacc 
- Pros : easy to use, fast development time, easy to make the grammar
evolve
- Cons : for now, I was unable to make Lex&Yacc create some nice C++
parser class that can be embedded in my tools.

2) write my own from scratch, maybe first writing a DumbParser class
that just provides with a bunch of basic string function, acting like a
Lexer and derive the different needed parsers from that, embedding the
grammar inside
- Pros : full control on the design and the implementation, in
comparison to the obfuscated code from Ley/Yacc
- Cons : more development time, grammar kind of hardcoded so not easily
maintainable, I'm not very experienced in writing text parsers :)

I wonder how people handle file parsing in their projects.
Thanks for your help.

-Marc
	

RE: [GD-General] Compile times

[Tom H. <to...@3d...>]

At 06:11 AM 12/10/2002, you wrote:
>If it is indeed a fact that using STL in a C++ project would badly
>increase compile times, then this might be seen by some as a valid
>argument against the use of STL. By the same logic, if you knew that you
>could get your work done faster using another programming language,
>would you do it? _Has_ anyone actually done it (e.g. even if only for
>internal tools)? I'd love to hear about the build times for large(-ish)
>Java or C# projects, for example.

When I first started working with Java code, I didn't think it was 
compiling. I expected at least a few seconds of feedback, but something 
flashed and it was done. Something must have been wrong ... but it wasn't. 
It was just done ;)

The ~400k (59 .java files) Java Applet I just finished compiles in well 
under a second.

After working with C/C++ for years, I recently started getting into Java. 
As a language, I think it destroys C/C++. However, I'm not willing to say 
its a better way to make games than C/C++.

Now, if I was able to write my low level stuff in C/C++ and do all my game 
play, UI, etc in Java I think I'd be in heaven ;) In fact, one of the 
things I want to get to as soon as I can is trying to set up just that 
situation using JNI. From what I've seen, it looks like a real pain in the 
butt though. Probably the most worrisome thing to me would be the ability 
to debug the Java code in a situation like that, and I suspect it is 
somewhat lacking (compared to C/C++ debugging). Won't know for sure till I 
get it set up.

Tom

RE: [GD-General] Compile times

[Donavon K. <kei...@ea...>]

Tom Nuydens [t.n...@vr...] wrote:
> In the scripting thread, Brian mentioned "faster development" (i.e. no
> rebuilds) as one of the reasons one might use scripting. Would anyone
> actually go so far as to implement a scripting engine just for this
> purpose? Or, to take it one step further, would you consider writing
> your application in a different language altogether (not C/C++), just
> for the sake of improving programmer productivity?

For years I've been desperate for something that could viably replace
C++ for at least much of game development.  Java and Python both fell
short in my estimation.  I've been using C# for two years now and it's
still looking promising.

In between contracts I do almost everything in C# and when I take a job
and go back to C++, I actually find that for a while anyway I tend to
significantly underestimate my tasks.  C# eliminates a lot of the
friction in C++ coding.  Partly it's because VS.Net integrates with C#
much better -- IntelliSense is nearly flawless, and that counts for a
LOT.  (Visual Assist certainly helps.)  And I've really become aware of
how much time gets wasted futzing around with header files -- create a
header and declare your class in it, create a .CPP and define your
functions there, make sure the signatures match, remember if you change
one to change the other, flip back and forth a lot, and of course sit
back and watch the dependencies recompile.  Header files suck.  They
need to die.

Just for kicks, I wrote a little multiplayer space trading game, sort of
like Gazillionaire, in C#.  You could play either through a browser or a
native client.  It used ADO.NET and SQL Server for the backend and
ASP.NET to serve up the web pages.  Knowing next to nothing about
ASP.NET and ADO.NET, I had it up and playable -- by multiple players --
in under a week.  And I wasn't rushing; I spent the better part of one
of those days just pulling sound effects down off the Net.

For me anyway, that's some pretty serious productivity.

But is C# viable for real game development?  Hard to say until somebody
actually does it.  Phil Taylor has claimed that the Managed DirectX
examples will run 98% as fast as the C++ examples.  That's bold, and
promising.  (Incidentally, Managed D3D is much cleaner and easier to
work with than regular old D3D.)  Still, it may be that you'd want your
low-level stuff in C/C++, and watch out for chatty interfaces.

Then there's GC.  Depending on the game you may be able to tolerate the
occasional GC hiccup and you may not.  In .NET it's so easy to create
and discard objects on the heap that every programmer would have to be
very disciplined about how memory is being consumed.

And of course there's portability.  For now you'd have to be pretty much
Windows-only.  With Rotor and Mono this may change. 

> By the same logic, if you knew that you
> could get your work done faster using another programming language,
> would you do it? _Has_ anyone actually done it (e.g. even if only for
> internal tools)? I'd love to hear about the build times for
large(-ish)
> Java or C# projects, for example.

For most tools I wouldn't use anything else.

None of my projects has gotten beyond maybe forty or fifty source files.
A normal build is one to two seconds.  A full rebuild (very rare) is
maybe a few seconds more.  I'm on vacation so I can't be more specific.
To be sure there's also a second or two hidden in the Jit compile.

Speaking of Jit, because the code is ultimately compiled on the user's
machine, the compiler can transparently use specific processor features
that C/C++ object code can't (MMX, SSI, etc).  Theoretically (some) C#
code could run faster than C/C++.

There's a lot more to say about C#/.NET's virtues and flaws (there are
some), but I'll leave it at that for now.

--Donavon

Re: [GD-General] Scripting

[mike w. <mi...@ub...>]

absolutely.

we've (somewhat/maybe/hopefully) managed to isolate the scripting side of
things with the workflow in our engine by providing the 'entities' as i
described below for the 'artists' on the team - even artists can hopefully
understand placing lights, effects, etc as entities in the world, most 3d
programs have similar concepts for placing lights & behaviors...

this way the scripts are something that the artist simply needs to 'attach'
to the entity as opposed to code from scratch.  the 'non-programming
designer-type' might never even need to see the scripts, they just know that
adding a pawn to their level & attaching the 'badguy1.s' script, they get
the desired result after recompiling their level (which if the designer is
only compiling the entities only takes seconds usually).

many of the core scripts start out being written by the 'programmer-types'
on the team - they are usually testing new features/functions that have been
implemented, as well as providing 'examples' for the rest of the designers
to modify or use as a starting point for their own custom implementations.

the beauty of it is that creating or modifying scripts doesn't actually need
the attention of a 'C++' programmer, anyone that has done basic programming
can modify or extend the 'base' scripts that the programmers have provided.
this saves us from having programmers create the cinematics scripts or
in-game NPC scripts - in other words doing jobs that should be left to the
designers & artists.

someone asked if anyone has created a main engine core that doesn't need to
be modified or recompiled and is fully scripted for all gameplay code - this
is basically what we have done.

i think this is a decision that should be made for several reasons, one of
which is details in the 'Big Orange Book' (game architecture & design) about
how each department of your project team should be responsible to the other
almost as they would external clients.

meaning that the programmers provide documentation for their releases,
provide reasonable examples & samples of how to implement the various
features.  in turn the designers provide detailed 'use cases' that help the
programmers implement the various features.  cycle ad nauseum.

instead of being teams that 'work against each other' as programmers &
artists seem to naturally, you create defined boundaries & expectations for
your work.  the programmers work should not be affected by the designers,
and vice versa, yet allowing for concrete lines of communication...

(who said that everything ends up being about management? ;)

cheers,

mike w
www.uber-geek.ca


----- Original Message -----
From: "Jamie Fowlston" <ja...@qu...>
To: <gam...@li...>
Sent: Tuesday, December 10, 2002 5:30 AM
Subject: RE: [GD-General] Scripting


> i think one key point that hasn't been touched on (enough? :) yet is that
> the scripting language (whether data definition, a full language, or
> whatever) should be appropriate to the people who will use it.
>
> some designers can think like a coder. some can't. similarly with artists.
> if you pitch the scripting at the appropriate level, it will work great.
> this is my main complaint with generic scripting systems: they've been
> designed at a particular level of complexity, and that simply can't be
> appropriate for every user.
>
> jamie
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> mike wuetherick
> Sent: 10 December 2002 03:55
> To: gam...@li...
> Subject: Re: [GD-General] Scripting
>
>
> > My instinct is that a scripting language as an "extension" (vs. "as
> > data") seems ill advised at times, because you kind of have
> > responsibilities that are mixed and often poorly defined.  Using it as
> > your primary application language means it's no longer "scripting", it's
> > just the language you happen to be developing in and you're now calling
> > into a separate native engine for system specific tasks.  That seems
> > completely reasonable if you feel the language itself is much more
> > productive than C or C++ or whatever.
>
> good point, didn't see the difference initially.
>
> the way things have worked generally is that they start out as simple
> 'entities' (which are simple structs that have custom pragmas that the
> editor recognizes, providing public and private data for this particular
> entity (private data is used by the game engine on runtime, public is
> exposed to the level designer as the entities properties) that the
designer
> can drop into their levels (lights, etc) and if the complexity of the
> feature becomes too unwieldy to edit via entities (as adding many of a
> similar entity can become), then that functionality is moved into
scripting.
>
> for example, the players in-game actions are currently read in via an ini
> file - there are basic 'set' actions that the player can do, essentially a
> reference to an animation & that's about it.  this is being updated to
> provide links to scripts (or functions within one) that will allow for
more
> complicated actions (all custom-created by the designer without needing to
> recompile the engine) such as special moves, animated camera motions
during
> specific in-game actions (pull off a special finishing move & trigger a
> flyby camera sequence), etc...
>
> of course, certain features are scriptable by default as well, and
anything
> simpler is left as entities.  the combinations seems to work well &
provides
> an extremely good range of possiblities for the designer.
>
> cheers,
>
> mike w
> www.uber-geek.ca
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

RE: [GD-General] Compile times

[Chris C. <chr...@l8...>]

> would you do it? _Has_ anyone actually done it (e.g. even if only for
> internal tools)? I'd love to hear about the build times for 
> large(-ish)
> Java or C# projects, for example.

not related to GD, but jikes can compile our 1MB source code webapp in under
4 seconds
(wouldnt want to use javac though)

ChrisC

Re: id and Obj-C was RE: Paradigms was [GD-General] Compile times/scripting/oop

[BG <arc...@ma...>]

On Tuesday, December 10, 2002, at 04:22  PM, Brian Hook wrote:

>> wasn't most of Id's early stuff written in Obj-C?
>
> The arrival of MacOS X and Cocoa hasn't changed anything, because I
> believe most of their tools are now either commadline or integrated  
> into
> the engine itself.
>
> Brian

Well pretty much any game that Omni ports will have some amount of  
Obj-C within, although not entirely written in it...


------------------------------------------------------------------------ 
--------------------------
Copyright 2002 archie4oz email -- End User Licensing Agreement -- By  
reading the above post you grant archie4oz (email author of said listed  
party name) the right to take your money, eat your cat, and urinate on  
your house. In addition you give archie4oz (above mentioned) the right  
to use your sister in anyway he sees fit. If you do not agree to these  
terms then DO NOT READ the above email.

Re: Paradigms was [GD-General] Compile times/scripting/oop

[<cas...@ya...>]

mike wuetherick wrote:
> >Are there any games written in Obj-C?
>
> wasn't most of Id's early stuff written in Obj-C?  i recall an article
where
> John Carmack was lamenting the fact that Id stopped using it at some point
> (for quake and later games i think?)

Yep, the QuakeEd editor was a  NEXTSTEP application and was written in
Obj-C, the other tools were plain C.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Sorteos
Consulta si tu número ha sido premiado en
Yahoo! Sorteos http://loteria.yahoo.es

id and Obj-C was RE: Paradigms was [GD-General] Compile times/scripting/oop

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

> wasn't most of Id's early stuff written in Obj-C?

Only the tools.  DoomEd and QuakeEd were written in Obj-C, but the games
were pure ANSI C.  They didn't convert to C++ until Doom3, and I'm not
sure how that's going.

At some point QuakeEd got ported to C to run under Windows.  They had to
move to C because there was no OpenGL bindings available for Obj-C at
the time -- NeXT was busy pushing RenderMan as their graphics API.

Because John wanted/needed to start looking at hardware acceleration on
NT, he was pretty much left with no choice but to move to C in order to
use OpenGL under NT.  After the move was made, Obj-C was pretty much a
non-issue because NeXT ceased to be relevant (at the time of QuakeEd you
could still get OpenStep machines no x86 and PA-RISC).

The arrival of MacOS X and Cocoa hasn't changed anything, because I
believe most of their tools are now either commadline or integrated into
the engine itself.

Brian

Obj-C was RE: Paradigms was [GD-General] Compile times/scripting/oop

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

> I've recently learned Obj-C, and completely agree with you, 
> it's a great language. So, why don't use it as primary 
> language? You can still do all the low level code in C and in 
> the game code the small overhead of the messaging is acceptable.

If my target audience was the Mac, I'd use it in a heartbeat.  The main
reasons why it's not practical for me is that I have to give up too many
good tools in order to use it.  Sad, but true -- the productivity
increase from having a great language aren't made up for by the lack of
a quality IDE, quality build tools, quality debugger, etc.

Also, it's not a "ratified" language, so there are numerous variants of
it floating around.  GCC's is the default, but I think Apple doesn't
even use GCC, they fork their own copy and then make their own versions.

Finally, one of the reasons that Obj-C is so powerful is that the
toolkits available for it are incredible.  Anyone who has developed a
GUI app using Interface Builder and Cocoa/AppKit knows exactly what I'm
talking about.  It's actually FUN putting together an interface.  I'm in
awe of how much better it is for GUI development compared to something
like Java/Swing or (ick) MFC/C++.  Night and day.  GNUStep is supposedly
coming along "pretty well", but it still has some key differences from
Cocoa, and right now I think Apple is disinclined to make Cocoa/Obj-C
available off of OS X because that's one of the few competitive
advantages they can tout to developers (at least, to developers willing
to learn it).

My first OpenGL app under Cocoa took a few hours to get up and running,
and that's with me simultaneously learning Cocoa, the Cocoa OpenGL
class, Objective-C and an entirely new development environment
(ProjectBuilder).

I can now prototype and throw together an OpenGL app under Obj-C, with
full toolbars, etc. in a matter of 30 minuets.  For hacking
visualization apps and tools, nothing comes close.

> Are there any games written in Obj-C?

I've actually heard that several MUDs have been written in Obj-C because
it lends itself so well to that type of universe.  Because of Obj-C's
ability to dynamically load not just code but entirely new classes off
disk, you can keep a MUD up and running and take down/replace/augment
selective parts of it.

Brian

Re: Paradigms was [GD-General] Compile times/scripting/oop

[mike w. <mi...@ub...>]

>Are there any games written in Obj-C?

wasn't most of Id's early stuff written in Obj-C?  i recall an article where
John Carmack was lamenting the fact that Id stopped using it at some point
(for quake and later games i think?)

cheers

mike w
www.uber-geek.ca

Re: Paradigms was [GD-General] Compile times/scripting/oop

[<cas...@ya...>]

Brian Hook wrote:
> system, e.g. Obj-C vs. C++ (actually, not entirely fair -- Obj-C
> encourages static type checking but doesn't require it, another reason
> why it's The Greatest LANGWIJ EVAR!).

I've recently learned Obj-C, and completely agree with you, it's a great
language. So, why don't use it as primary language? You can still do all the
low level code in C and in the game code the small overhead of the messaging
is acceptable.

GCC is an obj-c compiler, and it's also available on mingw for win32. The
obj-c compiler is almost a preprocessor, obj-c code is internally translated
to pure C, so the code generation should be as good as in C. Are there any
games written in Obj-C?


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Sorteos
Consulta si tu número ha sido premiado en
Yahoo! Sorteos http://loteria.yahoo.es

RE: Paradigms was RE: [GD-General] Compile times/scripting/oop

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

If by "paradigms" you mean OOP vs. procedural/imperative vs. functional
vs. logic, I think there are some pretty good comparisons of these on
the net.  There's also the issue of static vs. dynamic typing in an OOP
system, e.g. Obj-C vs. C++ (actually, not entirely fair -- Obj-C
encourages static type checking but doesn't require it, another reason
why it's The Greatest LANGWIJ EVAR!).

http://www.cs.williams.edu/~andrea/cs373/Lectures/lecture5-6.pdf


-Hook

Paradigms was RE: [GD-General] Compile times/scripting/oop

[Evan H. <eh...@at...>]

  This discussion has gotten me interested in whether anyone knows of a good
comparative reference on programming paradigms and so forth. I have recently
been looking to broaden my set of tools, especially for working on pet
projects. 

  Most books on the subject seem to be actively selling a particular
language or paradigm as a one-size fits all hammer. I am a pretty firm
believer that not-all paradigms fit all tasks equally well.

  -Evan

OOP was RE: [GD-General] Compile times

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

> Learning OO design with Eiffel and Modula2 probablyhelped, too.

Definitely.  The problem is that I had learned really basic procedural C
and then immediately hopped over to C++ back when C++ was the new "it"
language.  In fact, I was at the local college bookstore before it
opened when I knew they got in their first shipment of Borland C++ 1.0,
the first C++ compiler for the PC that wasn't hideously expensive (prior
to that you had to use cfront, g++ didn't exist yet -- and if you wanted
to use cfront, you had to be on a Unix system).

So my introduction to OOP came directly from learning C++ via Stroustrup
and Lippman, and that imposed a ton of bad habits from day one.
Specifically, it imposed no habits, because of C++'s strong
philosophical belief that "there's no right way to do OOP".  So given a
syntax and some general guidelines, I marched on from there.

If I had started with something with a lot stronger philosophy about
programming, such as Objective-C, SmallTalk, Eiffel, etc. I would have
had at least some context when learning.  As it were, I just was kind of
winging it, and this was before there was a lot of documentation on
"proper" OOP. 

And, of course, the concepts of "proper OOP" have changed drastically
over the past 10 years.

Using Objective-C has greatly cleaned up a lot of my code structure, but
at the same the inability to carry over parts of Obj-C to C++ is
incredibly frustrating.  Most of it is doable in ways I don't find
appealing (interfaces-via-MI), but it's still doable.

Brian

Re: [GD-General] Compile times

[Javier A. <ja...@py...>]

brian hook <bri...@py...> wrote:

> So if anything, my problem is that I've used C++ too much because the
> language and its "proper" usage has shifted massively over the past
> decade+.

That's interesting. In contrast, I believe I haven't changed my approach to
code design that much from the way I used to back in Z80 assembler times. I
was using function pointers to handle game entities (and behavior states)
polymorphically, so there you go. Of course the tools have changed, the
style has evolved and new techniques have been added to account for large
projects, but the overall idea isn't much different.

Learning OO design with Eiffel and Modula2 probablyhelped, too.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] Compile times

[brian h. <bri...@py...>]

> I believe this has more to do with your experience in both languages 
> than anything else. You've huge experience writing C code, but (from 
> what I can infer) little experience working with large C++ codebases. 

That's not actually the case, I have significantly more time using C++ 
than C actually -- I started coding in C++ in 1989 and didn't actually 
switch "back" to ANSI C until 1995, then I switched back to C++ in 1999.

The problem is that I've used and "survived" C++ through several 
different shifts in conventional idiomatic usage.  When I first started 
using C++, inheritance was all the rage and templates didn't exist.  
You were supposed to use private inheritance to inherit an 
implementation and public inheritance to inherit an interface and/or 
implementation.  Then sometime in the late 90s, inheritance was moving 
away from popularity and it was time to switch to using generics (and 
you were now expected to use exceptions and RTTI was becoming 
formalized).  Except that no compiler had competent template 
implementations, and even today, MSVC 7 doesn't have partial template 
specialization.

So if anything, my problem is that I've used C++ too much because the 
language and its "proper" usage has shifted massively over the past 
decade+.

> What's worse, C++ can be badly used in more varied and obscure ways 
> than C or other simpler languages, and some design philosophies even 
> encourage these uses.

This is quite true, and if I had to list one single reason why C++ code 
across the board is a disaster, it would be this: there are no 
generally accepted idiomatic usage patterns for even the most basic 
things.  Every aspect of the language may or may not be used by a 
programmer, and you can have one person do it "right" and another 
person do it "right" and both of them completely and utterly not 
understand what the other is doing.

There are valid reasons to use multiple inheritance, templates, 
exception handling, operator overloading, STL, private inheritance, 
default arguments, non-virtual functions, factory methods with 
protected constructors/destructors, etc.  But there are also many valid 
reasons not to, and a lot of it boils down to philosophy.  Because C++ 
tried so hard to be philosophically agnostic, there is no right/wrong 
way.

Contrast this to a language like Eiffel, Objective-C or SmallTalk, 
where idioms WERE established, and those languages have a very clean 
feel to them compared to C++.  You understand what one person's Obj-C 
is supposed to be doing, whereas decoding another person's Obj-C is 
completely hit/miss depending on the amount of time you have and how 
much effort they spent into cleaning up their code.

Two pretty good books on these subjects: Objects Unencapsulated 
(written by a guy that likes Eiffel, but it's still a damn good take on 
modern OO languages) and Introduction to Object Oriented Programming by 
Timothy Budd.  The latter feels extremely unbiased and is also a good 
overview.

I don't actually have very deep hierarchies.  In fact, I think the 
deepest I have anywhere is three, but I'm not even sure I have one that 
deep.  The dependencies are due to aggregation and actual usage -- for 
example, my HPuzzleGame class probably uses about 20-30 different 
classes.  And some classes are implemented on assumptions about how 
other classes operate (yes, this breaks all manner of OOP, but 
unfortunately in the real world you don't know what you're abstracting 
until you're done writing code -- that's why going back and refactoring 
is so important).

Brian

Re: [GD-General] Compile times

[Pierre T. <p.t...@wa...>]

>Out of curiousity, what's the general size of your codebase?

My personal codebase :

767 .h files, 3.3 Mb
719 .cpp files, 9.6 Mb

Full rebuild in 4:05 according to MSVC's /y3 option.

- 1Ghz Athlon, 256 Mb ram
- No STL
- Very few templates
- No RTTI / Exceptions, but C++ otherwise (multiple inheritance, etc)
- Cut in 19 DLLs and a main app (exe)
- Almost all headers in the PCH (I know it's bad but I don't care in my
case)

It was much much slower on my previous machine (500 Mhz Celeron with less
ram). It definitely makes a difference for compile times.

Pierre

RE: [GD-General] Scripting

[Awen L. <ali...@ed...>]

One Point for Jamie.
Further thought: the (scripting) language complexity may have some ugly
impacts on the overall (potential) game scripting complexity. Subtle, but
that's probably the reason why all the script engine i knew were dedicated
to one project and forgotten for the next: appropriate for its purpose
(serving The Game) and its users. 2 good reasons for dedicating code.
Awen

-----Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
Jamie Fowlston
Envoyé : mardi 10 décembre 2002 14:31
À : gam...@li...
Objet : RE: [GD-General] Scripting


i think one key point that hasn't been touched on (enough? :) yet is that
the scripting language (whether data definition, a full language, or
whatever) should be appropriate to the people who will use it.

some designers can think like a coder. some can't. similarly with artists.
if you pitch the scripting at the appropriate level, it will work great.
this is my main complaint with generic scripting systems: they've been
designed at a particular level of complexity, and that simply can't be
appropriate for every user.

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
mike wuetherick
Sent: 10 December 2002 03:55
To: gam...@li...
Subject: Re: [GD-General] Scripting


> My instinct is that a scripting language as an "extension" (vs. "as
> data") seems ill advised at times, because you kind of have
> responsibilities that are mixed and often poorly defined.  Using it as
> your primary application language means it's no longer "scripting", it's
> just the language you happen to be developing in and you're now calling
> into a separate native engine for system specific tasks.  That seems
> completely reasonable if you feel the language itself is much more
> productive than C or C++ or whatever.

good point, didn't see the difference initially.

the way things have worked generally is that they start out as simple
'entities' (which are simple structs that have custom pragmas that the
editor recognizes, providing public and private data for this particular
entity (private data is used by the game engine on runtime, public is
exposed to the level designer as the entities properties) that the designer
can drop into their levels (lights, etc) and if the complexity of the
feature becomes too unwieldy to edit via entities (as adding many of a
similar entity can become), then that functionality is moved into scripting.

for example, the players in-game actions are currently read in via an ini
file - there are basic 'set' actions that the player can do, essentially a
reference to an animation & that's about it.  this is being updated to
provide links to scripts (or functions within one) that will allow for more
complicated actions (all custom-created by the designer without needing to
recompile the engine) such as special moves, animated camera motions during
specific in-game actions (pull off a special finishing move & trigger a
flyby camera sequence), etc...

of course, certain features are scriptable by default as well, and anything
simpler is left as entities.  the combinations seems to work well & provides
an extremely good range of possiblities for the designer.

cheers,

mike w
www.uber-geek.ca



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557