Open felipesanches opened 7 years ago
This is one example:
case 0x10: /* blitFramebuffer */
{
uint8_t pageId = fetch_byte();
#ifdef VM_HACK_SWITCH_FROM_INTRO_TO_LAKE
//Nasty hack....was this present in the original assembly ??!!
//This seems to be necessary for switching from the intro sequence to the lake stage
if (m_currentPartId == GAME_PART(0) && read_vm_variable(0x67) == 1)
write_vm_variable(0xDC, 0x21);
#endif
[...]
I've just disabled this one and I can confirm that switching from intro sequence to lake stage actually fails without this both on MSDOS and Amiga bytecode.
On the other hand, in this same blitframebuffer instruction implementation we have this other hack which does not seem to be really needed:
#ifdef VM_HACK_BLITFRAMEBUFFER_VAR_F7
//Why ?
write_vm_variable(0xF7, 0x0000);
#endif
I disabled it and was unable to observe any difference at runtime. Unfortunately whoever put this in the VM code did not add a proper comment explaining why this is needed or how it would affect the VM execution or gameplay events.
The 0xDC variable is part of the copy protection and must be set to 33 during gameplay. The checks can be found in the game bytecode.
Below are the expected values depending on the version -
if (_is3DO) {
_scriptVars[0xDB] = 1;
_scriptVars[0xE2] = 1;
_scriptVars[0xF2] = 6000;
} else {
_scriptVars[0xBC] = 0x10;
_scriptVars[0xC6] = 0x80;
_scriptVars[0xF2] = (_res->getDataType() == Resource::DT_AMIGA) ? 6000 : 4000;
_scriptVars[0xDC] = 33;
}
And a possible workaround for accepting any input in the copy protection screen https://github.com/cyxx/rawgl/blob/master/script.cpp#L153
There are some places in the VM implementation where VM vars are set to hardcoded values. Some comments on @fabiensanglard 's VM re-implementation make me believe those are hacks crafted to tweak the bytecode of specific releases at runtime. Idealy, I'd like to acchieve a VM implementation that is clean of hacks.
Towards that goal, I'll be wrapping these tweaks with #ifdefs so that we can temporarily disable them at compile-time and verify what are the differences at runtime.
Hopefully I'll end up figuring out a way of getting rid of all of these VM irregularities.