Xe03 Spectrum

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.

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.

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.

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... ;)

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....