gdalgorithms-list

RE: [Algorithms] FPS Questions

[<sro...@te...>]

well, i dont know for you but i can see the difference beetween 30 and 60
fps

Corrosif,
Ignore demands from the marketing department to release premature shots.
These people are for the  most part clueless, and are only trying to justify
their job." George Broussard, President of 3DRealms.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Jim
Offerman
Sent: Monday, July 31, 2000 3:31 PM
To: gda...@li...
Subject: Re: [Algorithms] FPS Questions


> 60fps is the ideal target.

I blindly follow the masses here, but I can't help wondering why... Anything
above 24-25 fps will not be noticed by the human eye, 30 fps animations look
_really_ smooth. So why are we all targetting for 60 fps? Shouldn't we
rather crank up the detail some more and all target 30 fps? What makes a 60
fps game more playable than a 30 fps game?

Jim Offerman

Innovade
- designing the designer


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

Re: [Algorithms] FPS Questions (60fps vs 30fps)

[Adam W. <ad...@ar...>]

Ack, seem to have bookmarked page 2, there is a page 1
(http://www.penstarsys.com/editor/30v60/30v60p1.htm).

Sorry,

adamw

----- Original Message -----
From: "Adam Wright" <ad...@ar...>
To: <gda...@li...>
Sent: Monday, July 31, 2000 8:44 PM
Subject: Re: [Algorithms] FPS Questions (60fps vs 30fps)


> http://www.penstarsys.com/editor/30v60/30v60p2.htm
>
> has a reasonable discussion on the topic.
>
> adamw
>
> ----- Original Message -----
> From: "Jim Offerman" <j.o...@in...>
> To: <gda...@li...>
> Sent: Monday, July 31, 2000 8:31 PM
> Subject: Re: [Algorithms] FPS Questions
>
>
> > > 60fps is the ideal target.
> >
> > I blindly follow the masses here, but I can't help wondering why...
> Anything
> > above 24-25 fps will not be noticed by the human eye, 30 fps animations
> look
> > _really_ smooth. So why are we all targetting for 60 fps? Shouldn't we
> > rather crank up the detail some more and all target 30 fps? What makes a
> 60
> > fps game more playable than a 30 fps game?
> >
> > Jim Offerman
> >
> > Innovade
> > - designing the designer
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FPS Questions (60fps vs 30fps)

[Adam W. <ad...@ar...>]

http://www.penstarsys.com/editor/30v60/30v60p2.htm

has a reasonable discussion on the topic.

adamw

----- Original Message -----
From: "Jim Offerman" <j.o...@in...>
To: <gda...@li...>
Sent: Monday, July 31, 2000 8:31 PM
Subject: Re: [Algorithms] FPS Questions


> > 60fps is the ideal target.
>
> I blindly follow the masses here, but I can't help wondering why...
Anything
> above 24-25 fps will not be noticed by the human eye, 30 fps animations
look
> _really_ smooth. So why are we all targetting for 60 fps? Shouldn't we
> rather crank up the detail some more and all target 30 fps? What makes a
60
> fps game more playable than a 30 fps game?
>
> Jim Offerman
>
> Innovade
> - designing the designer
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FPS Questions

[Jim O. <j.o...@in...>]

> 60fps is the ideal target.

I blindly follow the masses here, but I can't help wondering why... Anything
above 24-25 fps will not be noticed by the human eye, 30 fps animations look
_really_ smooth. So why are we all targetting for 60 fps? Shouldn't we
rather crank up the detail some more and all target 30 fps? What makes a 60
fps game more playable than a 30 fps game?

Jim Offerman

Innovade
- designing the designer

Re: [Algorithms] VIPM on a machine with DMA :)

[Jim O. <j.o...@in...>]

As I understand it, you not supposed to touch the actual vertex data of a
VIPMed and, if the model is at full detail you will have exactly the same
data as when you render a 'normal' model. However, in addition you have some
'control data' to govern the process of adding/removing detail (which, like
Tom mentions, is all done by manipulating the index list). Since you never
send the control data to the rendering API, it won't even know the
difference...

Jim Offerman

Innovade
- designing the designer
----- Original Message -----
From: "Jamie Fowlston" <j.f...@re...>
To: <gda...@li...>
Sent: Monday, July 31, 2000 8:32 PM
Subject: Re: [Algorithms] VIPM on a machine with DMA :)


> Still have to DMA the vertex data, which is larger for VIPMed models (am I
> right? I've not implemented VIPM, but think I've understood the general
idea).
> So total transfer is larger than it would be for non-VIPMed model. We're
> expecting to be DMA speed constrained rather than draw speed constrained.
>
> Have you actually implemented VIPM on... that machine? :) Some sort of
> algorithms-style section in the support newsgroup would be nice, and I
could
> stop waffling and talk specifics.... :) Talk about LoD would be useful.
I'll
> post something....
>
> I know some stuff about other consoles... but AFAIK, I can't say which or
how
> much. Aren't NDAs fun? :)
>
> Jamie
>
>
> Tom Forsyth wrote:
>
> > > From: Jamie Fowlston [mailto:j.f...@re...]
> >
> > [snip]
> >
> > > Not regardless of hardware. For us, drawing several instances
> > > of the same model
> > > saves us DMA bandwidth. CLOD trashes the ability to do that.
> >
> > VIPM won't. Since you use the same vertex data for all levels of detail,
> > multiple instances are very cheap. All you change is a bunch of indices.
On
> > two of the future consoles I know well enough(*) to comment on, this
will be
> > nice and fast. You'll need to DMA across the new indices, but that's
tiny
> > amounts of memory. You may even be able to do the VIPM expands/collapses
on
> > the ... you know ... thing that does the transforms - the
expand/collapse
> > routine is absurdly simple. Which will make multiple instances awesomely
> > cheap!
> >
> > Oh dear - I'm off again about VIPM. Sorry list :-)
> >
> > > Polygons are very
> > > cheap to draw, so we might as well draw them.... Unless
> > > anyone else knows
> > > better? :)
> > >
> > > Maybe when we've had more experience of the machine we'll
> > > change our minds. :)
> > >
> > > Jamie
> >
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> >
> > (*) The one I don't know about, I knew exactly one hard fact about it -
its
> > name. And then they changed it, and I can't remember what to. So I now
know
> > precisely zero about it :-)
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] VIPM on a machine with DMA :)

[Tom F. <to...@mu...>]

> From: Jamie Fowlston [mailto:j.f...@re...]
> 
> 
> Still have to DMA the vertex data, which is larger for VIPMed 
> models (am I
> right? I've not implemented VIPM, but think I've understood 
> the general idea).

No, the vertex data is precisely as big as your most-detailed model - that
is, the most detailed model you want to draw that frame (or that instance or
whatever). There is zero bloating of vertex data.

The index data is indexed lists, so that's very slightly bloated from
indexed strips in some cases, but probably not so you'd notice - indices are
tiny compared to the vertices anyway. And the collapse/expand info is
moderately big thinking about it (12 bytes per collapse on average I think -
I can't remember), so it may not be a win to do the collapse/expand on the
"non-CPU unit" - who can tell? It's pretty quick on both to be honest.

> So total transfer is larger than it would be for non-VIPMed 
> model. We're
> expecting to be DMA speed constrained rather than draw speed 
> constrained.

Indeed, that's what I woudl expect too - the DMA seems to be the hardest
thing to get right about the machine. But fortunately there is no bloat. Go
and read Charles Bloom's excellent VIPM tutorial (one day I'll get around to
doing my own - actually, there's not much point - it'll be identical to
Charles'). (http://208.55.130.3/3d/ - sixth link down).

> Have you actually implemented VIPM on... that machine? :) Some sort of
> algorithms-style section in the support newsgroup would be 
> nice, and I could
> stop waffling and talk specifics.... :) Talk about LoD would 
> be useful. I'll
> post something....

No, I haven't actually played with that machine yet, except in my head from
the specs (and I'm not on the newsgroup or anything). Busy enough playing
with the Dreamcast!

I have implemented it on the PC, using similar sorts of semantics -
Optimised VBs. There, DMA speed (well, AGP bus speed) is king as well.

> I know some stuff about other consoles... but AFAIK, I can't 
> say which or how
> much. Aren't NDAs fun? :)

Grrrr. :-)

> Jamie

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

Re: [Algorithms] VIPM on a machine with DMA :)

[Jamie F. <j.f...@re...>]

Still have to DMA the vertex data, which is larger for VIPMed models (am I
right? I've not implemented VIPM, but think I've understood the general idea).
So total transfer is larger than it would be for non-VIPMed model. We're
expecting to be DMA speed constrained rather than draw speed constrained.

Have you actually implemented VIPM on... that machine? :) Some sort of
algorithms-style section in the support newsgroup would be nice, and I could
stop waffling and talk specifics.... :) Talk about LoD would be useful. I'll
post something....

I know some stuff about other consoles... but AFAIK, I can't say which or how
much. Aren't NDAs fun? :)

Jamie


Tom Forsyth wrote:

> > From: Jamie Fowlston [mailto:j.f...@re...]
>
> [snip]
>
> > Not regardless of hardware. For us, drawing several instances
> > of the same model
> > saves us DMA bandwidth. CLOD trashes the ability to do that.
>
> VIPM won't. Since you use the same vertex data for all levels of detail,
> multiple instances are very cheap. All you change is a bunch of indices. On
> two of the future consoles I know well enough(*) to comment on, this will be
> nice and fast. You'll need to DMA across the new indices, but that's tiny
> amounts of memory. You may even be able to do the VIPM expands/collapses on
> the ... you know ... thing that does the transforms - the expand/collapse
> routine is absurdly simple. Which will make multiple instances awesomely
> cheap!
>
> Oh dear - I'm off again about VIPM. Sorry list :-)
>
> > Polygons are very
> > cheap to draw, so we might as well draw them.... Unless
> > anyone else knows
> > better? :)
> >
> > Maybe when we've had more experience of the machine we'll
> > change our minds. :)
> >
> > Jamie
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> (*) The one I don't know about, I knew exactly one hard fact about it - its
> name. And then they changed it, and I can't remember what to. So I now know
> precisely zero about it :-)
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Scalability costs

[Tom F. <to...@mu...>]

> From: Jamie Fowlston [mailto:j.f...@re...]

[snip]

> Not regardless of hardware. For us, drawing several instances 
> of the same model
> saves us DMA bandwidth. CLOD trashes the ability to do that. 

VIPM won't. Since you use the same vertex data for all levels of detail,
multiple instances are very cheap. All you change is a bunch of indices. On
two of the future consoles I know well enough(*) to comment on, this will be
nice and fast. You'll need to DMA across the new indices, but that's tiny
amounts of memory. You may even be able to do the VIPM expands/collapses on
the ... you know ... thing that does the transforms - the expand/collapse
routine is absurdly simple. Which will make multiple instances awesomely
cheap!

Oh dear - I'm off again about VIPM. Sorry list :-)

> Polygons are very
> cheap to draw, so we might as well draw them.... Unless 
> anyone else knows
> better? :)
> 
> Maybe when we've had more experience of the machine we'll 
> change our minds. :)
> 
> Jamie

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.


(*) The one I don't know about, I knew exactly one hard fact about it - its
name. And then they changed it, and I can't remember what to. So I now know
precisely zero about it :-)

Re: [Algorithms] FPS Questions

[Keith Z.L. <ke...@dr...>]

60fps is the ideal target.

Instead of using a timer, what I do is add up the elapsed time from the previous
frame
until it is greater than 1 sec.  at that point I compute the average frame rate
and reset to
zero.

I do it this way because windows has a great deal of variance in the timer
function.  If you
use a multi-media timer you can get better accuracy, but at a cost of
performance.

Keith
DreamForge

Steve Wood wrote:

> Personally, I use a counter for the number of frames I render, plus use a
> timer at 1 second intervals to display the count and reset it for the next
> second.  I don't have any game code yet...just the collision testing and
> 10,000 tris with one point light and ability to 'fly' around the world which
> consists of a sphere, a triangular pyramid, and two square boxes.  I get 70
> fps at 640x480x32 running a PII-350 with Creative Labs Rive TNT AGP, but
> drops down to 55 when the objects completely fill the screen.
>
> R&R
>
> > -----Original Message-----
> > From: Pai-Hung Chen [mailto:pa...@ac...]
> > Sent: Sunday, July 30, 2000 3:18 PM
> > To: GDA...@li...
> > Subject: [Algorithms] FPS Questions
> >
> >
> > Hi,
> >
> > (1) Is there a universally agreed way to calculate
> > Frame-Per-Second information?
> >
> > (2) What is the acceptable FPS for today's 3D games?
> >
> > Thanks,
> >
> > Pai-Hung Chen
> >
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Scalability costs

[Jamie F. <j.f...@re...>]

Jim Offerman wrote:

> > Great idea, does it really happen in practice? We seem to end up starting
> from
> > scratch every time. Or at least taking the old stuff, using it as a base,
> and
> > then rewriting most of it. New consoles don't help, of course :)
>
> I am quite a fanatic reuser... while some parts of my engine are written
> only yesterday, other parts are several years old and have survived many
> generations of my engine.

Impressive :)

> I find myself constantly tweaking the parts of the
> engine which interface with stuff like direct3d (technology side) and such
> all the time,

Us console programmers just get a new console to play with :)

> while my scenegraph (content side) has remained quite constant
> for several years now.
>
> > That definitely makes sense. All our geometry is going through the same
> > pipeline. CLOD does not make sense for us given time constraints, and it
> > doesn't fit the hardware too well either (according to our somewhat
> limited
> > research :). Next generation of games, we may try something a little more
> > procedural, but not for the mo....
>
> Admittedly, I cannot really afford to spend much time on progressive meshes,
> my biggest worry at the moment is getting my game up and running. Still, I
> am always on my toes and looking ahead... Given the architecture of my
> engine, VIPM is the way to go for me, since it can be implemented in my
> engine with quite little effort (the hard part is writing the code that
> generates the VIPM...) and in addition it is _very_ hardware friendly.

Not regardless of hardware. For us, drawing several instances of the same model
saves us DMA bandwidth. CLOD trashes the ability to do that. Polygons are very
cheap to draw, so we might as well draw them.... Unless anyone else knows
better? :)

Maybe when we've had more experience of the machine we'll change our minds. :)

Jamie

Re: [Algorithms] Scalability costs

[Jamie F. <j.f...@re...>]

>
> It does happen when the engine has some nice generalities to it. Even if
> none of the actual code get shared (which is the usual case, admittedly),
> the people involved usualy just rewrite what they had before, maybe with a
> few neat tricks they've learned in the meantime. You can rewrite something
> very quickly if you've done it once and solved all the hard problems. It's
> that sort of "reuse" I meant, rather than the actual code itself.

Plenty of ideas live past the original code, that's true :)

>
>
> [snip]
> > Algorithms that scale well are a good thing... he says,
> > frantically trying to
> > convince himself the thread's not OT.... :)
>
> I don't think it's even close to OT - this is a games algorithms list, and
> LoD algorithms are amongst the trickiest and most varied algorithms out
> there.

True, this just seems peripheral to the algorithms themselves :)

Jamie

RE: [Algorithms] Scalability costs

[Brian M. <bma...@ra...>]

> Is this true in the PC market? For consoles, you get most sales
> in early days,
> very little afterward. Tom's suggestion that you can still be
> looking good in n
> years time isn't matched by sales in our circumstances.

This varies a lot with product - Goldeneye has sold many millions but
started very slowly - a few hundred thousand. And it's still selling.
Scalability for a console is more useful for load balancing the engine to
keep the frame rate and detail. Or for handling things like play modes that
need twice the number of character on screen.

One challenge I'm working on here is getting the processor time to scale in
line with the graphics - there are solutions for scaling the graphics that
work nicely - processor scaling is proving something more difficult.

Also making the artists more productive is a very big thing - just building
one version with automatic lodding helps a lot, even before you get to the
authoring approaches like Tom F. has detailed.

-Brian.

RE: [Algorithms] FPS Questions

[Steve W. <Ste...@im...>]

OOPS!  I meant 1,000 tris.

Personally, I use a counter for the number of frames I render, plus use a
timer at 1 second intervals to display the count and reset it for the next
second.  I don't have any game code yet...just the collision testing and
10,000 tris with one point light and ability to 'fly' around the world which
consists of a sphere, a triangular pyramid, and two square boxes.  I get 70
fps at 640x480x32 running a PII-350 with Creative Labs Rive TNT AGP, but
drops down to 55 when the objects completely fill the screen.

R&R

> -----Original Message-----
> From: Pai-Hung Chen [mailto:pa...@ac...]
> Sent: Sunday, July 30, 2000 3:18 PM
> To: GDA...@li...
> Subject: [Algorithms] FPS Questions
> 
> 
> Hi,
> 
> (1) Is there a universally agreed way to calculate
> Frame-Per-Second information?
> 
> (2) What is the acceptable FPS for today's 3D games?
> 
> Thanks,
> 
> Pai-Hung Chen
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

> -----Original Message-----
> From: Pai-Hung Chen [mailto:pa...@ac...]
> Sent: Sunday, July 30, 2000 3:18 PM
> To: GDA...@li...
> Subject: [Algorithms] FPS Questions
> 
> 
> Hi,
> 
> (1) Is there a universally agreed way to calculate
> Frame-Per-Second information?
> 
> (2) What is the acceptable FPS for today's 3D games?
> 
> Thanks,
> 
> Pai-Hung Chen
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] FPS Questions

[Steve W. <Ste...@im...>]

Personally, I use a counter for the number of frames I render, plus use a
timer at 1 second intervals to display the count and reset it for the next
second.  I don't have any game code yet...just the collision testing and
10,000 tris with one point light and ability to 'fly' around the world which
consists of a sphere, a triangular pyramid, and two square boxes.  I get 70
fps at 640x480x32 running a PII-350 with Creative Labs Rive TNT AGP, but
drops down to 55 when the objects completely fill the screen.

R&R

> -----Original Message-----
> From: Pai-Hung Chen [mailto:pa...@ac...]
> Sent: Sunday, July 30, 2000 3:18 PM
> To: GDA...@li...
> Subject: [Algorithms] FPS Questions
> 
> 
> Hi,
> 
> (1) Is there a universally agreed way to calculate
> Frame-Per-Second information?
> 
> (2) What is the acceptable FPS for today's 3D games?
> 
> Thanks,
> 
> Pai-Hung Chen
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] Scalability costs

[Jim O. <j.o...@in...>]

> Great idea, does it really happen in practice? We seem to end up starting
from
> scratch every time. Or at least taking the old stuff, using it as a base,
and
> then rewriting most of it. New consoles don't help, of course :)

I am quite a fanatic reuser... while some parts of my engine are written
only yesterday, other parts are several years old and have survived many
generations of my engine. I find myself constantly tweaking the parts of the
engine which interface with stuff like direct3d (technology side) and such
all the time, while my scenegraph (content side) has remained quite constant
for several years now.

> That definitely makes sense. All our geometry is going through the same
> pipeline. CLOD does not make sense for us given time constraints, and it
> doesn't fit the hardware too well either (according to our somewhat
limited
> research :). Next generation of games, we may try something a little more
> procedural, but not for the mo....

Admittedly, I cannot really afford to spend much time on progressive meshes,
my biggest worry at the moment is getting my game up and running. Still, I
am always on my toes and looking ahead... Given the architecture of my
engine, VIPM is the way to go for me, since it can be implemented in my
engine with quite little effort (the hard part is writing the code that
generates the VIPM...) and in addition it is _very_ hardware friendly.

Jim Offerman

Innovade
- designing the designer

[Algorithms] class parser

[Blade S.N <he...@ci...>]

SGkgYWxsLCANCldlIGFyZSBnb2luZyB0byBwb3J0IG91ciBnYW1lIHRvIE1hYyBhbmQgYmVnaW4g
dG8gZXhwZXJpZW5jZSBwcm9ibGVtIG9mIHNtYWxsX2JpZyAgZW5kaWFuIGNvbnZlcnNpb24uSXQg
aXMgY29uY2VybmVkICB3aXRoIHRvbyBtYW55IGNsYXNzIGFuZCBzdHJ1Y3R1cmUgLkl0J3MgaW1w
b3NzaWJsZSB0byB3cml0ZSBhbGwgdGhlIGNvbnZlcnNpb24gY29kZSBmb3IgZXZlcnkgZGF0YSBm
aWxlIHR5cGUuIFNvIEkgYW0gZ29pbmcgdG8gaW1wbGVtZW50IGEgaGVhZCBmaWxlIHBhcnNlciB0
byBwYXJzZSB0aGUgZGVmaW5pdGlvbiBvZiBlYWNoIGNsYXNzIGFuZCBnZW5lcmF0ZSB0aGUgY29u
dmVyc2lvbiBjb2RlICBhdXRvbWF0aWNhbGx5IC5JdCdzIHN1cmVseSBub3QgdGhlIG1vc3QgY29u
dmVuaWVudCB3YXkgdG8gbWFrZSB0aGF0LkJ1dCBJIGhhdmVuJ3QgYW55IGdvb2QgaWRlYS4NCkNh
biBhbnlvbmUgaGVyZSBlbmxpZ2h0ZW4gIG1lLklzIHRoZXJlIGFueSBzaW1wbGUgd2F5Pw0KVGhh
bmtzIGluIGFkdmFuY2UuDQpTLk4NCg0KDQo=

RE: [Algorithms] Scalability costs

[Tom F. <to...@mu...>]

> From: Jamie Fowlston [mailto:j.f...@re...]
> 
> Jim Offerman wrote:
> 
> > > It's a nice idea, but is it worth the cost in development time?
> >
> > I think that any form of scalability (whether it is 
> achieved through some
> > pre-calculated LoD levels or through advanced techniques, like the
> > forementioned VIPM, or even just scalability/modularity of 
> your engine it
> > self) is worth the cost in development time, since it 
> potentially increases
> > the replayability of your game and/or the reusability of 
> your engine.
> >
> > So your game can potentially sell more copies of a longer 
> period, since it
> > can still compete with the newest releases (hence you earn 
> more money with
> > it)
> 
> Is this true in the PC market? For consoles, you get most 
> sales in early days,
> very little afterward. Tom's suggestion that you can still be 
> looking good in n
> years time isn't matched by sales in our circumstances.

There are a few games that have the distinction of earning money well past
the usual sell-by date. True, most of them tend to be the "sim" or "theme"
games, but there is the odd graphics-heavy one (e.g. Half-Life, though it is
helped by having more superb mods than you can empty a full mag at).

Having a good scalable engine can only help...

> > and you can potentially reduce the development cycle of 
> your next game,
> > since you already have a good basis to start from.
> 
> Great idea, does it really happen in practice? We seem to end 
> up starting from
> scratch every time. Or at least taking the old stuff, using 
> it as a base, and
> then rewriting most of it. New consoles don't help, of course :)

It does happen when the engine has some nice generalities to it. Even if
none of the actual code get shared (which is the usual case, admittedly),
the people involved usualy just rewrite what they had before, maybe with a
few neat tricks they've learned in the meantime. You can rewrite something
very quickly if you've done it once and solved all the hard problems. It's
that sort of "reuse" I meant, rather than the actual code itself.

[snip]
> Algorithms that scale well are a good thing... he says, 
> frantically trying to
> convince himself the thread's not OT.... :)

I don't think it's even close to OT - this is a games algorithms list, and
LoD algorithms are amongst the trickiest and most varied algorithms out
there.

> Jamie

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

Re: [Algorithms] Scalability costs

[Jamie F. <j.f...@re...>]

Jim Offerman wrote:

> > It's a nice idea, but is it worth the cost in development time?
>
> I think that any form of scalability (whether it is achieved through some
> pre-calculated LoD levels or through advanced techniques, like the
> forementioned VIPM, or even just scalability/modularity of your engine it
> self) is worth the cost in development time, since it potentially increases
> the replayability of your game and/or the reusability of your engine.
>
> So your game can potentially sell more copies of a longer period, since it
> can still compete with the newest releases (hence you earn more money with
> it)

Is this true in the PC market? For consoles, you get most sales in early days,
very little afterward. Tom's suggestion that you can still be looking good in n
years time isn't matched by sales in our circumstances.

> and you can potentially reduce the development cycle of your next game,
> since you already have a good basis to start from.
>

Great idea, does it really happen in practice? We seem to end up starting from
scratch every time. Or at least taking the old stuff, using it as a base, and
then rewriting most of it. New consoles don't help, of course :)

>
> Scalability combined with modularity can even save you development time. If
> you implement a general case CLOD algorithm in your engine, you can apply
> this technique to both your game entities (units, buildings, etc.) and your
> terrain. Such a decision may have far reaching consequences: Since all your
> geometry is essentially the same, you can also handle all your geometry in
> the same way, which means less special case algorithms (which makes sense,
> since everything is evolving to more general case algorithms anyway...) and
> thus less code to write and debug.

That definitely makes sense. All our geometry is going through the same
pipeline. CLOD does not make sense for us given time constraints, and it
doesn't fit the hardware too well either (according to our somewhat limited
research :). Next generation of games, we may try something a little more
procedural, but not for the mo....

Algorithms that scale well are a good thing... he says, frantically trying to
convince himself the thread's not OT.... :)

Jamie

Re: [Algorithms] FPS Questions

[Dave S. <Dav...@sd...>]

> (1) Is there a universally agreed way to calculate
> Frame-Per-Second information?
> 

It's platform-dependent.

> (2) What is the acceptable FPS for today's 3D games?
> 

Good animation is 30 fps.  So so...20.  15 or less is blah.
Anymore than 30 is just game engine hype. :-)

-DaveS

Re: [Algorithms] How to derive transformation matrices

[Stephen J B. <sj...@li...>]

On Sun, 23 Jul 2000, Lorrimar wrote:

> I'm curious on how to derive transformation matrices in 2d and 3d for things
> like shear and rotate. I've had an attempt at the maths but it didn't really
> work out. I'm wondering if anyone knows any internet resources that derive
> these matrices, and not just provide them.
 
Read this:

  http://web2.airmail.net/sjbaker1/matrices_can_be_your_friends.html

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

RE: [Algorithms] Bullets on walls

[Stephen J B. <sj...@li...>]

On Sun, 23 Jul 2000, Brian Marshall wrote:

> 	The N64 supports this op. It was used for the bullet holes in Perfect Dark
> (and Goldeneye.). It still doesn't give a glitch free result. It does 'clip'
> to the edges on polygons when the decal goes over the edge of the polygon
> its sat on, but its really just scissoring with Z to do that.
> 	One thing to remember is that the error in the z slope calculations on the
> small decal polygon is higher than that on a larger (in screen space)
> polygon. So you are always going to have some accuracy worries. Using one
> decal polygon the same size as the surface it's resting on may work very
> well. With individual decals someone will always get them all on one wall if
> you let them - which is a big hit with individual decals, small with one big
> decal.
> 	Unless you can use precisely the same polygon for generating Z values you
> will need to add Z-bias to minimize glitching.
 
Strictly speaking (in OpenGL at least), even making the polygons the
same size won't guarantee no Z-fighting.  The OpenGL spec allows implementations
to generate different Z values even when vertices are shared when certain GL
states are not shared.

The reason for that is that you might (for example) have to do a software
fallback for one set of states and not for the other - since software and
hardware rendering are unlikely to generate the exact same Z values, you
can't guarantee no Z-fighting.

However, you'll probably get away with it on most machines.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] Scalability costs

[Jim O. <j.o...@in...>]

> It's a nice idea, but is it worth the cost in development time?

I think that any form of scalability (whether it is achieved through some
pre-calculated LoD levels or through advanced techniques, like the
forementioned VIPM, or even just scalability/modularity of your engine it
self) is worth the cost in development time, since it potentially increases
the replayability of your game and/or the reusability of your engine.

So your game can potentially sell more copies of a longer period, since it
can still compete with the newest releases (hence you earn more money with
it) and you can potentially reduce the development cycle of your next game,
since you already have a good basis to start from.

Scalability combined with modularity can even save you development time. If
you implement a general case CLOD algorithm in your engine, you can apply
this technique to both your game entities (units, buildings, etc.) and your
terrain. Such a decision may have far reaching consequences: Since all your
geometry is essentially the same, you can also handle all your geometry in
the same way, which means less special case algorithms (which makes sense,
since everything is evolving to more general case algorithms anyway...) and
thus less code to write and debug.

Jim Offerman

Innovade
- designing the designer

RE: [Algorithms] Scalability costs

[Tom F. <to...@mu...>]

Well, that's the real trick, isn't it? You certainly need some sort of
order-of-magnitude scalability - existing cards and systems have that large
a variation in performance - so you need to invest the coder development
time anyway. The real trick is getting that scalability without chewing
through artist and animator time. And for most things, the stuff I talked
about at WGDC(*) fits the bill nicely, which is cool. Particle systems are
dead easy to scale as long as you build it into the system at design time
(ditto for explosions, lightning, etc). And landscapes have been talked
about endlessly...

Then there's the basic scalabiity of what texturing and rendering you use -
that's a case of picking sensible fallback rendering styles when your
fabulous eight-texture bumpmapping shadowed thing doesn't run fast enough on
a Voodoo1. Resoloution, texture memory, display depth, etc. fallbacks
(basically, make mipmaps, and be ready to ditch any stencil-buffer or
destination alpha effects).

All these things need to be done anyway to cope with current cards, and it's
a good idea to plan ahead for two reasons. First, you can re-use a lot of
your engine (assuming it fits the game type), and second, if you slip by six
months, your game doesn't look obsolete when it's released (which certainly
has happened to some games that slip).

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

(*) http://www.muckyfoot.com/downloads/tom.shtml

> -----Original Message-----
> From: Jamie Fowlston [mailto:j.f...@re...]
> Sent: 31 July 2000 12:06
> To: gda...@li...
> Subject: Re: [Algorithms] Scalability costs
> 
> 
> It's a nice idea, but is it worth the cost in development time?
> 
> Jamie
> 
> 
> Jim Offerman wrote:
> 
> > Hail to scalability :-)
> >
> > Jim Offerman
> >
> > Innovade
> > - designing the designer
> >
> > ----- Original Message -----
> > From: "Tom Forsyth" <to...@mu...>
> > To: <gda...@li...>
> > Sent: Monday, July 31, 2000 11:04 AM
> > Subject: RE: [Algorithms] Terrain Organization
> >
> > > Indeed - my goal for graphics systems is that when they 
> are released, they
> > > should be able to bring even the best existing machine 
> down to sub-1Hz
> > speed
> > > if you turn all the detail levels up, and yet have 
> perfectly acceptable
> > > performance on five-year-old machines with the auto-LoD 
> system on. That
> > way
> > > you know (a) you've done a good job of scaling stuff, (b) 
> you're pretty
> > sure
> > > you can re-use the engine (or something derived from it) 
> for the next
> > > project, and (c) people will still play your game in five 
> years - it won't
> > > look sad. Oh yes, and (d) you might get some good 
> bundling deals with new
> > > graphics cards - and they're always welcome.
> > >
> > > Tom Forsyth - Muckyfoot bloke.
> > > Whizzing and pasting and pooting through the day.
> > >
> > > > -----Original Message-----
> > > > From: Jim Offerman [mailto:j.o...@in...]
> > > > Sent: 31 July 2000 08:09
> > > > To: gda...@li...
> > > > Subject: Re: [Algorithms] Terrain Organization
> > > >
> > > >
> > > > > As for not everyone having TnL cards, well, I thought that
> > > > any game which
> > > > is
> > > > > *now* in development will probably run on fast systems. By
> > > > fast I mean
> > > > either
> > > > > TnL, or on CPUs which are fast enough that regular cards
> > > > don't suffer too
> > > > > much. Anyway, this is up to you, it depends on you budget
> > > > and a lot of
> > > > other
> > > > > things.
> > > >
> > > > If you are going to implement some form of CLOD (this is
> > > > where Tom Forsyth
> > > > would promote using VIPM - which is not a bad idea at all), I
> > > > think you
> > > > should couple the runtime error calculations to your fps...
> > > > i.e. if your fps
> > > > drops, crank down all lod levels in the game until the 
> fps reaches an
> > > > acceptable level. Your gime might be spitting out 100K tris
> > > > per second on a
> > > > souped up PIII with GeForce2 GTS and pump through a humble
> > > > 15K on a PII with
> > > > TNT PCI.
> > > >
> > > > And, since you have tied your CLOD calculations to the 
> fps you could
> > > > (theoratically) also truly design your game for the future -
> > > > i.e. use models
> > > > which by todays standards contain far to many triangles, the
> > > > CLOD will keep
> > > > performance acceptable on today's high end hardware and
> > > > increase detail on
> > > > tomorrow's hardware. Imagine playing Half-Life again, 
> finding that the
> > > > overall detail has increased by a factor ten.
> > > >
> > > > Jim Offerman
> > > >
> > > > Innovade
> > > > - designing the designer
> > >
> > > _______________________________________________
> > > GDAlgorithms-list mailing list
> > > GDA...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> > >
> > >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] Scalability costs

[Jamie F. <j.f...@re...>]

It's a nice idea, but is it worth the cost in development time?

Jamie


Jim Offerman wrote:

> Hail to scalability :-)
>
> Jim Offerman
>
> Innovade
> - designing the designer
>
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: <gda...@li...>
> Sent: Monday, July 31, 2000 11:04 AM
> Subject: RE: [Algorithms] Terrain Organization
>
> > Indeed - my goal for graphics systems is that when they are released, they
> > should be able to bring even the best existing machine down to sub-1Hz
> speed
> > if you turn all the detail levels up, and yet have perfectly acceptable
> > performance on five-year-old machines with the auto-LoD system on. That
> way
> > you know (a) you've done a good job of scaling stuff, (b) you're pretty
> sure
> > you can re-use the engine (or something derived from it) for the next
> > project, and (c) people will still play your game in five years - it won't
> > look sad. Oh yes, and (d) you might get some good bundling deals with new
> > graphics cards - and they're always welcome.
> >
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> >
> > > -----Original Message-----
> > > From: Jim Offerman [mailto:j.o...@in...]
> > > Sent: 31 July 2000 08:09
> > > To: gda...@li...
> > > Subject: Re: [Algorithms] Terrain Organization
> > >
> > >
> > > > As for not everyone having TnL cards, well, I thought that
> > > any game which
> > > is
> > > > *now* in development will probably run on fast systems. By
> > > fast I mean
> > > either
> > > > TnL, or on CPUs which are fast enough that regular cards
> > > don't suffer too
> > > > much. Anyway, this is up to you, it depends on you budget
> > > and a lot of
> > > other
> > > > things.
> > >
> > > If you are going to implement some form of CLOD (this is
> > > where Tom Forsyth
> > > would promote using VIPM - which is not a bad idea at all), I
> > > think you
> > > should couple the runtime error calculations to your fps...
> > > i.e. if your fps
> > > drops, crank down all lod levels in the game until the fps reaches an
> > > acceptable level. Your gime might be spitting out 100K tris
> > > per second on a
> > > souped up PIII with GeForce2 GTS and pump through a humble
> > > 15K on a PII with
> > > TNT PCI.
> > >
> > > And, since you have tied your CLOD calculations to the fps you could
> > > (theoratically) also truly design your game for the future -
> > > i.e. use models
> > > which by todays standards contain far to many triangles, the
> > > CLOD will keep
> > > performance acceptable on today's high end hardware and
> > > increase detail on
> > > tomorrow's hardware. Imagine playing Half-Life again, finding that the
> > > overall detail has increased by a factor ten.
> > >
> > > Jim Offerman
> > >
> > > Innovade
> > > - designing the designer
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> >
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Terrain Organization

[Jim O. <j.o...@in...>]

Hail to scalability :-)

Jim Offerman

Innovade
- designing the designer

----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: <gda...@li...>
Sent: Monday, July 31, 2000 11:04 AM
Subject: RE: [Algorithms] Terrain Organization


> Indeed - my goal for graphics systems is that when they are released, they
> should be able to bring even the best existing machine down to sub-1Hz
speed
> if you turn all the detail levels up, and yet have perfectly acceptable
> performance on five-year-old machines with the auto-LoD system on. That
way
> you know (a) you've done a good job of scaling stuff, (b) you're pretty
sure
> you can re-use the engine (or something derived from it) for the next
> project, and (c) people will still play your game in five years - it won't
> look sad. Oh yes, and (d) you might get some good bundling deals with new
> graphics cards - and they're always welcome.
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> > -----Original Message-----
> > From: Jim Offerman [mailto:j.o...@in...]
> > Sent: 31 July 2000 08:09
> > To: gda...@li...
> > Subject: Re: [Algorithms] Terrain Organization
> >
> >
> > > As for not everyone having TnL cards, well, I thought that
> > any game which
> > is
> > > *now* in development will probably run on fast systems. By
> > fast I mean
> > either
> > > TnL, or on CPUs which are fast enough that regular cards
> > don't suffer too
> > > much. Anyway, this is up to you, it depends on you budget
> > and a lot of
> > other
> > > things.
> >
> > If you are going to implement some form of CLOD (this is
> > where Tom Forsyth
> > would promote using VIPM - which is not a bad idea at all), I
> > think you
> > should couple the runtime error calculations to your fps...
> > i.e. if your fps
> > drops, crank down all lod levels in the game until the fps reaches an
> > acceptable level. Your gime might be spitting out 100K tris
> > per second on a
> > souped up PIII with GeForce2 GTS and pump through a humble
> > 15K on a PII with
> > TNT PCI.
> >
> > And, since you have tied your CLOD calculations to the fps you could
> > (theoratically) also truly design your game for the future -
> > i.e. use models
> > which by todays standards contain far to many triangles, the
> > CLOD will keep
> > performance acceptable on today's high end hardware and
> > increase detail on
> > tomorrow's hardware. Imagine playing Half-Life again, finding that the
> > overall detail has increased by a factor ten.
> >
> > Jim Offerman
> >
> > Innovade
> > - designing the designer
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>