It is currently Mon Oct 20, 2014 4:42 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Tue Sep 29, 2009 1:30 pm 
Offline
User avatar
 Profile

Joined: Wed Jan 09, 2008 7:30 am
Posts: 406
I've written a demo (with a video) for moving Mode 2 sprites around, page at

http://www.retrosoftware.co.uk/wiki/ind ... ritesMode2

I wanted to really do a much more fuller description of what's happening (source is commented though) but it'd take ages and I've other things to work on ! I may update it periodically.

Source is available on the page. This particular routine uses a timer to ensure that the re-draw occurs as soon as the visible screen has been rendered by the raster rather than wait for Vsync which is a little later on than that.

Note that the fastest moving sprite moves at 1 screen position (byte positions) at a time and in reality moves smooth enough but on the video it looks a little jerky, something to do with the capture process i guess.


Top
 
PostPosted: Tue Sep 29, 2009 11:58 pm 
Offline
User avatar
 Profile

Joined: Fri Apr 25, 2008 7:55 pm
Posts: 147
Absolutely brilliant Steve Image

This is the kind of thing that's really helpful for us games novices. The little demo is really smart - if I'd seen it randomly without knowing the platform I'd have guessed it was a modern console. The blue background is very effective - is this where the significance of the colour mask comes into play?

Martin


Top
 
PostPosted: Wed Sep 30, 2009 9:27 am 
Offline
User avatar
 Profile

Joined: Wed Jan 09, 2008 7:30 am
Posts: 406
MartinB wrote:
Absolutely brilliant Steve Image
The blue background is very effective - is this where the significance of the colour mask comes into play?
Martin


Cheers Martin, thanks for the feedback.

No, not really. I chose blue as the background as you can't see the black hair of the man or the black outline of the "Minosoku" if it was a black outline.

The background can be any "actual" colour, but it must be (for the simple erase used) logical colour 0. So all the bytes of the background are value 0. I just redefined the palette so that the Beeb displays any 0 as blue rather than the normal black.

In fact the masked plotting routine is advanced enough plot over any background (0 bytes or otherwise). It can even plot over pictures or other background graphics (which is why sprites move over each other smoothly). But... the simple erase routine can only handle erasing to 0 value bytes. This was done deliberately as I didn't want to over complicate the demo with an advanced erase routine. You'll find that for one heck of a lot of games use this type of erase and it is perfectly adequate and faster than a more complex erase that preserves any background images.

I'll have to try and put up a Wiki page about Mode 2 masks. For now people should be able to just use the sprite plotter code and just add game logic to move the sprites about without worrying too much about how it all works :) Look in the Behaviours routine for ideas on how to implement game logic and sprite behaviours.


Top
 
PostPosted: Thu Oct 01, 2009 11:50 am 
Offline
 Profile

Joined: Tue Mar 04, 2008 7:19 pm
Posts: 16
Good job! There's nothing quite like pictures (still and moving) to really put an idea across.

How much slower would a backstore bg erase be, do you think?


Top
 
PostPosted: Thu Oct 01, 2009 12:46 pm 
Offline
User avatar
 Profile

Joined: Wed Jan 09, 2008 7:30 am
Posts: 406
garfield wrote:
Good job! There's nothing quite like pictures (still and moving) to really put an idea across.

How much slower would a backstore bg erase be, do you think?


The core loop of the erase routine at the moment is basically this (presuming the accumalator is pre-filled with 0)

loop:
STA ScreenAddress,X
DEX
BPL loop

which (when the branch occurs, which is most of the time) would take 9 cycles per byte to erase (presuming no page boundarys crossed for the address + the index).

To do background erasing would basically mean changing it to this

loop:
LDA BackGroundGraphic,X
STA ScreenAddress,X
DEX
BPL loop

An increase from 9 cycles to 13 cycles (4 cycles more). I'll leave you to do the maths for the percentage increase. Obviously there are additional overheads in setting up the address of the background graphic but the main area to look for any speed differences is in the inner most loop of the erase routine.

The erase routine is optimised to erase full char rows for the width of the sprite. Any part char rows (i.e. that sometimes can occur at top or bottom of sprite) are dealt with separately but in a similar manner.

For background erasing your scenery graphics would need to be stored in row format rather than the typical column format used for sprites (See Swift sprite document for explanation of these formats if you are unsure about them). This gives a speed increase in plotting these graphics initially as well as when it comes to erasing them but of course they need to be vertically aligned to char rows and be whole char rows in height. But this is a common technique for most games regardless of whether the background has sprites floating over them or not.


Top
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron