Fourspriter: Alternate Version

[slenkar]

does the memcopy command create the background?

The saving and redrawing of the background is cool,
I had a question about that
say in R-Type for example
lets say there is an explosion sprite which has been on the screen for 1 second and needs to disappear, what if there is a ship flying into the explosion, wont the ship be considered as 'background' and be copied back to the screen as a static object?

lets say the explosion is 4 blocks in size on the screen, lets say the ship is 2 blocks in size so it covers half the explosion

the explosion is drawn first, then the ship
the ship moves forward , the ship sprite thinks the explosion is the background so it redraws that
the explosion dissapears and thinks the ship is the background so now even though the ship has moved forward it has a copy that stays still on the screen.


This problem can easily be avodied by the game developer
(some simple checks to see if 2 sprites are in the same position,) I just wondered if that is a problem with 4spriter or not.

By the way, is the version in this thread considered the best?

[britlion]

does the memcopy command create the background?

Yes, it just dumps a chunk of the ROM to the screen in this case - in general terms, it copies bytes of memory around.

The saving and redrawing of the background is cool,
I had a question about that
say in R-Type for example
lets say there is an explosion sprite which has been on the screen for 1 second and needs to disappear, what if there is a ship flying into the explosion, wont the ship be considered as 'background' and be copied back to the screen as a static object?

In this case it undraws all four sprites back to the background in reverse order; so yes some sprites may have other sprites as their background item, but when you've rubbed out all four in reverse order, it doesn't really matter - you're back to background anyway.

I've got a part written version (ignored for the past year, listed as Fourspriter Mk 3) that uses push and pop to draw it to the screen, and only rubs out sprites that moved, trying to track collisions. It doesn't really work though. It is low on flicker, however

By the way, is the version in this thread considered the best?

Ooh. Tough call to make, that. It's complete, and it works, in that it's practically identical to the source code the mojon twins released initially, but with some cleanups and optimizations.
Since Boriel surely writes better code than me, it may well be better than the one in this thread - though I think my version uses fewer functions, and because it's more assembly optimized might run faster. I haven't really played with the inbuilt library version.

[slenkar]

ah thats very good, removing them in reverse order,
for example in Renegade you would have someone standing closer to the 'camera' than someone else, therefore having 2 sprites in the same screen space
if their x coordinate was the same of course
thats a great way of 'erasing' that problem


the copying of memory to the screen seems to be a good way of creating 'noise'
if the background color was green and the foreground was a bunch of random black dots that would be a nice graphic of grass