Gasman demo
in [Commodore]
|
Prev: MPS 1270A compatibility
Next: plus/4 GEOS questions
From: A936 on 17 Jan 2006 06:19 Jason wrote: > A936(a)hotmail.com wrote: > > The one frame constraint is mandatory for machines with hw sprites > > otherwise you'll see flicker, but that's not so for sw sprites. > Actually, that's wrong; hardware sprites don't *have* to be moved every > frame because they just sit there and wait for their next update, not Actually I was thinking of the raster tricks being played to get more than the supported 8 sprites, since the context was a 24 sprite demo. To play any raster tricks you have to do things each frame or there will be flicker. Am I okay now :-) ? > damaging the background or indeed each other - the reason they tend to move > every frame is quite simple, it's because anything moving on any system > looks better if it shifts every frame. If the programmer wants, the C64 can Every frame update is important if you have very fast moving objects on screen, but that is almost never the case because the game would be impossible to play. Just FYI: I am not aware of a single Spectrum game that is full frame rate. The games known for their ultra smoothness (Zynaps, Ghouls 'n' Ghosts come to mind) are updated every two frames and are not the worse for it. Certainly have a peak at Zynaps as it's worth a look for its scrolling. Another popular example that isn't quite as smooth but nevertheless looks quite good is Green Beret and its update rate is every three frames (two when there's not much happening on screen). > > If you really want to be honest about the pros for sprite hw, you > > also have to look at the cons. My personal opinion is hw should > > be used as a substitute for processor speed and only then. > > Otherwise cpu will always do it better. > If the Spectrum were about a hundred times faster than the C64 and not just > two to two and a half times faster that might be a vaild viewpoint, but > since one 16x16 software sprite needs 48 bytes [1] of data and every > ... > writes to do the same with C64 hardware and that's a vast difference; the > former needs 96 times the speed, the latter 112. 96 times or 112 times what? Those are big numbers but I think you are seriously overestimating the processor equivalent of the c64 sprite hw. And I will show you how: http://www.geocities.com/aralbrec/tidbits/demo.zip This is a demo showing 24 sprites moving around in linear motion that was initially set randomly. Each sprite is also animated at independent frame rates. Each sprite is 16x16 pixels in size. There is approximately an equal mixture of four kinds of sprites: masked, or, xor and load. This kind of mixture is roughly equivalent to 24 sprites somewhere between mask and or. In addition, the sw is dynamically rotating the sprites -- these sprites are NOT stored as prerotated bitmaps. The sprite engine being used does not synchronize with the raster and yet it avoids flicker because it never erases anything. It uses a dirty rectangles method at a character resolution (8x8 pixel chars) to only draw portions of the screen needing update. The flicker is eliminated by completely drawing a single character's graphics (background and all sprites occupying the char) into an 8 byte buffer before quickly copying the final result to screen. Now the caveats: this engine is quite far from how fast things can be done on the spectrum for several reasons, the most important of which is that it was desirable to have the engine interruptable so no stack tricks could be used. On the Spectrum stack tricks would make things at least twice as fast (I have roughly sketched this out). Also, the next version of this lib will be around 30% faster as some of the algorithms used were less than optimal. Anyway enough with the backgound. This demo, with the 24 sprites, takes about 5 frames between each update. The motion is jerky and the mouse not too responsive (enable Kempston mouse in your emulator, hold down enter to freeze the sprites and move the mouse comfortably for comparison). Let's suppose the Spectrum were twice as fast (7MHz). Get into your emulator options and adjust the cpu speed. Most current emulatos will allow this -- I'm using Spectaculator and you can find cpu speed in "tools->options->hardware tab". At twice the speed, the demo is very smooth indeed. Someone from the c64 camp a long time ago said being twice as fast wasn't significant but I think this demonstrates that it certainly is. Anyways, go ahead and up the speed to 100 times and see the blazing fast motion in the demo. So no, I don't think the cpu needs to be 96-112 times faster to match the c64 sprite hw :-)) As an aside -- reducing frame rates can be handled gracefully. By making sure the main sprite is updated frequently (every frame or every other frame) and then do 1/3 of the sprites every frame rather than all every 3 frames, you can get much better visual results. > Then there's the issues of colour clash which can't be resolved with software. Granted. Simon posted the following -- I thought it was in your post too but I was mistaken so I'm going to cut and paste here. Simon Scott wrote: >> sure those 92 sprites pass through the same pixel row frequently >> -- how difficult would that be to duplicate on a hw machine with >> no flicker allowed? > >Not very. But this is a like for like comparison. With 8 hw sprites, it would seem to me to be impossible to have more than 8 in the same raster at the same time. Which is why I find moving 24 sprites in a sinusoidal shape a little disingenuous for even a "like for like" comparison. Maybe it would be more interesting just to have 24 sprites moving up and down on the same pixel row? I don't know.. maybe I'm being clueless again; I certainly don't know all the tricks.
From: Simon Scott on 17 Jan 2006 06:44 A936(a)hotmail.com wrote: > Anyway enough with the backgound. This demo, with the > 24 sprites, takes about 5 frames between each update. Wow, what a post. Anyway, my only point here is - if it aint full rate, it aint worth doing. Updating every frame on the c64 (moving one pixel per frame) means moving (on PAL) 50 pixels per frame, or approximately 1/6th of the screen width. That means it takes 6 seconds to move from one side of the screen to the other. Hardly 'too fast', just smooth. > > With 8 hw sprites, it would seem to me to be impossible > to have more than 8 in the same raster at the same time. > Which is why I find moving 24 sprites in a sinusoidal shape > a little disingenuous for even a "like for like" comparison. > Maybe it would be more interesting just to have 24 > sprites moving up and down on the same pixel row? > > I don't know.. maybe I'm being clueless again; I certainly > don't know all the tricks. This is true - but remember that the c64 can do software sprites too :) Sometimes they were used in games where more than 8 sprites would be on the same rasterline (shootemups etc). For what its worth, it really aint that much of a limitation anyway. The point of the exercise was to compare faster processor/no hw sprites vs slower processor/hw sprites. Im currently writing a radix bucket sort for this very reason :)
From: Nick Humphries, via obd on 17 Jan 2006 06:47 On Tue, 17 Jan 2006 A936(a)hotmail.com wrote: > Just FYI: I am not aware of a single Spectrum game that > is full frame rate. The games known for their ultra smoothness > (Zynaps, Ghouls 'n' Ghosts come to mind) are updated every > two frames and are not the worse for it. Certainly have a peak > at Zynaps as it's worth a look for its scrolling. Another popular > example that isn't quite as smooth but nevertheless looks quite > good is Green Beret and its update rate is every three frames > (two when there's not much happening on screen). A quick aside for your aside: many programmers when interviewed by magazines about the games they were working on said that once they got the frame rate to 17fps, that would be good enough as that tricks the human eye into thinking it's a smooth animation. -- Nick Humphries, nick(a)egyptus.co.uk http://www.egyptus.co.uk/ Your Sinclair Rock'n'Roll Years http://www.ysrnry.co.uk/ YSRnRY documentary (1985 OUT NOW) http://www.ysrnry.co.uk/tvprog/ The Tipshop http://www.the-tipshop.co.uk/
From: W Marsh on 17 Jan 2006 07:22 On Tue, 17 Jan 2006 11:47:27 +0000, "Nick Humphries, via obd" <nickjunk(a)egyptus.co.uk> wrote: >On Tue, 17 Jan 2006 A936(a)hotmail.com wrote: > >> Just FYI: I am not aware of a single Spectrum game that >> is full frame rate. The games known for their ultra smoothness >> (Zynaps, Ghouls 'n' Ghosts come to mind) are updated every >> two frames and are not the worse for it. Certainly have a peak >> at Zynaps as it's worth a look for its scrolling. Another popular >> example that isn't quite as smooth but nevertheless looks quite >> good is Green Beret and its update rate is every three frames >> (two when there's not much happening on screen). > >A quick aside for your aside: many programmers when interviewed by >magazines about the games they were working on said that once they got the >frame rate to 17fps, that would be good enough as that tricks the human >eye into thinking it's a smooth animation. I think it depends on how much is actually moving, and what sort of motion it is. A Space Invaders sprite plodding across the screen is fine at 17FPS, but a rotating 3D landscape is just going to look horrible at anything under 30FPS (and even that is pushing things a bit).
From: Nick Humphries on 17 Jan 2006 08:01
"W Marsh" <wayne.marsh(a)gmail.com> wrote in message news:t6ops1pu0rg8kbho2t7589luo5vc9re4d0(a)4ax.com > I think it depends on how much is actually moving, and what sort of > motion it is. A Space Invaders sprite plodding across the screen is > fine at 17FPS, but a rotating 3D landscape is just going to look > horrible at anything under 30FPS (and even that is pushing things a > bit). Intriguing... but yes, I was assuming 2D graphics, and presumably 3D wireframe vectors can get away with the lower frame rate. As for filled vectors, I doubt either machine got anywhere near a high frame rate judging from the Freescape games' performace... -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG |