Thursday, November 02, 2006

XeO3: Go faster sprites....

Just had a small brainwave..... Normally 16x16 sprites actually draw 24x24 due to rotation, however when the sprite "fits" perfectly inside a 16x16 (say its coordinate is 0,0 and hence has no actual rotation), you can drop the surrounding characters. While drawing the chars themselves don't take long, they still have to get masked. BUT! becasue +4 sprites are character based, so is my clipping routeing, which means I can drop any individual character from the sprite simply by flagging the character its about to overdraw as $FF. This is how I do clipping off the top and edges, I just have a table of indexes some of which point to $FF characters.

Normal NoY NoX NoX&Y
-------------------------------
ADG ADG AD AD
BEH BEH BE BE
CFI CF

Anyway, what I now do is check to see if the Y coordinate has a fractional component, and if not, I set the bottom row to be clipped! If we still have to draw the full 24x24 sprite (which is most of the time), then this only adds 30 cycles PER sprite(300 over all), which isn't much - really. However, if we find we're dipping below our desired framerate I now have another tool to help speed things up. Take a sprite that simply flys across the screen, well if I make sure this sprite does this on an 8 pixel Y boundary, then its always going to be significantly faster due to the fact it will never draw the lower row.

I could do the same on X where I drop the last row, but because of the scrolling, this won't happen very often... I'll probably try it and see, but I think the Y check is good enough.

8 comments:

Anonymous said...

Awesome!

What about programming a lemmings game for the plus4? I think you would even be able to program a much better c64 version than the official one!

Anonymous said...

@ Chicken

And next a Vic20 unexpanded version of Xeo3 ;)

I would like also to see something in bitmap mode for the plus4, it would be more colourfull I guess, but slow?!

Anonymous said...

Algarbian: someone just tried to accomplish in a Lemmings +4 coding, but unfortunately he failed :(
http://plus4.emucamp.com/sd.php?pid=20000

Anonymous said...

This means, when I'll have to move, i.e., a midboss, there will be more convenient X positions to move it along Y (for example, a straight attack).

Anonymous said...

@Luca
Thanx for that link, it's a pity they didn't succeed. The screen shots look quite nice...
Congrats for all the nice gfx in XeO3 Luca! hope to see more soon ;)

Cheers
Sandro

Mike said...

Luca: Yes... left/right movement will be quicker. Although, because scrolling will have stopped, up/down as long as its on an 8 pixel X boundary would be okay too.
(saying I add that in)


Actually.... thinking about lemmings... It should be possible... use 4 double buffered character sets (16k), then have it stored in colums

A1
B1
C1
D1
E1
A2
B2
blah...
blah....

Then you'r just doing a normal sprite routine. Pre-shift the lemmings, and tag characters to replace (lemmings tend to walk in left/right straight lines)

a 160x640 bitmap screen takes 12k..

Looks possible... Just drawing the lemmings - but since its now virtually a bitmap, it should be okay drawing speed. Original game ran in 3 frames, but we also noticed that you dont' really need 100 lemmings - 20 does fine.. That should be doable!

So yeah... smaller levels... but doable!

COurse...if you add a memory expansion, should be easy! :)

Anonymous said...

@mike

Never thought that the bitmap would take 12k! I was thinking of 8k... This is a lot.

Mike said...

There are ways to cut this down, but I wouldnt if at all possible as it spoils the "character bitmap".

However, if you really wanted to you "could" replace all spaces with charcater 0x00, and then allocate new characters as you need them. You then limit the amount of builders you're allowed so that you dont allocate too much memory.

I did this in Lemmings2 on the SNES (although on a larger scale).

However... the drawing speed really comes from having a nice character BITMAP.

(although... you could compress the big bitmap and then decompress it when it got drawn to the screen. This would only affect scrolling, and wouldn't be too bad.....)