English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 30 November 2015, 23:08   #101
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Codetapper View Post
Apart from a few games like Rick Dangerous that use 24 pixel wide bobs (so the graphics are standard across all platforms), I would say you'd hardly find any games that don't have the majority of their graphics very close to a 16 pixel wide boundary.
The reasoning here is oddly circular... obviously if the bob engine only supports images with widths of multiples of 16, it would be wasteful not to design your graphics to that limitation.
Quote:
I don't believe this 30% speedup at all, you'd be lucky to save 10% total and you probably lose that when you add up all the extra checks you have to do on every object to detect them, thus wiping out any saving.
It is exactly a third less in terms of total blitted area. I think you are overestimating the complexity of the process, there are no "extra checks on every object", all there is is a function that can redraw the map in a rectangular area. There is obviously some extra CPU overhead involved, but it's hardly reams of code.

Quote:
For a 16 pixel wide object, you have 1 case where you adjust the mask to be $ffff, and can draw the object with 1 word if it's being plotted with 0 pixel indentation to a word boundary.
For a 15 pixel wide object, you have 2 cases where you adjust the mask to be $fffe, and can draw the object with 1 word if it's being plotted with 0-1 pixel indentation to a word boundary.
For a 14 pixel wide object, you have 3 cases where you adjust the mask to be $fffc, and can draw the object with 1 word if it's being plotted with 0-2 pixel indentation to a word boundary.
etc...
You think it is a special case for every extra pixel wide, this is strange. There is the case where you have to blit an extra word wide, and the case when you don't. There is no need to worry about the LWM at all in the latter case, since the bob's own mask image is zero there anyway.

Quote:
you don't need to calculate if it's going to need one word less to blit, don't need to adjust those modulos when the edge case is found, can use the blit-one-extra-word-with-last-word-mask-set-to-$0000 trick for shifting etc.
But these calculations are trivial. For a 16-pixel wide bob, knowing when not to blit one extra word wide is just a case of checking if the bit shift is zero. For other widths it's just a comparison against (16 minus (pixel width & $f)).

Quote:
Not to mention your restoring-from-tiles idea, adding that onto a complicated blitter routine when the screen could be using a copper-split to begin with seems inefficient.
Copper-split does add some complexity, but it is worth doing for the sake of the scrolling. Although i have another idea up my sleeve for my next scrolling and bob routine.

Quote:
If you go ahead and disassemble some games you will see that most have quite a compact blitter drawing routine. They do not tend to have loads of extra cases to speed up blitting in the rare event that it happens. If it was worthwhile, I would imagine most of the big name games would have extremely complicated blitter routines, but the simple fact is that they don't. Check out the Lotus series for a great example of how simple the blitter routines are.
Well i imagine if it was "fast enough" and they had a release deadline coming up, that they were happy to leave it at that, and we all know how many games creators seemed happy with 25fps. Lotus is not a great example to compare, since most of its bobs are fairly large and probably appear in a fairly uniform distribution regarding their position on the screen, but for 2D scrolling games things are different. Often enemies are constrained to move along one axis at a time. If they move sideways at 4 pixels per frame, they are on word boundaries 1/4 of the time, not 1/16. If they move around a maze like pacman, they are on word boundaries about 1/2 the time. If they only move up and down, they are on word boundaries ALL the time. So for 16 pixel wide bobs, you can cut the blitting time in half, and you would tell me that it's not worth doing, for the sake of a few CPU instructions? And that when it is usually the CPU waiting for the Blitter, rather than the other way around, and that the CPU can perform its calculations for the next blit while the Blitter is still busy on the previous one.

Last edited by Mrs Beanbag; 30 November 2015 at 23:16.
Mrs Beanbag is offline  
AdSense AdSense  
Old 01 December 2015, 00:27   #102
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
Quote:
Originally Posted by Mrs Beanbag View Post
It is exactly a third less in terms of total blitted area. I think you are overestimating the complexity of the process, there are no "extra checks on every object", all there is is a function that can redraw the map in a rectangular area. There is obviously some extra CPU overhead involved, but it's hardly reams of code.
You're simplifying things here. How many games use 16x16 bobs? And how many restrict the enemies to 2 or 4 pixel horizontal movement?

Since you've been talking about Chuck Rock, most of those are 32, 48 or even 64 pixels wide. There's a few 16 pixel wide bobs, but most are larger. The enemies such as the bird follow a smooth sine wave when lifting Chuck up over the gap. The large dinosaur you move on also moves around smoothly. The coconuts that get thrown from the tree take up the full 16x16 pixels and can move to any pixel (sine waves again, plus bouncing). There's many more examples through the game.

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.

Quote:
But these calculations are trivial. For a 16-pixel wide bob, knowing when not to blit one extra word wide is just a case of checking if the bit shift is zero. For other widths it's just a comparison against (16 minus (pixel width & $f)).
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) and if only 1/16 bobs happen to be on that boundary, you're saving 1 word of blitting x the height of 3 bobs for the cost of all those calculations. 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.

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.
Codetapper is offline  
Old 01 December 2015, 01:26   #103
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
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.

Quote:
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:


Quote:
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.

Quote:
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.

Quote:
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...

