Game Dev Algorithms

RE: [Algorithms] general engine questionWe have the same architecture =
and currently only support a D3D renderer.  The bigger benefit, IMHO, =
from wrapping your 3D API is that you can upgrade through the API =
versions during development without much hassle.  We moved from DX6 to =
DX7 in no time.

-Mike
  ----- Original Message -----=20
  From: Herb Marselas=20
  To: 'gdalgorithms-list@...
  Sent: Wednesday, March 14, 2001 6:47 PM
  Subject: RE: [Algorithms] general engine question




  Up until about 9 months ago we supported 3 renderers (D3D, OGL, NULL) =
using a simple abstraction layer, with each renderer in it's own DLL.

  Doing features in D3D and OGL took a lot of time, and there were a lot =
of driver bugs in OGL, but we supported it since our art team was only =
running NT4.  When they moved to win2k we dropped OGL support since they =
could now run D3D.

  Now, we support only D3D and NULL.=20

  I'm sure that as long as we keep things clean we could go in later and =
put OGL back in, but there's little reason to do so.



  - herb=20



  Ensemble Studios=20
  http://www.ensemblestudios.com=20

  mailto:hmarselas@...
  ICQ:35921824=20



  -----Original Message-----=20
  From: Daniel Renkel [mailto:DanielRenkel@...
  Sent: Wednesday, March 14, 2001 5:40 PM=20
  To: gdalgorithms-list@...
  Subject: [Algorithms] general engine question=20



  hi there,=20

  a simple question to all programmer's who do code actually complex 3d=20
  engine's for commercial games:=20
  how many of you use ONLY directx or ONLY opengl for it=20
  and how many use both via a layer / wrapper sort of - for their=20
  interface(s).=20

  we are somehow stuck in our discussion about it, in our team;=20
      Daniel 'SirLeto' Renkel [D.Renkel@...
      technical design director - creactivity and technowhow =3D8O)=20
      Future Interactive [http://www.FutureInt.de]=20

  _______________________________________________=20
  GDAlgorithms-list mailing list=20
  GDAlgorithms-list@...
  http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list=20

My personal view on this is that it's not worth getting too uptight about
it. If you're going to have time to tweak for each platform, you may well
end up with things you want to do and can do but which violate your API
layer (especially if it's your first time round trying to make such a layer,
as it is mine). The API's good while it lets you do what you want. When it
gets in the way, fix it or modify as you see fit.

Jamie


-----Original Message-----
From: Neal Tringham [mailto:neal@...]
Sent: 15 March 2001 12:03
To: gdalgorithms-list@...
Subject: Re: [Algorithms] general engine question


From: Daniel Renkel <DanielRenkel@...>


> a simple question to all programmer's who do code actually complex 3d
> engine's for commercial games:
> how many of you use ONLY directx or ONLY opengl for it
> and how many use both via a layer / wrapper sort of - for their
> interface(s).
> we are somehow stuck in our discussion about it, in our team

At present we use OpenGL (for PCs) and PlayStation 2 "native mode".  To be
honest, though, I suspect the important question is not exactly which APIs
or targets you support as whether you should have some sort of intermediate
layer which allows you to support more than one target.  I'd suggest that
the answer to this is definitely yes, given that you might want to port to
any of several consoles, and you can't be sure when you start which systems
you might be asked to support in the end.  I'd also suggest building your
intermediate layer to use reasonably high level concepts rather than being
simply an API wrapper.  Essentially, if I were on your team I'd want to have
a fairly high level "platform layer" and then implement it initially for
either D3D or OpenGL and a NULL (empty) renderer.

Neal Tringham (Sick Puppies / Empire Interactive)

neal@...
neal@...




_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
-Virus scanned and cleared ok

----- Original Message -----
From: "Jamie Fowlston" <jfowlston@...>
To: <gdalgorithms-list@...>
Sent: Thursday, March 15, 2001 1:01 PM
Subject: RE: [Algorithms] general engine question


> My personal view on this is that it's not worth getting too uptight about
> it. If you're going to have time to tweak for each platform, you may well
> end up with things you want to do and can do but which violate your API
> layer (especially if it's your first time round trying to make such a
layer,
> as it is mine). The API's good while it lets you do what you want. When it
> gets in the way, fix it or modify as you see fit.
>
> Jamie

yeah that's exactly the point why we are arguing about that. It's our first
game and we'd like to get it finished. Building such a layer might improve
the overall quality of the engine since it's easily portable and extensible
but it costs us even more time to do something like that. And since we are
pretty sure that the game will be PC-only some of us think it's not
necessary to build such a layer. And even if we port the game to consoles
like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So
why bother about it?
A compromise would be just to code the high-level functions (as mentioned
before) and on low-level everything is API-specific. But the problems I see
are for example that APIs use different coordinate systems, handle their
renderstates in a different manner and maybe even are totally different in
their design.
That's why I just think: Code it in DX8, need half the time and get the game
finished rather than wasting lots of time on the engine just to realize in
the end that we can't get it done in a proper way. And THEN when we have
experience in how to write an engine (all of us are "newbies") we can write
a better one for our second project.
Opinions on that? What would you do if it was your first engine? Go the fast
and safe way or the 'better' one?


>
> -----Original Message-----
> From: Neal Tringham [mailto:neal@...]
> Sent: 15 March 2001 12:03
> To: gdalgorithms-list@...
> Subject: Re: [Algorithms] general engine question
>
>
> From: Daniel Renkel <DanielRenkel@...>
>
>
> > a simple question to all programmer's who do code actually complex 3d
> > engine's for commercial games:
> > how many of you use ONLY directx or ONLY opengl for it
> > and how many use both via a layer / wrapper sort of - for their
> > interface(s).
> > we are somehow stuck in our discussion about it, in our team
>
> At present we use OpenGL (for PCs) and PlayStation 2 "native mode".  To be
> honest, though, I suspect the important question is not exactly which APIs
> or targets you support as whether you should have some sort of
intermediate
> layer which allows you to support more than one target.  I'd suggest that
> the answer to this is definitely yes, given that you might want to port to
> any of several consoles, and you can't be sure when you start which
systems
> you might be asked to support in the end.  I'd also suggest building your
> intermediate layer to use reasonably high level concepts rather than being
> simply an API wrapper.  Essentially, if I were on your team I'd want to
have
> a fairly high level "platform layer" and then implement it initially for
> either D3D or OpenGL and a NULL (empty) renderer.
>
> Neal Tringham (Sick Puppies / Empire Interactive)
>
> neal@...
> neal@...
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> -Virus scanned and cleared ok
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>

In my opinion, this is similar to many optimization arguments.

My general rule is:

Make it work, then make it fast.


For your question, I might turn it around and say

Make it work, then make it portable.


If you're all newbies, I would recommend that you concentrate on the things 
you *know* you'll need for your game (if it's PC-only, you don't really 
need support for anything but DX).  If you *think* you might want to port 
it to other platforms later, you can do simple things like encapsulating 
platform specific data types (matrices and such) in your own classes, 
isolating the the use of DX in just a few files now, but mainly worry about 
getting the engine and game *done*.

It doesn't matter how flexible and portable your design is if the game 
never gets finished or is very late.


At 03:48 PM 3/15/2001 +0100, you wrote:
>----- Original Message -----
>From: "Jamie Fowlston" <jfowlston@...>
>To: <gdalgorithms-list@...>
>Sent: Thursday, March 15, 2001 1:01 PM
>Subject: RE: [Algorithms] general engine question
>
>
> > My personal view on this is that it's not worth getting too uptight about
> > it. If you're going to have time to tweak for each platform, you may well
> > end up with things you want to do and can do but which violate your API
> > layer (especially if it's your first time round trying to make such a
>layer,
> > as it is mine). The API's good while it lets you do what you want. When it
> > gets in the way, fix it or modify as you see fit.
> >
> > Jamie
>
>yeah that's exactly the point why we are arguing about that. It's our first
>game and we'd like to get it finished. Building such a layer might improve
>the overall quality of the engine since it's easily portable and extensible
>but it costs us even more time to do something like that. And since we are
>pretty sure that the game will be PC-only some of us think it's not
>necessary to build such a layer. And even if we port the game to consoles
>like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So
>why bother about it?
>A compromise would be just to code the high-level functions (as mentioned
>before) and on low-level everything is API-specific. But the problems I see
>are for example that APIs use different coordinate systems, handle their
>renderstates in a different manner and maybe even are totally different in
>their design.
>That's why I just think: Code it in DX8, need half the time and get the game
>finished rather than wasting lots of time on the engine just to realize in
>the end that we can't get it done in a proper way. And THEN when we have
>experience in how to write an engine (all of us are "newbies") we can write
>a better one for our second project.
>Opinions on that? What would you do if it was your first engine? Go the fast
>and safe way or the 'better' one?
>
>
> >
> > -----Original Message-----
> > From: Neal Tringham [mailto:neal@...]
> > Sent: 15 March 2001 12:03
> > To: gdalgorithms-list@...
> > Subject: Re: [Algorithms] general engine question
> >
> >
> > From: Daniel Renkel <DanielRenkel@...>
> >
> >
> > > a simple question to all programmer's who do code actually complex 3d
> > > engine's for commercial games:
> > > how many of you use ONLY directx or ONLY opengl for it
> > > and how many use both via a layer / wrapper sort of - for their
> > > interface(s).
> > > we are somehow stuck in our discussion about it, in our team
> >
> > At present we use OpenGL (for PCs) and PlayStation 2 "native mode".  To be
> > honest, though, I suspect the important question is not exactly which APIs
> > or targets you support as whether you should have some sort of
>intermediate
> > layer which allows you to support more than one target.  I'd suggest that
> > the answer to this is definitely yes, given that you might want to port to
> > any of several consoles, and you can't be sure when you start which
>systems
> > you might be asked to support in the end.  I'd also suggest building your
> > intermediate layer to use reasonably high level concepts rather than being
> > simply an API wrapper.  Essentially, if I were on your team I'd want to
>have
> > a fairly high level "platform layer" and then implement it initially for
> > either D3D or OpenGL and a NULL (empty) renderer.
> >
> > Neal Tringham (Sick Puppies / Empire Interactive)
> >
> > neal@...
> > neal@...
> >
> >
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDAlgorithms-list@...
> > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > -Virus scanned and cleared ok
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDAlgorithms-list@...
> > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> >
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDAlgorithms-list@...
>http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list


- Michael Harrison
   Senior Software Engineer
   Paradigm Entertainment
   Voice 972-488-6393

I would say that the extra layer of abstraction is quite useful; it helps
keep clear what you're working on, and where it belongs in the grand scheme
of things. We've already experienced that benefit over our previous quick
and dirty methods. Well, I have, anyway :)

