crem

Totally offtopic for this thread, but I'm just curious. Usually when talking about memory addresses written in hexadecimal form, I can see 3 prefixes are used: #, $ and & (#DA78, $DA78 and &DA78) (Also there's 0xDA78 and DA78h but those I know where they come from). I wonder which of those prefixes is more common and where they all come from? I know that in Pascal $ is a prefix for hex numbers, but weren't there a Z80 assembler which used that?

Were all examples of truncated posts truncated on word boundary? If yes, I think maybe there are some Unicode characters that database doesn't understand? Like emojis with codepoint values larger than U+FFFF. Or maybe when copying/pasting around, some control characters (like byte order marks) were carried along, and database didn't like it? Do you know in which format the data is stored in database? Is it possible to look at database for raw posts? Another option could be that there's something weird at parsing level, not at database level (then in the database the posts are still intact). E.g. if there's some unmatched control codes (like [/bold] without [bold]), the post parser/formatter stops formatting.

One more case where it could matter is if LDIR overwrites the memory of the instruction itself. Hopefully that doesn't happen in JSW though. Also I'm a bit afraid that after my replacement it with a simple memcpy, I'll leave cpu in wrong state (e.g. forget to set flags which would be needed afterwards... But I think JSW doesn't rely on register/flag values after LDIR instructions). I'll give it a try anyway. Do you think something like that would be good enough (e.g. ignoring all flags altogether)? uint16_t hl = GET_HL(); uint16_t de = GET_DE(); uint16_t bc = GET_BC(); memmove(&memory[de], &memory[hl], bc); // Can overflow if goes over 0xffff but should not happen in JSW SET_HL(hl + bc); SET_DE(de + bc); SET_BC(0); The current emulation code also does some magic with Y, X and V flags, and I never even heard about those Z80 flags. 🙂 Hopefully it's ok not to touch them. Although maybe it makes sense to reset S/Z/C.

Thanks a lot, that helped a lot! Without changes I could generate 2450 frames per second. With 3 LDIRs replaced with NOPS, 3950 fps. With your changes (and LDIRs replaced) -- whopping 5130 fps! With LDIR being so slow, I'm thinking of changing the emulator to just run memset() for LDIR instead of emulating it "properly" (with fetching instruction on every iteration, incrementing all the registers and updating t-state count as it runs). Maybe then it would get even higher. For now I'm not sure if that's worth the time to implement it, so any other micro-optimizations like that would be appreciated.

Now I'm trying to speed up JSW emulation (and don't care what's displayed in the screen). Do I understand it correctly, that it's safe to remove LDIR at addresses #89FE, #8A2F and #8B10, but not the ones at #89B9 and #89C4? (addresses taken from https://skoolkit.ca/disassemblies/jet_set_willy/hex/asm/89AD.html and https://skoolkit.ca/disassemblies/jet_set_willy/hex/asm/8B07.html)

Would you want that in ZX Spectrum or any platform? I believe on PC that would be one week of coding + some weeks of graphics/level/sound design. xxiv) mass multiplayer 😛 ..would add some months to development. 🙂

I didn't do the full run, but I started it once watched some "intermediate" bests (the fastest way Willy can get to the particular parts of the level). All those routes had waiting somewhere, so I concluded that waiting would be unavoidable in the final run too, that one extra frame won't help. Yeah, actually I was wrong when said it's the same number of frames but 4 points less solar exposure. Indeed, the route is much longer now, but having one intersection fewer with the solar beam compensates it.

Here it is (the rightmost column; two others are frame number and "air left + some constant"). lvl19-air.mp4

...and I found the bug. 🙂 Lvl19, Score=1137 The same number of frames as the previously known best, but manages to have 4 more points due to less solar beam exposure. R R R R . Q R . Q R R . Q R R R R R R R R R R R R R R R R . . . . . . . R R R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . R R R R Q R . Q . R Q . R R R R R RM . . . . . . . . . . . . R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R Q Q Q M . . . . . . . . . . . . QM . . . . . . . . . . . . R RM . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q . . . . . . . R R R R R R . . . . . . . Q Q R RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q . R . Q . R . R R R R RM . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . RM . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q R R . R R Q QM . . . . . . . . . . . . R RM . . . . . . . . . . . . . . . R R R R R R R R RM . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . . . . . . . . . . . Q Q R Q R . Q R Q QM . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q . R R Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . lvl19.mp4 lvl19.rzx

