Chunky Pixel Collision

[ervin]

Hi all.

Wow - has it really been 9 months since the last update?!?!?!
Holy cow...

Alrighty, work has (believe it or not) continued on this project.
I did have a quiet few months at the end of 2011, due to RealLife(tm).
But of course that itch is always in the back of a programmer's mind...

When I got my recent CPC6128 acquisition working, I was able to finally run my code on real hardware.
It was a wonderful, inspiring, and very proud moment, and the creative spark returned. 

I did a whole lot of work on the road routines, and then got stuck for several weeks trying to figure out how to translate it to pseudo-3D. 

Then 2 nights ago, while laying in bed ready to go to sleep, an idea popped into my brain. I quietly crept out of bed so as to not wake my lovely wife, and got to work.

I now have a routine (on PC) that calculates raster positions (i.e. y coordinate) depending on an object's Z coordinate. These coordinates will be stored in a lookup table.

I had initially toyed with figures from actual perspective projections, and of course it looked realistic, but it just didn't feel "right" in the content of my game. I studied videos of Outrun, Space Harrier etc. etc. and realised that the sprite scaling calculations don't appear to be accurate  anyway! They have been scaled in order to create an illusion of movement and speed, rather than an illusion of 3D! (I could be wrong about this of course!)

Anyway, the routine I have now matches more closely the way those Sega games scaled their sprites.

In the last few weeks, I've also thrown away the scaling matrix lookup tables, which would have required quite a large amount of memory. Every width had to have its own scaling matrix (eg. the matrix for a 64-pixel wide sprite, for all scaling levels).

Instead I'm now calculating the scaling matrix for a sprite, once per frame, in real-time. It took several failed attempts, but I finally came up with a scaling routine that I was very happy with.

It is of course a little bit slower than simply looking up the scaling matrix, but it uses a heck of a lot less memory!
In fact the routine is very small, and in real usage (i.e. how fast the routine "feels"), there is no noticeable difference.
If I remember correctly, it takes just over half a second longer to render a screen-height sprite 100 times. I think that is an acceptable trade-off between speed and memory. 

Another benefit is that I can plug in new sprites much more easily now, as I don't need to go through the tedious process of pre-calculating the required scaling matrices.

So I now have a way to quickly determine the raster that a sprite should be sitting on, and which raster each strip of "road" should be allocated to. I've also got sprite scaling routines that I am very happy with, from both speed and "visual feel" terms.

Now to get something useful working!

Incidentally, a couple of weeks ago, I had almost committed to abandoning the idea of a 3D undulating road.
But now that idea is back, and hopefully I'll be able to implement it.

[Gryzor]

Thanks for the update, really nice to see things are progressing and that that CPC of yours is going to be put to good use


Btw, I always keep a notepad at my bedside

[ervin]

Btw, I always keep a notepad at my bedside

Indeed the notepad would be the way to go... but I just couldn't let the idea wait. 
Tsk. Developers eh?

[ervin]

Alrighty, we have a working road now.
At last.

It doesn't undulate, or even bend or twist, but it does work.
Slowly.

It is frightfully slow at the moment, due to being completely unoptimised.
It's going to be a heck of a lot faster than this - I'm certain of it.

[Gryzor]

Well, with Winape in turbo mode it's fast....ish. Good job

[ervin]

 

I'm actually using WinAPE's turbo mode to make testing bearable during this unoptimised phase.
Incidentally, I've already got it running quite a bit faster - and looking a bit different as well.

[ervin]

I've got the road code looking very different, and also running a heck of a lot faster now.
There is still lots more optimisation to do though, which is good as I ultimately want the road itself to have a negligible effect on framerate. The sprites will need as much cpu time as they can get. 

I also found a few bugs related to the way the road works depending on how fast the "player" is travelling. I think it is all ok now.

When the attached program loads, you'll be presented with 3 options: slow, medium and fast.
These don't refer to how fast the program runs. 
They refer to how fast the player travels.

In the game, the idea is for the player to be travelling FAST, with the other 2 speeds used to add interesting feedback to collisions.

[Gryzor]

When the attached program loads, you'll be presented with 3 options: slow, medium and fast.
These don't refer to how fast the program runs. 
They refer to how fast the player travels.

This will teach me to read the description before loading the image
But why does the line travel slower, the higher it is on the screen? And what's with the colour scheme?

[ervin]

The colour scheme is something that isn't locked down yet.
I want to keep the moving lines quite subtle compared to the solid road, but the actual combination of colours is undecided.

The line speeds up as it moves down because it is actually moving towards you.
(Well, not really, but that's the illusion I'm trying to create. Think of it as a 3D road).
The "closer" it is to you, the faster it appears to move.

[Gryzor]

I know what you mean, but somehow it doesn't look convincing. I'd probably prefer it if they came at me at constant speed (depending on the actual "character"/"hero" speed of course)

[ervin]

It might be hard to imagine the effect I'm after, as there aren't any sprites racing towards you at the moment.
Once they are in, the effect might be more convincing.
I hope. 

I'm thinking that if the lines all came toward you at the same speed, it would just look like a vertical scroll.
In any case, I can adjust the speed of the line at every part of the road really easily, due to the way the routine is written.

[Gryzor]

I see what you mean. Maybe I'm wrong, it's just that it doesn't quite feel... right. Indeed, who knows, maybe it makes sense in your hear because you know what's supposed to be going on in it in the end!

[ervin]

No matter what though, once I have some sprites moving toward the player as they race along the road, I'll certainly be open to suggestions.

Also, thanks for taking the time to give me feedback.
Feedback will get more and more important as development continues.

[Gryzor]

My pleasure, I really enjoy this progress