We're not finished yet, but we have a fairly reasonable abstraction for the
moment. There are a few things (e.g. how dynamic lighting in the environment
works) which threaten to violate the current API, and may be different when
it comes to cross-platform stuff. When that happens, I'll be prepared to
violate the API, as it's not sacrosanct... it's just some code.

In my mind, the big mistake is thinking that 'cos some chunk of code has
worked well up till now, it should remain the way it is indefinitely :) And
if it's turning into a big argument, it may be better just to get on with it
:) You learn so much first time round that however well you plan it,
there'll be things you'll wish you'd done differently by the end of the
project.

Jamie


-----Original Message-----
From: David 'Mythomania' Zaadstra [mailto:mythomania@...]
Sent: 15 March 2001 14:48
To: gdalgorithms-list@...
Subject: Re: [Algorithms] general engine question


----- Original Message -----
From: "Jamie Fowlston" <jfowlston@...>
To: <gdalgorithms-list@...>
Sent: Thursday, March 15, 2001 1:01 PM
Subject: RE: [Algorithms] general engine question


> My personal view on this is that it's not worth getting too uptight about
> it. If you're going to have time to tweak for each platform, you may well
> end up with things you want to do and can do but which violate your API
> layer (especially if it's your first time round trying to make such a
layer,
> as it is mine). The API's good while it lets you do what you want. When it
> gets in the way, fix it or modify as you see fit.
>
> Jamie

yeah that's exactly the point why we are arguing about that. It's our first
game and we'd like to get it finished. Building such a layer might improve
the overall quality of the engine since it's easily portable and extensible
but it costs us even more time to do something like that. And since we are
pretty sure that the game will be PC-only some of us think it's not
necessary to build such a layer. And even if we port the game to consoles
like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So
why bother about it?
A compromise would be just to code the high-level functions (as mentioned
before) and on low-level everything is API-specific. But the problems I see
are for example that APIs use different coordinate systems, handle their
renderstates in a different manner and maybe even are totally different in
their design.
That's why I just think: Code it in DX8, need half the time and get the game
finished rather than wasting lots of time on the engine just to realize in
the end that we can't get it done in a proper way. And THEN when we have
experience in how to write an engine (all of us are "newbies") we can write
a better one for our second project.
Opinions on that? What would you do if it was your first engine? Go the fast
and safe way or the 'better' one?


>
> -----Original Message-----
> From: Neal Tringham [mailto:neal@...]
> Sent: 15 March 2001 12:03
> To: gdalgorithms-list@...
> Subject: Re: [Algorithms] general engine question
>
>
> From: Daniel Renkel <DanielRenkel@...>
>
>
> > a simple question to all programmer's who do code actually complex 3d
> > engine's for commercial games:
> > how many of you use ONLY directx or ONLY opengl for it
> > and how many use both via a layer / wrapper sort of - for their
> > interface(s).
> > we are somehow stuck in our discussion about it, in our team
>
> At present we use OpenGL (for PCs) and PlayStation 2 "native mode".  To be
> honest, though, I suspect the important question is not exactly which APIs
> or targets you support as whether you should have some sort of
intermediate
> layer which allows you to support more than one target.  I'd suggest that
> the answer to this is definitely yes, given that you might want to port to
> any of several consoles, and you can't be sure when you start which
systems
> you might be asked to support in the end.  I'd also suggest building your
> intermediate layer to use reasonably high level concepts rather than being
> simply an API wrapper.  Essentially, if I were on your team I'd want to
have
> a fairly high level "platform layer" and then implement it initially for
> either D3D or OpenGL and a NULL (empty) renderer.
>
> Neal Tringham (Sick Puppies / Empire Interactive)
>
> neal@...
> neal@...
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> -Virus scanned and cleared ok
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>


_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
-Virus scanned and cleared ok

-----Original Message-----
From: Jeffrey Cahyono [mailto:jeffreycahyono@...]
Sent: 15 March 2001 15:49
To: gdalgorithms-list@...
Subject: Re: [Algorithms] general engine question


[Snip]
aggred, but we still need primitives rendering to draw
billboards, view frustum, and Object's bounding
volume(for debugging purpose).

[/Snip]


Not so. Such things can be drawn as meshes just like everything else. Our
current solution is only to render meshes, and provide means to modify
meshes. Although properly double buffering them promises to be interesting
:)

Jamie
-Virus scanned and cleared ok

On Mar 15, 2001 at 03:48 +0100, David 'Mythomania' Zaadstra wrote:
> ----- Original Message -----
> From: "Jamie Fowlston" <jfowlston@...>
> To: <gdalgorithms-list@...>
> Sent: Thursday, March 15, 2001 1:01 PM
> Subject: RE: [Algorithms] general engine question
> 
> > My personal view on this is that it's not worth getting too
> > uptight about it. If you're going to have time to tweak for each
> > platform, you may well end up with things you want to do and can
> > do but which violate your API layer (especially if it's your first
> > time round trying to make such a > layer, as it is mine). The
> > API's good while it lets you do what you want. When it gets in the
> > way, fix it or modify as you see fit.
> 
> yeah that's exactly the point why we are arguing about that. It's our first
> game and we'd like to get it finished. Building such a layer might improve
> the overall quality of the engine since it's easily portable and extensible
> but it costs us even more time to do something like that. And since we are
> pretty sure that the game will be PC-only some of us think it's not
> necessary to build such a layer. And even if we port the game to consoles
> like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So
> why bother about it?
> A compromise would be just to code the high-level functions (as mentioned
> before) and on low-level everything is API-specific. But the problems I see
> are for example that APIs use different coordinate systems, handle their
> renderstates in a different manner and maybe even are totally different in
> their design.
> That's why I just think: Code it in DX8, need half the time and get the game
> finished rather than wasting lots of time on the engine just to realize in
> the end that we can't get it done in a proper way. And THEN when we have
> experience in how to write an engine (all of us are "newbies") we can write
> a better one for our second project.
> Opinions on that? What would you do if it was your first engine? Go the fast
> and safe way or the 'better' one?

I'm not a big fan of API wrapper layers.  I started out writing one
for Soul Ride, but it turned into a time sink with little tangible
benefit that I could see.  You either spend a bunch of time becoming
an API lawyer to figure out what exactly the lowest common denominator
is, or you define things at such a high level that you make low-level
hacks prohibitive to even try.  In either case, you only ever have
multiple functioning back ends if you have an excess of coding time or
a paucity of rendering features.

After a while I decided to dispense with the layer in order to save
time and effort.  I picked the other API because I think it's easier
to use, less intrusive on your data, and saves coding time and
headaches, which are exactly the benefits I wanted from a wrapper in
the first place.  But lots of people are perfectly happy coding
directly to DX, so don't be afraid to go for it.

-- 
Thatcher Ulrich <tu@...>
==  Soul Ride -- pure snowboarding for the PC -- http://soulride.com
==  real-world terrain -- physics-based gameplay -- no view limits

The lowest level of abstraction I would advocate has calls like:

Mesh::DrawThisMesh ( Matrix &orn );
TriBucket::AddTheseEffectTrisToABucket(...);
TriBucket::FlushToScreen();

etc.

Stuff like vertex buffers, index buffers, material setup, texture
management, etc is just so different between APIs that it's madness to try
to wrap anything lower-level than the above, IMHO.


Tom Forsyth - Muckyfoot bloke.

What's he up to now?
http://www.muckyfoot.com/startopia/cam.html



> -----Original Message-----
> From: Jamie Fowlston [mailto:jfowlston@...]
> Sent: 15 March 2001 15:32
> To: 'gdalgorithms-list@...'
> Subject: RE: [Algorithms] general engine question
> 
> 
> I would say that the extra layer of abstraction is quite 
> useful; it helps
> keep clear what you're working on, and where it belongs in 
> the grand scheme
> of things. We've already experienced that benefit over our 
> previous quick
> and dirty methods. Well, I have, anyway :)
> 
> We're not finished yet, but we have a fairly reasonable 
> abstraction for the
> moment. There are a few things (e.g. how dynamic lighting in 
> the environment
> works) which threaten to violate the current API, and may be 
> different when
> it comes to cross-platform stuff. When that happens, I'll be 
> prepared to
> violate the API, as it's not sacrosanct... it's just some code.
> 
> In my mind, the big mistake is thinking that 'cos some chunk 
> of code has
> worked well up till now, it should remain the way it is 
> indefinitely :) And
> if it's turning into a big argument, it may be better just to 
> get on with it
> :) You learn so much first time round that however well you plan it,
> there'll be things you'll wish you'd done differently by the 
> end of the
> project.
> 
> Jamie

Jamie Fowlston wrote:

> -----Original Message-----
> From: Jeffrey Cahyono [mailto:jeffreycahyono@...]
> Sent: 15 March 2001 15:49
> To: gdalgorithms-list@...
> Subject: Re: [Algorithms] general engine question
>
> [Snip]
> aggred, but we still need primitives rendering to draw
> billboards, view frustum, and Object's bounding
> volume(for debugging purpose).
>
> [/Snip]
>
> Not so. Such things can be drawn as meshes just like everything else. Our
> current solution is only to render meshes, and provide means to modify
> meshes. Although properly double buffering them promises to be interesting
> :)

What about stuff like HUDs and particles and cases where you need to
procedurally
generate geometry like subdivision etc?

Cheers, Paul.

>Opinions on that? What would you do if it was your first engine? Go the
fast
>and safe way or the 'better' one?
wow.
some really interesting ideas in this topic.

this is the way i look at it.

learn as you code.
and don't worry if your always rewriting your engine blocks or if file
formats never stick
:)
like even "professional engines" go through lots of rewrites,
unreal tournament went through about 8.
and iirc with *quake1,  abrash said they probably wrote around 10-15 engines
at his gdc talk("good to be balk" iirc).


*john told me this was the hardest engine to write

i can't emphasize more, screw "official" design initially, just rewrite code
:D
i see people that have never written 3d software in there life and ponder on
how they
are going to write the most optimal texture manager using classes(virtual,
private, protected, friends, way to much to think about for your first try)
and how they should use inheritance cause it seems like the right thing to
do.
;)


laterz,
-akbar A.


;vertexabuse.cjb.net
or
;www.vertexabuse.com
cjb goes down once in a while


"plastic or metallic.
please pick your version of lighting ;) "
.me

