TheBackShed.com

Forum Index : Microcontroller and PC projects : Sprites, layers, pages and 12-bit modes

Author

Message

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10580

Posted: 04:53pm 09 Aug 2020

Copy link to clipboard

Print this post

There is clearly confusion here so I'll have another go at explaining.

Pages are areas of memory that are sized as defined by the resolution. So each page for mode 1,8 is an area of memory 800 x 600 x one byte. Modes 1,16 is 800 x 600 x two bytes.

In all modes PAGE 0 is is shown on the display. In 12-bit modes PAGE 1 sits on top of PAGE 0 and is also displayed in which case PAGE 0 pixels show through to the extent that PAGE 1 pixels have some level of transparency.

Use MM.INFO(MAX PAGES) to tell you the highest page number you can use for any resolution. There is 3.5Mbytes of RAM allocated to video pages and this is allocated in units of 128KBytes.

PAGE COPY simply takes the memory contents of a page and copies it to another page

All graphics output (including sprite commands) goes to the page set by the most recently executed PAGE WRITE command except for a small number of commands that explicitly allow you to define it (e.g. PAGE SCROLL)

When multiple pages are in use it is essential that all sprite commands that change the page act on the same page. For reasons that will become clear it makes sense to allocate a page other than 0 or 1 for sprite usage. I suggest you standardise on page 2. This means before any sprite write operation you should set PAGE WRITE 2.

Sprites are entirely implemented in code. There is no supporting hardware. To move a sprite the firmware first redraws the stored background of the page where the sprite is drawn, then stores the background of where it will move to, then draws the sprite. If the sprites are drawn on page 0 then unless you use a technique to control when you move a sprite relative to frame blanking (there are two ways of doing this documented in the manual) you will see flashing which is why it is better to use sprites on a non-displayed page.

It is poor programming to show a sprite repeatedly in your process loop unless something has changed (position, orientation, sprite image changed by a READ).

Don't use PAGE SCROLL on the page that contains sprites. You must use the SPRITE SCROLL command as this understands sprites. It is however less efficient and a PAGE COPY then PAGE SCROLL may be better.

Sprite layers have nothing to do with pages
Sprite layers are used in just three ways:
1. Sprites on layer 0 will move with the background of the page on which they are drawn when the SPRITE SCROLL command is used
2. A sprite move will only trigger a collision with a sprite on the same layer or layer 0
3. A sprite scroll can trigger a collision between a layer 0 sprite and a sprite on another layer

If you want to hide a sprite it is down to you to know if there are any sprites that overlap it and have been drawn after it in which case you must hide them first then redraw them after hiding the intended sprite. So a typical algorithm for a sprite "killing" another is as follows:

sprite show weaponsprite, x,y,n 'this move triggers a collision

sub sprite interrupt
local killedsprite=sprite(C,S,1)
sprite hide weaponsprite
sprite hide killedsprite
sprite show weaponsprite, x, y, n
end sub

capsikin
Guru

Joined: 30/06/2020
Location: Australia
Posts: 342

Posted: 03:37am 11 Aug 2020

Copy link to clipboard

Print this post

matherp said There is clearly confusion here so I'll have another go at explaining.

Pages are areas of memory that are sized �as defined by the resolution. So each page for mode 1,8 is an area of memory 800 x 600 x one byte. Modes 1,16 is 800 x 600 x two bytes.

In all modes PAGE 0 is is shown on the display. In 12-bit modes PAGE 1 sits on top of PAGE 0 and is also displayed in which case PAGE 0 pixels show through to the extent that PAGE 1 pixels have some level of transparency.

Use MM.INFO(MAX PAGES) to tell you the highest page number you can use for any resolution. There is 3.5Mbytes of RAM allocated to video pages and this is allocated in units of 128KBytes.

PAGE COPY simply takes the memory contents of a page and copies it to another page

All graphics output (including sprite commands) goes to the page set by the most recently executed PAGE WRITE command except for a small number of commands that explicitly allow you to define it (e.g. PAGE SCROLL)

When multiple pages are in use it is essential that all sprite commands that change the page act on the same page. For reasons that will become clear it makes sense to allocate a page other than 0 or 1 for sprite usage. I suggest you standardise on page 2. This means before any sprite write operation you should set PAGE WRITE 2.

Sprites are entirely implemented in code. There is no supporting hardware. To move a sprite the firmware first redraws the stored background of the page where the sprite is drawn, then stores the background of where it will move to, then draws the sprite. If the sprites are drawn on page 0 then unless you use a technique to control when you move a sprite relative to frame blanking (there are two ways of doing this documented in the manual) you will see flashing which is why it is better to use sprites on a non-displayed page.

It is poor programming to show a sprite repeatedly in your process loop unless something has changed (position, orientation, sprite image changed by a READ).

Don't use PAGE SCROLL on the page that contains sprites. You must use the SPRITE SCROLL command as this understands sprites. It is however less efficient and a PAGE COPY then PAGE SCROLL may be better.

Sprite layers have nothing to do with pages
Sprite layers are used in just three ways:
1. Sprites on layer 0 will move with the background of the page on which they are drawn when the SPRITE SCROLL command is used
2. A sprite move will only trigger a collision with a sprite on the same layer or layer 0
3. A sprite scroll can trigger a collision between a layer 0 sprite and a sprite on another layer

If you want to hide a sprite it is down to you to know if there are any sprites that overlap it and have been drawn after it in which case you must hide them first then redraw them after hiding the intended sprite. So a typical algorithm for a sprite "killing" another is as follows:

sprite show weaponsprite, x,y,n 'this move triggers a collision

sub sprite interrupt
�local killedsprite=sprite(C,S,1)
�sprite hide weaponsprite
�sprite hide killedsprite
�sprite show weaponsprite, x, y, n
end sub

That looks fine if you're dealing with overlaps one at a time as soon as they happen, otherwise you might not always know when a sprite you want to remove is under another one.

I did a test using SPRITE NEXT and SPRITE MOVE.

It looks like they take care of clearing and redrawing sprites in the correct order when there's overlap, even when there's another sprite on top that didn't have a SPRITE NEXT command.

So if you don't know what sprites are on top you could use SPRITE NEXT / SPRITE MOVE to move it offscreen before hiding it.

Is there a safe way to do SPRITE SWAP if the sprite might be under other ones you're not keeping track of?

capsikin
Guru

Joined: 30/06/2020
Location: Australia
Posts: 342

Posted: 04:22am 11 Aug 2020

Copy link to clipboard

Print this post

Thanks for the explanations - I'd probably seen that the 12 bit mode "layers" are pages 1 and 0, but I think I forgot.

regarding this:

Quote When multiple pages are in use it is essential that all sprite commands that change the page act on the same page. For reasons that will become clear it makes sense to allocate a page other than 0 or 1 for sprite usage. I suggest you standardise on page 2. This means before any sprite write operation you should set PAGE WRITE 2.

I'm guessing it doesn't apply to the SPRITE WRITE command itself, since that doesn't save or restore the background, is that right?

Print this page

To reply to this topic, you need to log in.