gamedevlists-general — List for discussing general game development issues

RE: [GD-General] what you look for in a physics engine coder...engine transaction

[Stefan B. <Ste...@di...>]

   I wouldn't hire a physics programmer to write a next-generation =
physics engine. I would hire a physics programmer to make use of a =
middleware physics engine such as Meqon or Havok, since it would be near =
impossible to compete with them by starting from scratch. Also it's not =
clear what advantage you get from building your own.
=20
   As for prices of turnkey engines... It varies greatly, and it's =
usually negotiable assuming the deal is interesting to the licensor. =
Also, the price depends on how many SKUs you intend to produce. Nowadays =
more and more middleware providers work exclusively with publishers, so =
it may be difficult to even evaluate an engine without having a =
publisher in the first place.
=20
   Physics engines range from $0 up to $200k, but again it's negotiable =
and highly dependent on who you are, what you intend to do and who your =
publisher is. The more capable products also cost more - you get what =
you pay for not just in terms of functionality but also support (which =
is crucial).
=20
/Stefan

________________________________

From: gam...@li... on behalf of =
CAVEY GERARD
Sent: Mon 7/19/2004 4:53 PM
To: 'gam...@li...'
Subject: [GD-General] what you look for in a physics engine =
coder...engine transaction



Hi

My question is a bit OT but anyway ...
when you give someone the job to write the next generation
physics engine, what profiles do you look for?I m not sure a basic =
engineer
can fit the task.
Any experience with it ?
IMO nowadays we can no longer fake physics (for actions titles).

Second OT question what could be the price of a "good enough" 3D engine =
plus
the surrouding tools
+ plugins for 3d apps?
I heard the Quake3 engine cost was 500 000$ ,but this is (was ,domm3 is
going to bury it )
a ground breaking technology i know ...
And the price of a "good enough" physics engine?
When you sell such a technology how does it work? Do you have to sell =
some
support,
patchs,consulting ....?

Thanks in advance

GC.


*************************************************************************=

Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration.
SG Asset Management et ses filiales declinent toute responsabilite au =
titre
de ce message s'il a ete altere, deforme ou falsifie.

D=E9couvrez l'offre et les services de SG Asset Management sur le site
www.sgam.fr

                                ********

This message and any attachments (the "message") are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration. =20
Neither SG Asset Management nor any of its subsidiaries or affiliates =
shall
be liable for the message if altered, changed or falsified.

*************************************************************************=






-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

RE: [GD-General] what you look for in a physics engine coder...engine transaction

[Jamie F. <ja...@qu...>]

oh, and also some appreciation of things which currently aren't truly
realtime, but are getting there. Fluid dynamics, finite element analysis,
etc....

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jamie Fowlston
Sent: 19 July 2004 16:29
To: gam...@li...
Subject: RE: [GD-General] what you look for in a physics engine
coder...engine transaction


I won't attempt to answer the second question, although there seem to be =
a
number of reasonably good free physics engines out there :)

Re. things to look for in a physics coder, off the top of my head:

Necessary:

- I would want someone who had done it before. They would have to have
shipped a title with their physics in, or at the very least done _very_
convincing demos.
- Very strong maths (at least degree level).
- Ability to handle numerical accuracy issues (in practice, not just in
theory).
- An awareness of the general methods that get used in collision detectio=
n
(e.g. broad phase collision detection systems (i.e. all sorts of spatial
partitioning), narrow phase collision detection systems (primitive v.
primitive, understanding of the double dispatch problem, GJK, Minkowksi
sums, etc.))
- An awareness of the general methods that get used in collision resoluti=
on
(impulse methods, penalty methods, LCP, general numerical solvers and
degrees of freedom).
- An awareness of the research that's out there (e.g. Mirtich, Baraff, et=
c.)
- An understanding of the problem areas (e.g. stacking, coming to rest,
etc.)

Nice to have:

- Implemented physics in at least two significantly different ways.
- Familiarity with physics middleware.


Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
CAVEY GERARD
Sent: 19 July 2004 15:53
To: 'gam...@li...'
Subject: [GD-General] what you look for in a physics engine
coder...engine transaction


Hi

My question is a bit OT but anyway ...
when you give someone the job to write the next generation
physics engine, what profiles do you look for?I m not sure a basic engine=
er
can fit the task.
Any experience with it ?
IMO nowadays we can no longer fake physics (for actions titles).

Second OT question what could be the price of a "good enough" 3D engine p=
lus
the surrouding tools
+ plugins for 3d apps?
I heard the Quake3 engine cost was 500 000$ ,but this is (was ,domm3 is
going to bury it )
a ground breaking technology i know ...
And the price of a "good enough" physics engine?
When you sell such a technology how does it work? Do you have to sell som=
e
support,
patchs,consulting ....?

Thanks in advance

GC.


*************************************************************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration.
SG Asset Management et ses filiales declinent toute responsabilite au tit=
re
de ce message s'il a ete altere, deforme ou falsifie.

D=E9couvrez l'offre et les services de SG Asset Management sur le site
www.sgam.fr

				********

This message and any attachments (the "message") are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration.
Neither SG Asset Management nor any of its subsidiaries or affiliates sha=
ll
be liable for the message if altered, changed or falsified.

*************************************************************************





-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

RE: [GD-General] what you look for in a physics engine coder...engine transaction

[Jamie F. <ja...@qu...>]

I won't attempt to answer the second question, although there seem to be =
a
number of reasonably good free physics engines out there :)

Re. things to look for in a physics coder, off the top of my head:

Necessary:

- I would want someone who had done it before. They would have to have
shipped a title with their physics in, or at the very least done _very_
convincing demos.
- Very strong maths (at least degree level).
- Ability to handle numerical accuracy issues (in practice, not just in
theory).
- An awareness of the general methods that get used in collision detectio=
n
(e.g. broad phase collision detection systems (i.e. all sorts of spatial
partitioning), narrow phase collision detection systems (primitive v.
primitive, understanding of the double dispatch problem, GJK, Minkowksi
sums, etc.))
- An awareness of the general methods that get used in collision resoluti=
on
(impulse methods, penalty methods, LCP, general numerical solvers and
degrees of freedom).
- An awareness of the research that's out there (e.g. Mirtich, Baraff, et=
c.)
- An understanding of the problem areas (e.g. stacking, coming to rest,
etc.)

Nice to have:

- Implemented physics in at least two significantly different ways.
- Familiarity with physics middleware.


Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
CAVEY GERARD
Sent: 19 July 2004 15:53
To: 'gam...@li...'
Subject: [GD-General] what you look for in a physics engine
coder...engine transaction


Hi

My question is a bit OT but anyway ...
when you give someone the job to write the next generation
physics engine, what profiles do you look for?I m not sure a basic engine=
er
can fit the task.
Any experience with it ?
IMO nowadays we can no longer fake physics (for actions titles).

Second OT question what could be the price of a "good enough" 3D engine p=
lus
the surrouding tools
+ plugins for 3d apps?
I heard the Quake3 engine cost was 500 000$ ,but this is (was ,domm3 is
going to bury it )
a ground breaking technology i know ...
And the price of a "good enough" physics engine?
When you sell such a technology how does it work? Do you have to sell som=
e
support,
patchs,consulting ....?

Thanks in advance

GC.


*************************************************************************
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration.
SG Asset Management et ses filiales declinent toute responsabilite au tit=
re
de ce message s'il a ete altere, deforme ou falsifie.

D=E9couvrez l'offre et les services de SG Asset Management sur le site
www.sgam.fr

				********

This message and any attachments (the "message") are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration.
Neither SG Asset Management nor any of its subsidiaries or affiliates sha=
ll
be liable for the message if altered, changed or falsified.

*************************************************************************





-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

[GD-General] what you look for in a physics engine coder...engine transaction

[CAVEY G. <GER...@sg...>]

Hi

My question is a bit OT but anyway ...
when you give someone the job to write the next generation
physics engine, what profiles do you look for?I m not sure a basic =
engineer
can fit the task.
Any experience with it ?
IMO nowadays we can no longer fake physics (for actions titles).

Second OT question what could be the price of a "good enough" 3D engine =
plus
the surrouding tools
+ plugins for 3d apps?
I heard the Quake3 engine cost was 500 000$ ,but this is (was ,domm3 is
going to bury it )
a ground breaking technology i know ...
And the price of a "good enough" physics engine?
When you sell such a technology how does it work? Do you have to sell =
some
support,
patchs,consulting ....?

Thanks in advance

GC.


************************************************************************=
*
Ce message et toutes les pieces jointes (ci-apres le "message") sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.=20
Tout message electronique est susceptible d'alteration.=20
SG Asset Management et ses filiales declinent toute responsabilite au =
titre
de ce message s'il a ete altere, deforme ou falsifie.

D=E9couvrez l'offre et les services de SG Asset Management sur le site
www.sgam.fr=20

				********

