Hi everyone.
It's been several months since I have touched any CPC development.
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.
And then ronaldo announced CPCtelera... and I was fascinated.
I've never done any dev in C, and I've always wanted to learn it.
When the CPCRetroDev2015 compo was announced, I decided it was time to dive in and give CPCtelera a try.
And I'm glad I did!
It's absolutely brilliant.
If the devs back in the 80s/90s had access to something like this (even on the *much* slower PCs of the day), things would have been very interesting indeed.
Any devs around here that are curious about CPCtelera should give it a try. I think it's absolutely awesome.
And the dev (ronaldo) is super responsive and supportive, and is always willing to listen to suggestions.
So! I'll have a go at coding a simple into-the-screen auto-runner.
The idea is that simple sprites (composed of tiles) will advance toward the player at high speed, and the player's job is simply to avoid crashing for as long as possible.
It's inspired by the glut of very simple and very difficult games flooding mobile.
I'm making slow but steady progress, as I'm learning C while I write this.
I've already thrown away a lot of code, but now I've got a box being drawn on screen, aligned with a horizontal line representing road movement.
The box grows and shrinks as the player moves forward and backward.
The road line's position, and the box's position and size, are calculated using proper 3d-to-2d projection.
The calculations appear to be quick enough in SDCC, which is a good thing, as I won't be using any asm in the project at all.
I'm gonna see how fast I can make it run using pure SDCC (and my poor C skills) along with CPCtelera's *wonderful* framework.
It's horribly unoptimised, and only uses character printing for test purposes for the time-being.
But it's a start, and because the game idea is so simple, I can already see light at the end of the tunnel.
8)
I've gotta give a big round of applause to CPCtelera's fast character printing functions - they are very very nice indeed.
If you're interested in following where this project goes, the first DSK is attached.
The game will (rather pretentiously) be called RUN"CPC".
;D
[EDIT] I forgot to mention that the "game" is controlled with the arrow keys.
How about storing a few prescaled sprites like they did back in the day? Then choose them based on distance from the viewer
? It may help to avoid being concerned with the how and let you concentrate on the game play. Hint, those runner type games often appear to have a set of prepare sections which are randomly placed after each other. This allows the game to be possible without making it totally random and potentially impossible if the random choice is bad.
I am looking forward to playing your game. I always thought a runner game would suite cpc.
Quote from: arnoldemu on 13:25, 28 June 15
How about storing a few prescaled sprites like they did back in the day? Then choose them based on distance from the viewer
? It may help to avoid being concerned with the how and let you concentrate on the game play. Hint, those runner type games often appear to have a set of prepare sections which are randomly placed after each other. This allows the game to be possible without making it totally random and potentially impossible if the random choice is bad.
Indeed I will use prepared sections, as otherwise things could become a bit messy for the player!
:)
As for the sprites, I'm sort of going to use pre-scaled sprites.
My obstacles will have 21 different sizes, depending on the distance from the player.
Each one will simply be composed of data such as width, height, and then a list of tile references.
So each obstacle will be constructed using tiles, instead of colour values for every pixel.
Using a dirty buffer approach, I should hopefully achieve a playable speed (at full-screen).
8)
Quote from: arnoldemu on 13:27, 28 June 15
I am looking forward to playing your game. I always thought a runner game would suite cpc.
Thanks man.
I certainly hope it will suit the cpc.
8)
Thank you for your kind words, @ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82). I'm glad to help :)
It's quite curious the scrolling effect you've made out of characters. It remembers me to lots of games I've made using characters :D. Character and string drawing functions are indeed fast, if you take into account they are reading characters from ROM. However, it is much much faster drawing sprites than characters (you can check it on the measures included in the documentation). Even drawing boxes (with cpct_drawSolidBox) is a much faster alternative. In the end, the fastest functions are those which draw tiles.
Will be following your progress and expecting your great results ;)
Thanks for the update mate!!
Quote from: ronaldo on 17:05, 28 June 15
Thank you for your kind words, @ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82). I'm glad to help :)
It's quite curious the scrolling effect you've made out of characters. It remembers me to lots of games I've made using characters :D . Character and string drawing functions are indeed fast, if you take into account they are reading characters from ROM. However, it is much much faster drawing sprites than characters (you can check it on the measures included in the documentation). Even drawing boxes (with cpct_drawSolidBox) is a much faster alternative. In the end, the fastest functions are those which draw tiles.
Will be following your progress and expecting your great results ;)
At the moment, I'm trying to get a dirty buffer working, where only changed character blocks are printed, and no clearscreen is needed. Once I've got that working, the next step will indeed be to use tiles instead.
8)
Alrighty, I've added test_2.zip to the original post.
It still contains a box drawn with characters, but now uses a dirty buffer approach, so I no longer clear the screen between frames, and I can now print a filled box instead of just an outline.
It's still very slow of course, but as a quick test I'm very happy with it.
Now I'll try to figure out how to use CPCtelera's excellent tile features!
8)
Did you forget to attach it to the post? :)
[EDIT]: Sorry, I didn't see you attached it to the first post, not to this last one :)
This is a bit like the second level in Savage, isn't it?
Quote from: McKlain on 13:58, 29 June 15
This is a bit like the second level in Savage, isn't it?
A little bit, but without the shooting.
And probably nowhere near as smooth either! ;D
I've uploaded test_3.zip, which contains 2 large white squares that can be moved closer or further away (up/down arrow keys).
This one gives a good idea of the effect I'll be trying to achieve in my game, though of course the graphics will look a bit different.
I've gotta say, I'm very happy with cpctelera's tile functions.
They are very fast, and they make creating this sort of program a joy.
8)
Also, some questions for any SDCC devs out there.
(I'm still learning C and probably not doing things optimally).
This is the code that compares frameBuffer with screenBuffer.
(They are both arrays of 1000 bytes).
for (buffIdx=0;buffIdx<1000;buffIdx++){
if (frameBuffer[buffIdx]!=screenBuffer[buffIdx])
screenBuffer[buffIdx]=frameBuffer[buffIdx];
}
Does anyone know of a way to make following things quicker?
- the FOR loop (buffIdx is an unsigned int)
- the != comparison
- copying frameBuffer[buffIdx] to screenBuffer[buffIdx]
Thanks.
Quote from: ervin on 08:41, 30 June 15
Does anyone know of a way to make following things quicker?
- the FOR loop (buffIdx is an unsigned int)
- the != comparison
- copying frameBuffer[buffIdx] to screenBuffer[buffIdx]
"!=" means not equal to.
"Unsigned Ints" are always Positive values.
You might be able to make things quicker by using a different kind of loop, I cannot say with any absolute certainty.
Also usually the notation for increments to variables is ++buffIdx.
I'm unsure if you can get away without the Brackets after the FOR statement, C can allow a simple statement after a FOR, though it doesn't say if that simple statement can be a IF <Condition> <Simple Statement>; condition.
In Assembly, if you can embed that into your code, it's merely a comparison check you need to do and if it equals the same, you would skip the code. I'm not sure what it should look like, all really depends on how C interacts with the Assembly, so it may not look like this:
ld a,(frameBuffer[buffIdx])
ld hl,(screenBuffer[buffIdx])
cp (hl)
jr z,skip ;; if HL = A Skip
ld (hl),a
.skip
Of course it might have to be modified to ld hl,screenBuffer[buffIdx] to obtain the address of screenBuffer[buffIdx] rather than the contents of it, contents are check on comparison.
Quote from: AMSDOS on 11:11, 30 June 15
"!=" means not equal to.
"Unsigned Ints" are always Positive values.
You might be able to make things quicker by using a different kind of loop, I cannot say with any absolute certainty.
Also usually the notation for increments to variables is ++buffIdx.
I'm unsure if you can get away without the Brackets after the FOR statement, C can allow a simple statement after a FOR, though it doesn't say if that simple statement can be a IF <Condition> <Simple Statement>; condition.
In Assembly, if you can embed that into your code, it's merely a comparison check you need to do and if it equals the same, you would skip the code.
Yep, the "!=" and the Unsigned Int parts are cool. I was just wondering if anyone knew of something quicker than what I was doing in those statements.
I've researched other loop types (while, do while, etc.), and the general consensus seems to be that we should leave it to the compiler, as these days compiler optimisation is very good (and SDCC does indeed seem to do an excellent job in this regard).
The lack of braces is an interesting one. I initially thought I'd need them after every single FOR, IF etc.
But it seems that if there is only a single statement following FOR or IF, it will execute correctly.
In the case of nesting an IF inside the FOR as I have done, it looks as though no braces are needed at all, if the IF only has one statement after it. And it looks as though the compiler treats that IF (and its one statement) as one statement after the FOR. Weird, but it seems to work! 8)
[EDIT] I had tried a bit of assembler, but then I thought no no no... I don't want to head down that path of staring at assembly for hours on end trying to get a bit more speed out of it. It's very satisfying when you find that extra speed, but I did enough of that during Chunky Pixel Curator to last a lifetime! :P
I assume that you have 2 tile buffers and compare changes between one and the other. This approach is not much more improvable: you can go down to assembly and improve it, or do some C hacks, but that's not a good way to address this issue.
What you should do at this point is changing your drawing algorithm. You should have a dirty buffer which only stores changes (not the entire screen). Then, when looping through the dirty buffer, you dont have to make hundreds of comparisons to decide that nothing should be done (unchanged tiles). You only have to worry about changes.
Other thing you should do to improve your code is not using unsigned int unless you require them. If your values are going to be in the range [0,255] you should use only 8-bits per tile, and not 16-bits (the size of a unsigned int). For that, you can use unsigned char. In CPCtelera (http://lronaldo.github.io/cpctelera) you have some aliases for types (http://lronaldo.github.io/cpctelera/files/types-h.html) to fastly identify their size and use what you require. In your case, you should use u8 type (unsigned 8-bits).
If your tiles are going to be in a narrower range, you can use CPCtelera (http://lronaldo.github.io/cpctelera)'s bitarrays (http://lronaldo.github.io/cpctelera/files/bitarray/cpct_get4Bits-s.html). What you do here is defining a normal u8 array, but using it as 1-bit, 2-bits or 4-bits elements, instead of 8-bits. So, you can do things like this:
// Array with 8 elemnts of 8-bits or 16 elements of 4-bits each
u8 array4bits[8];
// Fill 16 4-bits elements with the numbers from 0 to 15
u8 i;
for(i=0; i < 16; ++i)
cpct_set4Bits(array4bits, i, i);
In this case, you can save a lot of memory, not loosing to much performance (always depending on your needs) :).
Quote from: ronaldo on 12:53, 30 June 15
I assume that you have 2 tile buffers and compare changes between one and the other. This approach is not much more improvable: you can go down to assembly and improve it, or do some C hacks, but that's not a good way to address this issue.
What you should do at this point is changing your drawing algorithm. You should have a dirty buffer which only stores changes (not the entire screen). Then, when looping through the dirty buffer, you dont have to make hundreds of comparisons to decide that nothing should be done (unchanged tiles). You only have to worry about changes.
Other thing you should do to improve your code is not using unsigned int unless you require them. If your values are going to be in the range [0,255] you should use only 8-bits per tile, and not 16-bits (the size of a unsigned int). For that, you can use unsigned char. In CPCtelera (http://lronaldo.github.io/cpctelera) you have some aliases for types (http://lronaldo.github.io/cpctelera/files/types-h.html) to fastly identify their size and use what you require. In your case, you should use u8 type (unsigned 8-bits).
Thanks ronaldo.
You've given me an idea...
8)
I've uploaded test_4.zip to the first post in this thread.
Oh yeah! That's more like it!
Got some *really* nice speed happening now, all with pure SDCC+cpctelera.
This has now confirmed that I can totally stay away from any assembler coding for this project - I'm really happy about that! ;D
Please ignore the horrendous colours - the graphics are just placeholders for now.
Quote from: ervin on 02:47, 01 July 15
This has now confirmed that I can totally stay away from any assembler coding for this project - I'm really happy about that! ;D
Probably better that way, always seems to be fiddly incorporating assembly within C code.
Quote from: ervin on 08:41, 30 June 15
Also, some questions for any SDCC devs out there.
(I'm still learning C and probably not doing things optimally).
This is the code that compares frameBuffer with screenBuffer.
(They are both arrays of 1000 bytes).
for (buffIdx=0;buffIdx<1000;buffIdx++){
if (frameBuffer[buffIdx]!=screenBuffer[buffIdx])
screenBuffer[buffIdx]=frameBuffer[buffIdx];
}
Does anyone know of a way to make following things quicker?
- the FOR loop (buffIdx is an unsigned int)
- the != comparison
- copying frameBuffer[buffIdx] to screenBuffer[buffIdx]
Thanks.
The IF is probably the biggest problem there, it's a lot more effort for the Z80 to read both numbers and compare them then do the copy than it is to blindly copy them and, since you aren't doing anything special, the end result will be the same.
Quote from: andycadley on 18:34, 01 July 15
The IF is probably the biggest problem there, it's a lot more effort for the Z80 to read both numbers and compare them then do the copy than it is to blindly copy them and, since you aren't doing anything special, the end result will be the same.
Yes, you're right.
However, that IF is what determines whether or not a tile is actually printed to the screen.
I left out the rest of the code so that it would be clear what I was talking about... except that doing so removed context.
:-[
test_5.zip has been uploaded to the original post.
This one contains more colour, more giant squares, and more speed!
I'm *very* happy with how fast it's running.
There is some screen tearing, but I'll live with it for now.
The squares aren't being sorted yet, so there is some incorrect overlapping of squares, but as a concept demo this is fine.
8)
Just wondering, who thinks I should keep the road stripe?
I'm thinking I may not need it...
It's really nice, man :).
Maybe its time for you to start considering Double Buffer to stop flickering and visual redrawing :).
Road stripe coud be changed or visually improved, but I think it helps the visual 3D effect.
Nice work!
Quote from: ronaldo on 12:52, 02 July 15
It's really nice, man :) .
Maybe its time for you to start considering Double Buffer to stop flickering and visual redrawing :) .
Road stripe coud be changed or visually improved, but I think it helps the visual 3D effect.
Nice work!
Thanks ronaldo.
Another question for any SDCC devs out there...
How is SDCC with putting things below 0x4000?
(I've got the firmware disabled, if that helps).
I'll need to put my tiles somewhere, and if I use double-buffering, I might run out of RAM.
Where can I put my tiles, and how would I tell SDCC to put them at (for example) 0x1000?
Also, I'd need to move my code to 0x8000, but cpctelera compiles to 0x4000 by default.
How do I change that?
Thanks for any help.
:)
[EDIT] I think I found how to put the code at a different address.
In build_config.mk I'd say
Z80CODELOC := 0x8000
Is that right?
You can put things in memory wherever you want. There is no restriction at all for that, and has nothing to do with SDCC, in fact. However, you must take into account some thigs:
- First 64 bytes of memory are reserved for RST vectors (0x0000-0x0039)
- The Stack is usually placed at 0xBFFF (just before the start of default video memory) and grows inversely (from there to 0x0000)
- If you use firmware, you should take it into account. It lives in 0xA6F0-0xBF80 aprox (up to the stack).
- If you wanted to respect BASIC, you should take care of its working area (variables mainly) 0x0040-0x0170 and the program (0x0170-HIMEM)
- If you use firmware functions, lower ROM will be enabled, shadowing the first 0x4000 bytes of RAM. Reads below 0x4000 will come from ROM instead of RAM, and any code placed there will be unaccessible. That happens with drawChar and drawString functions of CPCtelera (http://lronaldo.github.io/cpctelera): their code MUST be placed beyond 0x4000 or the computer will likely hang when calling them.
Provided that, you can place your program wherever you wanted. There are some CPCtelera (http://lronaldo.github.io/cpctelera) examples that place code start at 0x100, for instance.
You can easily select where you want your code to start as an option of cpct_mkproject script, or just editing the file cfg/build_config.mk of your project and changing 0x4000 for your desired code start address:
Z80CODELOC := 0x4000
That's excellent - thanks so much for all of that information!
8)
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.
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:
__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.
Quote from: ronaldo on 13:56, 02 July 15
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:
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!!!
Woohoo!!!
I've now got the game running with double-buffering!
It looks much nicer now.
cpctelera's video memory page management is excellent.
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.
8)
Quote from: ervin on 13:08, 28 June 15
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!
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!
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).
8)
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! ;D
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!
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! 8)
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.
;D
Now it's time to create the data structures I'll need to track obstacles, and spawn new ones as required.
Just took a look at some updates! WoW!!! We got nearly finished games here!!!!!!! AWESOME WORK!!!!
Keep it going!!!! :) :) :) :) :) :) :) :) :) :)
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!
8)
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!
:P
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...
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!
8)
Heya YES! ;D
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.
;D
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.
:o
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!!! :) :) :)
Oh! i see the Out Run remake more near... for now is more quick!
It reminds me the second level of Savage :)
Quote from: [[C|-|E]] on 00:50, 15 July 15
It reminds me the second level of Savage :)
Yes, it's a bit like that, only this is full-screen.
;D
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.
:P
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!
Quote from: ervin on 01:46, 15 July 15
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? :)
Quote from: mr_lou on 05:12, 15 July 15
Isn't it awesome how the CPC can still give us the same joy it gave us 25 years ago too? :)
Heck yes!
8)
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!
Quote from: ervin on 01:46, 15 July 15
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?
Surely you play the role of the target.... A bit like me on halo death match games.
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.
8)
Quote from: CraigsBar on 16:05, 15 July 15
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? :laugh:
Quote from: TFM on 16:25, 16 July 15
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!
What's a fourth person shooter? You kill the gamer? :laugh:
Quote from: TFM on 21:38, 16 July 15
What's a fourth person shooter? You kill the gamer? [emoji23]
Couldn't tell you. I dead long before then lol.
Alright you two.
Let's sort this out once and for all.
:P
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 (http://www.escapistmagazine.com/forums/read/9.374209-The-Second-Person-Perspective-in-Videogames)
Also, this:
Second-Person Perspective (Concept) - Giant Bomb (http://www.giantbomb.com/second-person-perspective/3015-2722/)
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!
:P
You're hardcore.
You'll definitely score points for technical achievements with all these optimizations you're constantly doing. :)
Quote from: mr_lou on 05:19, 17 July 15
You're hardcore.
You'll definitely score points for technical achievements with all these optimizations you're constantly doing. :)
;D
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!
8)
Quote from: ervin on 05:40, 17 July 15The 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. :)
Quote from: mr_lou on 06:29, 17 July 15
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!
8) 8) 8)
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.
;D
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 :P
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.
Quote from: Trebmint on 08:45, 17 July 15
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 :P
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...
:D
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
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179): CPCtelera (http://lronaldo.github.io/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 (http://lronaldo.github.io/cpctelera) you have to create your own set of functions. No problem on doing that, as CPCtelera (http://lronaldo.github.io/cpctelera) can work as a framework only, no need to use the API.
Quote from: TFM on 16:22, 17 July 15
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.
:D
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!
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.
;D
Nice work, man. I'm glad to see that my suggestion was useful for you :)
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? :laugh:
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! 8)
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! ;D
I guess you could say Outrun started life as an WIP that got better with the likes of Turbo Outrun & Outrun Europa. :D
Quote from: AMSDOS on 06:20, 27 July 15
I guess you could say Outrun started life as an WIP that got better with the likes of Turbo Outrun & Outrun Europa. :D
Indeed you may be right!
:laugh:
So far my last potential speed-up idea is coming along very nicely indeed!
;D
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!!!
8)
[EDIT] YIPPEE!!! Around 20% faster now!
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!
;D ;D ;D
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.
8)
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!
;D
Hi! This project is for sure the best in 'technical achievement'. And I state that without even knowing the other productions. ;D
One life.... can you put some cheat mode in please? :-X
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! :)
Quote from: TFM on 16:42, 30 July 15
Hi! This project is for sure the best in 'technical achievement'. And I state that without even knowing the other productions. ;D
One life.... can you put some cheat mode in please? :-X
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.
8)
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.
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. ;)
Quote from: TFM on 20:33, 31 July 15
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. ;)
It's cool, no offense taken.
8) :)
You're absolutely right, so I've been working on tweaking the collision detection routines, so that they work no matter where the player sprite is on the screen.
Then I'll adjust the 3D calculations so that the obstacles still move around correctly, even though the player sprite can change position on-screen.
Once that is done, I'll post one more build to see what you think (despite saying that I wouldn't upload any more versions).
:)
Don't post too much. I'm really looking forward to see the final polished result! And it will be great! :)
Alrighty! I've now got the player sprite moving around the screen (within a limited area, in order to still relate correctly to the position of the obstacles).
I had to subtly change the 3D calculations in order to offset the obstacle positions correctly when the player sprite moves from the centre.
That part was easier than I thought it would be.
The collision detection however has been trickier than I expected. :'(
I've *almost* got the adjustments working now; just a nasty glitch to fix.
Hopefully that'll be sorted out very soon.
[EDIT] YES!!! Sorted!
This change has resulted in a 2% drop in average frame-rate, but that's ok.
It's not noticeable during gameplay anyway, so I can live with it.
8)
So, even though it'll make a liar out of me, I've uploaded ONE. LAST. BUILD.
runcpc_9 contains the player sprite movement, and the adjusted collision detection routines.
I think it feels great, but I know it could be a bit better.
Luckily, it *will* get a bit better because my player sprite will have some animation frames to imply movement - though that won't be shown until the competition is over.
:P
9 is the perfect number, so upload #9 is just fine. Will play it immediately...
Wow, transparency within tiles is a pain in the butt when using double buffering!
Because of the dirty buffer system I've got running, I'd sometimes get leftovers from the previous frame (i.e. the last time the same screen buffer was displayed). So I was getting annoying flickering, particularly around the player sprite.
And if the player doesn't move for a moment, the dirty buffer thought that the cells where the player sprite is printed hadn't changed, and the see-through bits weren't being updated, because the cell wasn't being updated! >:(
To solve this I have to print the player sprite every frame, whether it changes position or not.
This has caused a slight speed hit, but oh well. It's still very fast.
That little glitch took many frustrating hours to fix... I hope it's the last major difficulty I'm going to face.
"Not likely!", say the programmers reading this!
:P
Ervin, this is one of the most impressive things i have ever seen on CPC!!! :o
Great job.
Quote from: alex76gr on 07:43, 05 August 15
Ervin, this is one of the most impressive things i have ever seen on CPC!!! :o
Great job.
:)
Thanks man!
It's amazing to hear (or read!) someone say that about something I'm working on.
Makes all the hard work worthwhile.
Alrighty, I've now got 25 different frames of animation for the player sprite, which display depending where the player sprite is on-screen.
This enhances the feeling of movement - it's like a tilting effect on the sprite as you move up/down, and a turning effect as you move left/right.
I've also managed to solve the drop in speed caused by forcing the player sprite to be printed each frame.
I incorporated the player sprite into the main tile printing routine more smoothly, and now things are flying along again!
I'm pretty happy about that.
;D
In other news, I've just discovered the joy of the cpctelera script cpct_bin2c.
This instantly converts a compiled binary into a C array of byte values, which is amazingly useful, because I'll need to stored sprite definitions as compressed data (via exomizer), in order to fit all my sprite defs in.
Sprite data will be uncompressed on the fly as required, when the game changes the "zone" that the player is flying through.
Each obstacle's uncompressed sprite definitions will take up 1,805 bytes, so RAM will run out very fast without this method.
The reason the sprite defs take up so much space is because I'm storing 21 sprite definitions for each obstacle, effectively pre-calculating the scaled versions of each obstacle.
I wrote a quick little program (in Blitz Basic) last night, that converts an image into a list of tile references.
At the moment it only handles tiles of one colour, but I'll have to extend it to cater for tiles that are more than a simple block of colour.
This little program will make it very easy to convert the tile graphics into something usable within SDCC.
I'm creating the sprites in PhotoFiltre, and then I'll chop them into tiles using the cpctelera script cpct_sp2tile.
Have I mentioned before how awesome cpctelera is? :D
I only need to manually create one version of each obstacle (the "closest" sprite - i.e. the largest, unscaled version), and then I can use PhotoFiltre re-sizing tools to create the other 20 sprites.
Some tidy-up is required, but this method is still very quick. Good thing too, as time is moving very quickly, and I need to take as many shortcuts as I can!
Also, I'm not very good at pixel art, so having the graphics pre-scaled by PhotoFiltre will save me many, many hours of work.
I'm really happy to see that utilities we have created within CPCtelera (http://lronaldo.github.io/cpctelera) are really useful for projects :). That also empowers our spirits to carry on :)
Have you tried the latest script included in 1.2, cpct_img2tileset (http://lronaldo.github.io/cpctelera/files/commandline/cpct_img2tileset-.html)? Reading your comments I imagine that it will be helpful for you :).
Keep up the good work! :D
Thanks ronaldo.
cpct_img2tileset looks like it would be very useful as well!
I'm not sure which one will be best for my needs, but I'll give both cpct_img2tileset and cpct_sp2tile a try.
[EDIT] I just had an idea...
Let's say you have a main.c that simply contains a number of array declarations (all initialised with data), and an empty void main(){}
It would be great to do the following:
- compile that main.c file
Does it have to be called "main.c"?
Does it need void main(){}?
- compress the resulting .bin file with exomizer
For example, exomizer raw "file.bin" -o "file.exo"
- use cpct_bin2c to create a C array of the compressed data
For example, cpct_bin2c file.exo>file.txt
[EDIT 2] Ah, I just realised that this won't work, as exomizer is a windows program...
Never mind. It's easy to do these steps manually anyway.
:)
Well, cpct_img2tileset (http://lronaldo.github.io/cpctelera/files/commandline/cpct_img2tileset-.html) and cpct_sp2tiles (http://lronaldo.github.io/cpctelera/files/commandline/cpct_sp2tiles-.html) have different uses. The second one works over a C array, splitting them in smaller arrays (tiles). The first one works directly over an image (PNG, TIFF, JPG). It treats the image as a set of tiles or sprites of the same size, and generates two files .c and .h with all the tiles/sprites converted to C-Arrays, and a tileset array pointing to all of them.
So, cpct_img2tileset (http://lronaldo.github.io/cpctelera/files/commandline/cpct_img2tileset-.html) is designed to work direcly on assets and transform them into code. cpct_sp2tiles (http://lronaldo.github.io/cpctelera/files/commandline/cpct_sp2tiles-.html) works on code. Everything depends always on your needs :).
The maskSpritesAligned example (https://github.com/lronaldo/cpctelera/tree/master/examples/medium/maskSpritesAligned) has an assets folder (https://github.com/lronaldo/cpctelera/tree/master/examples/medium/maskSpritesAligned/src/assets) with the tileset it uses in PNG format. Focusing on workflow, designers create tilesets like this one, and then they can be mapped with Tiled (http://www.mapeditor.org/) (.tmx and .csv files). Then a command like this one:
cpct_img2tileset -pf { 0 18 5 6 9 11 12 } tiles.png
Is all you need to generate tiles.c and tiles.h files, with all tile definitions and the tileset array, ready to compile in your code :).
The final step will be performed on future versions, integrating this with the building procedure, so that nothing else than make is requiered. Then designers can focus on design, while coders focus on code :).
Thanks ronaldo - that's *very* useful information.
:)
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): I've read your exomizer thoughts and do not understand what you are proposing. Are you talking about creating a compressed binary to load faster? Is it that you think of a way of compressing all data of a program transparently to the programmer?
Quote from: ronaldo on 08:36, 07 August 15
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): I've read your exomizer thoughts and do not understand what you are proposing. Are you talking about creating a compressed binary to load faster? Is it that you think of a way of compressing all data of a program transparently to the programmer?
No, nothing that complex.
:)
What I need to do in my program is store my sprite definition tables in a compressed form.
Otherwise they simply won't fit, as I've got 21 sprites (some of which are VERY large) for each obstacle.
So I will be creating a small C program for each obstacle's sprite definitions.
If I end up having 10 obstacle types, I'll need to create 10 of these little programs.
Each of these small programs will consist of 21 initialised arrays, and an empty main() function.
(The main() function appears to be required in order for the C file to compile).
Now, the compiled file is a .bin consisting of 1,805 bytes, which is way too big.
So I will run them through exomizer to compress them.
The first one I tried came down to under 200 bytes, due to the high repetition of bytes in the compiled file.
So theoretically I will be able to fit several compressed files into a portion of memory reserved for this data.
Now, I want the program to be single-load, so I need the compressed files to be resident in memory.
When I need a new sprite to be available to the program, I will uncompress it using the z80 decompressor, to another area of memory where uncompressed sprite data will temporarily sit.
(Unfortunately the decompress routine needs modification, as it is not 100% compatible with the z80 format used by SDCC).
To get the compressed .EXO files into memory (i.e. to be included in the game binary file), I want to put the compressed data into my C program somewhere, most likely as a bunch of include files. cpct_bin2c makes this very easy.
That's about it. Quite messy, but it's the only way all my huge sprites will fit in 64K.
:)
Grand :D
Quote from: Neil79 on 12:38, 07 August 15
Grand :D
I've been featured!
Thanks man!
The game has progressed quite a bit since the last version I uploaded, but I can't upload any more builds, as I don't want to break the competition rules regarding releasing the game independently of the competition.
I *could* release what I've got now and I think I'd be safe, but I'd rather not take any chances.
:P
Quote from: ervin on 13:16, 07 August 15
I've been featured!
Thanks man!
The game has progressed quite a bit since the last version I uploaded, but I can't upload any more builds, as I don't want to break the competition rules regarding releasing the game independently of the competition.
I *could* release what I've got now and I think I'd be safe, but I'd rather not take any chances.
:P
Any time buddy, I did note that it was an early build, so it's all good ;D
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): I undetstand better now :). I've been thinking about similar problem for some time and I've got some designs in mind about data management tools (something more general that will cover your case). Unfortunately, my designs will have to wait some months until I finish another more urgent project I'm developing now (work always has greater priority, regrettably). However, I promise I will develop these ideas as soon as I'm able to return again to the scene :D.
Quote from: ronaldo on 15:14, 07 August 15
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): I undetstand better now :) . I've been thinking about similar problem for some time and I've got some designs in mind about data management tools (something more general that will cover your case). Unfortunately, my designs will have to wait some months until I finish another more urgent project I'm developing now (work always has greater priority, regrettably). However, I promise I will develop these ideas as soon as I'm able to return again to the scene :D .
No trouble at all.
It's easy to do this stuff manually.
:)
I've now got my program storing 2 sets of compressed data in RAM, and one of them is chosen at random whenever the player enters a new "zone".
The data is uncompressed in the "live" sprite data area, and the appropriate sprite set is used for obstacles!
This technique has made a HUGE difference to memory usage.
I now have lots of memory left - more than enough to finish the game, I think.
(I can afford to devote a little over 8K to compressed sprite data).
With a little bit of research in cpctelera's docs, I've figured out how to write a PressAnyKey routine, as opposed to a routine that waits for a specific keypress (like Space, for example).
This means my front screen now says "PRESS ANY KEY" instead of "PRESS SPACE".
Much better.
Here is the code.
The first DO loop waits until there are no keys being held down.
The second DO loop can then check for a "clean" keypress.
void waitForKey(){
u8 i;
u8 keyPressed=0;
do{
keyPressed=0;
cpct_scanKeyboard_f();
for (i=0;i<10;i++){
if (cpct_keyboardStatusBuffer[i]!=255){
keyPressed=1;
}
}
} while(keyPressed!=0);
do{
keyPressed=0;
cpct_scanKeyboard_f();
for (i=0;i<10;i++){
if (cpct_keyboardStatusBuffer[i]!=255){
keyPressed=1;
}
}
} while(keyPressed==0);
}
Also, I've been able to make good use of cpctelera's cpct_drawStringM0 function to nicely centre text on a mode 0 screen.
This function (and I presume the mode 1 version as well) allows the x position of a string to be any byte position on a character row.
So whereas normal mode 0 printing in BASIC forces a string to be at byte positions 0, 4, 8, 12 and so on, cpct_drawStringM0 allows it to be at any byte position, thereby making centering much more accurate.
8)
In other news, I've got the gameplay flow nailed down now.
I run with a "level" for 10 "stages".
These are indicated by the colour of the ground stripes approaching the player - each colour represents a stage.
After 10 stages, there is an empty stage, where I decompress the next set of sprite data.
The new sprites then appear in the subsequent stage, and stay for 10 stages.
And so on...
The speed also increases every 10 stages (though the maximum speed will be capped).
:P
At first I didn't have the empty stage during the decompress phase, and I found that any sprites currently on screen would suddenly change to new sprites!
This happened because the same area of memory is being used from level to level to read the sprite data, and the program would continue reading that area and happily printing the newly decompressed sprites!
:laugh:
Having this empty stage also gives the player a brief respite from the onslaught of approaching obstacles!
In addition, it hides the slight pause during sprite decompression.
Nice work @ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82) :) . Here I leave you some suggestions for improving performance on checking keyboard for any key. All functions return TRUE when there was at least 1 key pressed, and 0 otherwise:
//
// C Version 1: Compact and Balanced.
//
u8 isAnyKeyPressed_1() {
u8 i=10, result, *keys = cpct_keyboardStatusBuffer;
result = *keys;
while(--i) {
result &= *++keys;
}
return 1 + result;
}
//
// C Version 2: Expanded, but faster
//
u8 isAnyKeyPressed_2() {
u8 *keys = cpct_keyboardStatusBuffer;
return 1 + (*keys++ & *keys++ & *keys++ & *keys++ & *keys++ &
*keys++ & *keys++ & *keys++ & *keys++ & *keys);
}
//
// ASM Version 1: Compact and Balanced (much better than C version 1)
//
u8 isAnyKeyPressed_3() {
__asm
ld hl, #_cpct_keyboardStatusBuffer
ld b, #9
ld a, (hl)
$0001:
inc hl
and (hl)
djnz $0001
inc a
ld l, a
__endasm;
}
//
// ASM Version 2: Expanded and fast (faster of all 4, smaller than C version 2)
//
u8 isAnyKeyPressed_4() {
__asm
ld hl, #_cpct_keyboardStatusBuffer
ld a, (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc a
ld l, a
__endasm;
}
Then, picking up any of these functions, you may rewrite your code like this:
void wait4Keypress() {
// First, if there is any key pressed, we wait until no key is pressed
do { cpct_scanKeyboard_f(); } while ( isAnyKeyPressed());
// Then we wait until a Key is pressed
do { cpct_scanKeyboard_f(); } while ( !isAnyKeyPressed());
}
Hope that helps :) . Keep up the good work! :D
Quote from: ervin on 03:00, 12 August 15
Having this empty stage also gives the player a brief respite from the onslaught of approaching obstacles!
In addition, it hides the slight pause during sprite decompression.
You mentioned previously that you were using exomizer for that. If that is still the case, have you tried bitbuster (http://cpcrulez.fr/applications_tools_cruncher_bitbuster_Z80.htm)at all? It's not quite as good at packing as exomizer but is a great deal faster at depacking.
Quote from: ronaldo on 10:01, 12 August 15
Nice work @ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82) :) . Here I leave you some suggestions for improving performance on checking keyboard for any key. All functions return TRUE when there was at least 1 key pressed, and 0 otherwise:
//
// C Version 1: Compact and Balanced.
//
u8 isAnyKeyPressed_1() {
u8 i=10, result, *keys = cpct_keyboardStatusBuffer;
result = *keys;
while(--i) {
result &= *++keys;
}
return 1 + result;
}
//
// C Version 2: Expanded, but faster
//
u8 isAnyKeyPressed_2() {
u8 *keys = cpct_keyboardStatusBuffer;
return 1 + (*keys++ & *keys++ & *keys++ & *keys++ & *keys++ &
*keys++ & *keys++ & *keys++ & *keys++ & *keys);
}
//
// ASM Version 1: Compact and Balanced (much better than C version 1)
//
u8 isAnyKeyPressed_3() {
__asm
ld hl, #_cpct_keyboardStatusBuffer
ld b, #9
ld a, (hl)
$0001:
inc hl
and (hl)
djnz $0001
inc a
ld l, a
__endasm;
}
//
// ASM Version 2: Expanded and fast (faster of all 4, smaller than C version 2)
//
u8 isAnyKeyPressed_4() {
__asm
ld hl, #_cpct_keyboardStatusBuffer
ld a, (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc hl
and (hl)
inc a
ld l, a
__endasm;
}
Then, picking up any of these functions, you may rewrite your code like this:
void wait4Keypress() {
// First, if there is any key pressed, we wait until no key is pressed
do { cpct_scanKeyboard_f(); } while ( isAnyKeyPressed());
// Then we wait until a Key is pressed
do { cpct_scanKeyboard_f(); } while ( !isAnyKeyPressed());
}
Hope that helps :) . Keep up the good work! :D
Brilliant! Thanks ronaldo.
Quote from: Axelay on 10:11, 12 August 15
You mentioned previously that you were using exomizer for that. If that is still the case, have you tried bitbuster (http://cpcrulez.fr/applications_tools_cruncher_bitbuster_Z80.htm)at all? It's not quite as good at packing as exomizer but is a great deal faster at depacking.
Thanks Axelay.
I haven't tried bitbuster before, but it might be worth a look...
Having said that, I'm only doing decompressing during the empty stage, which is the transition stage between sets of 10 stages.
The empty stage has no sprites on screen, so rendering is very fast - just sky and ground, and I only draw character cells which have changed since the last frame.
As a result, the decompressing phase is virtually invisible to the player.
I know it's happening, but I have to look very hard to notice it.
:)
The problem with Exomizer is, that depacking sometime crash the CPC. Reasons unknown.
Well, I think I can imagine the problem. If depacker is decompressing a buffer and looks for some condition to detect the end of the buffer, when that condition is not met, it will continue filling up the memory with rubbish.
The difficult thing would be detecting when does this happen. It might be due to bad understanding between compressor and decompressor. Say that you have a compressor that doesn't have a last minute modification done to the decompressor (or viceversa) and there you have a problem like this.
I used exomizer a *lot* with all sorts of data files when I was working on chunky pixel curator, and it never caused a crash.
So far in my development of RUN"CPC", it has worked fine every time (though of course I haven't used it for very many data files yet).
:)
Been working on my sprite routines over the last few evenings.
I had to make some changes to accomodate larger sprites, and still fit things into memory.
I think I've got it sorted.
I will now have sprites that can take up *over* half the screen when they are closest to the player.
I'm trying for sprites that can be 25x25 characters.
This naturally will cause a performance hit, but it's still very fast, so I'm happy with the trade-off.
I also had to drop the idea of tiles with transparency because TechnicalReasons(tm). It's a trade-off I'm less happy about, but I can live with it.
:)
The reason I want huge sprites is that it will give me more options for better gameplay.
Tunnels, wide objects, etc. I'll have more options, and therefore more variety.
I've also changed the visual style a bit, in order to simplify the graphics but hopefully still make them appealing.
Otherwise I won't finish the game in time!
[EDIT] I've got huge obstacles of 25x25 characters working, at a decent speed!
YEEHAA!!!
I've done some very careful analysis, and planned a memory map that allows sprites of 32x25 characters (80% of the regular screen)!
They are huge, and it's awesome to see them zooming around the screen!
I've also identified a small optimisation in my tile routine, which is very useful considering the enlarged sprites.
Time to start setting the game's palette!
I'm steering away from the bright and cheerful look, and going for something a bit different from the regular gaudy CPC game.
Holy cow only 2 months to go!!!
:o
I've now got my player sprite in the game!
Very happy about that.
:)
Unfortunately I've had to discard the idea of having multiple frames of animation for the player sprite (i.e. leaning left/right, tilting up/down), due to the approaching deadline.
I'm *really* bad at pixel art, and I don't have the time to develop some skill in it.
On the other hand, I've regained some memory, as I had already written the routines to display multiple frames, and allocated space for the sprite data.
Those things have now been removed.
8)
And of course, another couple of optimisations have been found.
I just can't help it!
Hey, for being bad at pixel art this looks really cute. You're keeping it simple and it works!
Thanks man.
:)
It will have a lot of graphics in it, but they will indeed be simple, as otherwise I'll never finish it.
Hopefully I can make simple graphics look ok!
:-[
That's quite impressive. It kinda reminds me of this
Indeed, early versions of my game did look a bit like that, but now it looks quite different, and hopefully a lot better.
I'm using pixels instead of character blocks for the graphics now, albeit large chunky pixels.
(Though of course the game is still tiled, so everything is rendered in character positions).
I haven't seen that version of space harrier before.
Pretty impressive, considering the limitations.
However, the main influence for my game is Chris Butler's work! :o
Yes, the genius that created space harrier, thunderblade, power drift and turbocharge on the c64.
The games vary in quality, but the graphical presentation was remarkably clever.
He used the character mode of the c64 to create some of the fastest pseudo-3d games on the machine.
Of course, the cpc doesn't have a character mode as such, so I'm emulating the idea using tiles.
My main concern was always whether or not it would be fast enough, but thankfully it is.
:)
Sigh... this pixel art business is very difficult!
Folks like Carnivac make me jealous.
It's an *amazing* skill, and I don't have one ounce of it!
As a result, I'm simplifying my graphics, though not quite down to character block level.
Otherwise this game will never be finished in time!
Quote from: ervin on 02:52, 26 August 15
Sigh... this pixel art business is very difficult!
Folks like Carnivac make me jealous.
It's an *amazing* skill, and I don't have one ounce of it!
As a result, I'm simplifying my graphics, though not quite down to character block level.
Otherwise this game will never be finished in time!
Nothing to do with Pixel Movement is it?
Quote from: AMSDOS on 11:31, 26 August 15
Nothing to do with Pixel Movement is it?
Movement will still be character-based, but I'm going to use large "pixels", similar in size to those in Chunky Pixel Curator.
But of course, this engine is totally different.
:)
Quote from: ervin on 11:36, 26 August 15
Movement will still be character-based, but I'm going to use large "pixels", similar in size to those in Chunky Pixel Curator.
But of course, this engine is totally different.
:)
It's still CPCtelera your using, or is the updated Library creating havoc?
Quote from: AMSDOS on 11:44, 26 August 15
It's still CPCtelera your using, or is the updated Library creating havoc?
Yep, I'm using cpctelera.
I absolutely love it.
And it has been getting better and better at a remarkable rate!
Any subsequent CPC projects will certainly 100% be created using it.
:'( :'( :'( :'( :'(
I finally finished all 21 frames of my first obstacle sprite today.
It's really just a very large collection of tile references.
Unfortunately (hence the crying faces), the exomize'd file is over 1,800 bytes.
Which means that if I want to have a dozen or so different obstacle sprites in the game, I'm gonna run out of memory.
So I have to simplify my graphics even more, and go back to character blocks as "pixels".
That calls for some more tears... :'( :'( :'( :'( :'(
I'm going back to character blocks in order to reduce the number of tiles required.
This will then allow much more repetition in the tile reference lists, thereby compressing them much better.
And then hopefully I will fit them all in memory!
There is a positive side to this though... because there will be less tiles, there will also be less character cells changing per frame, so the speed will be kept high!
It's always difficult to maintain a good balance between memory constraints for the different thins we want to fit in a game :). That's what makes a great differences when yo see a greatest hit and a good game :).
Come on! You still have almost 2 months for the deadline ;).
I was thinking over the weekend about optimisations I could make, due to the fact that I have had to go back to character blocks for the obstacle graphics...
And I realised that because there won't be very many such tiles, I can use a compiled sprite approach!
Instead of copying data from the tile table, and printing it to the screen, I can simply write a routine for each character-block tile that sets each byte in the tile to a colour value! And then I realised that I don't need to have a routine per tile... I just need an input that sets the colour to be used!
I had it up and running within 2 hours (after lots of crashes), and the speed difference is awesome!
The program seems to be around 25% faster now - I'm absolutely chuffed. This will (sort of) make up for the fact that my game will look like something made of character attribute squares on the Spectrum.
:P
The player sprite is displayed using a more traditional tile technique (lots of LDIs). I didn't want the player sprite to be composed of a few character blocks only.
:)
All my tiles are finished (and tested)!
Yay!
Admittedly, I don't have very many tiles, as my graphics will be so chunky and simple, but still eh?
Less than 7 weeks to go!!!
:o
AT LAST I have got my first obstacle in the game, correctly drawn and coloured.
It looks really cool, seeing the final version of some (admittedly poor) pixel art, finally in the game!
I also found another (tiny) optimisation!
8)
After a few stressful nights being stuck on a nasty bug, I'm back on track.
I've just finished the 2nd obstacle, and the 3rd is on the way.
8)
Alongside the game's dev, I've also been writing some tools to help with the graphics.
I've written some programs (in blitz basic on the PC) to generate the scaled sprites for me, and to colour them appropriately, so they look nicely shaded as they approach.
I hope people like the graphic style I've gone for - it's probably going to be rather weird for some people, but that's ok.
I loaded the game on my 6128 earlier tonight, and it was wonderful seeing it in action.
The monitor hides some of the strangeness in my graphics, resulting in a more shaded look.
(In WinAPE the shading is less subtle).
I certainly don't recall seeing any games that look like this.
Whether that is a good or bad thing will be up to the judges/players!
It's quite possible that people may find this game a bit ugly... we'll see!
:o
3rd obstacle is in!
This development is really becoming fun now!
My daughter tried the current build on my 6128, and she said, "wow dad, this is really good!".
I hope she's right... :)
Having said that, the game is *extremely* simple.
It's more like a tech demo with a thin slice of gameplay attached, so I doubt that I'll be walking away with one of the "best game" prizes.
That's ok though - I just very very happy that I've got this far!
:)
I just found a small optimisation, and made the tile routine 5 NOPs faster... I wish I could show you all how it's looking and running now!
;D
Quote from: ervin on 04:09, 17 September 15
I just found a small optimisation, and made the tile routine 5 NOPs faster... I wish I could show you all how it's looking and running now!
;D
Won't take long until we're there. :)
No more optimisations to be found, it seems...
Never mind.
:)
I've put in a very simple front-screen.
I don't think I'll have time (or the skill) to make it fancy, but that's ok.
I've also got a game over condition now, which takes you back to the title screen after a collision.
If you have some time then add some eye candy. That's what I did learn from the ROM competition. Only few people will appreciate your work actually (that's the ones who can code Z80), the majority will not understand how your great creation actually works and just judge 'by eyeball'.
What I've seen from your side is imho to be the winner, but they may have another POV. Give them some nice loading screen, so to make the first impression well.
And wasn't there something like '5 Extrapoints for a connection to a movie'. You could put something little in your loading screen.
Who else is participating, anything known already?
Quote from: TFM on 16:04, 18 September 15
Who else is participating, anything known already?
Morri I think, only Morri knows that! ;D
Quote from: AMSDOS on 23:06, 18 September 15
Morri I think, only Morri knows that! ;D
I won't be able to enter now. My game has turned into a bloated mess ::) so I've had to make it a 128kb disc game which takes me out of the comp.
Have no fear though, I am still working on it and will update the Let's Go thread now as not to overrun @Ervin 's thread.
Quote from: TFM on 16:04, 18 September 15
If you have some time then add some eye candy. That's what I did learn from the ROM competition. Only few people will appreciate your work actually (that's the ones who can code Z80), the majority will not understand how your great creation actually works and just judge 'by eyeball'.
What I've seen from your side is imho to be the winner, but they may have another POV. Give them some nice loading screen, so to make the first impression well.
And wasn't there something like '5 Extrapoints for a connection to a movie'. You could put something little in your loading screen.
Who else is participating, anything known already?
Yes, I think you may be right.
I'll see what I can do.
I have an idea for a connection to BTTF... quite a simple idea that might be very effective.
Not sure who else is competing.
The Spanish guys are all in stealth mode.
Really looking forward to seeing the other entries - there were some great games in last year's comp.
Quote from: Morri on 23:33, 18 September 15
I won't be able to enter now. My game has turned into a bloated mess ::) so I've had to make it a 128kb disc game which takes me out of the comp.
Have no fear though, I am still working on it and will update the Let's Go thread now as not to overrun @Ervin 's thread.
Oh no, that's a pity!
Regardless, I'm really looking forward to your game. It's looking great.
:)
Quote from: Morri on 23:33, 18 September 15
I won't be able to enter now. My game has turned into a bloated mess ::) so I've had to make it a 128kb disc game which takes me out of the comp.
Have no fear though, I am still working on it and will update the Let's Go thread now as not to overrun @Ervin 's thread.
I remember "The Eternal Light" having no chance of becoming a 64k game, though I cannot remember why that was, even after the tune had been removed. Must of been size of the game & levels. I'm presuming Let's Go progressively gets harder and levels become larger, that would present problems if the game was to become a Multi-load (if you read my earlier comments in the other thread). Otherwise a fixed portion of memory set aside for your level data in the main 64k, could be simply loaded in when required.
Hi folks.
A little update on the BTTF connection.
For the last 2 nights I've been trying to draw a Delorean, to use as the player sprite!
Due to my cr@p pixel skills, it took a while.
Here's how it looks.
Dropbox - delorean.png (https://www.dropbox.com/s/zub293pa24t9237/delorean.png?dl=0)
I was really happy with how it turned out... until I put it into a screenshot of my game.
It looked completely out of place.
:doh: :'(
In addition to that, I'd have to rewrite some graphic routines to accommodate it, as the tile routines for my player sprite have been written with a chunkier sprite in mind. That's not such a problem of course, however my tile definition table is just about full, and it would require some serious thinking to find a way of putting the Delorean in.
So, with just over 4 weeks to go, I need to think carefully about what I can afford to do, in terms of how much time I have left.
So the Delorean will not go into the game, and therefore my game will not have a BTTF reference.
:'(
Those bonus points would have come in handy.
Ah well.
It's not all bad news though, as I have a player sprite I am very happy with, and that's the one we'll go with.
It's a chunky landspeeder type of thing, done in black and white pixels only.
It looks really good against the rush of colour going on around you.
;)
Now I'm frantically trying to create a certain graphical effect, to represent what happens to the player sprite after a collision. Man, pixels are hard!
Well, instead of a DeLorean you could have put Marty on a Hoverboard :laugh:
Quote from: McKlain on 07:54, 23 September 15
Well, instead of a DeLorean you could have put Marty on a Hoverboard :laugh:
I had actually considered that, believe it or not!
However, due to my useless pixel skills, I knew that there would be almost no point trying!
:laugh:
Probably RAM is running out anyway, but.... can the Delorian be an option, so the player can use it or another player sprite. Then you got the BTTF reference and two possible player sprites?
Or, if the game gets a Highscoretable, the first place predefined with 1.21 Gigapoints as reference to 1.21 Gigawatt... ;)
Quote from: Fessor on 19:40, 23 September 15
Or, if the game gets a Highscoretable, the first place predefined with 1.21 Gigapoints as reference to 1.21 Gigawatt... ;)
You think that somebody will get that? ;)
They want a reference, therefore they must know the movies. and that 1.21 is a famous number as 42 ;)
There are many references possibles if they are fans of the movies.
A possible obstacle could also be a manure heap. (as every member of the tannen family in every movie crashed into one)
*edit*
If the game is in style of the uploads from the first post or that space harrier thingy... why not a level in that rainy highway flying scene of bttf 2?
*/edit*
Including some quotes / character names in top 10 default highscore should do the trick. Lots of games did it
Quote from: TFM on 17:33, 23 September 15
Probably RAM is running out anyway, but.... can the Delorian be an option, so the player can use it or another player sprite. Then you got the BTTF reference and two possible player sprites?
That's a really great idea... but I don't think I'll have time.
:(
Quote from: Fessor on 20:05, 23 September 15
They want a reference, therefore they must know the movies. and that 1.21 is a famous number as 42 ;)
There are many references possibles if they are fans of the movies.
A possible obstacle could also be a manure heap. (as every member of the tannen family in every movie crashed into one)
*edit*
If the game is in style of the uploads from the first post or that space harrier thingy... why not a level in that rainy highway flying scene of bttf 2?
*/edit*
That's a great idea as well, but I almost certainly won't have time to implement a level that is so specifically styled. :(
Quote from: Singaja on 20:11, 23 September 15
Including some quotes / character names in top 10 default highscore should do the trick. Lots of games did it
Hmmm... now THAT is something I might be able to do something with, in the time I have left.
If I have any spare time once the rest of the game is finished, I'll implement this.
Fingers crossed!
In other news, I now have a lovely colourful explosion when the player collides with an obstacle!
Hi everyone.
I now have a game-over sequence I'm very happy with.
It's really just a bunch of explosions, but it looks very cool within the context of the game.
I've also started to experiment with sound.
Arkos Tracker is really cool!
I've never used it before, but it takes me back to the days of Sound Tracker etc. on the Amiga.
Ah, happy days.
I just need to figure out how to play sound fx and music using cpctelera.
It looks easy enough from the instructions, but I haven't actually tried it yet...
In other news, I've been going over the gameplay in my mind for almost 2 weeks, struggling with some concepts.
- What's to stop the player from simply going around obstacles, thereby making the game too easy? (I can't have too many obstacles on the screen at once due to performance concerns, so level design is a bit challenging).
- How do I keep the gameplay interesting?
- How do I give the game a reason for existing?
Well... earlier today I was chatting to a friend about it at work, and he casually offered a suggestion, and I said, "YES! THAT'S BRILLIANT!!!".
The basic idea is that to progress to the next level, players will be forced to play dangerously.
They will have to fly through the gaps in obstacles, or between obstacles, in order to score points.
After scoring a certain number of points, the next level will begin.
Of course, a collision will be instant "game over".
:)
I think/hope this idea will make the game more than just a glorified tech demo, and it shouldn't be too difficult or time-consuming to implement.
8)
ok, I just stay in Level 1 then ;)
Quote from: TFM on 17:26, 25 September 15
ok, I just stay in Level 1 then ;)
:D :D :D
YEEHAA!!!
I've got some (really bad!) music playing on my title screen now!
I'm surprised how easy it was to get it working.
The one thing that tripped me up was to make sure (when exporting to BIN) that I export my arkos tracker song to the address it will reside at in my program.
Once I figured that out, it worked!
Now I can add some equally bad sfx!
Wow... that was frustrating!
For the last couple of evenings I've been stuck on ONE BUG.
??? :'(
It only occurred very occasionally, and was very hard to reproduce.
It took a heck of a lot of debugging, but I finally narrowed it down to one function.
And in that function, under a very specific circumstance, another function was being called one time too many - but only very occasionally.
It came down to the simple mistake of not initialising a variable during my initGame() routine.
A simple mistake that caused hours of frustration!
Ah, the joys of programming!
:-\
Oh, incidentally, solving this lead to another little optimisation I discovered whilst debugging.
So something good came out of it then!
Quote from: ervin on 06:22, 29 September 15
Wow... that was frustrating!
For the last couple of evenings I've been stuck on ONE BUG.
??? :'(
It only occurred very occasionally, and was very hard to reproduce.
It took a heck of a lot of debugging, but I finally narrowed it down to one function.
And in that function, under a very specific circumstance, another function was being called one time too many - but only very occasionally.
It came down to the simple mistake of not initialising a variable during my initGame() routine.
A simple mistake that caused hours of frustration!
Ah, the joys of programming!
:-\
Oh, incidentally, solving this lead to another little optimisation I discovered whilst debugging.
So something good came out of it then!
Thought I was the only 1 that did that! :D
Quote from: ervin on 06:22, 29 September 15
Wow... that was frustrating!
For the last couple of evenings I've been stuck on ONE BUG.
??? :'(
It only occurred very occasionally, and was very hard to reproduce.
It took a heck of a lot of debugging, but I finally narrowed it down to one function.
And in that function, under a very specific circumstance, another function was being called one time too many - but only very occasionally.
It came down to the simple mistake of not initialising a variable during my initGame() routine.
A simple mistake that caused hours of frustration!
Ah that's nothing. Once I had a bug, it took me over 3 weeks to track it down. Even gave it a name: TRI. I thought I get mad, but at the end I found it the TRI (track register increase) happens only with 6128 Plus 3" drives when changing the track before the FDC did read all GAP#3 bytes. After that I had to explain the problematic to a bunch of coders. Still now once in a while somebody suffers from the TRI bug. So if you solved an occasional appearing bug in days only: My congratulations, great work!!! :) :) :)
Quote from: TFM on 19:27, 29 September 15
Ah that's nothing. Once I had a bug, it took me over 3 weeks to track it down. Even gave it a name: TRI. I thought I get mad, but at the end I found it the TRI (track register increase) happens only with 6128 Plus 3" drives when changing the track before the FDC did read all GAP#3 bytes. After that I had to explain the problematic to a bunch of coders. Still now once in a while somebody suffers from the TRI bug. So if you solved an occasional appearing bug in days only: My congratulations, great work!!! :) :) :)
Wow, that's amazing persistence - 3 weeks!
I guess when you REALLY want to do something, you'll find a way to do it!
I know the feeling all too well...
Although I have no idea about TRI, FDC and GAP bytes.
:P
Praise the lord for that! Hahaha! (If you need FDC routines let me know).
Hi folks.
I can't believe it's been a week since my last update!
I've done lots of behind-the-scenes work in order to free up some memory.
My biggest gain has come from implementing cpctelera's randomisation functions.
They replaced SDCC's srand() and rand() functions, and gave me back around 600 bytes!!!
:o ;D
I haven't got much time left (!!!), but I still have the following to do:
- final bits of gameplay logic
- better music and sfx
- create the final set of obstacles
- hi-score table
I'm very stressed about meeting the deadline, but the fact that my lovely 9-year old daughter and my brother-in-law both think the game is great gives me a lot of confidence.
(Though they would say that wouldn't they?) :P
OMG! 600 bytes for a ramdom value! That's shocking crazy. For Cyber Chicken I use a random number generator which is iirc less than 10 bytes. Something like read register R and mix it with some other register, then a value from ram. it works quite nice. 600 bytes for that - the curse of high level languages I guess. Great that you freed the space and settled it down. :)
Yeah, cpctelera's random number generator is tiny compared to sdcc's.
I couldn't believe the difference.
And seeing how low my available RAM is running, it's a very welcome change!
I don't understand how it works, but that doesn't matter.
That's the point of a good framework - things work well, and are efficient, but I don't need to know how they work.
:)
It's always nice to here that algorithms like this one are useful :). Uniform random number generator integrated ni CPCtelera (http://lronaldo.github.io/cpctelera) is extremely simple and quite known 33*seed mod 257. This is knwon as Fast RND and it's quite similar to Spectrum's ROM integrated pseudo-random generator.
You have to take into account that I've modified the standard algorithm to add an entropy byte. The standard algorithm has a periodicity of 170 numbers. So, once you have asked for 170 random numbers using the same seed, you start getting the same 170 numbers again and again in the same order. However, if you feed the algorithm with an entropy byte (a random byte comming from some entropy source) only once every 15 numbers you can get a sequence of up to 55360 random numbers without repetition. The nice point of this algorithm is that it is fast, simple and takes up only few bytes.
Anyways, this is not enough in some cases. It may be useful for general and simple applications (or most games), but sometimes a better quality pseudo-random generator will be required.
More to come on future releases ;).
Quote from: ronaldo on 12:01, 07 October 15
It's always nice to here that algorithms like this one are useful :) . Uniform random number generator integrated ni CPCtelera (http://lronaldo.github.io/cpctelera) is extremely simple and quite known 33*seed mod 257. This is knwon as Fast RND and it's quite similar to Spectrum's ROM integrated pseudo-random generator.
You have to take into account that I've modified the standard algorithm to add an entropy byte. The standard algorithm has a periodicity of 170 numbers. So, once you have asked for 170 random numbers using the same seed, you start getting the same 170 numbers again and again in the same order. However, if you feed the algorithm with an entropy byte (a random byte comming from some entropy source) only once every 15 numbers you can get a sequence of up to 55360 random numbers without repetition. The nice point of this algorithm is that it is fast, simple and takes up only few bytes.
Anyways, this is not enough in some cases. It may be useful for general and simple applications (or most games), but sometimes a better quality pseudo-random generator will be required.
More to come on future releases ;) .
Thanks for the info ronaldo.
:)
It actually took me a little while to figure out the best way to use the random number generator in my game.
In the end I went with this:
cpct_setRandomSeedUniform_u8(ni);
ni is the number of while loop iterations that pass on the title screen, as the game waits for the player to press a key.
Then I use this to select the next level:
currentLevel=(cpct_getRandomUniform_u8_f(0)*10)>>8;
I've done extensive testing, and I get a nice even spread of numbers from 0 to 9, which is exactly what I want.
8)
Hi folks.
Another update...
I've got the obstacle-passing detection working properly at last!
The idea is that each "level" will consist of one type of obstacle in various arrangements.
For example, you might need to fly "through" an obstacle in order to score a point, and you would lose a point if you go around the obstacle instead.
This was a lot easier than I expected, thankfully.
:)
After that I began work on ending the current level, and starting the next one, once the required number of points had been scored.
But this resulted in nothing but frustration.
After much head-scratching, and game-breaking nonsense, I realised that I'd have to rewrite parts of my existing level transition code, in order to implement this idea.
And I don't have the time left to do so...
:'(
So I went to sleep wondering what the heck I was going to do, in order to make the game interesting (now that my main gameplay "hook" was no longer feasible).
During breakfast this morning, I had an idea.
What if I do the following?
- don't reduce the player's score if they "miss" an obstacle (i.e. the player simply scores a point if the pass an obstacle correctly, and that score cannot be taken away from them)
- have an energy level (perhaps 10 units)
- when the player passes an obstacle correctly, their energy increases by 1 unit (up to the maximum of 10)
- when the player misses an obstacle, their energy reduces by 1 unit
- when the player's energy hits 0, the land speeder drops to the ground and it's game over
- of course, crashing into an obstacle is still instant game over
- so we'll have a game where, in order to continue, the player will need to fly through obstacles and play dangerously
- if the player doesn't play dangerously/aggressively enough, they won't last very long!
8)
This might be the best gameplay hook I can implement in the time I have left, considering how much other stuff I have left to do.
:o
I now have a fully operational battle station status panel!
It displays the player's energy level, the score, and the requirement for the current level.
Getting all of that working, without making the speed of the game suffer, was trickier than I thought it would be.
Especially when taking double-buffering into account, as it needs to be printed twice!
The panel is not updated every frame; only when it needs to be.
And when the panel is updated, it is built character-by-character, only printing the characters that have changed.
In addition to that, the panel update is spread across 2 screen updates (one for each screen buffer), so that it isn't being printed twice in the same frame.
???
I'm glad that part is behind me now.
8)
That's a great idea! Only print on screen what you really need. Some GFX elements may not change at all, so no need to check them for a change anyway. :)
YIPPEE!!!
The main gameplay loop is finished!!!
- pressing a key from the main menu takes you into the game.
- your landspeeder takes off.
- you fly about for a bit.
- you accumulate points and gain energy if you pass obstacles correctly.
- you lose energy if you pass things incorrectly.
- if you run out of energy, you fall to the ground and explode - game over.
- if you hit an obstacle, you explode - game over.
- you get a game over screen.
- pressing a key takes you back to the main menu.
I'm so happy right now!
I've still got lots to do, but the actual "game" part of the project is done!
;D ;D ;D ;D ;D
Things to do:
- a bit more information on the game over screen
- high score table
- entry of a high score
- instructions
- better music and sfx
- more obstacles and graphics
- proper level layouts
- a simple loading screen
And I've only got 2 weeks left!!!
:o
The game-over screen now contains some info (i.e. SCORE), and we now have an instruction screen!
Simple instructions that get straight to the point.
I'm running dangerously low on RAM now... luckily I still have a large area of RAM reserved for compressed files.
I might be able to use some of that, but to do that I may need to compromise the number of obstacles.
:-\
If Arkos don't use it, there are a few hundred bytes where the OS stores the definitions of the ENVs and ENTs that could be used. (As you don't use the Firmware-Routines for Sound there should be no Problem)
Only Problem is that the Adresses are different on 464 and 664/6128
464: From &b61a to &b7f9
664/6128: from &b2b6 to &b495
That gives you additional 479 bytes for Data-Storage
The Area before this, where the Soundqueue is stored may be also usable and gives some hundred bytes more.
Quote from: Fessor on 02:01, 10 October 15
If Arkos don't use it, there are a few hundred bytes where the OS stores the definitions of the ENVs and ENTs that could be used. (As you don't use the Firmware-Routines for Sound there should be no Problem)
Only Problem is that the Adresses are different on 464 and 664/6128
464: From &b61a to &b7f9
664/6128: from &b2b6 to &b495
That gives you additional 479 bytes for Data-Storage
The Area before this, where the Soundqueue is stored may be also usable and gives some hundred bytes more.
Thanks for the info; I didn't know that.
However, I've got the firmware disabled, and I'm using that area of RAM anyway, for double-buffering.
(I'm using 0x8000 and 0xC000 as the 2 screens).
Alrighty...
- The game-over screen now shows your final score.
- There is now an instruction screen (with a *very* subtle movie reference).
- There is a little feature (I think it's kind of cute) which displays the number of points you score when you pass through an obstacle - I don't want to give too much away so I'll leave this one a bit vague. ;D
- The high-score table is almost finished (with appropriate movie references).
Yes, we're getting there now...
BUT I've run out of memory!!!
:doh: :doh: :doh:
I've had to claw back 1K from my compressed files storage area.
I don't yet know if this will be a problem, but, as mentioned before, I may need to compromise the number of obstacles in the game.
:(
Still, at least the game is working well, and is actually a proper "game" now!
Thanks for the update mate :)
Quote from: Gryzor on 16:33, 11 October 15
Thanks for the update mate :)
Always a pleasure.
Although I probably spend a *bit* too much time talking about this project, not only on here, but to my long suffering family as well!
:laugh:
At least my daughters enjoy testing the game.
;D
The high score table is almost finished now.
I know I said it was almost finished a day or two ago, but it turns out that it wasn't.
:doh:
It's much closer now.
The player is now able to type in their name (up to 8 characters).
I just need to store it in the correct row of the high score table.
I also tweaked the collision detection, so that the player now has to be within the vertical bounds of a sprite as well (until now they've only had to be within the horizontal bounds). This means (if I have time and RAM) that I will be able to have a couple of obstacles that are off the ground, forcing the player to change their vertical position more often. :P
Then I'll throw together a little loading screen.
Then it'll just be graphics, sound, and level layouts.
But yes, I ran out of RAM again last night.
:'( :'( :'(
I'll have to be very careful with the space I've got remaining in my compressed files buffer (where the exomize'd graphic and sound data is stored).
Oh the pressure!!!
YEEEESSSS!!!!!
;D ;D ;D ;D ;D
The *program* part of RUNCPC is finished!
I'm so happy right now!!!
The high score table is in and fully functional, and I've been able to put 384 bytes back into my exomized files buffer.
So altogether I've got 8,944 bytes available to store compressed sprite/tile/sound data.
That should be enough for a few more obstacles!
My remaining to-do items:
- simple loading screen
- more obstacles, along with their associated graphics and level layouts
- more/better sound
But as of right now, I have a feature-complete game!!!
Awesome!!! Can't wait to play it! :)
Congratulations for finishing coding your game !
Now i want to see it ;)
The loading screen is finished.
;D
Nothing fancy, but it'll do.
I don't have the time (or skill) to make a nice pixel art loading screen.
Onto audio now...
Quote from: ervin on 13:49, 14 October 15
The loading screen is finished.
;D
Nothing fancy, but it'll do.
I don't have the time (or skill) to make a nice pixel art loading screen.
Onto audio now...
Contact MacDeath!
Not a bad idea!
However, the loading screen is all done, and matches the game's title screen, so I'll leave it for now.
:)
Music is half done now.
It's not very good (as I'm certainly not much of a musician!), but it works well enough.
Sort of.
:laugh:
Woohoo! The title screen music is done!
It's only a short composition (and of course I'm completely cr@p as a musician), but to be honest I'm really happy with it!
Who woulda thought?
;D
[EDIT] Also, I've managed to claw back over half-K for my exomized files buffer.
I realised that the music can be uncompressed into the same area of RAM that sprites get uncompressed to during gameplay.
That allowed me to make the music better, and also to reduce the amount of space needed for the sfx (because the audio buffer no longer needs to be as big as it was).
In fact, the sfx can now reside in RAM uncompressed, and no longer need to be uncompressed whenever the player starts a new game.
This is a great result, and will give me some breathing room to finish my obstacles.
Sound effects are done!
They're not particularly good, but they do create a weird, trippy soundscape as you play, as well as letting the player know how they are doing.
The death sound effect is particularly weird (and has some randomness built in), and it's quite shocking to the ears after the sounds that happen before it, but I like it, so it stays.
:P
So at last, FINALLY, I'm up to the last part of the development.
The level layouts and obstacle graphics.
This part should be a bit of fun, as I've written a bunch of tools to assist with creation of the obstacle graphics.
Hopefully this part will be trouble-free (NOTHING else has been so far!).
I won't have a whole lot of time for playtesting and tweaking, so hopefully I make something fairly playable!
It might turn out to be awful (I *really* hope not... I've put so, so much effort into this).
:o
Ahhhh not in time for the weekend then. Next week hopefully! :)
Yep, I sure hope so!
I've got 7 days left to finish this thing!
:o
Go, go, GO!
Yes yes yes!!!
I've added some level layouts to the first level, and I'm really excited to say that it works really well!
It's very fast and very difficult, but the frustration is balanced out by the angry desire to do better!
So I think some people will like the game a lot, and some people will hate it. And that's perfectly ok.
:laugh:
I personally think it's going to be a pretty good game, and I'm very glad (and relieved) about that.
I'm actually hoping that at least one CPC user out there will like it enough that they will want to take turns with a friend, to see who can get the best score.
I'm certainly aiming for a very competitive high-score chaser style of game.
And for the first time, I'm feeling confident with the time I have left as well.
:)
Keeping my fingers crossed for your final sprint and looking forward to play it on real CPC :-)
Quote from: Singaja on 15:10, 16 October 15
Keeping my fingers crossed for your final sprint and looking forward to play it on real CPC :-)
Thanks.
;D
It works nicely on my real CPC.
8)
ONE OBSTACLE LEFT TO DO!!!
But I need sleep...
I've got just over 900 bytes left to squeeze the exomized data for the last obstacle into...
I can't believe I'm almost there.
I've got 9 obstacles so far, and I've always wanted 10, so I've just about achieved that.
I'm not sure they all look particularly good, and I'm worried that I'm not the best person to judge the gameplay and difficulty level.
Some obstacle types are a bit easier to navigate than others.
(I've playtested this game so much, that I can no longer tell if it is too hard/easy).
Oh well, it is what it is.
I just hope other people enjoy it... soon now...
:)
... aaaaaaand the final obstacle is in!!!
YEEEEEEHAAAAAAA!!!
;D ;D ;D ;D ;D
Just managed to fit it into the remaining RAM!
Now I've got a little bit of time for playtesting/tweaking the level layouts.
Then I've gotta put together the documentation and other bits and pieces, to meet the comp requirements.
I can't wait to show this game to you all.
8)
Congratulations! :)
FINISHED!!!
;D ;D ;D
I have a couple of days left to gather all the other competition requirements together.
But at last, the game is done.
8)
AWESOME!!!!! :) :) :) :) :) :) :) :) :)
(http://www.cpcwiki.eu/imgs/a/a9/RuncpcTitle.png)
Ooooh yeah. Too bad I won't have time today...
Can you up it to the Downloads section? :)
Quote from: Gryzor on 13:51, 21 October 15
Ooooh yeah. Too bad I won't have time today...
Can you up it to the Downloads section? :)
I'd love to, but I'm not allowed to upload it anywhere until the competition is over.
I'm bursting with excitement for you all to see the game!
Quote from: ervin on 14:24, 21 October 15
I'd love to, but I'm not allowed to upload it anywhere until the competition is over.
I'm bursting with excitement for you all to see the game!
The embargo is until October 31st, isn't it?
After that you'll be free to distribute the game :)
Psssst!
Just send it to my email. Nobody needs to know!
Quote from: reidrac on 14:39, 21 October 15
The embargo is until October 31st, isn't it?
After that you'll be free to distribute the game :)
Yes, I think that is correct.
Quote from: Gryzor on 14:42, 21 October 15
Psssst!
Just send it to my email. Nobody needs to know!
:laugh: :laugh: :laugh:
I would so very much love to do just that.
Sorry man, I've gotta wait just a *bit* longer.
It is done.
RUNCPC (along with all the required support material) has been uploaded to the competition website.
Tomorrow night, I will go to sleep at a normal hour!
;D
I can't believe I actually went through with all of this and succeeded!
I am *so* excited!
It's the weirdest feeling actually... for 4 months I've been working very hard on this project, and now it's gone.
It's out there, no longer mine...
Very strange feeling.
Time to think about a level editor then ... ;D Good luck! But for technical achievement you shall win anyway! :laugh:
all the best Erv man cant wait to see the retro dev results and cant wait till we are allowed to play it ;D
Quote from: TFM on 19:46, 21 October 15
Time to think about a level editor then ... ;D Good luck! But for technical achievement you shall win anyway! :laugh:
Thanks man.
:)
I don't think a level editor will be happening.
I have less than 100 bytes left, the way the program is now.
In any case, putting new obstacles in is quite complex.
I've written a number of tools (using Blitz3D!) during RUNCPC's development, including a program that automatically resizes an obstacle's fully zoomed image into the other sizes required, and another program that converts each of those images into tile reference lists.
Those tools are not very user friendly.
:-[
On top of that, the obstacle definitions (i.e. tile reference lists) are exomized, and then stored in specific locations in my main .BIN file.
The exomized obstacles also contain level layout data.
So I'm afraid a level editor is probably unlikely.
:(
I think I'll pause my CPC dev for a little while now, though I would like to send a Bresenham's routine (as well as a PLOT routine) to ronaldo, for possible inclusion in cpctelera...
Quote from: cpc4eva on 20:46, 21 October 15
all the best Erv man cant wait to see the retro dev results and cant wait till we are allowed to play it ;D
Thanks man.
:)
Still feeling really weird this morning.
I don't know if it's the anticipation, the relief, or the fact that the thing I've been laser-focused on for 4 months is now over, and I won't know what to do with myself!
???
Sorry for derailing here, but I guess the experts about CPCTelera do read here.... So what does CPCTelera actually target? Is it the CPC hardware directly? The firmware? Does need some parts of the old OS?
My apologies for the question, but I'm not into PC stuff or C. :)
I know CPCTelera offers some optimized routines to replace the firmware ones for tiles and such. Disabling the firmware is optional I reckon.
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179): Referring to the low-level library, CPCtelera (http://lronaldo.github.io/cpctelera) directly speaks to hardware. The only "firmware" part it provides is an implementation of the putchar function to let you use C's printf function without any problem.
Everything is written in ASM. You can navigate and check source code directly at github.
Quote from: ronaldo on 18:06, 22 October 15
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179): Referring to the low-level library, CPCtelera (http://lronaldo.github.io/cpctelera) directly speaks to hardware. The only "firmware" part it provides is an implementation of the putchar function to let you use C's printf function without any problem.
Everything is written in ASM. You can navigate and check source code directly at github.
Pretty awesome!
So... a CPCTelera program can be (in principle) started from Amsdos, CP/M or whatever, right?
Can't wait to download the games of the Game competition... only one day left!!!
Well, you'll have to wait a little bit more. Games won't be published until Award Ceremony is over, next saturday, the 31st :) . Nominees and their games are to be presented there, through the streaming online, to the entire world ;)
Quote from: ronaldo on 19:25, 22 October 15
Well, you'll have to wait a little bit more. Games won't be published until Award Ceremony is over, next saturday, the 31st :) . Nominees and their games are to be presented there, through the streaming online, to the entire world ;)
Wow, there are some VERY interesting games popping up.
I'm so excited to see what everyone has created (even if my entry will be beaten by a number of them)!
Quote from: ervin on 23:28, 21 October 15
Thanks man.
:)
Still feeling really weird this morning.
I don't know if it's the anticipation, the relief, or the fact that the thing I've been laser-focused on for 4 months is now over, and I won't know what to do with myself!
???
u better go have a mini celebration to release all that nervous energy then you can have a bigger celebration if you win something ;D
Hi everyone.
Now that the competition is over, I can present my game to you all!
I hope you enjoy playing RUNCPC as much as I enjoyed creating it.
;D
To run the game, simply type:
RUN"CPC
;)
Yeah bummer it missed out, I didn't even see a Screenshot of it ???
I had the chance to see it on the livestream , the message "I'm f.... fast" ;D was definitely delivered. Awesome dynamics,almost too good as the game has no remorse on the player, hahah it's pure punishment. Imho the difficulty needs to progress more steadily (bigger rings for starters ;) ). Sometimes you get the impossible ones at the very beginning. I barely made it to highscore on continuous retries. This has it's charm in the spirit of 80s, where most of the games where so unforgiving. Great work Ervin
Hello, here my comments :
- First of all it's really fast for full screen game, your engine runs very well
- The game is very hard, and i wonder if the main sprite is not a little too large to have good visibility, or you can reduce the hitbox.
- For improve gameplay :
- Start the game with easy rings and increase difficulty
- In the first levels set more space beetwen rings
- When hitting an obstacle lose a life or lose double energy, sometimes i have game over with less than 3 seconds of play.
Honestly good works.
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82), my comments:
- nice sparkle effect on run-cpc made with simple chars
- menu screen is simple and colourful and easy to navigate
- i really like the in-game graphics style. the variation in the coloured blocks is very nice. the graphics of the ship are chunky and suit the style. continue to explore this style, it's worth it and your results are really nice.
- game is too hard and too fast for me. it's hard to avoid things and the things you have to avoid i think could have better design to make it easier. the z shape is awkward for me.
- dying quickly makes it harder, consider something where you can scrape if you get close and loose some energy. this would allow simple errors in play but make it a bit easier.
- consider telling the player which way to go. maybe some hint. it depends on if the flying is freeform or a set route.
on the whole, its a fun, but tough, game with a nice style.
EDIT: For me the size of the main ship sprite is fine. :)
Quote from: AMSDOS on 01:44, 01 November 15
Yeah bummer it missed out, I didn't even see a Screenshot of it ???
Yeah I was a *little* disappointed that I didn't get at least third place.
I guess when you put your heart and soul into something, you hope that others see that effort, and enjoy what you've created.
:)
However, reading the comments that have been posted so far today, I can see that I made the game *far* too difficult.
I did indeed set out to make a very difficult game. That was always the intention.
I was very much inspired by the feeling of satisfaction felt in Dark Souls, when you overcome a particularly difficult part of the game that has had you stumped for days...
I guess RUNCPC's difficulty is what defeated it in the end.
Having said that, I was beaten by some *stunning* games.
I can't wait for the download links to appear... I'm SO excited to try all the games, especially the top 3 games in the PRO category.
I have to admit, when I saw the first video posted for Frogalot, my immediate thought was, "That's it. I've got no chance"!
:laugh:
Quote from: Singaja on 08:47, 01 November 15
I had the chance to see it on the livestream , the message "I'm f.... fast" ;D was definitely delivered. Awesome dynamics,almost too good as the game has no remorse on the player, hahah it's pure punishment. Imho the difficulty needs to progress more steadily (bigger rings for starters ;) ). Sometimes you get the impossible ones at the very beginning. I barely made it to highscore on continuous retries. This has it's charm in the spirit of 80s, where most of the games where so unforgiving. Great work Ervin
Thanks Singaja.
I think you've pretty much nailed what I was aiming for!
I
did consider making the difficulty a *little* bit more gradual, and I had some brief designs for it, but I decided against it in the end.
Ah well...
Quote from: Arnaud on 09:31, 01 November 15
Hello, here my comments :
- First of all it's really fast for full screen game, your engine runs very well
- The game is very hard, and i wonder if the main sprite is not a little too large to have good visibility, or you can reduce the hitbox.
- For improve gameplay :
- Start the game with easy rings and increase difficulty
- In the first levels set more space beetwen rings
- When hitting an obstacle lose a life or lose double energy, sometimes i have game over with less than 3 seconds of play.
Honestly good works.
Thanks Arnaud.
I really appreciate your comments.
I did try a smaller sprite, but it felt "wrong"...
I also tried a smaller hitbox (shrinking by one "cell" either side of the ship), but it felt too easy. I guess that's the problem when you're the developer and the tester at the same time.
Those are all good ideas, and I had actually thought of some of them, but in the end I had pretty much run out of memory and time, so I submitted what I had.
But it means a lot to me that the awesome folks on this forum appreciate the engine I created (I like designing games very much, but I'm primarily a programmer).
:)
Quote from: arnoldemu on 09:50, 01 November 15
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82), my comments:
- nice sparkle effect on run-cpc made with simple chars
- menu screen is simple and colourful and easy to navigate
- i really like the in-game graphics style. the variation in the coloured blocks is very nice. the graphics of the ship are chunky and suit the style. continue to explore this style, it's worth it and your results are really nice.
- game is too hard and too fast for me. it's hard to avoid things and the things you have to avoid i think could have better design to make it easier. the z shape is awkward for me.
- dying quickly makes it harder, consider something where you can scrape if you get close and loose some energy. this would allow simple errors in play but make it a bit easier.
- consider telling the player which way to go. maybe some hint. it depends on if the flying is freeform or a set route.
on the whole, its a fun, but tough, game with a nice style.
EDIT: For me the size of the main ship sprite is fine. :)
Thanks so much for your comments.
I consider you one of the finest CPC devs around, so I really appreciate that you like what I've done.
It means a lot to me.
:)
I'm so glad you like the graphics style.
It was very much born out of necessity.
Simple blocks are of course very fast to draw as tiles (and in fact my tile routines are pretty much compiled sprite routines with 2 parameters for colours).
I can't pixel my way out of a paper bag, so that player sprite took hours! :laugh:
I made it chunky to keep the pixels square, to fit in with the larger chunks flying at the player!
Believe it or not the game was originally faster - a lot faster!
Somewhere between 40% to 50% faster, in fact (not frame rate, but game speed).
Of course it was virtually impossible, so I slowed it down.
I had considered losing energy on a hit instead of instant game over, but unfortunately I decided against it.
Never mind...
Incidentally the game does sort of tell the player which way to go (or rather, what to do), by way of the instructional word in the top right corner.
That's pretty much all you need to do, because other than that, the game is totally on rails - there's no real freedom of movement as such.
The "Z" obstacle caused me more grief than any of the others.
It was originally a bit fatter, and far more difficult.
I trimmed it down to something that felt a lot fairer, but never managed to make it gel with the other designs in terms of difficulty.
I wish I had another day left to tweak that aspect of the game.
Incidentally, the A and Z obstacles are tributes to my daughters, and the roses are for my wife.
;)
[EDIT] By the way, I've changed my forum sig. It now mentions RUNCPC, and points to the pouet.net page for it.
Very nice game. Easy to enjoy is short bursts. Reminds me to Flappy Bird on that regard.
Getting between the obstacles and scoring is very satisfying, I like the sound effect. Getting killed is nice too, but as others said it is a little bit unforgiving and perhaps it could benefit of having more than one life; but no necessarily. The way is it now is fine, it is easy to start again.
Currently the only way of getting some sense of progress is the score (and it works great!), but the fact that the obstacles change each play makes me feel that some plays are harder just because of randomness and not because of my skill.
Thanks for the game!
Quote from: reidrac on 14:17, 01 November 15
Very nice game. Easy to enjoy is short bursts. Reminds me to Flappy Bird on that regard.
Getting between the obstacles and scoring is very satisfying, I like the sound effect. Getting killed is nice too, but as others said it is a little bit unforgiving and perhaps it could benefit of having more than one life; but no necessarily. The way is it now is fine, it is easy to start again.
Currently the only way of getting some sense of progress is the score (and it works great!), but the fact that the obstacles change each play makes me feel that some plays are harder just because of randomness and not because of my skill.
Thanks for the game!
Thanks reidrac.
:)
Indeed you are right - some plays are indeed harder due to randomness.
I've mentioned the "Z" before, but I also find the twin snakes a bit harder than the bubbles, even though they are virtually the same dimensions!
Can we have an old people Mode by seeding the PRNG at start of a game with a fixed value so that the obstacles in each game are on the same place as in the game before?
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): thanks :)
btw, i also think that you don't need to go back and change anything. runcpc is released and no need to go back and change it. i would not go back and change any of my games even if they had poor feedback. i think it's too demotivating to do that. i prefer to take the feedback and apply it to the next game.
i played runcpc again and this time i looked at the word in the top right. i watched this and followed what it said. i am getting better each time i try it. :)
Quote from: ervin on 12:57, 01 November 15
However, reading the comments that have been posted so far today, I can see that I made the game *far* too difficult.
As far as difficulty went, flying through the "O" was the hardest for me, because it seemed to be about getting the elevation & position correct. I did a lot better flying along the bottom of the "A"'s and got into the Hiscore Table. But I only 113 as my PB, not that it took me that long. As a game of concentration I love it.
Quote from: Fessor on 20:04, 01 November 15
Can we have an old people Mode by seeding the PRNG at start of a game with a fixed value so that the obstacles in each game are on the same place as in the game before?
For anyone playing the game on an emulator, try slowing the emulation down.
RUNCPC is still very playable even at 50% speed, but it's a heck of a lot easier!
For those playing on real hardware, I'm sorry to say there is no cheat mode.
However, it definitely plays better on real hardware!
Quote from: AMSDOS on 22:41, 01 November 15
As far as difficulty went, flying through the "O" was the hardest for me, because it seemed to be about getting the elevation & position correct. I did a lot better flying along the bottom of the "A"'s and got into the Hiscore Table. But I only 113 as my PB, not that it took me that long. As a game of concentration I love it.
Do you mean the blue bubble?
Yeah that one is a bit tricky, but it's actually my favourite.
I wanted a mixture of levels that require horizontal+vertical movement, and levels requiring only horizontal movement.
Even though levels with vertical movement are harder, I find them the most fun to play.
:)
Quote from: arnoldemu on 20:14, 01 November 15
@ervin (http://www.cpcwiki.eu/forum/index.php?action=profile;u=82): thanks :)
btw, i also think that you don't need to go back and change anything. runcpc is released and no need to go back and change it. i would not go back and change any of my games even if they had poor feedback. i think it's too demotivating to do that. i prefer to take the feedback and apply it to the next game.
i played runcpc again and this time i looked at the word in the top right. i watched this and followed what it said. i am getting better each time i try it. :)
Thanks man.
:)
Yeah the word in the top right is something that came along quite early in the game's design.
Originally I wanted the word to fly across the screen at the start of a level (this would have made the objectives clearer), but I decided to leave it as a feature that would go in if there was enough memory left.
Unfortunately there wasn't. :(
I've seen mention a couple of times of Flappy Bird (both here and on pouet.net), in relation to RUNCPC's difficulty, and the quick restarts.
Indeed it was an inspiration.
:)
Although I don't like Flappy Bird very much, I do like the punishing difficulty. For a pure score-chaser as my game is, the satisfaction comes from improving your score, little by little (if you have the patience for it!).
Of course, RUNCPC throws some chaos into the mix by starting you on a random level.
;)
Quote from: ervin on 23:25, 01 November 15
Do you mean the blue bubble?
Yeah that one is a bit tricky, but it's actually my favourite.
I wanted a mixture of levels that require horizontal+vertical movement, and levels requiring only horizontal movement.
Even though levels with vertical movement are harder, I find them the most fun to play.
:)
Well it's an 'O' and you fly through the middle of it to get your 7 points. :D
That just seemed to be the Hardest out of all the Letters being tossed towards your ship.
Is it the twin green snakes?
If so, that one is quite hard, yes.
:P
WoW! Great game! Best technical achievement (ok, Frogalot too), but way too hard for me. Fun playing!!! Awesome job done!!! :) :) :)
Quote from: TFM on 22:16, 02 November 15
WoW! Great game! Best technical achievement (ok, Frogalot too), but way too hard for me. Fun playing!!! Awesome job done!!! :) :) :)
Thanks man.
Glad you like it.
:)
The choice of colors is very impressive too! :)
Quote from: TFM on 17:01, 03 November 15
The choice of colors is very impressive too! :)
Thanks man.
Yeah, I actually chose the colours very carefully.
Black and dark blue for the sky/ground, so that it doesn't stand out or interfere with the visuals in any way.
White for the player sprite - I wanted it to "glow" against the background.
Lots of colours for the obstacles, to make them stand out against the background, and to try to make up for my lack of pixel skills.
:laugh:
I've had a couple of requests (over at pouet.net) to upload a video of RUNCPC to youtube.
So, I've done just that.
8)
RUNCPC - YouTube (https://youtu.be/Yy8RP95iXAQ)
Quote from: ervin on 12:40, 04 November 15
I've had a couple of requests (over at pouet.net) to upload a video of RUNCPC to youtube.
So, I've done just that.
8)
RUNCPC - YouTube (https://youtu.be/Yy8RP95iXAQ)
Nice to know that it's not only me who sucks at this game ;D
Quote from: remax on 13:44, 04 November 15
Nice to know that it's not only me who sucks at this game ;D
:laugh: :laugh: :laugh:
Yes indeed, I played pretty badly in that vid!
I haven't played the game since I submitted it to the comp, so I was a bit out of practice.
That's my excuse and I'm sticking to it!
:P
I absolutely loved the release. Yes, it seemed too hard for me but I put it down to my crappy gaming skills as I grow up :D I didn't regret losing though, it did feel fast and furious!
Quote from: Gryzor on 15:27, 10 November 15
I absolutely loved the release. Yes, it seemed too hard for me but I put it down to my crappy gaming skills as I grow up :D I didn't regret losing though, it did feel fast and furious!
Progressively I think playing T-Bird, followed by Space Harrier, followed by RUN"CPC" should help.