View Single Post
Old 01 December 2015, 00:26   #103
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Originally Posted by Codetapper View Post
You're simplifying things here. How many games use 16x16 bobs? And how many restrict the enemies to 2 or 4 pixel horizontal movement?
Quite a lot. Anyway that's beside the point. You brought up the case of small bobs, 2x2 in fact, which is smaller than anything i've ever used. 8x8 is perfectly reasonable for bullets, or bits of shrapnel or whatever.

Since you've been talking about Chuck Rock, most of those are 32, 48 or even 64 pixels wide.
and in only 3 bitplanes. I mentioned Chuck Rock because it draws the bobs behind the main playfield, and i'd speculated about how that was done (and got it wrong, ok). Most of Mr Beanbag's enemies are 32x32, 48x48 is common on later levels. 16x16 or smaller is usually for thrown or fired objects, animated collectables &c.

Here is 48x48 elephant and 64x32 tiger:

Maybe Mr Beanbag is an overly simplified game engine compared to Chuck Rock and you're thinking about that specific case of horizontal/vertical only movement in only 2 or 4 pixel chunks but not considering a more general game? One game I'm working on has the main character moving 3 pixels per frame for example.
It's not an oversimplified engine. It's an overcomplicated engine according to you. Of course it can handle any complexity of movement, but if you do keep objects to word boundaries, you get the benefits of that. There are 16x64 portcullis objects that swing up and down, for instance, and 64x16 moving platforms that move in a similar pattern, plus all of the beans and various other collectable items oscillate up and down. Not wasting time on these objects means i can spend it elsewhere, or have loads of them on screen. Main character is a sprite in any case so that's academic (in Mr Beanbag and in Chuck Rock). Many of the objects in Chuck Rock appear to move at constant sideways speeds, some quite fast.

And my point is if you have 50 objects to check, that's 50 series of calculations you're doing to work out if the bob can save one extra word (after retrieving exact pixel dimensions, so that's even more CPU usage)
How is retrieving "exact pixel dimensions" any more CPU usage? It fits in a word in either case... 50 objects on screen would be pretty chaotic anyway, just picture that for a second. There are only 70 background tiles on the screen, with 32x32 tiles. And it's not "one extra word". We're talking about *doubling the size of all the blits of 16-pixel wide objects*. Or for 32-pixel wide objects, it's 50% extra blitting.

And if the blits are small (only a few pixels high) the blitter will be finished and wasting time waiting for all your extra calculations to take place.
but you were just saying that most game objects are large... make your mind up...

Maybe in your simple restricted-to-up-down-left-right game it's worth it, I don't know. For a general game it sounds like the 6.25% of the time on average the bob would be exactly on a word boundary isn't worth the complexity added with the code.
But it's hardly any complexity, it's literally a few extra instructions, and you can *arrange* for objects to fall on word boundaries more often than they would by pure chance. It is a simple matter to ensure that an enemy's bullets go at 8 pixels per frame, for instance, or that an enemy charges at 4 pixels per frame.

Last edited by Mrs Beanbag; 01 December 2015 at 00:32.
Mrs Beanbag is offline  
Page generated in 0.06114 seconds with 9 queries