I believed this has entertainment value to it, unlike the other submission, so I'm submitting this run based on entertainment.
I just want to mention that Neko Project 2 isn't in the "Preferred Emulators" list on the Wiki: EmulatorResources page on the site, despite the site now accepting PC-98 TASes. It's only present in the Sub-pages section at the very bottom of the page.
Sorry about not having much written on the submission page right now, I intend to fill it out later but I just wanted to get it submitted so it doesn't have to wait any longer. I should honestly probably just translate the TeX document to whatever formatting the site uses so that it's visible right here. But it's 23 pages, is it too much?
I can still see any chances of optimization in ACT 3-3, 6-1 & 6-2. I may delay it for 3 days or more.
I've just updated the new one in my userfile
Which leads to https://tasvideos.org/UserFiles/Info/637940787633340433 in your case.
I promise not to do any more changes before the completion of judgement
And watching this makes me curious if Pacifist No Damage run even possible...
You are not allowed to run a console game in an unintended environment, including modifying emulator settings for unintended speed advantages.For PC games, environment settings explicitly supported by the game or its documentation are allowed.
- Backwards compatibility modes, such as running Game Boy games in Game Boy Advance mode, are allowed if a physical console (or the game) supports it, unless there are noticeable audio, video, and/or gameplay-affecting glitches.
- If a setting is not mentioned in any way, it's allowed if it doesn't cause noticeable audio, video, and/or gameplay-affecting glitches.
i would implement all of this myself, but the problem is for some reason, fceux wont register any inputs in tas editor.
I had to compile PCem from source
One unfortunate thing is that the system of this movie will be Linux when, in my opinion, it should be PICO-8. But it seems that it's already been decided that PICO-8 games will remain with the system of Linux, as was done for [4585] PICO8 CELESTE Classic by FlyingPenguin223, RichConnerGMN, cominixo, ikuyo, Meep, Snoo23, gonengazit, Lord Snek, Akliant, Beeb, Warspyking & RoundUpGaming in 01:42.77.
The VDA / RAM Search pairing is used when you don't know the RAM address.
Overall, how do you like the proposal?
But that shouldn't excuse using an E ROM for the submission in the first place when there was a good dump U version available.
Depending on the core you may get the PC right before your address is written, but it would still be easy to find in the tracelog for the frame it changes at. And in the tracelog you can go up and see how the value affecting it is changing. You don't have memory view there, but you have affected addresses printed out anyway. I feel you'd be better of just implementing proper breakpoints, then debugger would instantly jump to the location your address is changed on. The problem with the current hawk is that debugger is a tool and tools don't update midframe unless it's a hook like in lua. But you seem to have solved that part. https://tasvideos.org/Bizhawk/LuaFunctionsLanguage: lualocal function print_disasm() local pc = emu.getregister("PC") -- or whatever the PC register is called for that core, check using emu.getregisters() local dis = emu.disassemble(pc).disasm -- not all cores have this, so you can just print the PC print(string.format("%X: %s", pc, dis)) end event.onmemorywrite( print_disasm, 0 -- or whatever your address is )
I'll agree with that. After all, we have the same standard for judging optimization in every other run. However, I still think the score should match or beat all known scores. There's not much of a point in calling the branch "maximum score" if somebody can just point to a higher score during judgment.
I did some research and I think I understand now what's going on with this game. The game itself runs at ~12 fps, which is resolved by advancing one game frame every 4 or 5 video frames (similar to the Prince of Persia NES movie I worked on), notwithstanding lag frames from excess of active objects in the screen. The difference between E and U is the number of lag frames introduced to keep the game running at 12 fps, even though the console runs at 50 or 60fps. The fact that the U version requires more lag frames to keep 12fps doesn't mean that the game runs slower or a movie for that version would be slower (as I mistakenly thought at the beginning). So therefore there should be no difference in look&feel between the two versions.
It's the fastest one I could find. Maybe someone could do better, with some more in depth understanding of the game code. Either way, it's not gonna be easy to improve.
To make things less onerous for judges, the proof that the score really is maximized could just be that it beats all other known scores and there are no obvious ways to increase it further.
My idea is accepting "easiest password" for Standard because it's the fastest, and accepting "hardest password" for Moons because it's more about being fancy with a self-imposed challenge (maybe it doesn't meet the Moons entertainment requirement, but I have a major "improvement" in the works, stay tuned 😉)