Quote:
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 01:32.
Mrs Beanbag is offline  
Old 01 December 2015, 03:09   #104
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,135
Quote:
Originally Posted by Mrs Beanbag View Post
How is retrieving "exact pixel dimensions" any more CPU usage?
In my case, I don't bother storing the width of the object in pixels as when you're plotting it it doesn't make any difference if it's 31 pixels wide or 32. I store the fact it is 2 words wide on the sheet of graphics so it's ready for the blitter. It seems pointless to read the width as 31 into a register if the final pixel happens to be empty and make a bunch of calculations including shifts (which are slow on the 68k) to work out that almost all of the time it's going to still take up 2 words plus the one extra for shifts. Remember the A500 has a fast blitter compared to the CPU, and I am making it to run on the A500 at 50fps.

Quote:
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.
It's not "extra" at all, that is the "normal" case that you should consider - ie. the object NOT exactly on the word boundary. Anything else is (hopefully) an optimisation to save one word per pixel height (but if you do too much work on every object to work that out, it's not).

Anyway, I originally wrote my code thinking that method you speak of might work (saving a word rarely) and ditched it as it made the general blitting routine much more of a mess and so I ditched it.

Quote:
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.
Have you seen shoot'em-ups that do that? They look utterly mental. The bullets either look like they're appearing from way out in front of the guns one frame and way back the next frame when you creep forward a pixel.
Codetapper is offline  
Old 01 December 2015, 04:27   #105
turrican3
Moon 1969 = amiga 1985

turrican3's Avatar
 
Join Date: Apr 2007
Location: belgium
Age: 41
Posts: 3,157
REally interesting...
Guys you should make a new team fo amiga coders !!!
You should make a kickstarter to finish blaze or to make a new amiga game !!!
turrican3 is offline  
Old 01 December 2015, 11:14   #106
JudasEZT
Registered User
JudasEZT's Avatar
 
Join Date: May 2003
Location: mercury
Posts: 536
Quote:
Originally Posted by keithbugeja View Post
Thanks! The foreground objects are not just decorative - behind them you can actually hide from enemies.
Yeah! I've checked it.. its true.. very cool feature. Now the game also is a bit more like a MetalGearSolid
JudasEZT is offline  
Old 01 December 2015, 12:58   #107
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Codetapper View Post
In my case, I don't bother storing the width of the object in pixels as when you're plotting it it doesn't make any difference if it's 31 pixels wide or 32.
So do i, currently, but i'm thinking about not doing that in future. Or perhaps store the word width, plus an additional value to compare against the shift register when you have it, which might be faster than a shift.

Quote:
I store the fact it is 2 words wide on the sheet of graphics so it's ready for the blitter. It seems pointless to read the width as 31 into a register if the final pixel happens to be empty and make a bunch of calculations including shifts (which are slow on the 68k) to work out that almost all of the time it's going to still take up 2 words plus the one extra for shifts. Remember the A500 has a fast blitter compared to the CPU, and I am making it to run on the A500 at 50fps.
There is not "a bunch of calculations". There is a single comparison operation (once you know what to compare against, which you can precalculate), and you either proceed exactly as normal, or you decrement the word width/increment modulos and set the Last Word Mask to $ffff. If you were using a lot of 8-pixel wide bullets i think that would be worth doing. Obviously there's no point programming features you don't intend to use. Admittedly, i've been coding for A1200, where the profile is different.

Quote:
It's not "extra" at all, that is the "normal" case that you should consider - ie. the object NOT exactly on the word boundary. Anything else is (hopefully) an optimisation to save one word per pixel height (but if you do too much work on every object to work that out, it's not).
We risk falling into pedantic word games here. It's "extra" in the cases where it isn't really needed. How often this case occurs depends on the design of the game. I can think of many cases where it would occur a lot. Platform games where characters go up and down word-aligned ladders, vertical shoot-em-ups with waves of 16-pixel wide missiles hailing down the screen.

Quote:
Anyway, I originally wrote my code thinking that method you speak of might work (saving a word rarely) and ditched it as it made the general blitting routine much more of a mess and so I ditched it.
i've also ditched things in the past that i could probably do better now. i tried to implement some kind of blitter queue at one stage, that didn't really work out so i gave it up. i might try again at some point.

Quote:
Have you seen shoot'em-ups that do that? They look utterly mental. The bullets either look like they're appearing from way out in front of the guns one frame and way back the next frame when you creep forward a pixel.
If the guns firing such bullets are stationary, it is not a problem.

EDIT: just been looking at my source code, i haven't touched it for over a decade and i can see immediately that i could do some fairly trivial optimisations (the benefits of hanging out here), but after that and stripping out the code that handles the clipping at the edge of the screen, calculation of BltAFWM/BltALWM looks like this:
Code:
  moveq.l #-1,D4
  and.w #$F,D1  ; low 4 bits of X-coordinate
  beq.s aligned
    addq.w #2,D2  ; blit width
    subq.w #2,D3  ; A/B modulo
    clr.w D4
aligned
  [lsl.w D1,D4]  ; BltAFWM : BltALWM
EDIT2: wait a minute that can't be right, i'm going to have to sort this out until it makes sense again
EDIT3: worked it out, the last line only happens during clipping (forgot how the masks worked! it's been too long)

Last edited by Mrs Beanbag; 01 December 2015 at 22:13.
Mrs Beanbag is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Game unreleased-Nuxelia- vitux project.aGTW 91 21 April 2017 23:06
Unreleased Amiga Game?? hansel75 Amiga scene 3 05 February 2014 16:01
unreleased game Antheus Tony Landais HOL suggestions and feedback 5 20 May 2013 10:36
Convert my unreleased game to WHDLoad? jimmy2x2x Games images which need to be WHDified 52 16 April 2011 23:20
Once again, an unreleased game is found! dlfrsilver project.aGTW 82 20 October 2008 00:22

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:25.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.22001 seconds with 12 queries