Wonky

[Ersh]

I did some further testing. Like mentioned, when the guy runs on the titlescreen the game seems to move at the same speed regardless if music is on or off. However, if you start the game and let the runner go back and forth on the bottom of the first level (picking up the pill as you go) without pressing anything the two recordings will eventually desynch, but it takes quite a while. And like stated earlier; on level 2 while jumping from platform to platform without music you'll pull away with several seconds in a short span.

[dfzx]

I did some further testing. Like mentioned, when the guy runs on the titlescreen the game seems to move at the same speed regardless if music is on or off. However, if you start the game and let the runner go back and forth on the bottom of the first level (picking up the pill as you go) without pressing anything the two recordings will eventually desynch, but it takes quite a while. And like stated earlier; on level 2 while jumping from platform to platform without music you'll pull away with several seconds in a short span.

Thanks [mention]Ersh[/mention], I'm seeing it now. It's most obvious on the level with the red and yellow brick walls. There's a loop there, from the top, long drop, along the bottom, back again, then teleport up to repeat. With the music on he runs that loop in 14.5 seconds. With the music off it's 11.0 seconds.

At first I thought this must be due to contended memory being used somewhere I didn't think it was, but after a code review I couldn't find any such problem. So I recompiled my local Fuse build with contended memory turned off and that doesn't fix it, so it must be something else. I'll find it.

[Ersh]

Could it be that the game is running at 50hz without music but misses an occasional frame from time to time with music on? Have you timed it?

[dfzx]

Could it be that the game is running at 50hz without music but misses an occasional frame from time to time with music on? Have you timed it?

I have quite extensive tracing in the code which builds trace tables and acts much like a "flight recorder" allowing me to see what's happening. It's skipping every 4th frame, which makes perfect sense because the music plays a note every 4th frame. I took out the music player routine and replaced it with a HALT, and the behaviour is exactly the same, so that confirms it. In fact, if you look at the timings I reported last post, 11.0 seconds is pretty much exactly 75% of 14.5 seconds - it's losing a quarter of its frames. The fact it's very regular made it non obvious, which is why I didn't spot it. I've seen occasions in development when it misses one frame intermittently, and that's fairly obvious because it hiccups as he moves.

Clearly I've added something to the main loop such that the normal processing, plus the music note, now consistently takes longer than 20ms. The fact it doesn't do it on the first 2 levels or the intro suggests it's to do with the doors or the keys, or maybe the teleporters. More interesting to me at this point is why my tracing didn't reveal it.

If it's a simple fix I'll do it for v1.0.1. I suspect, however, it's going to require quite a bit of optimisation, so I'll probably just leave it as it is.

[Ersh]

I have quite extensive tracing in the code which builds trace tables and acts much like a "flight recorder" allowing me to see what's happening. It's skipping every 4th frame, which makes perfect sense because the music plays a note every 4th frame. I took out the music player routine and replaced it with a HALT, and the behaviour is exactly the same, so that confirms it. In fact, if you look at the timings I reported last post, 11.0 seconds is pretty much exactly 75% of 14.5 seconds - it's losing a quarter of its frames. The fact it's very regular made it non obvious, which is why I didn't spot it. I've seen occasions in development when it misses one frame intermittently, and that's fairly obvious because it hiccups as he moves.

Clearly I've added something to the main loop such that the normal processing, plus the music note, now consistently takes longer than 20ms. The fact it doesn't do it on the first 2 levels or the intro suggests it's to do with the doors or the keys, or maybe the teleporters. More interesting to me at this point is why my tracing didn't reveal it.

If it's a simple fix I'll do it for v1.0.1. I suspect, however, it's going to require quite a bit of optimisation, so I'll probably just leave it as it is.

Ah! It also does it on level 2. Timed from the first jump it takes ~00:33 to complete with music on and ~00:25 with music off, that conforms with what you found as well. However I'm pretty sure level 1 also drops frames, maybe not as frequent though, as in my 2 RZX experiments it takes quite a few seconds before they are out of synch. Only the titlescreen doesn't seem to drop any at all.

Yeah, if it's a consistent drop of 1 frame every fourth, it's still smooth in my book, I never noticed it anyway.

[Pegaz]

I wrote a game! Compared to most of the stuff that's released these days it's pretty awful, but I'm quite proud of it because it's the first Spectrum program I've completed since my Computer Studies O'Level project in 1985. In fact, come to think of it, it's only the second Spectrum program I've ever completed, the other one being my Computer Studies O'Level project in 1985.

It's called ZX Wonky One Key, and it's a little platformer, written in C using Z88DK and the SP1 library. It's key points:

* it's 48K only, tested under Fuse on Linux and Speccy on Windows 7 (via a virtual machine)
* it only has one control key: space, and no, you can't redefine it
* there are no baddies, mostly because I don't know how to do collision detection in SP1
* it has background music, which you'll turn off almost immediately
* it runs at 50 frames per second, achieved by virtue of there being no baddies
* it's open source, free software, licenced under GPL

There's only 5 levels, so if it takes you more than 15 minutes you're not really trying.

The pre-built TAP file is here.

The project, including source and a Wiki which other C developers might find useful, is here

Perhaps I should make clear (getting my excuses in early) that this is the only Spectrum game development project I've ever undertaken. I'm not exactly experienced at this. It's been a great learning exercise, and I'm looking forward to trying something else. Also, I'm not sure how well Github works as a distribution point. Any problems getting, building or playing the game, please ask.

Brilliant game, idea and execution, perfect gameplay.
You literally steal the show, with this game.
Great job, really.

[Morkin]

Peter, where are the P?s? jars? It's time for Ersh's drug test.

Haha yeah, was going to say [mention]Ersh[/mention] needs to record an rzx of Rally Driver while he's 'in the zone'...

Given that there must be a few non-superhumans out there managing to complete the game, I gave it another try, and managed to reach level 3 (OK, so with a bunch of snapshots on level 2). But stupidly I didn't twig that the timer doesn't reset for each screen... Doh..!

Spoiler

It's an addictive game though, it would be nice to finish it... And on a completely unrelated subject, 6 pages of comments and no infinite time/slowdown POKE yet? (hint, hint)

[dfzx]

It's an addictive game though, it would be nice to finish it... And on a completely unrelated subject, 6 pages of comments and no infinite time/slowdown POKE yet? (hint, hint)

It's compiled C. It's obviously just a Z80 program at the end of the day, but I'm not sure how easy people find unravelling the output of a compiler.

Of course, it's also open source so anyone who builds it themselves gets a copy of the symbol table.

[djnzx48]

Try POKE 37793,24.

[Morkin]

Nice.! Will give it a try later

[Ersh]

Haha yeah, was going to say @Ersh needs to record an rzx of Rally Driver while he's 'in the zone'...

Yeah, had a look at that, no bloody way.