My CPCRetroDev2015 entry - RUN"CPC"

[ervin]

That's excellent - thanks so much for all of that information!


Okay, I've got my code at 0x8000 now, and of course it works fine.
How would I place my sprite tables at 0x1000?

Thanks so much once again for all your help.

[ronaldo]

You can tell SDCC to place things at a concrete location in memory. You can see it in the arkosAudio example used to place the song data at a concrete memory location:

Code Select Expand


__at(0x1D4D) const u8 molusk_song[8883]

You can use __at(memory_address) prefix to tell SDCC where a variable should be placed in memory . However, use this with care: SDCC may ovewrite things if your placements are not well calculated, as you are forcing it to place things in a given place.

[ervin]

You can tell SDCC to place things at a concrete location in memory. You can see it in the arkosAudio example used to place the song data at a concrete memory location:

Code Select Expand


extern __at(0x1D4D) const u8 molusk_song[8883];

You can use __at(memory_address) prefix to tell SDCC where a variable should be placed in memory . However, use this with care: SDCC may ovewrite things if your placements are not well calculated, as you are forcing it to place things in a given place.

Perfect.
Thanks again!!!

[ervin]

Woohoo!!!
I've now got the game running with double-buffering!
It looks much nicer now.

cpctelera's video memory page management is excellent.

[ervin]

runcpc.zip has been uploaded to the first post.

It contains the following new features:
- double-buffering.
- correct ordering of blocks, so they don't overlap in a weird way as they move closer/further.
- left/right movement is back in.
- better use of pointers in the code (as I'm still learning my way around C, this should hopefully continue to improve).
- data structures are now working their way into the code. There's a long way to go sorting them out, but it's a start.

Use arrow keys to move.

It has taken a bit of a speed hit, because the dirty buffer is now having to work harder due to the double-buffering.

The reason is because:
(pseudocode warning!)

repeat(forever){
screen 0xC000 has all its tile cells compared with the latest live tile cells, then it is displayed
screen 0x4000 has all its tile cells compared with the latest live tile cells, then it is displayed
}

When the code goes back to repeat the screen 0xC000/0x4000 operations, it is having to draw the tile changes from 2 live tile updates ago.
So more tiles have to be drawn.

Oh well, I'll just have to live with it.
It still runs at a playable speed, thankfully.

[tastefulmrship]

Some of you may have noticed my Chunky Pixel Curator thread go quiet... unfortunately I just ran out of steam on it. 
I looked at how much was left to do, and I just couldn't bear the thought of going on with it any more... it was just too ambitious, and I felt burned out.
Even today, if I look at the source code, I just crawl away into a corner and hide.

The good thing is that I achieved what I wanted to achieve from it, on a technical level at least.
I'm still very proud of what I was able to do regarding real-time sprite scaling on a CPC.

This is a dark day for the CPC community. That project was so impressive, it's a shame you've stopped! But, good luck with your CPCtelera project... hopefully you might be able to merge the projects and release something even more awesome than the awesome you usually release!

[ervin]

Thanks man.


Yes, I worked on that project for over 4 years in its many forms, and it breaks my heart to stop work on it.
I would really like to finish it one day... but right now, I just... can't.


I'll make this one as awesome as I can!

[ervin]

Another day, another update.
runcpc_2.zip has been added to the original post.

This one contains the results of several under-the-hood changes.
I spent a bunch more time learning about C pointers, function pointers, arrays of function pointers etc.
Really weird at first, but as I get more used to these concepts, the more comfortable I get with them.

Also, I snuck a bit of assembler into the tile drawing section of the program.
(Couldn't help myself).


SDCC is an interesting beast regarding optimisation as well.
The optimisation that takes place during compilation seems to depend on the structure of a block of code.
It seems that if the same variable is used a few times in a row, SDCC makes very good use of registers behind the scenes.
If the order is changed, or lots of other variables are mixed in, it can affect the compiler's optimisation.
It's really great, though I'm probably just preaching to the choir here! 

Anyway, the result is that this version runs around 25% faster, which of course makes it feel a lot nicer.
It somehow makes it feel more "3D", if you know what I mean.
And that means... better playability!

Really looking forward to putting some proper graphics in!

[ervin]

For the last 2 days, I've spent my time on this game trying to figure out how to access SDCC pointers using inline assembler.
It was *very* difficult and frustrating, but I figured it out! 

The reason for this is because I wanted to see if I could change the SDCC looping used for the main display loop (processing the tile buffers, and displaying tiles if required) into assembler.
I had crash after crash after crash... but slowly, the number of crashes decreased, and things started to appear on screen... until eventually the *correct* things appeared on screen.
(This is very melodramatic isn't it?)

And it was FAST.
I optimised it some more, and I'm blown away and incredibly excited by how fast it runs now.
I'm actually shocked.

If you're interested, have a look at runcpc_3.zip, attached to the original post.


Now it's time to create the data structures I'll need to track obstacles, and spawn new ones as required.

[TFM]

Just took a look at some updates! WoW!!! We got nearly finished games here!!!!!!! AWESOME WORK!!!!


Keep it going!!!! 

[ervin]

Thanks man.


I've gotta mention - it's really nice to not worry so much about optimisation as I have in the past.
cpctelera is doing a lot of the hard work for me, and I can worry about getting things working quickly.

Of course, I still couldn't resist a little bit of assembler to make things really fly!

[ervin]

runcpc_4.zip has been uploaded to the original post.

Some more optimisations have made it faster again (page aligning my tile buffers, and other such delights).
And that should *really* be the end of optimisation of tile buffer and screen-related operations!


I  thought I'd try having more than 4 obstacles, to see if it still runs at a playable speed.
So I threw in 16.

And it does indeed run at a very playable speed!
It is considerably slower than the 4-obstacle version, but it's still absolutely great.
Things are looking good for a playable game...

[ervin]

Oh WOW.
I just tried this on my real 6128.

What an amazing feeling it is to see something I've created working on real hardware!

[TFM]

Heya YES! 

[ervin]

runcpc_5.zip has been added to the original post.

This version contains the goodness of data tables implemented as arrays of structures!
YAY!

This was incredibly difficult to learn how to do, but now that it's in, it is very easy to access data in a very simple and logical way.
And so I've been able to put in "sections".

In runner games, the road ahead consists of any number of pre-defined sections, which contain pre-positioned obstacles for the player to avoid.
The section that appears next is chosen randomly, which gives the game the illusion of a random, ever-changing path to run through.

This is one of the parts of this development that I was most worried about, but it's in and it works really well.


At the moment, I've got 6 sections.
They contain really poorly placed obstacles, just for testing purposes.
But it's clear that the next section is chosen randomly from that pool of 6.

Each section can contain up to 8 obstacles (for playability as well as performance reasons - more than 8 would be detrimental to both).
I keep 2 sections in play at any one time - one where a new section is swapped into, and one where a previously new section is swapped out of.

i.e. Section A is put into play. Then section B comes in behind it, pushing A into the 2nd section. Then section C comes in, pushing section B into the second section, thereby removing A from play.
And so on.

Now I can start figuring out how on earth to store information about which sprites are to be displayed in each section, and how they are to be constructed from tiles.

[TFM]

WoW! Is that really such a dramatic speed up? Or is it just because it's not Monday any longer? Great job done! This is light speed race driving now!!! 

[Joseman]

Oh! i see the Out Run remake more near... for now is more quick!

[||C|-|E||]

It reminds me the second level of Savage 

[ervin]

It reminds me the second level of Savage 

Yes, it's a bit like that, only this is full-screen.


However, this won't be first-person.
I'll be adding a vehicle of some sort to it shortly, and it will become third-person.
But I can't say what that vehicle is going to be - that's a secret that will only be revealed when the competition ends.


Collision detection will be a challenge, that's for sure!

Small update - I've added limited up/down movement now.
Also, you no longer need to press the UP key to move forward - it's automatic now.
And it feels HECTIC!

(I haven't uploaded this new version yet - I want to add some more things before the next upload).
I'm really excited with how this is going!

[mr_lou]

I'm really excited with how this is going!

Isn't it awesome how the CPC can still give us the same joy it gave us 25 years ago too? 

[ervin]

Isn't it awesome how the CPC can still give us the same joy it gave us 25 years ago too? 

Heck yes!


I'm now at the stage with this development where the ideas are just flowing thick and fast, and I've got to say NO to some of them, as I actually want to finish this in time for the deadline!

[TFM]

However, this won't be first-person.
I'll be adding a vehicle of some sort to it shortly, and it will become third-person.

Can actually somebody tell me how a second person shooter / game would look like? Any example?

[CraigsBar]

Surely you play the role of the target.... A bit like me on halo death match games.

[ervin]

runcpc_6.zip has been added to the first post.

This version contains the following:
- a few little performance tweaks (I've gotta stop doing that!)
- limited up/down movement
- a simple white rectangle to represent the player's sprite

Getting vertical movement working was far harder than I expected.

The sprites themselves were fine.
I just adjust their Y values in code, and they work - though I did need to add vertical clipping for them.

The ground however was another matter.
The position of the ground stripes seemed to go out of sync with sprite movement, once the Y value changed.
Took quite some effort to sort, but now the sprites and the ground stay perfectly in sync.
(I now understand why some games from back in the day had road stripes that moved at a different speed from that of the fast-approaching sprites).

Another annoyance was what to do with the ground when the player moves down (thereby effectively scrolling the screen up).
I was getting a large jump at the bottom of the screen when the ground stripe didn't work correctly.

I'm very happy with my solution for that problem.
It's perhaps a slightly strange solution, but in my opinion it actually adds to the feeling of movement, so that's that!
Try it out and let me know what you think.

[TFM]

Surely you play the role of the target.... A bit like me on halo death match games.

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