My CPCRetroDev2015 entry - RUN"CPC"

[CraigsBar]

Ok, this brings us one step forward. But who plays the shooter then? Do we need network for that? [emoji23]

Normally.... From my experience, Everyone else!

[TFM]

What's a fourth person shooter? You kill the gamer? 

[CraigsBar]

What's a fourth person shooter? You kill the gamer?  [emoji23]

Couldn't tell you. I dead long before then lol.

[ervin]

Alright you two.
Let's sort this out once and for all.


Here is a good description of 2nd-person as it relates to video games.
http://www.escapistmagazine.com/forums/read/9.374209-The-Second-Person-Perspective-in-Videogames

Also, this:
Second-Person Perspective (Concept) - Giant Bomb

[ervin]

In other news, I've now added some basic collision detection to the game.

At the moment, I've got it detecting when an obstacle is within "collision range", regardless of the speed the player is travelling at.
(i.e. if an obstacle is being printed for the last time before it is removed from the screen, that's when it is in range).

Ultimately it will be tile-accurate collision detection.
The tricky thing will be making sure it doesn't take up much CPU time.

Also, I've made the tile printing routine a fraction faster.
I can't help myself - optimisation is so satisfying!

[mr_lou]

You're hardcore.
You'll definitely score points for technical achievements with all these optimizations you're constantly doing. 

[ervin]

You're hardcore.
You'll definitely score points for technical achievements with all these optimizations you're constantly doing. 

Thanks!

The truth is that I have a bit of OCD, and I can't stand knowing that something can always be a *little* bit better.
It always niggles at the back of my mind.

Points for technical achievement would be lovely though!

[mr_lou]

The truth is that I have a bit of OCD, and I can't stand knowing that something can always be a *little* bit better.
It always niggles at the back of my mind.

Nothing wrong with a little obsessive compulsion. I have no idea why they feel the need to add "disorder" behind that. There's no disorder! It's f*cking awesome! It's great!
Leave our obsession alone, I say. 

[ervin]

Nothing wrong with a little obsessive compulsion. I have no idea why they feel the need to add "disorder" behind that. There's no disorder! It's f*cking awesome! It's great!
Leave our obsession alone, I say. 

Damn right!
Amen brother!


Without a bit of OCD, bleeding-edge optimisation probably wouldn't happen!

EDIT: I just squeezed 2.5% more performance out of my main screen update routine.

[Trebmint]

The whole project is looking great, and nothing at all wrong with optimization. Not sure its counts as OCD. Hoovering 6 hours a day is OCD madness. Getting a game running as fast as you can is just as it should be. Writing a game for a 30 year old computer is another type of mental disorder completely though


Another thing I found with CPCBasic 3 (And I'm obsessive as I'm trying to beat its speed for Unify) is that its single array handling is sub-optimal. Each array position seems to be evaluated by a multiply, which given the a single array can just be pointed to by a word sized offset is slow and quite bloaty. My advice if you want to speed that up is to complete the game, and then save it out s the source and then look for the obvious slow bits.


Its looking great though. I'm really happy that there seems to be some game dev joy going on around the CPC at the moment.

[ervin]

The whole project is looking great, and nothing at all wrong with optimization. Not sure its counts as OCD. Hoovering 6 hours a day is OCD madness. Getting a game running as fast as you can is just as it should be. Writing a game for a 30 year old computer is another type of mental disorder completely though


Another thing I found with CPCBasic 3 (And I'm obsessive as I'm trying to beat its speed for Unify) is that its single array handling is sub-optimal. Each array position seems to be evaluated by a multiply, which given the a single array can just be pointed to by a word sized offset is slow and quite bloaty. My advice if you want to speed that up is to complete the game, and then save it out s the source and then look for the obvious slow bits.


Its looking great though. I'm really happy that there seems to be some game dev joy going on around the CPC at the moment.

Yes you're absolutely right - this isn't OCD as in the disorder. It's more just a very strong desire to make something as efficient as possible. 

I'm writing this project in cpctelera, which uses SDCC.
I've found its array handling to be exceptional - very very fast.

The program is really fast now, so I really need to back away from the optimisation...
But... must... go... faster...

[TFM]

Hi Ervin!


Well, if you set the screen at the beginning to 80 * 25 (like it is under Amsdos anyway) then your program would also perfectly run with FutureOS. So it tells me that you don't use the Firmware, hence it's so quick.


That brings me to an idea: Why don't you move to 64 * 32 format?. Math will be way more easy and quick. Well, in case the new screen is taken into account. In 64 * 32 format you can use INC L instead of INC HL if you want to address the next byte on screen (horizontal). because all he "ends" of a 256 byte block are at the right end of the screen. But you know that of course. So maybe Telera SDCC is not optimized for that. Dunno if you could do it by hand?
Just thinking lound - never mind - Now it's already a game. Great job!!!  :-) :-D

[ronaldo]

@TFM: CPCtelera's routines are only for standard modes at its present status. I have plans to include other modes in the future (like 64x32, for instance) but It'll take time until this is implemented.

Right now, to use these modes with CPCtelera you have to create your own set of functions. No problem on doing that, as CPCtelera can work as a framework only, no need to use the API.

[ervin]

Hi Ervin!


Well, if you set the screen at the beginning to 80 * 25 (like it is under Amsdos anyway) then your program would also perfectly run with FutureOS. So it tells me that you don't use the Firmware, hence it's so quick.


That brings me to an idea: Why don't you move to 64 * 32 format?. Math will be way more easy and quick. Well, in case the new screen is taken into account. In 64 * 32 format you can use INC L instead of INC HL if you want to address the next byte on screen (horizontal). because all he "ends" of a 256 byte block are at the right end of the screen. But you know that of course. So maybe Telera SDCC is not optimized for that. Dunno if you could do it by hand?
Just thinking lound - never mind - Now it's already a game. Great job!!!  :-) :-D

Thanks TFM.


Yes, I am indeed using 80x25 (but used as 40x25).
In my case I don't think using 64x32 would make much difference.

This is because in my screen update routine, I'm using INC L to move to the next address.
This works because the screen is updated in chunks of 8, inside a DJNZ loop of 125 iterations.
Because it is character-based, I have to process 1000 cells every frame, hence 8x125.

The first 7 cells are traversed using INC L, and the 8th uses INC HL, to ensure that I don't cross any page boundaries incorrectly.
I was initially using INC HL before I discovered I could use INC L for most of them - using INC L instead made quite a noticeable difference!

[ervin]

runcpc_7 has now been added to the original post.

This contains the following:
- a bit more speed!
- collision detection
- a basic front-end screen, telling you what to do if you collide
- 2 control options: arrow keys or WASD

This version has had a number of improvements made under the hood, based on a few discussions about SDCC and related things.
The thing I'm most happy about is the much smaller compiled binary - a much more space-efficient method for providing a random number seed was suggested by ronaldo, and I was able to get rid of time.h from my project.

time.h bloated my program by well over 4K, so it's nice to get that space back.

[ronaldo]

Nice work, man. I'm glad to see that my suggestion was useful for you

[ervin]

Spare time over the last few days has been spent *finally* getting proper multi-coloured sprites into my game, instead of those boring monochrome squares!
I thought it would have been easier and taken a lot less time, but of course that's never the way is it?

The required data structures were difficult to set up, and even harder to get working efficiently (I wrote a separate - and very ugly - test program to assist with this part). As I'm learning C by writing this game, I'm often getting stuck on things like that. Stuff that experienced C programmers would take about half-an-hour to develop! 

Consequently, I had to change several little details, and of course that introduced lots and lots of bugs, some of which were *very* tricky to track down.
But it works!!!

I've also found one last potential speed-up, which could have quite a noticeable effect!
I'm cautiously optimistic, and hoping to implement this in the next few days.

I am so chuffed to see proper graphics in the game at last (though at the moment the graphics are horrible blocky things - just for testing purposes of course). Seeing these large sprites zooming around the screen, I can't help but think how Outrun could have been on the CPC... heck, if I knew how on earth to do a 3D road, I'd try it myself!

Due to memory constraints, the "pixels" in my sprites are going to be the same size as those in my "Chunky Pixel Curator" project.
(They work very differently though - this is just a style decision as opposed to an algorithm-based decision).

This will allow the number of tiles required to be substantially lower, which serves 4 purposes:
- less RAM needed to store the graphics, thereby actually fitting all the graphics in
- less time needed to put all the tile data into the program!
- less tile variations means less drawing required for each frame (due to the dirty buffer technique I'm using)
- transparent portions within tiles, without having to incorporate pixel masking!
So I think the extra chunkiness is a good compromise - and it looks really cool too! 

Once I have a few little things sorted out, I'll be uploading one last version.

After that I'll need to go quiet (as far as uploading versions at least), due to competition rules stating that a game cannot be released publicly before the competition is over. I don't want to take my chances with that rule, hence the caution.

In any case, I wouldn't want to spoil any surprises until the game is done!

[AMSDOS]

I guess you could say Outrun started life as an WIP that got better with the likes of Turbo Outrun & Outrun Europa.   

[ervin]

I guess you could say Outrun started life as an WIP that got better with the likes of Turbo Outrun & Outrun Europa.   

Indeed you may be right!

[ervin]

So far my last potential speed-up idea is coming along very nicely indeed!


The game now runs around 15% faster!
YAY!

I've got one more loop to optimise, and then I'll have to exercise some self-control, and stop optimising!!!


[EDIT] YIPPEE!!! Around 20% faster now!

[ervin]

Optimisation is done!
After struggling for hours with accessing pointer variables (and what they are pointing to) in asm, I have done it!
CHUFFED!!!

The game is now approximately 25% faster than it was before this final optimisation!
It absolutely flies now!

[ervin]

Alrighty... it is time to present one last version before I stop uploading builds.
runcpc_8 has been uploaded to the original post.

I won't upload any more builds after this, as I don't want to break the rules of the competition, and I also want some gameplay elements to remain a surprise.


This version contains proper tile graphics!
No more giant coloured squares or rectangles.

WARNING - the graphics in this version are HORRIBLE.
The only obstacle is an *extremely* blocky, poorly drawn tree.
The real graphics will be much better than this (I hope!), and not as blocky (though they will retain the chunkiness I like to use).

When you load the game, you'll be prompted to press SPACE.
The game starts at speed 1 (the slowest).
Every time you collide with a tree, the speed will increase by 1, up to a maximum of 5.
(Press SPACE to continue flying after a collision).

This mechanic is just for testing purposes (as is the awful tree!) - the final game will only give you one life, though the speed will increase as you get further.

I'm really excited about where this little game is headed.
No matter how the final version goes in the competition, I'm just thrilled that I've been able to create something like this!

[TFM]

Hi! This project is for sure the best in 'technical achievement'. And I state that without even knowing the other productions. 


One life.... can you put some cheat mode in please? 




EDIT: Also maybe it would 'feel' better if the player sprite in not exactly in the middle of the screen. But give it a try by yourself! You did awesome work anyway! Yay! 

[ervin]

Hi! This project is for sure the best in 'technical achievement'. And I state that without even knowing the other productions. 

One life.... can you put some cheat mode in please? 

EDIT: Also maybe it would 'feel' better if the player sprite in not exactly in the middle of the screen. But give it a try by yourself! You did awesome work anyway! Yay! 

Thanks man.


I'm not sure about a cheat mode... we shall see.

Thanks for the suggestion about the player position.
I'm making a small adjustment to it, which will feel a bit better, and will also *slightly* speed up collision detection.
However, the player sprite will still be vertically in the middle - that's how Space Harrier, Afterburner, Galaxy Force etc. do it, and I like the way those games feel.


What my game won't have though (unlike those games) is a player sprite that moves around the screen.
It'll be fixed in place, in the centre, partly because it makes collision detection a lot easier, but mostly because the obstacles don't need an additional offset based on the player's on-screen position (in order to maintain a consistent feel with the player's movement).

However, the player sprite will look slightly different when moving, to imply moving up, down, left or right.

[TFM]

No offense but... in the games the player can go up & down a bit. That makes the nice feeling imho. But you don't have to repeat old stuff.