-----Original Message-----
From: gdalgorithms-list-admin@...
[mailto:gdalgorithms-list-admin@... Behalf Of David
'Mythomania' Zaadstra
Sent: Thursday, March 15, 2001 8:48 AM
To: gdalgorithms-list@...
Subject: Re: [Algorithms] general engine question


----- Original Message -----
From: "Jamie Fowlston" <jfowlston@...>
To: <gdalgorithms-list@...>
Sent: Thursday, March 15, 2001 1:01 PM
Subject: RE: [Algorithms] general engine question


> My personal view on this is that it's not worth getting too uptight about
> it. If you're going to have time to tweak for each platform, you may well
> end up with things you want to do and can do but which violate your API
> layer (especially if it's your first time round trying to make such a
layer,
> as it is mine). The API's good while it lets you do what you want. When it
> gets in the way, fix it or modify as you see fit.
>
> Jamie

yeah that's exactly the point why we are arguing about that. It's our first
game and we'd like to get it finished. Building such a layer might improve
the overall quality of the engine since it's easily portable and extensible
but it costs us even more time to do something like that. And since we are
pretty sure that the game will be PC-only some of us think it's not
necessary to build such a layer. And even if we port the game to consoles
like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So
why bother about it?
A compromise would be just to code the high-level functions (as mentioned
before) and on low-level everything is API-specific. But the problems I see
are for example that APIs use different coordinate systems, handle their
renderstates in a different manner and maybe even are totally different in
their design.
That's why I just think: Code it in DX8, need half the time and get the game
finished rather than wasting lots of time on the engine just to realize in
the end that we can't get it done in a proper way. And THEN when we have
experience in how to write an engine (all of us are "newbies") we can write
a better one for our second project.
Opinions on that? What would you do if it was your first engine? Go the fast
and safe way or the 'better' one?


>
> -----Original Message-----
> From: Neal Tringham [mailto:neal@...]
> Sent: 15 March 2001 12:03
> To: gdalgorithms-list@...
> Subject: Re: [Algorithms] general engine question
>
>
> From: Daniel Renkel <DanielRenkel@...>
>
>
> > a simple question to all programmer's who do code actually complex 3d
> > engine's for commercial games:
> > how many of you use ONLY directx or ONLY opengl for it
> > and how many use both via a layer / wrapper sort of - for their
> > interface(s).
> > we are somehow stuck in our discussion about it, in our team
>
> At present we use OpenGL (for PCs) and PlayStation 2 "native mode".  To be
> honest, though, I suspect the important question is not exactly which APIs
> or targets you support as whether you should have some sort of
intermediate
> layer which allows you to support more than one target.  I'd suggest that
> the answer to this is definitely yes, given that you might want to port to
> any of several consoles, and you can't be sure when you start which
systems
> you might be asked to support in the end.  I'd also suggest building your
> intermediate layer to use reasonably high level concepts rather than being
> simply an API wrapper.  Essentially, if I were on your team I'd want to
have
> a fairly high level "platform layer" and then implement it initially for
> either D3D or OpenGL and a NULL (empty) renderer.
>
> Neal Tringham (Sick Puppies / Empire Interactive)
>
> neal@...
> neal@...
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> -Virus scanned and cleared ok
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>


_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list

I've also found that the whole rendering thing (bearing in mind we don't
have things like OpenGL / DirectX to hide stuff from us on PS2) is too
complicated to keep all in your head at one time. You'll need to have done
it at least once to be able to do it properly... and then will think you
need to do it again.... :)

Jamie


-----Original Message-----
From: Akbar A. [mailto:syedali011@...]
Sent: 15 March 2001 20:37
To: gdalgorithms-list@...
Subject: RE: [Algorithms] general engine question


>Opinions on that? What would you do if it was your first engine? Go the
fast
>and safe way or the 'better' one?
wow.
some really interesting ideas in this topic.

this is the way i look at it.

learn as you code.
and don't worry if your always rewriting your engine blocks or if file
formats never stick
:)
like even "professional engines" go through lots of rewrites,
unreal tournament went through about 8.
and iirc with *quake1,  abrash said they probably wrote around 10-15 engines
at his gdc talk("good to be balk" iirc).


*john told me this was the hardest engine to write

i can't emphasize more, screw "official" design initially, just rewrite code
:D
i see people that have never written 3d software in there life and ponder on
how they
are going to write the most optimal texture manager using classes(virtual,
private, protected, friends, way to much to think about for your first try)
and how they should use inheritance cause it seems like the right thing to
do.
;)


laterz,
-akbar A.


;vertexabuse.cjb.net
or
;www.vertexabuse.com
cjb goes down once in a while


"plastic or metallic.
please pick your version of lighting ;) "
.me