Indeed I think I didn't post it earlier, here it is. lvl8.mp4

Yeah it's possible. I'd estimate the probability that better solution exists less than 50% but still much larger than 0%. Maybe 30% chance. Worth giving another try.

I decided to give level 19 another go with extremely long search (2 days long) and extended logging and also additional checks that watch where the search starts to miss the current best score. It turned out that I have a bug somewhere. At frame 720 it said that it found another way to reach the same position with more AIR remaining, so it pruned the original state. At frame 759 it reported that if you press the same keys from that "better" frame 720 as in the original walkthrough, it results on losing a game (probably colliding with a guard). Which means that probably I have a bug in duplicate state detection, those states also differed by something else..

Hi all, I've started to work on building tools to generate a walkthrough of JSW (no estimations on timeline yet, and whether I have enough enthusiasm to finish yet; I hope so, although it feels a larger project than MM 🙂 ). I have a few questions on how to interpret the memory state (I have assumptions for most of those but it would be nice to confirm it). 1. There are 1-byte 0x85CF "Willy's Y location" and 2-byte 0x85D3 "Willy's attribute location in a buffer" variables is the game. At the beginning of the frame (when PC=0x89AD), is it always true, that memory[0x85D3]=0x5c00+32*(memory[0x85CF]/16)+x_offset? In other word, can it happen that they go out of sync (on the rope, on the ramp, during the jump, during room transition etc)? 2. Is it true, that [at the beginning of the frame (when PC=0x89AD)], I can ignore/write garbage to 0x85D5 "Jump animation counter" if 0x85D1 "Airborne status indicator" is not 1? 3. To save the resources and not try to press keys when Willy is jumping/falling, in Manic Miner I used the following logic: a) If before the frame, "Airborne status indicator" is 0, try all input combinations, else only try "no keys pressed" b) If _AFTER_ the frame, "Airborne status indicator" is 0, also try all other combinations for the previous frame (if didn't try already). Questions (both for MM where it seemed to work, and in JSW where I hope it to work): - Is it enough? (e.g. are no special cases like falling onto the edge of conveyor belt etc) - Maybe there's simpler logic? 4. It looks like "Willy's Y location" is rounded to the multiple of 16 if Willy is on the ramp. How exactly the logic that draws Willy goes then? "If Willy is in the same cell as ramp and not jumping/falling, move him up depending by the 0x85D2 "Willy's animation frame" value, but if Willy is jumping above ramp, 0x85CF "Willy's Y location" contains true Y position" -- is that understanding correct? Thanks!

Level 17 "The Warehouse", Software Project edition Score=1952, one frame improvement (and slightly different route) R R R R R R R R R R R R R . Q . . Q . . . R Q Q . . . . R . . . . Q Q . R R R R . . . R R R Q Q Q Q R . . . R R Q . Q R R R R . . . R . Q R . . R R R . . . R . Q Q Q Q Q Q R R . . . . Q Q Q Q QM . . . . . . . . . . . . R . . . . Q Q . . R R . . . R RM . . . . . . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . R R R RM . . . . . . . . . . . . R R R R R R R R R R R R R R . . . . RM . . . . . . . . . . . . R R R R R R R R . Q Q R . . . R R R R R R R R R R R . Q . . . . . QM . . . . . . . . . . . . RM . . . . . . . . . . . . R R R . Q R RM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . RM . . . lvl17-sp.mp4 lvl17-sp.rzx

Level 18, Software Projects version, no difference, score=1314 😞 I expected that there would be a difference, probably 1 frame, and not necessary an improvement. Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q R R R R QM . . . . . . . . . . . . . . . . . . M . . . . . . . . . . . . . . . . . . M . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . M . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . R RM . . . . . . . . . . . . . . . Q Q Q Q R R R R RM . . . . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R Q R R R RM . . . . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . . Q QM . . . . . . . . . . . . Q Q Q Q Q Q Q Q . R R R Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q QM . . . . . . . . . . . . . . . . . . . . R . Q . . . Q . Q Q QM . . . . . . . . . . . . R RM . . . . . . . . . . . . R R RM . . . . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q R R R R . R . Q R R RM . . . . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . . . . . . . . R R R R R RM . . . . . . lvl18-sp.mp4 lvl18-sp.rzx

Works like a charm, thanks! I've started calculating Amoebatrons' Revenge, should have the results in the evening.

Thanks for the suggestion, I indeed noticed that 40% of the time my tool spent in LDIR instruction emulation and thought about doing such change, but I was lazy to check whether that change would break something (e.g. maybe something after this instruction relies on BC being equal to 0 or something like that). During the search process I actually only show the screen only once per 10000 frames or so, just to visually control that the search progresses as expected. What I could do is to put LDIRs back only before the frames where I going to show the screen contents. Usually, it took around 10-12 hours to process one cavern. With this optimization it would be 6-10, would surely be useful. However, now that MM is almost "done", I think it's too late to implement such optimization. I'll surely look into that when I start the search in JSW. Will probably need some help in this forum. My experience with Z80 CPU is quite limited, I've read some books on this topic and also read some code, but I believe I've never written a single Z80 instruction myself.

Surely will do! Could you help me to pick a right file with this version, is it this one? (from worldofspectrum) Do you know if the memory layout is the same in this version? (currently I use a breakpoint at $870e to separate frames, at $8908 to detect loss and at $902b to detect win. Also some memory locations here to fetch state details) Interesting, I thought all collision detection was pixel-based.

During last 3 days, I had five "the final" runs of Level 19, and after every run (which takes ~12 hours) I realized there's a typo or another silly bug in my code. The last such attempt finished a few hours ago. I'll probably take some pause before doing yet another attempt, but for now here is one more interesting lvl19 attempt. Score=1127 (6 points below the current best), but even less sun exposure, only 148 points. Interesting that there are so many different ways to route this level (with 70 frame length difference), which end up having the similar score (within 10 points). lvl19_1127.mp4

It was a bit of an overstatement from my side to say JSW will be easier. There is surely much more work to do and also much more computation time is needed. So overall JSW is surely harder, but the missing crumbling platforms aspect makes at least one aspect easier. Well, the entire effort is/was intended to help speedrunners to find new strats. For MM I wasn't even going to generate the best possible score, it was to find new ideas. It's a scoreboard on this forum that turned me a bit into the "beat the score" direction 😛, but I didn't feel it like a "competition" either. Similarly, with JSW I mainly want to help with finding new strats for human speedrunners. Actually @RuffledBricks recently said that he considers JSW done and there's no point in running it again unless there are new strats. So I'd consider a project a success if it will be possible to make RuffledBricks run JSW again. 🙂 As for human vs script run, as with any human vs TAS run, there's no really point in doing that. Script will know the optimal route and will execute it perfectly, it's not something that people can (or should) compete against.

Already working on it. 🙂 It's tempting to jump on it right away, but I'm forcing myself to take a few weeks of pause first. It's actually not that bad. Having connected rooms with arbitrary route and place to enter every room adds complexity, but on the other hand JSW doesn't have have crumbling platforms. Without crumbling platforms, basically the coordinates of Willy (and set of collected items) is the only changing part given the frame number. For a typical room, there's only ~40000 realistically possible states per frame (and only 2.5million theoretically possible), and there's no difference how Willy got there. With crumbling platforms, the number of states explodes (8 states per platform, e.g. with 70 crumbling platforms in a level it gives number of 1645504557321206042154969182557350504982735865633579863348609024 theoretically possible states).

In the attached video the total air drain caused by the solar beam is shown as the number above (and also in a blue progress bar directly above the game screen). solar_beam.mp4

Maybe someone could quickly make a version that indicates that?.. Maybe by changing border or so.

Here is the score=1124 attempt of the level 19. Here 220 points were lost due to the solar beam, while in the current record of 1133, only 160 points were lost. The route is quite different, as you can see. lvl19-1124.mp4 out.rzx

I've updated the route post. As far as I remember, in the score=1133 run, 160 points were lost due to the solar beam. And in my score=1124 run, 220 points were lost. I can re-confirm that in the evening. I can also upload my 1124 run if that helps.