Thread: Re: [Algorithms] FPS Questions (Page 3)
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: gl <gl...@nt...> - 2000-08-01 21:54:30
|
> I'm surprised no one has mentioned thus far the most significant > difference between movie frames and real-time gfx frames. I know I drag you > all through this each time this discussion comes up, but I'll rehash once > more. Erm, <cough>. Incidentally, here's an excellent motion blur description (and demo executable) that perfectly demonstrate why accumlation buffer blur is nothing to do with real motion blur (ie. it doesn't contain any extra information, unlike true motion blur): http://freespace.virgin.net/hugo.elias/graphics/x_motion.htm -- gl |
|
From: jason w. <jas...@po...> - 2000-08-02 00:06:20
|
> executable) that perfectly demonstrate why accumlation buffer blur is you can use a accumulation buffer (or t buffer) to do proper motion blur... there's nothing that prevents you from using it to do the averaging of the multiple frames for each displayed frame, and that's probibly the best way to go about it. you do see a lot of people implimenting simple previous frame blurrs.. basicly, because it's cheap :) |
|
From: Jim O. <j.o...@in...> - 2000-08-02 07:56:25
|
> you can use a accumulation buffer (or t buffer) to do proper motion blur... > there's nothing that prevents you from using it to do the averaging of the > multiple frames for each displayed frame, and that's probibly the best way > to go about it. To simulate motion blur, rather than average a few frames, shouldn't we have a function like: P(1) = R(1) - C * P(0) Where P(0) and P(1) are the color values of some pixel in the (accumulation) buffer at t = 0 and t = 1 and R(1) is the color value for the same pixel, resulting from the rendering of a frame at t = 1. C is a constant, which controls the decay of light / the amount of motion blur. Note that P(2) = R(2) - C * P(1) = R(2) - C * (R(1) - C * P(0)) and so forth for P(3) to P(n). Probably (and I am guessing here), C shouldn't be a constant at all, but rather dependent on the velocity (both linear and radial) of the viewer, as I think that motion blur increases with velocity. Jim Offerman Innovade - designing the designer |
|
From: gl <gl...@nt...> - 2000-08-02 10:15:52
|
> > executable) that perfectly demonstrate why accumlation buffer blur is > > you can use a accumulation buffer (or t buffer) to do proper motion blur... > there's nothing that prevents you from using it to do the averaging of the > multiple frames for each displayed frame, and that's probibly the best way > to go about it. Good point. But then of course you need to supersample the framerate. Which brings us neatly back to why we need higher fps in the first place. -- gl |
|
From: Stephen J B. <sj...@li...> - 2000-08-02 14:18:09
|
On Wed, 2 Aug 2000, gl wrote: > > > executable) that perfectly demonstrate why accumlation buffer blur is > > > > you can use a accumulation buffer (or t buffer) to do proper motion > blur... > > there's nothing that prevents you from using it to do the averaging of the > > multiple frames for each displayed frame, and that's probibly the best way > > to go about it. > > Good point. But then of course you need to supersample the framerate. > Which brings us neatly back to why we need higher fps in the first place. Well, strictly, you should still use motion blur even at 60Hz or higher because motion blur is really just *temporal* antialiasing. The canonical example is that even on 60Hz systems, a rapidly spinning wheel will appear to slow down or run backwards when it revolves at speeds higher than 60Hz (or 60Hz divided by the rotational symmetry of the wheel). Motion blur is the way to fix that - and in theory, you always need it in any system that has a discreet 'frame rate'. Unfortunately, doing *good* motion blur (not just averaging together a bunch of static images - which doesn't really fix the temporal antialiasing problem) is incredibly difficult - you really have to render in four dimensions or something. 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 |
|
From: Stephen J B. <sj...@li...> - 2000-08-02 16:39:55
|
On Wed, 2 Aug 2000, Stephen J Baker wrote:
> On Wed, 2 Aug 2000, gl wrote:
>
> > > > executable) that perfectly demonstrate why accumlation buffer blur is
> > >
> > > you can use a accumulation buffer (or t buffer) to do proper motion
> > blur...
> > > there's nothing that prevents you from using it to do the averaging of the
> > > multiple frames for each displayed frame, and that's probibly the best way
> > > to go about it.
> >
> > Good point. But then of course you need to supersample the framerate.
> > Which brings us neatly back to why we need higher fps in the first place.
>
> Well, strictly, you should still use motion blur even at 60Hz or higher
> because motion blur is really just *temporal* antialiasing. The
> canonical example is that even on 60Hz systems, a rapidly spinning wheel
> will appear to slow down or run backwards when it revolves at speeds
> higher than 60Hz (or 60Hz divided by the rotational symmetry of the
^^^^^^^^^^^^^
Ooops! That should be 30Hz.
*Half* the frame rate.
> wheel). Motion blur is the way to fix that - and in theory, you always
> need it in any system that has a discreet 'frame rate'.
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
|
|
From: gl <gl...@nt...> - 2000-08-02 19:25:45
|
> > Well, strictly, you should still use motion blur even at 60Hz or higher > > because motion blur is really just *temporal* antialiasing. Exactly, but just as with anti-aliasing, if you can afford to render at 4 times the resolution, you might aswell just use 4 times the resolution, rather than downsample. Where it is useful (as someone touched on earlier) is where you are limited by the refresh rate of a particular monitor, and you have the option to render faster - you could then create real blur and get more movement info into each frame. But just as with anti-aliasing, you need a factor of 2 ideally, so you'd have to be able to run at least twice as fast, preferrably 4 times. -- gl |
|
From: gl <gl...@nt...> - 2000-08-02 19:51:51
|
> Exactly, but just as with anti-aliasing, if you can afford to render at 4 > times the resolution, you might aswell just use 4 times the resolution, Well, two times the resolution maybe ;) -- gl |
|
From: Tom F. <to...@mu...> - 2000-08-02 10:23:23
|
> From: Stephen J Baker [mailto:sj...@li...] [snip] > So what do console games do about interlace artifacts? Are > they actually > running at half the vertical resolution of broadcast TV - or > do they have > fancy antialiasing filters to deal with it? The Dreamcast certainly has very good anti-flicker filter that seems to work brilliantly - we didn't have to worry about horizontal white lines at all - they just work. IIRC, the PS1 has none, and horizontal lines flicker badly. I don't know about any of the other next-gen consoles, but I assume they have some sort of filtering. But it's only recently been a problem - most older consoles only ran at 320x240 anyway, so horizontal lines were on both fields, and didn't flicker (nearly as much). [snip] > 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 Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. |
|
From: Tom F. <to...@mu...> - 2000-08-02 10:27:42
|
Insane. But possibly just insane enough to actually work. Impressive. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: Conor Stokes [mailto:cs...@tp...] > Sent: 02 August 2000 05:02 > To: gda...@li... > Subject: Re: [Algorithms] FPS Questions > > > This is where I make evil confessions of things I've done :) > > Well, the main evil thing is actually using a form of AI system to > calculate LoD levels on the fly to get a constant frame rate > in specific > environments. A genetic algorithm which modified a neural > network style > structure on the fly. The neural network style object used an kd-tree > structure with output vectors stored at corner points of the > bounding hyper > boxes. [snip to avoid warping the mind] > Mwhuhahahahaha. Indeed. > Conor Stokes |
|
From: Conor S. <cs...@tp...> - 2000-08-02 12:19:56
|
> Insane. But possibly just insane enough to actually work. Impressive. > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > Probably :) Thats the effect I like to go for. Mad professor. Conor Stokes |
|
From: Tom F. <to...@mu...> - 2000-08-02 11:06:37
|
There's a fade in as well as a fade out. Motion blur is "forwards" as well as backwards. The exception to this is bright lights that "burn" the retina (they don't really) - they don't have a fade-in, just a fade-out (as the retina cells recover). But they're special cases - most stuff fades in as well as out, so a straight summing of n rendered frames, each with timestamps distributed over period is the right thing to do. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: Jim Offerman [mailto:j.o...@in...] > Sent: 02 August 2000 08:18 > To: gda...@li... > Subject: Re: [Algorithms] FPS Questions > > > > you can use a accumulation buffer (or t buffer) to do proper motion > blur... > > there's nothing that prevents you from using it to do the > averaging of the > > multiple frames for each displayed frame, and that's > probibly the best way > > to go about it. > > To simulate motion blur, rather than average a few frames, > shouldn't we have > a function like: > > P(1) = R(1) - C * P(0) > > Where P(0) and P(1) are the color values of some pixel in the > (accumulation) > buffer at t = 0 and t = 1 and R(1) is the color value for the > same pixel, > resulting from the rendering of a frame at t = 1. C is a > constant, which > controls the decay of light / the amount of motion blur. > > Note that P(2) = R(2) - C * P(1) = R(2) - C * (R(1) - C * > P(0)) and so forth > for P(3) to P(n). > > Probably (and I am guessing here), C shouldn't be a constant > at all, but > rather dependent on the velocity (both linear and radial) of > the viewer, as > I think that motion blur increases with velocity. > > Jim Offerman > > Innovade > - designing the designer > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Jim O. <j.o...@in...> - 2000-08-02 14:19:36
|
> There's a fade in as well as a fade out. Motion blur is "forwards" as well > as backwards. The exception to this is bright lights that "burn" the retina > (they don't really) - they don't have a fade-in, just a fade-out (as the > retina cells recover). But they're special cases - most stuff fades in as > well as out, so a straight summing of n rendered frames, each with > timestamps distributed over period is the right thing to do. If you say so... Well, I am off to my well deserved vacation any minute now, so I am not very eager to give it any more thoughts at this time - perhaps in a week or two, when I'm back ;-). Jim Offerman Innovade - designing the designer |
|
From: Robert D. <RD...@ac...> - 2000-08-02 14:25:36
|
or it can display in non-interlaced mode, so the signal makes the scan lines appear on top of each other, and you don't get the flicker. thats what most consoles do when not in hi res mode. -----Original Message----- From: Stephen J Baker [mailto:sj...@li...] Sent: 02 August 2000 16:26 To: gda...@li... Subject: Re: [Algorithms] FPS Questions On Wed, 2 Aug 2000, Leath Muller wrote: > > So what do console games do about interlace artifacts? Are they actually > > running at half the vertical resolution of broadcast TV - or do they have > > fancy antialiasing filters to deal with it? > > It's just in the HW to pass the image out to your TV... as far as the > console is concerned, it's just a set resolution, say 320x240. The image > is split at the HW just before the video cable and after the internal > rasterization etc HW... Same as the ol' Amiga, Atari ST, etc... Ah - that explains it. Since TV's have ~480 scanlines (NTSC) - or 640 (PAL), the console must be repeating each scanline twice at 320x240, so there is no interlace issue and it can effectively pretend to be a 60Hz non-interlaced display. 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 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
|
From: Thatcher U. <tu...@tu...> - 2000-08-02 16:46:15
|
From: Robert Dibley <RD...@ac...> > or it can display in non-interlaced mode, so the signal makes the scan lines > appear on top of each other, and you don't get the flicker. > > thats what most consoles do when not in hi res mode. Yeah... I got acquainted with the intricacies of non-interlaced NTSC-like video modes while working on the VR Bike & VR Climber, in which I had to drive an arcade-style TV monitor from a regular VGA card. Whereas a regular NTSC frame has 525 horizontal lines for every two vertical syncs (i.e. 262.5 lines per field), the non-interlaced version drops the extra half-line, so you have 262 lines per field. Assuming a fixed horizontal scan rate, you end up with a slightly higher vertical scan rate. Directly connecting to a monitor or a TV is no problem for such a tweaked mode, but it probably would choke most pro video gear; for those kinds of applications we ran an ordinary VGA signal through a scan-converter box. If you diagram out the timings you can see how it all fits together, and it becomes apparent what a clever trick interlacing is. Unfortunately, on larger monitors in non-interlaced modes the individual scan lines can be excessively obvious. I did a bunch of experimenting, trying out modes with more horizontal lines, to combat this effect. To get more lines in a frame you have to speed up the horizontal sync or slow down the vertical sync, which is all within the capabilities of a standard VGA card. There are tradeoffs naturally; with a slower vertical sync you have a slower refresh and more obvious flicker, with a faster horizontal sync you may have less horizontal resultion depending on how the video card timings work out. The big problem for me though was that while all monitors could sync to a 262-line signal at ~60Hz refresh, they varied in how far out-of-spec you could drive them before they completely lost sync. I even went as far as hacking up a circuit to induce interlace against the will of the monitor by delaying the vsync signal on every other pulse, but that didn't really work reliably. Plus, interlaced modes look a little "shimmery" to me, not as nice and solid as non-interlaced modes. I ended up sticking with the 262-line mode, and not worrying about the obvious scan lines. If you look at old arcade games you can see that many of them have similar issues with scan lines. Anyway, I don't think I have a point, but I couldn't resist the urge to talk about the old days. -- Thatcher Ulrich http://tulrich.com |
|
From: Bass, G. T. <gt...@ut...> - 2000-08-02 17:49:30
|
>To simulate motion blur, rather than average a few frames, >shouldn't we have... How about having a rasterizer feature in hardware that can draw lines instead of pixels? Give it a motion vector for each object you're drawing, and instead of rasterizing pixels, it will rasterize lines passing through the actual pixel in screenspace, fading in alpha with distance from the actual pixel location. This would make an excellent simulation of light reflection caught on film from an object moving quickly in a straight line, though it wouldn't look very good for spinning cubes and such. I suppose you could provide a velocity vector per vertex and interpolate the blur vectors on a per-pixel basis. With blazing fill-rate I think this could become feasible, and look quite nice. Any IHV's up to the challenge? ;) Regards, Garett Bass gt...@ut... |
|
From: Steve W. <Ste...@im...> - 2000-08-02 20:31:39
|
> -----Original Message----- > From: Stephen J Baker [mailto:sj...@li...] > > Motion blur is the way to fix that - and in theory, > you always need it in any system that has a discreet 'frame rate'. > I think the playing experience would be increased if there is always motion blur in a multiplayer game to account for players that have faster connections. It always tweaks me to see a player disappear and reappear several virtual feet away as I die from what seems like no reason except the non-visual but all-powerful ping weapon. At least with blur I'd see something even if it is a stretched out player like the special effects in John Carpenter's "The Thing" that has what appears to be several pikes sticking into me. > > Unfortunately, doing *good* motion blur (not just averaging together > a bunch of static images - which doesn't really fix the temporal > antialiasing problem) is incredibly difficult - you really have > to render in four dimensions or something. > hmm, why couldn't a card streak a tris or even a mesh for us? It would be costly to blur in code, but wouldn't it be fairly cheap for the hardware to copy the tris and just streaking the last few bits interleaved with bits which form an outline of the form being blurred? Actually, a proper blur would probably take a sampling of bits across the mesh...I think a good reference for the visual effect would be "Flash" comic books....just multiple copies as in Mel Brooks' "SpaceBalls The Movie" when time is compressed. R&R |
|
From: Tom F. <to...@mu...> - 2000-08-10 15:17:47
|
Kim, you'll find that if you spend enough time in the pubs, the movies won't bother you any more. :-) And yes, I think they can be trained. Maybe it's from years of sitting staring at a bright white ZX Spectrum(*) screen while coding in basic that I've become allergic to low frame rates. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. (*) Home computer, contemporary (and clear superior, obviously) of the C64. I think it was called a TRS80 on the other side of the pond? Fantastically popular here in Britland. > From: Pallister, Kim [mailto:kim...@in...] [snip] > Which leads me to a question: do you folks think that the > eyes & brain can > be trained to better perceive such errors? The movies never > used to bother > me until I became a graphics programmer. Now it bugs me. > Also, PAL didn't > used to bother me, but now I find the lower frame rate > intolerable, which is > why I make a point of not watching TV when I am in the UK, > but spend the > time in pubs instead! > > Kim Pallister > > We will find a way or we will make one. > - Hannibal |
|
From: Andrew H. <an...@co...> - 2000-08-10 15:28:25
|
> staring at a bright white ZX Spectrum(*) screen while coding in basic that > (*) Home computer, contemporary (and clear superior, obviously) of the C64. > I think it was called a TRS80 on the other side of the pond? Fantastically > popular here in Britland. I think you might mean Timex Sinclair. The ZX-81 was a TS 1000 I think, but I don't know the number for the Spectrum. Andrew. |
|
From: Vianet <sc...@vi...> - 2000-08-10 15:53:37
|
please do not send messages to me anymore -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Andrew Howe Sent: August 10, 2000 11:25 AM To: gda...@li... Subject: Re: [Algorithms] FPS Questions > staring at a bright white ZX Spectrum(*) screen while coding in basic that > (*) Home computer, contemporary (and clear superior, obviously) of the C64. > I think it was called a TRS80 on the other side of the pond? Fantastically > popular here in Britland. I think you might mean Timex Sinclair. The ZX-81 was a TS 1000 I think, but I don't know the number for the Spectrum. Andrew. _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
|
From: Akbar A. <sye...@ea...> - 2000-08-13 04:15:06
|
>please do not send messages to me anymore ? jeeeeeeeesh, for me, reading steve's messages is like a break from all the hard coding and reading i have to deal with. hehe check the bottom of the list message if you want off the list. peace. akbar A. "We want technology for the sake of the story, not for its own sake. When you look back, say 10 years from now, current technology will seem quaint" Pixars' Edwin Catmull. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Vianet Sent: Thursday, August 10, 2000 11:00 AM To: gda...@li... Subject: RE: [Algorithms] FPS Questions please do not send messages to me anymore -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Andrew Howe Sent: August 10, 2000 11:25 AM To: gda...@li... Subject: Re: [Algorithms] FPS Questions > staring at a bright white ZX Spectrum(*) screen while coding in basic that > (*) Home computer, contemporary (and clear superior, obviously) of the C64. > I think it was called a TRS80 on the other side of the pond? Fantastically > popular here in Britland. I think you might mean Timex Sinclair. The ZX-81 was a TS 1000 I think, but I don't know the number for the Spectrum. Andrew. _______________________________________________ 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 |
|
From: Steve B. <st...@li...> - 2000-08-10 17:20:46
|
On Thu, 10 Aug 2000, Tom Forsyth wrote: > Kim, you'll find that if you spend enough time in the pubs, the movies won't > bother you any more. :-) It'll bother you - you just won't *remember* that it bothered you :-) > And yes, I think they can be trained. Maybe it's from years of sitting > staring at a bright white ZX Spectrum(*) screen while coding in basic that > I've become allergic to low frame rates. Your memory is leaky. The Spectrum was BLACK. You're thinking of the ZX80 and ZX81. > (*) Home computer, contemporary (and clear superior, obviously) of the C64. > I think it was called a TRS80 on the other side of the pond? Fantastically > popular here in Britland. No! TRS-80 (Pronounced 'Trash-Eighty') was a Tandy/Radio-Shack machine with a *real* keyboard, *real* display, etc, etc. V.Superior to anything Sinclair produced. I owned three of them at one time! In the US, the ZX-80/81 was called "Timex 1000" or something like that, I didn't think the Spectrubbish was ever marketted in the US. Hmmm - Sinclair computers - the memories... The wobbly RAM pack - the BlueTac to stop it sliding around the desk - the 'dead flesh' feel to the so-called "keyboard" (on the Spectrum). That the display was generated in software (on the ZX80) - so the screen went blank whenever you ran a program or hit a key or something. The adverts that said that you could control a nuclear power plant with it. (That same advert showed the Spectrum displaying a Union Jack - which it cannot do because it's graphics 'cells' could only contain two colours per cell). The migrane-simulation it displayed as it loaded stuff from tape. The *requirement* that you use short-cut keys for all BASIC reserved words - so their interpreter wouldn't have to actually parse the source code! Having to use THREE shift keys to get to some of the more "unusual" BASIC operators...unusual like '<' and '>' :-) <shudder> I remember the ZX80/ZX81 and Spectrum *very* well. Each was truly a complete piece of shit - even by the low standards of the time! You thought it was better than C64?!? I *don't* think so. Still - you could always upgrade to the Sinclair QL (Quick-Lashup) with it's infamous 'microdrives'. (If you had two microdrives, drive A couldn't read tapes written by drive B and vice-versa!) Clive Sinclair made an "Electric Car" too...can you say "Death Trap" ? :-) 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 |
|
From: gl <gl...@nt...> - 2000-08-13 03:06:28
|
Hey - leave the Spec alone! Pick on a computer your own size. (i dunno, maybe a Cray or something)... I liked the loading feedback - always nice to see a good real-time visualisation of what goes on inside these strange boxes (you wouldn't believe how hard I tried to figure out how to change the two colours for my loaders ;) Of course nothing ever loaded when you wanted it to, usually failing at the last second... and the quickloaders, well, let's not talk about those (remember adjusting your tape head alignment endlessly)? Ah, memories... -- gl ----- Original Message ----- From: "Steve Baker" <st...@li...> To: <gda...@li...> Sent: Thursday, August 10, 2000 5:15 PM Subject: RE: [Algorithms] FPS Questions > On Thu, 10 Aug 2000, Tom Forsyth wrote: > > > Kim, you'll find that if you spend enough time in the pubs, the movies won't > > bother you any more. :-) > > It'll bother you - you just won't *remember* that it bothered you :-) > > > And yes, I think they can be trained. Maybe it's from years of sitting > > staring at a bright white ZX Spectrum(*) screen while coding in basic that > > I've become allergic to low frame rates. > > Your memory is leaky. The Spectrum was BLACK. You're thinking of the > ZX80 and ZX81. > > > (*) Home computer, contemporary (and clear superior, obviously) of the C64. > > I think it was called a TRS80 on the other side of the pond? Fantastically > > popular here in Britland. > > No! TRS-80 (Pronounced 'Trash-Eighty') was a Tandy/Radio-Shack machine > with a *real* keyboard, *real* display, etc, etc. V.Superior to anything > Sinclair produced. I owned three of them at one time! > > In the US, the ZX-80/81 was called "Timex 1000" or something like that, > I didn't think the Spectrubbish was ever marketted in the US. > > Hmmm - Sinclair computers - the memories... > > The wobbly RAM pack - the BlueTac to stop it sliding around > the desk - the 'dead flesh' feel to the so-called "keyboard" (on the > Spectrum). That the display was generated in software (on the ZX80) > - so the screen went blank whenever you ran a program or hit a key > or something. > > The adverts that said that you could control a nuclear power plant > with it. (That same advert showed the Spectrum displaying a Union > Jack - which it cannot do because it's graphics 'cells' could only > contain two colours per cell). > > The migrane-simulation it displayed as it loaded stuff from tape. > > The *requirement* that you use short-cut keys for all BASIC reserved > words - so their interpreter wouldn't have to actually parse the > source code! Having to use THREE shift keys to get to some of the > more "unusual" BASIC operators...unusual like '<' and '>' :-) > > <shudder> > > I remember the ZX80/ZX81 and Spectrum *very* well. Each was > truly a complete piece of shit - even by the low standards of > the time! > > You thought it was better than C64?!? I *don't* think so. > > Still - you could always upgrade to the Sinclair QL (Quick-Lashup) > with it's infamous 'microdrives'. (If you had two microdrives, > drive A couldn't read tapes written by drive B and vice-versa!) > > Clive Sinclair made an "Electric Car" too...can you say "Death Trap" ? > > :-) > > > 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 > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Dominic R. <dro...@wa...> - 2000-08-10 15:32:28
|
The Trash80 was a whole different animal ( also 'obviously' inferior to the Speccy ) - it lacked the rubber 'dead flesh' keyboard for one thing. Those were the days. Dominic > -----Original Message----- > From: Tom Forsyth [mailto:to...@mu...] > Sent: 10 August 2000 16:15 > To: gda...@li... > Subject: RE: [Algorithms] FPS Questions > > > Kim, you'll find that if you spend enough time in the pubs, > the movies won't > bother you any more. :-) > > And yes, I think they can be trained. Maybe it's from years of sitting > staring at a bright white ZX Spectrum(*) screen while coding > in basic that > I've become allergic to low frame rates. > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > > (*) Home computer, contemporary (and clear superior, > obviously) of the C64. > I think it was called a TRS80 on the other side of the pond? > Fantastically > popular here in Britland. > > > > From: Pallister, Kim [mailto:kim...@in...] > > [snip] > > > Which leads me to a question: do you folks think that the > > eyes & brain can > > be trained to better perceive such errors? The movies never > > used to bother > > me until I became a graphics programmer. Now it bugs me. > > Also, PAL didn't > > used to bother me, but now I find the lower frame rate > > intolerable, which is > > why I make a point of not watching TV when I am in the UK, > > but spend the > > time in pubs instead! > > > > Kim Pallister > > > > We will find a way or we will make one. > > - Hannibal > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Keith Z.L. <ke...@dr...> - 2000-07-31 18:12:39
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X