-----Original Message-----
From: gdalgorithms-list-admin@...
[mailto:gdalgorithms-list-admin@... Behalf Of David
'Mythomania' Zaadstra
Sent: Thursday, March 15, 2001 8:48 AM
To: gdalgorithms-list@...
Subject: Re: [Algorithms] general engine question


----- Original Message -----
From: "Jamie Fowlston" <jfowlston@...>
To: <gdalgorithms-list@...>
Sent: Thursday, March 15, 2001 1:01 PM
Subject: RE: [Algorithms] general engine question


> My personal view on this is that it's not worth getting too uptight about
> it. If you're going to have time to tweak for each platform, you may well
> end up with things you want to do and can do but which violate your API
> layer (especially if it's your first time round trying to make such a
layer,
> as it is mine). The API's good while it lets you do what you want. When it
> gets in the way, fix it or modify as you see fit.
>
> Jamie

yeah that's exactly the point why we are arguing about that. It's our first
game and we'd like to get it finished. Building such a layer might improve
the overall quality of the engine since it's easily portable and extensible
but it costs us even more time to do something like that. And since we are
pretty sure that the game will be PC-only some of us think it's not
necessary to build such a layer. And even if we port the game to consoles
like the XBox that shouldn't be a problem 'cause the XBox supports DX8. So
why bother about it?
A compromise would be just to code the high-level functions (as mentioned
before) and on low-level everything is API-specific. But the problems I see
are for example that APIs use different coordinate systems, handle their
renderstates in a different manner and maybe even are totally different in
their design.
That's why I just think: Code it in DX8, need half the time and get the game
finished rather than wasting lots of time on the engine just to realize in
the end that we can't get it done in a proper way. And THEN when we have
experience in how to write an engine (all of us are "newbies") we can write
a better one for our second project.
Opinions on that? What would you do if it was your first engine? Go the fast
and safe way or the 'better' one?


>
> -----Original Message-----
> From: Neal Tringham [mailto:neal@...]
> Sent: 15 March 2001 12:03
> To: gdalgorithms-list@...
> Subject: Re: [Algorithms] general engine question
>
>
> From: Daniel Renkel <DanielRenkel@...>
>
>
> > a simple question to all programmer's who do code actually complex 3d
> > engine's for commercial games:
> > how many of you use ONLY directx or ONLY opengl for it
> > and how many use both via a layer / wrapper sort of - for their
> > interface(s).
> > we are somehow stuck in our discussion about it, in our team
>
> At present we use OpenGL (for PCs) and PlayStation 2 "native mode".  To be
> honest, though, I suspect the important question is not exactly which APIs
> or targets you support as whether you should have some sort of
intermediate
> layer which allows you to support more than one target.  I'd suggest that
> the answer to this is definitely yes, given that you might want to port to
> any of several consoles, and you can't be sure when you start which
systems
> you might be asked to support in the end.  I'd also suggest building your
> intermediate layer to use reasonably high level concepts rather than being
> simply an API wrapper.  Essentially, if I were on your team I'd want to
have
> a fairly high level "platform layer" and then implement it initially for
> either D3D or OpenGL and a NULL (empty) renderer.
>
> Neal Tringham (Sick Puppies / Empire Interactive)
>
> neal@...
> neal@...
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> -Virus scanned and cleared ok
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDAlgorithms-list@...
> http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>


_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list


_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
-Virus scanned and cleared ok

-----Original Message-----
From: Paul Firth [mailto:pfirth@...]
Sent: 15 March 2001 16:56
To: gdalgorithms-list@...
Subject: Re: [Algorithms] general engine question


What about stuff like HUDs and particles and cases where you need to
procedurally
generate geometry like subdivision etc?



Particles are just a type of mesh. When the particles are updated, you
update the mesh. You can do the same for HUD, subdivision (although that may
end up lower down in the renderer) and so on.

You know the format for your meshes. So you can edit them. We're planning on
putting a useful interface on top of the mesh so people don't have to
understand the full intricacies of the mesh format, but the principle's the
same.

A mesh is just a way of batching polys together. There doesn't seem any
point adding individual poly functionality to our renderer: the stalls would
kill performance, and it would be hardly ever used anyway.

Jamie
-Virus scanned and cleared ok

We have (not actual names, but close in spirit :)

initialise
startFrame
addModel
addSprite

... and some functions to initialise stuff when it's loaded, and that's it.
Keeps everything sane :)

Jamie


-----Original Message-----
From: Tom Forsyth [mailto:tomf@...]
Sent: 15 March 2001 18:27
To: gdalgorithms-list@...
Subject: RE: [Algorithms] general engine question


The lowest level of abstraction I would advocate has calls like:

Mesh::DrawThisMesh ( Matrix &orn );
TriBucket::AddTheseEffectTrisToABucket(...);
TriBucket::FlushToScreen();

etc.

Stuff like vertex buffers, index buffers, material setup, texture
management, etc is just so different between APIs that it's madness to try
to wrap anything lower-level than the above, IMHO.


Tom Forsyth - Muckyfoot bloke.

What's he up to now?
http://www.muckyfoot.com/startopia/cam.html



> -----Original Message-----
> From: Jamie Fowlston [mailto:jfowlston@...]
> Sent: 15 March 2001 15:32
> To: 'gdalgorithms-list@...'
> Subject: RE: [Algorithms] general engine question
> 
> 
> I would say that the extra layer of abstraction is quite 
> useful; it helps
> keep clear what you're working on, and where it belongs in 
> the grand scheme
> of things. We've already experienced that benefit over our 
> previous quick
> and dirty methods. Well, I have, anyway :)
> 
> We're not finished yet, but we have a fairly reasonable 
> abstraction for the
> moment. There are a few things (e.g. how dynamic lighting in 
> the environment
> works) which threaten to violate the current API, and may be 
> different when
> it comes to cross-platform stuff. When that happens, I'll be 
> prepared to
> violate the API, as it's not sacrosanct... it's just some code.
> 
> In my mind, the big mistake is thinking that 'cos some chunk 
> of code has
> worked well up till now, it should remain the way it is 
> indefinitely :) And
> if it's turning into a big argument, it may be better just to 
> get on with it
> :) You learn so much first time round that however well you plan it,
> there'll be things you'll wish you'd done differently by the 
> end of the
> project.
> 
> Jamie

