Rocks'n'Diamonds

Pushed to public branch "master-next-patch-release" now!

Fixed now!

I can only partially reproduce your observations when replaying tapes in "invisible warp mode": R'n'D / EM / SP game engine with complete tape, counting score after playing: - everything is updated as it should after the tape was played (when score counting begins) R'n'D game engine with i...

Hmmm, well, I think its idea is that all changes you ever do (or ever have done) were done / will be done via `git`. So `git log whatever.txt` should tell you all about what and when. This doesn't seem entirely wrong to me. No, it's great, and I really love to use Git for R'n'D now (after many year...

I've checked all three levels / level sets, and I can confirm your observations. The problem here is that many EMC disks were released and re-released with different graphics (probably depending on the version of the EMC editor used to create or modify the EMC disk), so there are indeed different ve...

So I think A should be removed from the collection. I totally agree -- thank you for the detailed analysis of the differences of the two disks. (BTW, www.emeraldmines.net only knows the first one, but the second one should indeed be used!) Just removed "emc_freak_mine_super_pro" for the n...

An even better sub-second time score calculation (which would be possible using the internal frame counter) is left as an exercise to the programmer...

OK, added that, too.

The mechanism of calculation of additional points differs between original EM and EM engine in RND. You're right! This was caused by the original code of the native Emerald Mine engine counting time differently than in R'n'D (plus calculating score for all game engines the same way, although it dif...

I imagine I will have some trouble getting used to this change, but will get over it. I hope so! :wink: Will this affect the playback of tapes produced under the old scheme? Definitely not! It just changes when single-step mode will automatically enter pause mode. don't break old tapes! Exactly! :)

Levelsets have their own artwork, which might have a different viewport size. That's right, but you might decide to play it with a different artwork set (that might have a different viewport size). Or you might want to play it with "small game graphics" enabled (just as you did). So the v...

Yes, I thought about exactly these things when staring at the output of automatic tape testing today!

I had no immediate idea how to improve this ... your suggestion to simply add another line seems like a good idea here.

Last used? 'autotest' is a command line option that applies to a single levelset. Are you saying it carries over via setup.conf or something? Yes, unfortunately. It's a command line option, but in fact, the program only suppresses window and graphical output, but else does everything it would do wh...

I'll report which tapes have been fixed tomorrow.

Oh, BTW: The fixed tapes are exactly those that you already listed here:

- emc_boulder_dash_pro 086 087 095 096 097 098 099
- emc_emerald_mine_15 092

No other tapes were affected by this issue.

Sorry, it's not in the public git repo yet.

OK, just pushed all that stuff to the public repo, to branch "master-next-patch-release".

Haven't checked the code Sorry, it's not in the public git repo yet. but I imagine this is a new tape chunk which specifies the size? Yes, exactly. Then shouldn't the patched tapes use that chunk, specifying 34x34, rather than a special bug flag? Yes, that's exactly how it works! (When I read your ...