Rocks'n'Diamonds

Try http://web.archive.org/web/201701270052 ... m/RnD.html ?

> (But I will never write the words "CE" and "impossible" in the same sentence again, or else Alan Bond would prove me wrong. ;-) )

... but then you should do it!

> only the following part of the patch was required to fix the problem:

heh. Just moving a brace...

> Please "git pull && make run"!

I'm traveling this week, laptop not setup right for that, but I'll look at it next weekend... thanks!

Ah, did not mean to say that capslock or numlock was the cause in my cases; only that I was able to intentionally reproduce it by turning those on. I think it was *not*, because my keyboard has lights for those states and I would have noticed. (Except of course if X or whatever had gotten one of the...

Of course it is *my* fault, from some time ago, that the speed keys are mapped to [any modifier]-[digit]. I still think that's right, it just needs to be restricted to modifiers that actually make sense. I wanted it to respond to all modifiers because different GUIs trap or otherwise allocate differ...

FPS display actually works very nicely with the patch I posted. As I said, it's wrong, needs your touch to make it right, but it's basically what's needed. Drawing every .5s seems fine; even if it was .1s it wouldn't noticeably slow things down (vs. the .00025s it was actually doing...) Not sure if ...

This fixes it (part 7), and I promise it's wrong :) It causes recalc and draw every .5s. Problems: - looks like if FPS goes down a digit (1000 to 999), doesn't erase the high digit(s) - the actual calculated numbers look crazy to me - is probably FP(game-second) rather than FP(realtime-second) - mig...

Actually it seems like it would be better to use gettimeofday() / equivalent, to actually issue FPS at .5s intervals rather than some crazy calculated thing. Didn't even try to figure out the correct way to calculate the *value* of FPS, I'm just worrying about the interval between reports. 4000 time...

Part 7 is caused by redrawing the FPS about 4000 times per second. It needs to be scaled according to GameFrameDelay.

And is that actually calculating frames per second, or frames per GameFrameDelay-adjusted game-time-second?

I 'pulled' last night, built, and the result was nearly unusable for me -- then today I see it's a declared version :( A confluence of small things adds up to pain: 1. There's a longstanding bug I've been chasing where *sometimes* RnD gets in a mood where typing number keys changes the speed, despit...

BTW, I just thought to check whether the other TAS bug was fixed, and it was not: that quickly typing a TAS key followed by another action, the TAS key is often missed; 0-key rollover as it were... I don't expect you had intended the current work to fix that, but just in case you did, it isn't...

Hmmm. Here's an archive of two tapes from the same levelset -- one is the same as before. Tape ................................ 046.tape .. 065.tape Created under ................. 4.0.1.0 .... 4.0.1.0 Playback under 4.0.0.2 ... Fails ........ Works Playback under 4.0.1.0 ... Works ..... Fails Sugge...

Previous binary I was playing called itself 4.0.0.2 and was built 2017-04-11, most recent commit ad543757bee23838b7f1a58bd1eca6192a37af5e. New one is 4.0.1.0, 2017-09-16, most recent commit 25c22434b11938e230719d6f73df4ed7813570be. Today I am playing a level, finishing it, playing back the tape, and...

Same repository should contain other people's solutions (tapes), uploaded on an opt-in basis... I'm particularly interested in solutions to levels I've determined to be impossible (but contained in levelsets whose splash screens earnestly claim they're Now 100% Fixed And Really You Can Solve All Of ...

I noticed that fix go by : ) Built and have been using it for some amount of game play. On the very first level I played with the change, I noticed one instance of unexpected movement when using TAS keys. But I have not been able to reproduce it since then, even with vigorous key-mashing. At the tim...