Gasman demo
in [Commodore]
|
Prev: MPS 1270A compatibility
Next: plus/4 GEOS questions
From: Pasi Ojala on 18 Jan 2006 02:43 On 2006-01-17, Daniel Mandic <daniel_mandic(a)ping.at> wrote: > The World consists of that framerate your eyes and brain are capable of. The human brain does not have a framerate. -Pasi -- "Everything changes, Aram." /He had just never thought that he would have to change, too./ -- Perrin in The Wheel of Time:"The Path of Daggers"
From: Daniel Mandic on 18 Jan 2006 04:31 Pasi Ojala wrote: > On 2006-01-17, Daniel Mandic <daniel_mandic(a)ping.at> wrote: > > The World consists of that framerate your eyes and brain are > > capable of. > > The human brain does not have a framerate. > > -Pasi ;-) I believe in much, but not in everything. Everyone recepts other, or likes other. Well, the differences are small but less is often more :-). Best Regards, Daniel Mandic
From: A936 on 18 Jan 2006 06:07 Jason wrote: > A936(a)hotmail.com wrote: > > 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 :-) ? > > Well, one sprite takes less than one scanline to position or reposition, so > it's hardly a massive overhead. If the multiplex isn't moving, some of the > really good ones'll even disable the sort to save CPU time time and the > pre-sorted systems usually used in demos don't have that overhead to start with. I am not arguing this at all :-) The original point I was leading to has been obscured a bit by the quoting. Anyway it is this: that it is not necessary to have full frame rate update for games. The hw has to act at full frame rate but sw doesn't. Exactly what frame rate is required depends on the game, size of moving objects, speed of moving objects, display resolution, size of display device, persistance of display device, distance of observer from display surface, how much else is moving on screen, blah blah blah. In conclusion, the only real way to find out is to try an implementation :D In this very round about way I am saying that, in calculating the processing load effectively replacing the c64 sprite hw, it is not necessary to duplicate exactly what the hw is doing. But I will indulge your numbers below anyways. > > Just FYI: I am not aware of a single Spectrum game that > > is full frame rate. The games known for their ultra smoothness > i'm pretty well versed with Spectrum games and have played Zynaps and R-Type > (another good example for the scrolling, i thought) quite a bit. And no, Heh heh. I know -- I know you from wos. > i've not seen a game scroll a significant amount of screen at full > framerate, but i believe lots of static screen titles move their sprites > either every or every other frame; our own first Spectrum game Reaxion (a > port of the C64 original) runs every frame, for example. Yeah I think every two frames is most common, every frame is rare I think and every three frames does happen. As soon as you hit a certain number or size of sprites, there's an issue with flicker, particularly on 48K machines which don't have a second display file. This always means timing display writes with the raster, which means time is spent during the first frame preparing the sprites and the second frame is used to follow the raster around and write into the display file. My analysis of what's common and not comes from looking at about a dozen games, so keep that in mind. Only 7000+ to go to get an accurate measure :) > [About software compared to hardware sprites] > > 96 times or 112 times what? > > More bytes transferred per sprite; moving a C64 sprite takes at most three > writes to memory and to get as close an equivalent as possible in software > the routine needs to read the background, AND mask, OR in the data and write > and then repair the damage. EOR'd or unmasked soft sprites are faster > (although still nowhere near as fast as software sprites) but it's probably > best to consider them "cheating" if the claim is they're as good as hardware > - they're taking a *significant* hit of CPU power, so they're not. > > > Those are big numbers but I think you are seriously overestimating the > > processor equivalent of the c64 sprite hw. > > Actually, i'm *under* calculating because i'm assuming 16x16 pixel objects > at the Spectrum end; that's only two thirds the size of the C64's hardware > sprites. My roughed maths didn't take into consideration live pixel > shifting (i pre-roll my software sprites for speed) of the sprite data, > configuring the read/writes or anything else like that either. > > > 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 :-)) > > You're not really getting the point; to move a sprite up, down, left or > right can, if the MSB isn't considered for a moment, take as little as six > cycles, one DEC or INC command to the appropriate register. With 63 cycles > a scanline that's all eight sprites moved in that one scanline and even with > the MSB in use and some more complex calculations that leaves over scanlines > 300 left to do things like scroll the screen, plot software sprite bullets, > run the game logic, whatever else is needed No you're missing the point :) The fault in your logic is that the display is only updated at 50/60Hz. If the cpu can do all the movement, all the shifting, etc in ONE FRAME there is no visual difference between what the hw does and what the sw does. If you want to do a raster trick where a single sprite gets skewed to the right or left by changing its x position each raster line, I do the entire calculation during that one frame and draw the sprite that way without raster to raster timing. The demo shown took 5 frames to do what it was doing. Speed up the cpu 5x and everything is done in one frame. Going any faster makes zero difference because you can't see intermediate frames. Conclusion: the demo completely replaces the 64 hw equivalent at 5x cpu speed. It actually goes beyond that because the sw is more powerful than the c64 hw: there are no restrictions on what sprites can be where and when. However as I noted, 2x speed produces a smooth result I would be satisfied with, and that is my earlier point that it is not necessary for the sw to work at full frame rate to *effectively* replace the 64 sprite hw. > (although still nowhere near as fast as software sprites) but it's probably > best to consider them "cheating" if the claim is they're as good as hardware > - they're taking a *significant* hit of CPU power, so they're not. What we are talking about here is games. Very little cpu is taken by the game logic itself -- it is the display logic in non-hw assisted machines that takes almost all the cpu time. If we are not talking games, then we are talking a mouse pointer maybe and a single such sprite takes little cpu time. > For game use, the chances that every single sprite wants to exist on the > same scanline are pretty low and, if there are cases where more sprites are > needed per line, there's nothing to stop the C64 resorting to software > sprites as well or more commonly a mixture. i've already mentioned Uridium Yep, I agree with this too. But again the original point has been lost. This 24 sprite demo in one frame thing was proposed to see if the spectrum could do what the hw was doing in one frame. In fact it was a very calculated proposal that would not reveal a weakness in the hw, that of only being able to display 8 of those sprites in a single pixel row. That's why the sinusoidal path was so nonchalantly suggested. The sw implementation will, of course, be more powerful than the hw implementation because it is able to draw the sprites following any arbitrary path. With that in the clear, I look forward to the demos :) > And for demo use, cheat like *buggery* and hope the viewer doesn't notice. =-) Heh heh.
From: Simon Scott on 18 Jan 2006 06:26 Daniel Mandic wrote: > Pasi Ojala wrote: > >> On 2006-01-17, Daniel Mandic <daniel_mandic(a)ping.at> wrote: >> > The World consists of that framerate your eyes and brain are >> > capable of. >> >> The human brain does not have a framerate. >> >> -Pasi > > > ;-) > > I believe in much, but not in everything. > > Everyone recepts other, or likes other. Well, the differences are small > but less is often more :-). > > > > Best Regards, > > Daniel Mandic Killfile! Im on fire!
From: A936 on 18 Jan 2006 06:36
White Flame (aka David Holz) wrote: > > Anyway enough with the backgound. This demo, with the > > 24 sprites, takes about 5 frames between each update. > And how much CPU does it take? The C64 can do 24 504-pixel sprites in 1 It will be close to 95% or so. The program is in C but most of the time is spent in the sprite library. > frame taking only about 25-35% CPU in a normal game situation (well-made > general sorting multiplexer). Well this actually matters little. In a game situation (which is the only thing multiple sprites are useful for) only a small fraction of the cpu is used for the game logic. In non-hw assisted machines (like the Spectrum) it is normal for the display engine to take 90%+ of the cpu time. > If you can do 24 64-pixel (since your actual > sprite images are only 8x8 pixels) The images are 8x8 pixels but 16x16 pixels are being drawn. There is no cheating here; even the blank areas of the mask sprites are going through the full treatment of masking and oring nothing. > sprites in 5 frames taking 100% CPU, > that's a vast difference. Boost the CPU by 5x and you have full frame rate. > Now boost the CPU by another 8x to get 512-pixel sprites. Boost by 2x to get 512 pixels... but it doesn't scale that way. There is a lot more going on under the hood than just plotting to the screen. The plotting part is proportional to the number of pixel bytes but the movement part isn't. You can see this in the demo. Despite the fact the update rate is every 5 frames, the entire screen gets drawn in a little over 1 frame. Between 3 and 4 frames are involved in other household duties to support the display algorithm. This algorithm is not intended to support lots of sprites on screen at the same time :) |