Tuesday, November 21, 2006

It's been a while

Well I thought I should write something as it's been a while since I last posted.

Currently I'm writing some tools to convert map data into the correct format for the scrolling routines and eliminate a lot of the mistakes I've been making because I've had to type the data in by hand. It's taken a while because well ... no excuses really I've just not had the time recently.

Anyway I've gotten it mostly written now C# is a wonderful thing (best thing MS have done in a long time) so XeO3Gen now exists to convert maps into the correct format. Now I just need to modify the code to use the new format (that's tomorrows job).

And for the trivia fans the name XeO3Gen is an homage to the tool I wrote for Lemmings 2 (l2gen) that converted all the graphics and style files for the target machines.

It's been a while

Well I thought I should write something as it's been a while since I last posted.

Currently I'm writing some tools to convert map data into the correct format for the scrolling routines and eliminate a lot of the mistakes I've been making because I've had to type the data in by hand. It's taken a while because well ... no excuses really I've just not had the time recently.

Anyway I've gotten it mostly written now C# is a wonderful thing (best thing MS have done in a long time) so XeO3Gen now exists to convert maps into the correct format. Now I just need to modify the code to use the new format (that's tomorrows job).

And for the trivia fans the name XeO3Gen is an homage to the tool I wrote for Lemmings 2 (l2gen) that converted all the graphics and style files for the target machines.

Sunday, November 12, 2006

I've always hated the taste of SPAM

First time I've seen SPAM on a blog....

Anyway I've realised that I need to address the amount of time and memory that the scrolling graphics is going to take up, so I've been thinking how to change the routines as it stands (currently the scrolling is taking around half a frame of processing), now I know that I can improve that by storing the graphic pre-rotated but that means that each set of 4 tiles (they need to be grouped together0 will take 2K for all 16 rotations, which means that on a 48K Spectrum I would get very uninspiring graphics.

Well I think I have a new method but it will take a bit of experimentation.. so I'll keep you up to date with the progress.

Thursday, November 09, 2006

Xe03: Sprites

Well I've not fallen off the face of the planet, Mike and I have been busy beavering away and we've both been looking at the issue of sprites, I've been unsure on the best way to do them on the Spectrum and wondering how he has acheived so much on the Plus/4. Anyway see Mikes blog for some of the fruits of those discussions about different techniques.

So now that I have the scrolling working and rendering I want to draw as many sprites as possible (Mike manages 10 masked sprites on the Plus/4) onto the main play area. On the 48K (which is still my target, as much as Mike keeps saying that I should look at 128K). So to achieve this I have to ensure that I draw the sprites before the raster displays the area that I am rendering to. Therefore I need to draw the sprites in a sorted order (from the top of the screen to the bottom) to stay ahead of the raster. Since the scrolling takes from the top of the screen (where I sync to) to the bottom of the screen (well a few scan lines over) I have the whole of the lower border, VBlank, upper border and then the screen area (staying ahead of the raster). Which is a fair amount of time...

So I have to get a really fast sprite routine, and I invite you all to give suggestions on the best way. Following some discussions on the World of Spectrum (www.worldofspectrum.org/forums) I'm using the zig-zag pattern of sprites i.e. for a sprite that is of the format

ABC
DEF
GHI


then the bytes would be arranged normally as

A0 B0 C0
A1 B1 C1
A2 B2 C2
...
G7 H7 I7


In Zig Zag they are arranged as

A0 B0 C0
C1 B1 A1
A2 B2 C2
C3 B3 A3
...
I7 H7 G7


In this way it minimises the number of increments and decrements that a sprite routine has to do (also means that the screen address does not need to be reloaded at all).

So the basic structure of a sprite routine is
// byte 0
get source
logical operation with dest
store in dest
next source
inc dest
// byte 1
get source
logical operation with dest
store in dest
next source
inc dest
// byte 2
get source
logical operation with dest
store in dest
next source
move dest down one line
// byte 3
get source
logical operation with dest
store in dest
next source
dec dest
// byte 4
get source
logical operation with dest
store in dest
next source
dec dest
// byte 5
get source
logical operation with dest
store in dest
next source
move dest down one line


So going with my old favourite, I'm going to use the stack pointer to point at the source data and then store my Mask and Data together so that a single pop will read both of them and my inner core will become

     pop   de
ld a,(hl)
and e
or d
ld (hl),a
inc l


Using the stack means that we fetch the data and increment to the next byte all at once, the logical operation is fairly simple and the step to the next screen byte is a simple increment all nice and easy!!

Now I've done some timings and I can get around 14 (24x16) of these in our time frame which is pretty good.

The observant among you will have noticed that I'm not doing any rotation in this routine, that's because I'm going to implement a sprite cache like Mikes and store all the sprites rotated in the cache (remaking them when I need to), which means I don't need to do that in here (remember staying ahead of the raster).

Lastly I need to feed these routine as quickly as possible so I am using a small routine that reads a table and calls the correct draw routine as quickly as possible

DrawSprites:    di
ld (DS_sp_restore+1),sp

ld de,6
ld hl,SpriteStack
DS_lp: ld sp,hl
exx
pop hl ; routine address
ld a,h
and a
jr z,DS_exit

ld (DS_jump_address+1),hl
pop de ; screen address
pop hl ; graphics address
ld sp,hl
ex de,hl
DS_jump_address jp #ffff
DS_sp_lp_back: exx
add hl,de
jr DS_lp

DS_exit:
DS_sp_restore: ld sp,#ffff
ei
ret


So if you can spot a quicker way to do things let me know, because I want to make the Spectrum version better than the C64 or Plus4... ;)

Friday, November 03, 2006

Scrolling Working!

Well I got the scrolling working yesterday, so I thought I would put a video up for you all to see, still programmer art so it does not look very nice, and I have a particularly bad sprite routine in there just now (I know I can optimise the heck out of that one), I've been mainly worried about the scrolling up to now.

It is still taking a bit too much time just now, but I'm going to get the sprite routines in and start adding some gameplay in there before I go back and make more decisions on the scrolling.

Currently I have a cache of 16 tile pairs per screen that I am scrolling (as I'm trying to avoid storing prerotations) and 4 tile pairs per screen line, but I know I can expand that to 8 tile pairs per screen line, and I can move to pre-rotated tiles if need be (to lift the 16 tile pairs restriction). So I am fairly comfortable with this.

Also if I need them I can overlay sprites on the background as well to make it look nicer if need be, though my aim is to have as many sprites moving as possible to keep the action frenetic.

Anyway it's just a little taster to show progress... and remember I am no artist....


This page is powered by Blogger. Isn't yours?