The value will now be passed to the frontend for read callbacks and both read and write callbacks' values can now be changed in the callback.
execute would probably be possible but would require some additional code changes which I'm not sure about
I was unable to make it launch with full vision on the very first frame unless it's set during init. which means there will be savestate problems if we allow switching this on the fly. setting it on init only is probably fine too.
initially I read the code wrong. `demo_compatibility` means vanilla complevel, not "demo is running". for vanilla hitting 1 would switch to first only if you have berserk, otherwise it'd stick to chainsaw (provided you have it of course). that part was working ok. but for boom compat hitting 1 swaps fist and chainsaw at all times, and that part was broken: chainsaw would not get selected even if you have it.
pass button values directly (same can be done for arti)
they say the code should be so verbose that you won't need comments. indeed comments that restate the same thing that the code is doing are considered sloppy, because code will change and comments will become outdated. but if a comment is describing the logic of decision making or some unintuitive quirk, they're perfectly fine. so in a few places I go crazy with comments because the decision made there took a long time and a lot of changes, so it kinda summarizes the best result. that's it, no elaborate description of the change itself here... because I put it into that comment instead XD
note on using PALETTE_SIZE as offset. normally it's `256 colors * 3 bytes per color = 768`, but in our headless mode it's 256. upstream does `SDL_SetPaletteColors(screen->format->palette, playpal_data->colours + 256 * pal, 0, 256);` when palette is updated, so clearly it means offsetting by 256 colors=bytes. but PALETTE_SIZE I used as my offset is not for stuff upstream uses it for. just something better than a magic number.
* new callback system with callback return values
If the lua callback returns a value, the core will update the addr with it. Otherwise, the old value sent by the core will be used unmodified
* update MemoryCallbackDelegate return value to uint?
* throw NotSupportedException for GBA memory callbacks
* docs: return value of MemoryCallbackDelegate and CallMemoryCallbacks
user will be changing those options from hawk side dialog so it's impossible to miss what you're changing (you can look at the dialog again if you're THAT sloppy)
but since we're now initializing with default nonsync settings and changing them on the fly, those UI messages would be appearing all the time
automap messages are left intact since they appear upon in-game button press
worst case scenario, UI messages are moved to hawk side, but then why limit them to only whatever upstream reports and not report every change? which is never done anyway, so I doubt it'd come to this
- probably resolves#4325
built from 1.24.3 tag without router dll (so OpenAL32.dll is effectively soft_oal.dll). As far as I understand this has no implications other than disallowing other openal implementations
there's a major slowdown when doing several res changes in the same session, and its need is questionable anyway, because of potential inconsistency of screensize across states and stuff.
Morilli