This message and any attachments (the "message") are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.=20
E-mails are susceptible to alteration.  =20
Neither SG Asset Management nor any of its subsidiaries or affiliates =
shall
be liable for the message if altered, changed or falsified.=20

************************************************************************=
*

Re: [GD-General] Problem Breakdown

[Brett B. <res...@ga...>]

> One technique we use is what's called a sticky note meeting.

We have used this same technique and found it really handy too.  The only
problem with it I have found is that it presumes everyone has the same level
of understanding of the problem (as you mentioned).  I'm leading a foreign
team and although the team's English is good, the combination of English as
a second language and different terminology for certain programming algos,
constructs, etc. sometimes conspires against us.

> Sticky note meetings are not meant to replace the low-level design. You
> say "Rational Rose stuff" and UML are too high-level, but neither of
> these assumes a levelness. UML is perfectly suitable to designing "Hello
> World", a linked list, or a resource manager; just like a nuke is good
> at killing things of all sizes, these tools work for all problem sizes.

I guess what I meant to say is that when considering a problem with a clean
sheet of paper these tools make some assumptions you know you want to create
a "hello world" application.  Maybe what I meant was actually
"inappropriate"?

> 1) high level task analysis done via group effort sticky note meeting. A
> basic feature document must be pre-existing with a prioritized feature
> set on a scale of 1-4 (1 won't ship without, 2 very important, 3 would
> be nice, 4 can live without).
> 2) mid and low level task analysis done by a single engineer (research,
> prototypes, pre-existing solutions). Result is the design, a design
> worthy of being estimated and implemented
> 3) estimation
> 4) group review and sanity check
> 5) schedule created including milestones
>

Can this process simultaneously handle things like AI, geometry handling,
shader management, batching of stuff, cache managment, networking, time,
etc., etc. always seem to creep into any discussion we have about anything
in the game.  How do people breakdown these complex problems and assess the
tradeoffs and impact in implementation?  I'm finding it tough to do in a
team environment.

Re: [GD-General] Problem Breakdown

[Mike <mi...@ge...>]

> At 11:43 PM 7/12/2004, Brett Bibby wrote:
>> Is it common to look at _all_ ways to solve a complicated problem before
>> determining a solution?  Or do most people just pick a solution that gets
>> them going and refactor later? Or?

my 2 bits on the topic, i'm starting the process of doing a 'version 2' 
of our game engine, and have been going through these same types of 
questions myself.

i don't think you can necessarily think of ALL of the ways to implement 
a particular system or attack a particular problem, and even if you 
could, you run dangerously close to the 'research' side of software 
development, and research is necessarily open-ended, and does not fit 
nicely into releaseable software and game schedules.

you do need to consider reusability, if the engine in particular is 
being designed to last multiple projects (which i would assume most 
engines are these days).  This is probably becoming more of an issue as 
we move forward, since the time to rewrite an entire technology tree 
from the ground up is becoming so much more involved.

with our engine, every feature that is added to the engine must be 
considered from the aspect of reuseability - if it's something that 
changes the basic player movement system, then make it so that we can 
disable it just as easily.  it doesn't take much extra effort to provide 
this kind of customizability up-front, but from the sheer number of 
options that you provide the designer, documentation becomes a major 
issue (which we are constantly battling).

however, the engine in question is specifically a multi-genre game 
creation 'system' more than an engine for a specific game tailored from 
ground up for only that one game.

refactoring is inevitable we've found over the years of assembling the 
engine.  often a feature appears first as a simple entity with a few 
options to manipulate, and then if it evolves further, may get moved 
into the scripting api or config files, usually to make it easier for 
the designer to edit & reuse throughout a game.

from the programmers perspective, you will never think of all the 
possible ways that the designers are going to try and use the features 
that you give to them - they will undoubtedly come up with new and crazy 
ways to combine different elements in ways that you would never have 
thought up.  in situations like these, refactoring may well be required. 
  it's not a bad thing, but make sure that the changes you are making 
help expand the reusability of the engine, not reduce it.

-- 
Mike Wuetherick
Gekido Design Group Inc
www.gekidodesigns.com

RE: [GD-General] Problem Breakdown

[Johnson, J. <Jam...@si...>]

One technique we use is what's called a sticky note meeting. Basically
it's a meeting of engineers (though may included other interested
parties) with the goal of breaking down features into high-level tasks.
Its called a sticky note meeting because we jot down the tasks on sticky
notes and paste them to a large wall. The process is informal, everyone
is encouraged to contribute, all ideas are recorded regardless of how
brilliant or dumb they may seem. The result of this meeting should be a
fairly good representation of the tasks and task boundaries required for
a feature. It will most likely not be complete, but should be good
enough such that a single engineer can fill in the remaining details
with some investigation.

Sticky note meetings work well when the group of engineers participating
understand the problem domain. They are also a good means of
distributing knowledge within an organization. If your organization has
multiple teams then chances are you've got more than 1 AI 'expert' to
help you break down the problem. If your organization is small then you
might be surprised how many engineers have dabbled in AI. These
engineers may give insight to your problem.=0D

Sticky note meetings are not meant to replace the low-level design. You
say "Rational Rose stuff" and UML are too high-level, but neither of
these assumes a levelness. UML is perfectly suitable to designing "Hello
World", a linked list, or a resource manager; just like a nuke is good
at killing things of all sizes, these tools work for all problem sizes.=0D

Sticky note meetings are not helpful when the problem is not well
understood. For this I prefer standard research tools, e.g. books,
prototypes, and examination similar pre-existing solutions (chances are
someone somewhere has already solved your problem). If a problem can
easily be prototyped I'll always do a prototype (or 2 or 3) to develop a
better understanding of the problem and potential solutions. The result
of prototyping often allows me to create a design that can encapsulate a
number of potential solutions should I run into some unforeseen
circumstance later in development. Its important for me to emphasize
that last sentence because that is how I manage risk in my own
development process.

No one looks at all the ways to solve a problem.

In summary:

1) high level task analysis done via group effort sticky note meeting. A
basic feature document must be pre-existing with a prioritized feature
set on a scale of 1-4 (1 won't ship without, 2 very important, 3 would
be nice, 4 can live without).
2) mid and low level task analysis done by a single engineer (research,
prototypes, pre-existing solutions). Result is the design, a design
worthy of being estimated and implemented
3) estimation
4) group review and sanity check
5) schedule created including milestones




James


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Brett Bibby
Sent: Monday, July 12, 2004 8:44 PM
To: Gam...@li...
Subject: [GD-General] Problem Breakdown

I've noticed that with the increased complexity next-generation games
that my old ways of breaking down gameplay features and turning that
into a technical design seem to be lacking, or at least far more
difficult than it used to be.  When searching, most of the results are
perhaps too low-level in recommending various C++ "patterns", general
OOP principles, etc. or too high-level like Rational Rose stuff, UML
use-case diagrams etc.

My question is, given a problem (or feature to be implemented) what
methodolgies or techniques have proven useful to break down the problem
and detemine how to technically solve it?

The best example I have at the moment is implementing the AI for our
current game.  The are so many ways to look at the problem: I could
break it down into state machines, messaging, use-case, etc.  But each
one while excelling at some portion of the solution, also has a number
of problems.  Also, it involves an awful lot of people with different
skill sets: who will do the level AI markup? Path generation? Behavior
specification? Rules? Animation control? AI debugging method? Scripting
integration?

So you have a problem that slices across the company in terms of
departments/pipeline (horizontal), and also one is multi-layered
(vertical) in terms of features like goal determination, planning,
path-finding, steering, animation state, etc. that could be split up by
members within a team.

Is it common to look at _all_ ways to solve a complicated problem before
determining a solution?  Or do most people just pick a solution that
gets them going and refactor later? Or?

Thanks.



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
self defense, top technical experts, no vendor pitches, unmatched
networking opportunities. Visit www.blackhat.com
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557



----------------------------------------------------
Vivendi Universal Games- <<http://www.vugames.com>>:=0D
The information transmitted is intended only for the=0D
person or entity to which it is addressed and may=0D
contain confidential and/or privileged material of=0D
Vivendi Universal Games which is for the exclusive=0D
use of the individual designated above as the=0D
recipient. Any review, retransmission, dissemination=0D
or other use of, or taking of any action in reliance=0D
upon, this information by persons or entities other=0D
than the intended recipient is prohibited. If you=0D
received this in error, please contact immediately=0D
the sender by returning e-mail and delete the=0D
material from any computer. If you are not the=0D
specified recipient, you are hereby notified that=0D
all disclosure, reproduction, distribution or action
taken on the basis of this message is prohibited.

Re: [GD-General] Problem Breakdown

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

At 11:43 PM 7/12/2004, Brett Bibby wrote:
>I've noticed that with the increased complexity next-generation games that
>my old ways of breaking down gameplay features and turning that into a
>technical design seem to be lacking, or at least far more difficult than it
>used to be.



>My question is, given a problem (or feature to be implemented) what
>methodolgies or techniques have proven useful to break down the problem and
>detemine how to technically solve it?


>Is it common to look at _all_ ways to solve a complicated problem before
>determining a solution?  Or do most people just pick a solution that gets
>them going and refactor later? Or?

I consider myself a pretty good "big systems" guy. I worry about the 
architecture at the macro scale, and try to hire people who are better than 
I am at getting the details right.

I'm a huge fan of Implement, Refactor, Refine. I think there's so much 
learning that goes on during the course of a project. Not just learning new 
techniques or the way you're doing scripting, but learning about what 
really matters in your gameplay, and deciding that you can get a lot of 
mileage from a new UI paradigm you just invented. Consequently, I think 
it's counterproductive to try to sit down and design out a whole product in 
advance. You're cutting off huge swaths of what you might be able to learn.

The eXtreme Programming folks are fond of the acronym "YAGNI" -- you ain't 
gonna need it. Their concept is that you implement The Simplest Thing That 
Could Possibly Work and then improve it only if you need to. I don't go 
quite that far. A good dose of experience and/or common sense should help 
you figure out a reasonable guess as to how much is likely to be enough. 
Why build the wrong data structure if you know it'll be wrong?

The key, though, is understanding when you've underimplemented and taking 
the time to FIX it, not just patch it. That's a strategy that's hard for 
some managers to take. "What did you do today?" "I deleted 300 lines from 
the codebase and left it doing the exact same job!" "So you're saying 
you're wasting time?"

In fact, this whole strategy also sort of depends on my ability to convince 
people that the project is under control. Or being the one in charge in the 
first place.

So...do I look at all ways of solving a complicated problem? Well...I would 
say I probably consider MANY ways of solving a complicated problem, but 
most of them are rejected quite early. Sometimes I'll do experiments to 
test feasibility.

Another phrase that applies, though, is "The best is the enemy of the 
good." Far better to have a suboptimal solution that ships than an optimal 
one in the lab. Unless, of course, the suboptimal one hurts the product.

One of the reasons I like the game industry is that you have to get it 
*all* to beyond "good enough". You can't create a functional tool with a 
bad UI that people buy anyway because there's nothing better. It's 
entertainment. They only buy it if they like it, so you'd better make sure 
they like it.

In the end, it's all about managing risk. You spend your design time on the 
areas that are highest risk, and take shortcuts on areas where you know or 
can guess the right answer. And then polish, polish, polish.

         Kent








----
Kent Quirk
CTO, CogniToy

[GD-General] Problem Breakdown

[Brett B. <res...@ga...>]

I've noticed that with the increased complexity next-generation games that
my old ways of breaking down gameplay features and turning that into a
technical design seem to be lacking, or at least far more difficult than it
used to be.  When searching, most of the results are perhaps too low-level
in recommending various C++ "patterns", general OOP principles, etc. or too
high-level like Rational Rose stuff, UML use-case diagrams etc.

My question is, given a problem (or feature to be implemented) what
methodolgies or techniques have proven useful to break down the problem and
detemine how to technically solve it?

The best example I have at the moment is implementing the AI for our current
game.  The are so many ways to look at the problem: I could break it down
into state machines, messaging, use-case, etc.  But each one while excelling
at some portion of the solution, also has a number of problems.  Also, it
involves an awful lot of people with different skill sets: who will do the
level AI markup? Path generation? Behavior specification? Rules? Animation
control? AI debugging method? Scripting integration?

So you have a problem that slices across the company in terms of
departments/pipeline (horizontal), and also one is multi-layered (vertical)
in terms of features like goal determination, planning, path-finding,
steering, animation state, etc. that could be split up by members within a
team.

Is it common to look at _all_ ways to solve a complicated problem before
determining a solution?  Or do most people just pick a solution that gets
them going and refactor later? Or?

Thanks.

Re: [GD-General] Clean way of generalizing CDECL

[Jeremy V. <mad...@gm...>]

Hey guys,

The way I would choose, which is easy on the eyes, is to always define
__cdecl functions with both, and then have defines that eliminate one
syntax or the other depending on the platform. Such as:

#ifdef WIN32
# define __attribute(x) 
#else
# define __cdecl 
#endif

int __cdecl myFunction(double whatever) __attribute((cdecl));

Actually, this is the same as Brian's CDECL_PRE and CDECL_POST - so I
should probably just stick to lurking :p

Re: [GD-General] Clean way of generalizing CDECL

[Brian H. <ho...@bo...>]

> Most likely because you want to share many interfaces (header
> files) across platforms, therefore you want declarations to include
> "some" calling convention. 

Exactly.  

And it's necessary to specify calling conventions so that your library 
compiled with one convention is compatible with someone else's 
application that may have been built with __fastcall.

PoshLib (www.poshlib.org) tries to solve most of these problems 
cleanly and portably, which is why I'm asking about this.  I'm glad to 
find out that __attribute__((cdecl)) seems to be prefix or suffix 
friendly.

With POSH you do:

void POSH_CDECL foo( int x );

or, if you ant DLL export to work magically as well:

POSH_PUBLIC_API( void ) POSH_CDECL foo( int x );

Brian

Re: [GD-General] Clean way of generalizing CDECL

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

Ivan-Assen Ivanov wrote:

> Ummm, ok, let's rephrase this: WHY do you need to explicitly specify
> calling conventions in a cross-platform manner? It's not like you'd be
> linking object files from one platform against the libs of the other.

Most likely because you want to share many interfaces (header files) across
platforms, therefore you want declarations to include "some" calling
convention. Platform-specific configuration headers would #define the
platform-specific details of that calling convention. It's not too different
from the common technique used in Win32 DLL declarations:

// DLLFunctions.h
#ifdef DO_DLL_EXPORT
#define DLL_FUNCTION __declspec(dllexport)
#else
#define DLL_FUNCTION __declspec(dllimport)
#endif

extern "C" DLL_FUNCTION int DLLFunction1();
extern "C" DLL_FUNCTION void DLLFunction2();

// DLLFunctions.cpp
#define DO_DLL_EXPORT
#include "DLLFunctions.h"

// ...DLL functions implemented here

// DLLUser.h
#include "DLLFunctions.h"

// ...Code here uses the DLL functions

The original problem was that, since different platforms specify calling
conventions in different places (some before the function, some after the
parameters, etc), such a cross-platform call convention specifier may end up
being too ugly. I don't think there are much better ways than suggested by
Brian Sharon and Nick Trout. Techniques similar to Nick's are widely used in
K&R-conforming portable libraries like ZLib:

ZEXTERN int ZEXPORT inflate OF((z_streamp strm, int flush));

The OF macro here is used to remove the parameters from declarations in K&R
platforms.

-- 
  Javier Arevalo
  Pyro Studios

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

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

On Wednesday 07 July 2004 20:05, Brian Hook wrote:
> On Wed, 7 Jul 2004 22:14:09 -0400, Brian Hook wrote:
> > Here it is enumerated.  The prefix form of __attribute__((cdecl)):
> >
> > gcc 2.95, Linux/x86 -- YES
> > gcc 3.3.4, Linux/A64 -- NO
> > gcc 3.3, OS X/PowerPC -- NO
> > gcc 3.3.1, Cygwin/x86 -- YES
> >
> > No rhyme nor reason, other than possibly needing to be a pure x86
>
> ACtually, there is a rhyme -- it's supported on x86, and not supported
> on non-x86, where A64 is considered non-x86 for some reason.  This
> makes sense given that calling conventions are by and large an x86
> kind of thing (at least, these specific ones).
>
> So it's not a positioning thing, it's an availability thing.  Duh,
> shoulda thought of that a while ago.

Additionally I can also confirm that the followings also work:

gcc 3.2.3, Linux/x86
gcc 3.3.1, Linux/x86
gcc 3.4.0, Linux/x86

I don't have access to a non-x86 machine, but your conclusions make a lot o=
f=20
sense. To discard any othe possibility, you could also try with any other=20
attribute on a non-x86, like noreturn for instance.

=2D-=20
Ignacio Casta=F1o
cas...@ya...

RE: [GD-General] Clean way of generalizing CDECL

[Brian H. <ho...@bo...>]

> Ummm, ok, let's rephrase this: WHY do you need to explicitly
> specify calling conventions in a cross-platform manner? 

I don't, but I need to be able to have them specified on one platform 
and then not have them fail when compiled on another platform.

Brian

RE: [GD-General] Clean way of generalizing CDECL

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

> Yes and no.  cdecl, fastcall, stdcall, etc. are x86 specific 
> (not just Win32), but many platforms still have multiple 
> calling conventions (e.g. MacOS on the 68K had at least three 
> if I remember: pascal, OS, and something else).  So you still 
> need to be able to explicitly specify calling conventions 
> somehow in a vaguely cross-platform manner.

Ummm, ok, let's rephrase this: WHY do you need to explicitly specify
calling conventions in a cross-platform manner? It's not like you'd be
linking object files from one platform against the libs of the other.

RE: [GD-General] Clean way of generalizing CDECL

[Brian H. <ho...@bo...>]

> Why do you want to generalize it? Isn't cdecl something very win32-
> specific anyway?

Yes and no.  cdecl, fastcall, stdcall, etc. are x86 specific (not just 
Win32), but many platforms still have multiple calling conventions 
(e.g. MacOS on the 68K had at least three if I remember: pascal, OS, 
and something else).  So you still need to be able to explicitly 
specify calling conventions somehow in a vaguely cross-platform 
manner.

Brian

RE: [GD-General] Clean way of generalizing CDECL

[Stefan B. <Ste...@di...>]

  Why do you want to generalize it? Isn't cdecl something very
win32-specific anyway?

/Stefan

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Brian Hook
Sent: 07 July 2004 00:11
To: gam...@li...
Subject: [GD-General] Clean way of generalizing CDECL

I'd like to be able specify CDECL in a cross-platform manner.  On most=20
x86 compilers there's just the __cdecl keywod:

void __cdecl foo( int x, int y, int z );

GCC, of course, does it completely differently:

void foo( int x, int y, int z ) __attribute((cdecl));

So a simple #define won't work.  Now, you can do a kind of convoluted=20
thing using a define, but damn, it's REAL ugly.

Is there a cleaner way of doing this?




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[Brian H. <ho...@bo...>]

On Wed, 7 Jul 2004 22:14:09 -0400, Brian Hook wrote:
> Here it is enumerated.  The prefix form of __attribute__((cdecl)):
>
> gcc 2.95, Linux/x86 -- YES
> gcc 3.3.4, Linux/A64 -- NO
> gcc 3.3, OS X/PowerPC -- NO
> gcc 3.3.1, Cygwin/x86 -- YES
>
> No rhyme nor reason, other than possibly needing to be a pure x86


ACtually, there is a rhyme -- it's supported on x86, and not supported 
on non-x86, where A64 is considered non-x86 for some reason.  This 
makes sense given that calling conventions are by and large an x86 
kind of thing (at least, these specific ones).

So it's not a positioning thing, it's an availability thing.  Duh, 
shoulda thought of that a while ago.

Brian

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[Brian H. <ho...@bo...>]

Here it is enumerated.  The prefix form of __attribute__((cdecl)):

gcc 2.95, Linux/x86 -- YES
gcc 3.3.4, Linux/A64 -- NO
gcc 3.3, OS X/PowerPC -- NO
gcc 3.3.1, Cygwin/x86 -- YES

No rhyme nor reason, other than possibly needing to be a pure x86 code 
generator, but this is a front-end thing, not a back-end thing, so I 
dunno what's going on.

Brian

RE: [GD-General] Clean way of generalizing CDECL

[Nick T. <ni...@ro...>]

> > foo2 (int, blah, (int a, int b))  // declaration
>=20
> Nick, LOOK at that line for a second, and then ask yourself why I
> wouldn't want to write something like that =3D)

I think that looks like an excellent Lisp example. :) It works doesn't
it! I'd rather see that than loads of #ifdefs (e.g. see GLUT headers)
And you can easily add new platforms which also don't comply later.=20

Nick

[GD-General] RE: VC6 vs VC7

[Jeff L. <je...@SP...>]

Brian asked:
> Unrelated to this I just found out that Microsoft has the command line
> compiler from VC++ 7.2 available for download. I'd like to 
> test it out,
> but I don't want it to screw up my VC++ 6.0 installation -- has anyone
> downloaded it and used it with VC++ 6 and not had the latter die?

Tweety: replied:
> Works perfectly as long as you don't install them in the same folder and
> keep separate PATH env vars to switch around (this is kinda done for you
> with vdvars32.bat and similar).
> 
> As a side note, vc++ 8, vc# 8 and vb.net 8 beta 1 are also 
> available for
> free download with ide included. I heard they're pretty stable.
> 
> ----------------------------------

Something I found out the hard way was that you can't always mix/match DLLs
compiled with different VC compilers, if you use certain constructs.

You definitely can't *link* .obj files from VC6 with VC70 or VC71 because
the runtime support library for floats changed.

You can't pass FILE* pointers from VC6 to VC7 DLL's; Microsoft do lock
operations on the low-level file descriptors, but the VC6 and VC7 runtimes
use different offsets into a statically allocated table.

This knowledge comes the hard way, from having to compile arx plugins for
AutoCAD 2004 (which requires VC70) and AutoCAD 2002 (which requires VC6).

RE: [GD-General] Clean way of generalizing CDECL

[Brian H. <ho...@bo...>]

> Why not:
>
> #define foo(T,N, ...) T __cdecl N ( __VA_ARGS__ )

__VA_ARGS__ is C99, which isn't widely supported yet.

> #define foo2(T,N,A) T __cdecl N A
>
> foo2 (int, blah, (int a, int b))  // declaration

Nick, LOOK at that line for a second, and then ask yourself why I 
wouldn't want to write something like that =3D)

Brian

Re: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

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

--- ho...@bo... wrote: 
> Forgive me for doing this as a single question, I'm writing this from a
> Web client...
> 
> Going back to the __attribute((cdecl)) issue, I've found that this does
> NOT work when using GCC 3.3.4 for Athlon64.  I get a warning that the
> attribute will be ignored.  It compiles fine using GCC 3.3.1 for Cygwin
> however.
> 
> So, back to the drawing board I guess. *sigh*

Oh, that's sad, I've been using that on Cygwin and Linux with gcc3.3 and
maybe with other versions. I will do a more throughfull test as soon as I
come home. Maybe we could contact the gcc team and ask them to maintain that
feature, it's free software afterall.


> Unrelated to this I just found out that Microsoft has the command line
> compiler from VC++ 7.2 available for download. I'd like to test it out,
> but I don't want it to screw up my VC++ 6.0 installation -- has anyone
> downloaded it and used it with VC++ 6 and not had the latter die?

I've been using them together without any problem. However, you will also
have to download the platform sdk to do something useful with the compiler.
You can also use it with the old VC6 IDE by changing the path of the
executables in the settings.

The VC++ 8 beta1 is also available for download with the full IDE. However, I
haven't read the license in detail so I'm not aware of it's restrictions.

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





		
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es

RE: [GD-General] Clean way of generalizing CDECL

[Nick T. <ni...@ro...>]

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Brian Hook
> Sent: Tuesday, July 06, 2004 3:11 PM
> To: gam...@li...
> Subject: [GD-General] Clean way of generalizing CDECL
>=20
> I'd like to be able specify CDECL in a cross-platform manner.  On most
> x86 compilers there's just the __cdecl keywod:
>=20
> void __cdecl foo( int x, int y, int z );
>=20
> GCC, of course, does it completely differently:
>=20
> void foo( int x, int y, int z ) __attribute((cdecl));
>=20
> So a simple #define won't work.  Now, you can do a kind of convoluted
> thing using a define, but damn, it's REAL ugly.

Why not:

#define foo(T,N, ...) T __cdecl N ( __VA_ARGS__ )

foo (int, blah, int a, int b)  // declaration

or

#define foo2(T,N,A) T __cdecl N A=20

foo2 (int, blah, (int a, int b))  // declaration


Nick

RE: [GD-General] Two issues: __attribute__((cdecl)) and MSVC++ Toolkit 2003

[tweety <mi...@sy...>]

About the 2nd:
Works perfectly as long as you don't install them in the same folder and
keep separate PATH env vars to switch around (this is kinda done for you
with vdvars32.bat and similar).

As a side note, vc++ 8, vc# 8 and vb.net 8 beta 1 are also available for
free download with ide included. I heard they're pretty stable.

----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of ho...@bo...
> Sent: July 7, 2004 3:34 PM
> To: gam...@li...
> Subject: [GD-General] Two issues: __attribute__((cdecl)) and 
> MSVC++ Toolkit 2003
> 
> Forgive me for doing this as a single question, I'm writing 
> this from a
> Web client...
> 
> Going back to the __attribute((cdecl)) issue, I've found that 
> this does
> NOT work when using GCC 3.3.4 for Athlon64.  I get a warning that the
> attribute will be ignored.  It compiles fine using GCC 3.3.1 
> for Cygwin
> however.
> 
> So, back to the drawing board I guess. *sigh*
> 
> Unrelated to this I just found out that Microsoft has the command line
> compiler from VC++ 7.2 available for download. I'd like to 
> test it out,
> but I don't want it to screw up my VC++ 6.0 installation -- has anyone
> downloaded it and used it with VC++ 6 and not had the latter die?
> 
> Thanks,
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>