Chunky Pixel Collision

[Gryzor]

But (and not many games did that) the game should adjust the speed of the car depending on the curvature of the sides. Slower=going up, faster=going down.

[Bryce]

You need more horsepower Gryzor Real race cars barely slow down uphill

Bryce.

[ervin]

But (and not many games did that) the game should adjust the speed of the car depending on the curvature of the sides. Slower=going up, faster=going down.

Indeed that would be worth considering... if I was actually creating a racing game. 

[Gryzor]

Ahem Well, all sorts of vehicles and being slow down when they go up!

[TFM]

You need more horsepower Gryzor Real race cars barely slow down uphill

Bryce.

Yes, right! And if I take a look here at real traffic, then I see: People speed up when they drive up a bridge and slow a bit down when driving down. Probably this is due to the fact that the NOPD never checks speeding up on bridges 

[ervin]

Alrighty, I've completely re-written the sprite routines now. 
Thanks to arnoldemu, redbox and Axelay for their ideas with the sprite data format.
Savage now takes us much less memory, though I don't know the exact amount.

In addition to their ideas, I also changed the way a sprite is constructed.
For example, instead of giant Savage being a single block of data, he is now constructed of vertical strips.
Because the amount of x-axis movement is fixed depending on how "close" a sprite is to the player (in "3D"), that amount of movement can be the width for each vertical strip.

This is useful because it means that horizontal clipping is now trivial, and very cheap in cpu terms.
Vertical clipping still needs to be calculated the same way as before, but that was always quite easy and cheap, so no dramas there.

I've also realised that using vertical strips may have resulted in a rather nice side effect.
I might be able to implement sprite flipping, using the same data tables.
2 sprites for the price of 1. 
Savage is stored as right-facing, but with this idea he can change between left and right-facing with a toggle (once the sprite flipping code works correctly).

Once I've got sprite flipping working (fingers crossed), I'll upload a version for you all to have a play with, if you're interested.

At the moment, it's very slow, as it is completely unoptimised.
We're talking 5 frames a second here.

But that will change. Oh yes, yes it will.

[redbox]

I've also realised that using vertical strips may have resulted in a rather nice side effect.
I might be able to implement sprite flipping, using the same data tables.
2 sprites for the price of 1. 

It did cross my mind when discussing the compression that it might be possible to store it in a different format to just plain linear.


Glad to hear you've worked out something suitable and it has extra benefits!

[ervin]

Hi all.

Just a little update - I'm kinda excited by this one!

Giant Savage now takes up 1,543 bytes in memory.
In his entirety. 

This includes 15 magnifications of him in both left and right-facing versions!
To say I'm chuffed is an understatement!

It's still a bit slow, as I've been writing the code in ccz80 (which is a lot like C), but I will start converting it to pure assembly shortly. Despite the amount of data being moved around, it runs remarkably well in the plain ccz80 version. It's a really great compiler and I'd be stuffed without it.

Incidentally, the 15 magnifications are achieved using real-time sprite scaling.
I thought of the technique while having a shower a few days ago (that sounds really bad, dunnit?!?!), and thought I'd give it a go. And it works!

Of course the z80 is too slow to do sprite scaling using any sort of maths, so I'm using scaling matrices, which tell the program which rows/columns to skip, depending on the current sprite zoom level.

It's all tremendously exciting!

[redbox]

Of course the z80 is too slow to do sprite scaling using any sort of maths, so I'm using scaling matrices, which tell the program which rows/columns to skip, depending on the current sprite zoom level.

Ooh yeah, nice idea!


Looking forward to seeing it.

[arnoldemu]

Of course the z80 is too slow to do sprite scaling using any sort of maths, so I'm using scaling matrices, which tell the program which rows/columns to skip, depending on the current sprite zoom level.

Are you using fixed point to do this?
I would store xincrement as fixed point 8:8, you can then add the increment easily, and then extract the high byte using ld a,h for example.

[Gryzor]

You should actually be doing a dev log with an ETA or something (which of course would slip, but you get the idea)...

[ervin]

Are you using fixed point to do this?
I would store xincrement as fixed point 8:8, you can then add the increment easily, and then extract the high byte using ld a,h for example.

I'm actually storing the scaling matrices in bit-packed data tables.
4 pixels worth of yes/no in one byte.

Technically of course I could do 8, but that wouldn't be compatible with the rest of the sprite algorithm.

[ervin]

You should actually be doing a dev log with an ETA or something (which of course would slip, but you get the idea)...

Indeed I should, but I'm very much the sort of person that would get very slack with keeping the log up to date! 

An ETA is hard to come by, as this dev process is very organic, and I don't have all the details of the game nailed down just yet.
(2 weeks ago, I almost changed my mind about exactly what these sprite routines should become. Luckily I came to my senses).

[arnoldemu]

Indeed I should, but I'm very much the sort of person that would get very slack with keeping the log up to date! 

An ETA is hard to come by, as this dev process is very organic, and I don't have all the details of the game nailed down just yet.
(2 weeks ago, I almost changed my mind about exactly what these sprite routines should become. Luckily I came to my senses).

A dev diary would be nice for others, but I think concentrating on the game, as you are doing, is the most important thing.

[Gryzor]

Of course the program itself is more important. I just thought it'd be very fun and interesting to read about it in more detail. Dev logs as they appeared in the old magazines were truly great...

[ervin]

Time to demonstrate some stuff.

cpc5.dsk (attached) contains a program called JUNE2011.BAS.
Run it and you'll be able to have a play with the current version of my sprite scaling/flipping routines.

Note that the arrow keys move the camera, as opposed to moving Savage.
That's why at first he might seem to move in the opposite directions to your keypresses.

Also, the scaling factor might be a bit severe the way it is right now, but that's easy enough to change.

It is very slow at the moment, but will speed up significantly very soon.
But first, I'll have to put a large mode 1 sprite in, to keep Savage company...

I hope you all enjoy it.

[Axelay]

Nice effect     Reminds me of Sega's 'super scaler' games.

[ervin]

Nice effect     Reminds me of Sega's 'super scaler' games.

Yes indeed, Outrun and (in particular) Space Harrier have been major influences and inspirations.
I'm looking forward to seeing how my routines turn out after I optimise the living heck out of them! 

[redbox]

Very nice.


Can't remember if it's been mentioned before, but have you thought about using a 32x32 character screen? 


Then you can always use 8-bit increments rather than 16-bit, which of course makes things faster.

[ervin]

Very nice.

Can't remember if it's been mentioned before, but have you thought about using a 32x32 character screen? 

Then you can always use 8-bit increments rather than 16-bit, which of course makes things faster.

I haven't considered a 32x32 screen.
How much memory would such a screen take up?

[redbox]

I haven't considered a 32x32 screen.
How much memory would such a screen take up?

It uses 16kb like a normal screen (well, almost - a normal screen has a few bytes free at the end and this one doesn't).


The benefit is that no pixel row crosses the 256 byte page boundry if your screen is at a normal address like &4000 or &C000.  Therefore, when moving to the next byte in a sprite routine you can always use the 8-bit INC H or INC L instead of the 16-bit INC HL, which of course is much faster especially if you're using a lot of them.


The only real thing you'd need to change in your routine is the screen width is &40 instead of the normal &50.  The next pixel line down is still &800 away so that doesn't need to be changed and you can still use SET 3,H optimisations etc.

Code Select Expand



org &8000


ld bc,&bc01 ;CRTC register 1
out (c),c
ld bc,&bd00+32 ;set width in characters
out (c),c


ld bc,&bc02 ;CRTC register 2
out (c),c
ld bc,&bd00+42 ;set horizontal position
out (c),c


ld bc,&bc06 ;CRTC register 6
out (c),c
ld bc,&bd00+32 ;set height in characters
out (c),c


ld bc,&bc07 ;CRTC regsiter 7
out (c),c
ld bc,&bd00+34 ;set vertical position
out (c),c


ret


[ervin]

Ah, I see. That all makes perfect sense - thanks.
However, I'm still using about a million PUSHes to draw the screen, so I probably wouldn't get any benefit from this idea.

[redbox]

However, I'm still using about a million PUSHes to draw the screen, so I probably wouldn't get any benefit from this idea.

Yeah, I remembered you're using the stack after I made the post, d'oh! 

Anyway, might be worth bearing in mind if you do fall back onto 'traditional' sprite routines for something else like background tiles or something.

Let us know how you get on with your new optimisations.

[ervin]

Let us know how you get on with your new optimisations.

Will do.

I now have another large sprite next to Savage. A "mode 1" sprite.
I've also written a program (on PC) to quickly and accurately calculate my scaling matrices.
I'm now using 30 (instead of 15) scaling levels, so the zooming in/out on a sprite should be a lot smoother.
The scaling matrices take up quite a bit of memory, but I've got 2 ideas to shrink their RAM consumption siginificantly.

I'll put up another version shortly, and then the optimisation will begin!

[arnoldemu]

@ervin: Great as always.
It is good to see your progress, and I think everyone is excited to see what the future brings for your game.