28 November 2015, 06:26 | #81 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
And to add to the list of techniques which save time when drawing bobs. The fastest behind-bob background redrawing routine is the one ... you do not call. I'm sure you will figure it out very quickly if you dedicate a few neurons to the idea. |
|
28 November 2015, 11:10 | #82 | |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
Quote:
|
|
28 November 2015, 16:26 | #83 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Ah, i'd guessed that Chuck would be made of sprites (it's what i always do, anyway), but somehow it never occurred to me that the bobs would be drawn on the background layer. That also means you don't need to take a copy of the background under the bob, because you know the background image isn't going to change so you can just keep a spare copy of it and redraw it from that.
This would limit the effects that would be achievable on the background later though, so the sort of parallax effects you see in Kid Chaos wouldn't be possible. |
28 November 2015, 17:41 | #84 | ||||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Quote:
Obviously, to get maximum color variation one could use both foreground and background layers to draw bobs but it seems reasonable to try to favor the foreground one. It would also be viable to have some bobs use both layers to increase color count. Quote:
Quote:
If you take parallax shifting into account while blitting you can still draw bobs over the background as long as you split them appropriately. Note: we are quite off-topic, sorry Keith! |
||||
28 November 2015, 17:55 | #85 |
Global Moderator
Join Date: May 2013
Location: Setúbal, Portugal
Posts: 617
|
Indeed. This is a very interesting conversation but ultimately seems merely academic. Knowledge for its own sake is a good thing, but better yet is when that knowledge is applied. Is anyone actually "working" on Blaze or can we forget about this one too? If yes, then it's too bad, 'cos its potential was immense.
|
28 November 2015, 18:41 | #86 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
|
28 November 2015, 20:30 | #87 | |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
Quote:
Another thing you have overlooked in your earlier posts is when you suggested you don't need to save the graphics behind the baddies as you can just restore them from the tiles. This only works if you are going to redraw every enemy each update, which in some games is extremely wasteful. Consider the situation of a background tilemap, with 10 enemies that hardly move/animate, and say a bullet (with higher priority) passing over them. If you restore from tiles, you have to restore the background, then paste down the enemies, then the new bullet, when really only the graphics behind the bullet need to be replaced. Also the tile method can be extremely wasteful. If you have a small bullet (say 8 pixels wide by 2 high), that could potentially be covering 4 different tiles (and doesn't Mr Beanbag use massive 32x32 tiles?). That's a hell of a lot of blitter use just to move a tiny bullet. |
|
28 November 2015, 20:44 | #88 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Quote:
|
||
28 November 2015, 21:40 | #89 | |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
[QUOTE=Mrs Beanbag;1053312]well, if a bob doesn't move (or if it animates but its mask doesn't change) we need not redraw its background at all anyway, but we do still need to redraw the bob itself.[QUOTE]
But then you'd have to have your engine keep track of which bobs have a different mask between animation frames so as to know which ones don't need saving/restoring? Quote:
3 bullets that that partially obscure different parts of the same tile will then have 3 operations to restore it! The engine would get more and more complex with all these special cases and at some point it's simply easier to have one optimised routine that handles everything rather than all this added complexity. I do agree with you that it depends on the game what you're doing, but a more general approach that works well with almost all games is to save everything behind the bobs, redraw them, and restore them. And depending on the game, you don't need to waste time building up a second "clean" screen to restore the graphics from as you've saved the graphics behind the bobs anyway. If you're saving the equivalent of say 16 tiles worth of graphics behind the bobs, and in return you do not have to waste 40k of chip memory on a spare copy of the screen (to save one blitter operation/bob) and not have to draw the tiles into it, that's a big win. |
|
28 November 2015, 22:14 | #90 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Quote:
All i'm doing is redrawing the map, in rectangular regions, over the bobs from the last frame. In theory i could process that somehow so that such regions never overlapped, and you might be right that that isn't really worth doing. Sure there is some CPU overhead but i "guessed" that it wouldn't be as much overhead as the extra blitting, in the average case. Maybe in the worst case it's not as good, but in the best case it is definitely better, and in the average case, well, i honestly can't give you any concrete numbers. I apologise for being wrong about Chuck Rock, you seem to be really angry about that, i did say i was "guessing" how it works. I know i don't actually take games apart and analyse them like you do, so i bow to your superior knowledge in that respect. |
||
28 November 2015, 23:23 | #91 | |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
Quote:
Then you're comparing one save/draw/restore operation (and the save/restore is only a single blit using interleaved bitplanes) vs a minimum of 4 blits to restore the backgrounds and you have to first work out how much is obscured from each tile to determine you're doing 4 blits of 1 pixel high. And the chances of a bob overlapping more than one tile is at least 15/16. The only case where it wouldn't is a bob 16 pixels wide that fits perfectly inside the tile, so aligned on the edges. |
|
29 November 2015, 15:00 | #92 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Bit pedantic, i know. I get your point. But what is the total area of all these tiny bobs, compared to the total area of the large bobs? Usually, not a lot. Sure it costs us a bit of CPU time to handle these cases, but saves us a full blit the size of the bob for every bob on the screen, tiny or not. Quote:
With some careful thought, it is possible to have bobs less than 16 pixels wide. Yes it will necessarily take up the full word width in memory, but if it has a few blank pixels down one side, obviously you don't need to draw or redraw that part, if it crosses a word boundary. But coming back to Chuck Rock again for just a second, it makes me wonder about their design choice, if they are using the normal save/draw/clear method but drawing on the background layer, why have they bothered to do this? It must be because they want to use that colour palette, since it can have no performance advantage. If, however, you wanted to use the foreground palette, but were content with bobs appearing "behind" the playfield, it might be advantageous to use the method i speculated about earlier. Are you aware of any games that use such a technique? |
||
29 November 2015, 17:54 | #93 |
Registered User
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
|
|
29 November 2015, 18:54 | #94 |
Registered User
Join Date: May 2003
Location: mercury
Posts: 577
|
Indeed it is. I want at some point make a Rastan type of game, and this reading is great.
btw, Keith, I think your Blaze demo has the most prominent usage of animated-background tiles of any amiga game. Walking from behind some of the objects is really a nice feature. Last edited by JudasEZT; 29 November 2015 at 19:55. |
29 November 2015, 20:11 | #95 | ||||
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
Quote:
Quote:
A constant 8 pixel wide object on the other hand might be worth storing twice in memory (one version shifted 8 pixels) so you only have to blit one word depending on the type of game. Quote:
And the foreground playfield is drawn to in a couple of places (most notably the dinosaur that craps on you on the 2nd level). But that is blitted in front of that playfield like normal. Almost all enemies live on the back playfield. Quote:
Last edited by Codetapper; 29 November 2015 at 20:17. |
||||
29 November 2015, 20:19 | #96 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
it's funny that the hero can go behind a column and the bad guy can go in front!
|
29 November 2015, 20:28 | #97 | ||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Quote:
|
||
29 November 2015, 20:29 | #98 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,828
|
sorry you could easily create an effect of going behind something with a type of bob clip - object going behind get bob objet - follow hero etc
anyway for parallax I was thinking considerind the speed something like Toki with Two maps you have to redraw the background every? |
29 November 2015, 21:56 | #99 | |
Registered User
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
|
Quote:
Last edited by keithbugeja; 30 November 2015 at 08:01. |
|
29 November 2015, 23:43 | #100 | ||
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
Quote:
Quote:
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... For the "majority" case you don't need to store the exact pixel width (knowing the number of words wide to blit is enough), no need to recalculate/lookup/adjust/set the masks, 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. 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. 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. |
||
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 | 96 | 14 January 2024 14:40 |
Unreleased Amiga Game?? | hansel75 | Amiga scene | 3 | 05 February 2014 15:01 |
unreleased game Antheus | Tony Landais | HOL suggestions and feedback | 5 | 20 May 2013 09:36 |
Convert my unreleased game to WHDLoad? | jimmy2x2x | Games images which need to be WHDified | 52 | 16 April 2011 22:20 |
Once again, an unreleased game is found! | dlfrsilver | project.aGTW | 82 | 19 October 2008 23:22 |
|
|