_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
-Virus scanned and cleared ok

Jamie Fowlston wrote: 
> A mesh is just a way of batching polys together. There 
> doesn't seem any point adding individual poly
> functionality to our renderer: the stalls would
> kill performance, and it would be hardly ever used anyway.

As a couple of other people have said, we've found it quite useful to write
a very streamlined low and mid level renderer that deals only with meshes
(eg buckets of tris), and then build a really simplistic and easy to use
'draw a single rectangle/sprite/line' interface on the top. This is the
graphics interface for the non-graphics programmers who need to draw stuff,
either for debugging, or in a frontend screen, or for prototyping, or whilst
a pause menu is up, ie any situation where the performance hit isn't going
to be a problem. Certainly this interface is hardly ever used by any of the
graphics guys, but it's been very handy for the rest of the team!
	Of course, if any of this code shows up on the profiler in a master
build, it gets converted over to 'proper' graphics code, but that's been
quite rare.

Peter

Yeah, we've got it for sprites, I suppose (as they're very simple anyway).
But we're aiming for such things to be (in general) built from editable
meshes. Performs the same job, keeps polys batched nicely from the word go,
and just as easy for those who don't know what the renderer's really up to,
but keeps the renderer itself somewhat cleaner (in my opinion :).

Jamie


-----Original Message-----
From: Peter Warden [mailto:Peter.Warden@...]
Sent: 16 March 2001 10:40
To: gdalgorithms-list@...
Subject: RE: [Algorithms] general engine question


Jamie Fowlston wrote: 
> A mesh is just a way of batching polys together. There 
> doesn't seem any point adding individual poly
> functionality to our renderer: the stalls would
> kill performance, and it would be hardly ever used anyway.

As a couple of other people have said, we've found it quite useful to write
a very streamlined low and mid level renderer that deals only with meshes
(eg buckets of tris), and then build a really simplistic and easy to use
'draw a single rectangle/sprite/line' interface on the top. This is the
graphics interface for the non-graphics programmers who need to draw stuff,
either for debugging, or in a frontend screen, or for prototyping, or whilst
a pause menu is up, ie any situation where the performance hit isn't going
to be a problem. Certainly this interface is hardly ever used by any of the
graphics guys, but it's been very handy for the rest of the team!
	Of course, if any of this code shows up on the profiler in a master
build, it gets converted over to 'proper' graphics code, but that's been
quite rare.

Peter

_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-list@...
http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
-Virus scanned and cleared ok

> From: Peter Warden [mailto:Peter.Warden@...]
>
> As a couple of other people have said, we've found it quite 
> useful to write
> a very streamlined low and mid level renderer that deals only 
> with meshes
> (eg buckets of tris), and then build a really simplistic and 
> easy to use
> 'draw a single rectangle/sprite/line' interface on the top. 
> This is the
> graphics interface for the non-graphics programmers who need 
> to draw stuff,
> either for debugging, or in a frontend screen, or for 
> prototyping, or whilst
> a pause menu is up, ie any situation where the performance 
> hit isn't going
> to be a problem. Certainly this interface is hardly ever used 
> by any of the
> graphics guys, but it's been very handy for the rest of the team!
> 	Of course, if any of this code shows up on the profiler 
> in a master
> build, it gets converted over to 'proper' graphics code, but 
> that's been
> quite rare.
> 
> Peter


Works for us too. We also have some really grim-looking effects code that
can animate and draw a mesh just like normal, except that instead of
rendering the thing, for each triangle it calls a user-specified function
that can then do anything it wants with the data.

This is useful for stuff like teleporter effects, disintegration effects,
exploding, diseases, rotting flesh, deformations, blobbiness, etc. You only
get a few on-screen at any time, so the performance hit is fine, despite the
massive inefficiency of the code. But it allows non-core people to easily
throw some very cute effects together (we have one of those cartoon X-ray
machines that shows skeletons, and a "space warp" disease that makes people
look like they are reflected in a wibbly mirror)


Tom Forsyth - Muckyfoot bloke.

What's he up to now?
http://www.muckyfoot.com/startopia/cam.html