>Opinions on that? What would you do if it was your first engine? Go the
>and safe way or the 'better' one?
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
i see people that have never written 3d software in there life and ponder on
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
cjb goes down once in a while
"plastic or metallic.
please pick your version of lighting ;) "
[mailto:gdalgorithms-list-admin@... Behalf Of David
Sent: Thursday, March 15, 2001 8:48 AM
Subject: Re: [Algorithms] general engine question
----- Original Message -----
From: "Jamie Fowlston" <jfowlston@...>
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
> 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
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
> 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
> 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
> 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)
> GDAlgorithms-list mailing list
> -Virus scanned and cleared ok
> GDAlgorithms-list mailing list
GDAlgorithms-list mailing list