[Development] - Working on a Space Harrier style of game

[ervin]

Hi everyone.

I've been doing a bit of work on what I hope will become a Space Harrier style of game.
It's very early in development at the moment - work has only been done on the display.

I have been able to get very large sprites displaying quite quickly, as each sprite is a chunk of code (i.e. a compiled sprite).
To fit several of them into memory, I'm using LZ48 by roudoudou to decrunch each sprite in real-time, whenever it needs to be drawn to the screen.

I don't have any actual 3D working yet, just a tree being displayed at different scaling levels.
I'm very satisfied with the display routines, and I think I've found a nice balance between speed/size for the decrunching requirements.

https://www.dropbox.com/s/om98ednuv6pi8uh/vid1.gif?dl=0

[Arnaud]

Your engine seems really promising !

How many objects will be on the screen ? On google images for Space Harrier, it seems to have around ten objects at same time on screen.
Do you reuse part of the code of your canceled CPCRetroDev 2017 entry ?

[ervin]

Your engine seems really promising !

How many objects will be on the screen ? On google images for Space Harrier, it seems to have around ten objects at same time on screen.
Do you reuse part of the code of your canceled CPCRetroDev 2017 entry ?

Thanks Arnaud.

It's completely new code - nothing is shared from the 2017 code (except for my standard cpctelera setup code).

I think the engine can handle more than 10 objects on screen at once, because the objects will generally be displayed at different scaling levels; some close-up, so mid-distance, some far away etc. I could be wrong though. I guess we'll see what happens once I have some sort of 3D code put in. 

[Arnaud]

I could be wrong though. I guess we'll see what happens once I have some sort of 3D code put in. 

Your engine won't display only scaled objects ? You'll mix with wired 3d objects ?

[ervin]

Your engine won't display only scaled objects ? You'll mix with wired 3d objects ?

No, only scaled objects.
What I mean is that there are currently no calculations in the program to determine where to put a sprite, depending on its position in 3D space.
That's the next thing I need to figure out.

[Arnaud]

Another thing as long as i think about it :

Make your game less difficult than RUNCPC

[ervin]

Another thing as long as i think about it :

Make your game less difficult than RUNCPC

That's a very good idea!

[Gryzor]

At first I thought it had to do with Harrier Attack, not Space Harrier (which would be a great idea for a remake on the CPC!) and I couldn't figure out where you'd use scaling. Ugh...


Nice and smooth

[gorgh]

looking promising, good luck!

[ervin]

Quick update!

I've spent the last several days rewriting my compiled-sprite generator, in order to allow much larger(!) sprites, and to improve clipping efficiency. The changes to the generator also resulted in smaller code for compiled sprites, and also smaller compressed data sizes, which has made the program a bit faster!

The generator also builds in efficient sprite masking - it is only applied to pixels that need it. Pixels that don't need masking are simple byte-copies. So masking will only be applied to pixels that are around the edge of a sprite, or to pixels along gaps in the sprite. Even then, edge/gap pixels are not masked if they neatly fill a byte boundary.

While doing all of that I also found a small improvement for my screen-drawing routine. Very happy with these changes.


Another improvement was put into the routine that decrunches a compiled sprite before running it.
I moved some stuff out of the compressed data, but still linked it to its compressed data (I hope that makes sense).
This has allowed me to examine some information about a sprite (e.g. spriteWidth) without needing to decrunch it.
So now I don't need to decrunch a sprite at all if it clips completely off the screen.
Of course, that should improve speed in hectic parts of the game!

I've also solved (in my brain, at least) a cheap cheat's method for "calculating" the position of objects in a pseudo 3d world. It will require some tables to be set up, but will remove the need for time-consuming calculations.

Hope to have more to show soon.

[Arnaud]

Hope to have more to show soon.

Yes show us !

[ervin]

Yes show us !

I will, very soon.

[ervin]

Alrighty, I haven't solved the 3D yet, and the movement of the tree is a bit wobbly.
It's also a bit too low.

Anyway, this is sort of the effect I'm aiming for.

https://www.dropbox.com/s/lozdqgl6wc2ezue/vid2.gif?dl=0

[Gryzor]

That's nice... have you tried it with more sprites?

[Arnaud]

Alrighty, I haven't solved the 3D yet, and the movement of the tree is a bit wobbly.
It's also a bit too low.

Anyway, this is sort of the effect I'm aiming for.

https://www.dropbox.com/s/lozdqgl6wc2ezue/vid2.gif?dl=0

Damn i missed your update !
I found it's fast, and how it works with more sprites ?

[ervin]

@Gryzor and @Arnaud ...

I have fixed the vertical position of the tree, and reduced the problem with the wobbling, though that isn't perfect yet.
Anyway, I'm now working on the ground 3D effect (a simple stripe scroll), and as part of that I will start adding in more sprites.

Once I have something to show, I will upload another GIF.
Should be quite soon.

[ervin]

The last few days have been spent doing final optimisations on the sprite generator, and wrestling with a problem that appears to be caused by the decrunch routine (or maybe the crunching program... I'm not sure).

Anyway, I've worked around that for the time being, and managed to get a scrolling ground effect in as well.
Also, I've got more than one tree now.


It looks a bit weird at the moment, as if the trees are curving in towards the camera, but that's because I don't have any code in there yet to properly project the x position of a sprite based on its distance from the camera. That's the next thing to figure out.

For now, I'm very happy with how the program is running.

https://www.dropbox.com/s/sgqg5zkin5qep2f/vid3.gif?dl=0

[GUNHED]

That actually is DAMN GREAT WORK!!! 

[ervin]

That actually is DAMN GREAT WORK!!! 

Thanks! 

[Arnaud]

It's really really good and the display speed is perfect to make your arcade game.
How the complexity of the sprite impacts the drawing speed ?

[ervin]

It's really really good and the display speed is perfect to make your arcade game.
How the complexity of the sprite impacts the drawing speed ?

The drawing speed is very fast, and not affected very much by sprite complexity.
However, sprite complexity affects the decrunching speed, as there would be more data to decrunch (because of less repetition in the data).

So having simpler sprites is the best option for smaller compressed data.
The best way to simplify sprites for my engine is to use less colours.

[GUNHED]

The drawing speed is very fast, and not affected very much by sprite complexity.
However, sprite complexity affects the decrunching speed, as there would be more data to decrunch (because of less repetition in the data).

Well, in case you can detect let's say 512 KB of RAM, then you could decompress all sprites at the beginning and gain some speed up. Guess you already thought about it. 

[ervin]

Well, in case you can detect let's say 512 KB of RAM, then you could decompress all sprites at the beginning and gain some speed up. Guess you already thought about it. 

Indeed you are right; the speed-up would be significant.
However, this game is being designed to run on an unexpanded 464.

[GUNHED]

Well, why not two versions? Shouldn't be much more effort. Just an idea. 

[ervin]

Wow, the last 2 weeks have been full of algorithm-related problems!
I've been trying to get the trees to move in more of a 3D fashion, and that has been very difficult to get right.

However, it is now working, and I found a few optimisations as well.


https://www.dropbox.com/s/8omt3vz95bjbf67/vid4.gif?dl=0