Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[anotherworld] Investigate VM irregularities #17

Open
felipesanches opened this issue Jun 1, 2017 · 4 comments
Open

[anotherworld] Investigate VM irregularities #17

felipesanches opened this issue Jun 1, 2017 · 4 comments

Comments

@felipesanches
Copy link
Owner

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.

@felipesanches felipesanches self-assigned this Jun 1, 2017
@felipesanches
Copy link
Owner Author

felipesanches commented Jun 1, 2017

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.

@felipesanches
Copy link
Owner Author

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.

felipesanches added a commit that referenced this issue Jun 1, 2017
@cyxx
Copy link

cyxx commented Nov 23, 2019

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;
}

@cyxx
Copy link

cyxx commented Nov 23, 2019

And a possible workaround for accepting any input in the copy protection screen https://github.com/cyxx/rawgl/blob/master/script.cpp#L153

@felipesanches felipesanches changed the title [anotherworld] Investigate VM irregularities Investigate VM irregularities Mar 24, 2022
@felipesanches felipesanches changed the title Investigate VM irregularities [anotherworld] Investigate VM irregularities Mar 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants