I installed it somehow but when running AutoRun.exe through LocalE then the first (uppermost) button for launching the game is greyed out for some reason.

i think i had to install it through localeEmu launched autorun. i'll see about trying to reinstall it in a VM to confirm though.

Edit: windows 7 VM installs and a reinstall of my main Magical Chase install on win10 confirms that it will install fine when you go via localemu launched autorun.

OK, I have good news.

Button for starting the game was greyed out because the game wasn't installed completely, I guess the earlier install process aborted abnormally because some of the game files were copied to the hd.

So, I launched AUTORUN.EXE from the CD through LocalE and pressing the second button (uhmm.. my Japanese is weak a bit 😀 ) launched the installation process. Now it completed normally, so the game launcher button became available.
It run but switching to fullscreen caused crash as shown on your video. It turned out that MCHASE.EXE has too small stack, that's the reason.
So I increased it to 16MB with EDITBIN and now the game runs in fullscreen too.

The only app compat needed for MCHASE.EXE is 8 bit color desktop mode, even Win95 is needless.
Also, I figured out what command line parameter is needed for MCHASE.EXE to avoid launching it from AUTORUN.EXE.
(I hope that parameter is not dynamically generated for each installation, so hopefully it'll work for you too.)

Patch: http://dege.fw.hu/temp/Magical_Chase_Stack_patch.zip

As for fullscreen mode: according to the proper game menu item, Alt-Enter should work to switch between windowed/full screen but it doesn't do. The only way to switch to fullscreen is choosing the menu item and there is no way back (quit can be done by Alt-F4).
dgVoodoo's built-in Alt-Enter support is also unusable because even when in fullscreen, the game thinks he is still in windowed mode so only the upper left region of the screen will be rendered. (Forcing a windowed app to fullscreen doesn't work if the game window is not resizeable.)

Altough it's not a problem for this game, I'm planning some modifications in dgVoodoo for taking the emulated desktop bitdepth into account when creating DDraw primary surface.

so poor porting on their part? good to know. is that with the joystick patch or without it? i'm more than happy to patch it myself if it's without. good to know that it's possible to launch it on it's own too.

It's with the joystick patch.

cool. i just tried running it and yes it does indeed go into fullscreen as you described now. but i still had to launch from autorun in order to avoid it complaining about being unable to open wave files due to lack of resources. but i might just go ahead and do something in ida to see if i can get past the 8-bit color mode compatibility and also to create a no cd. i'll get back to you on that one though

ok, had no luck in reverse engineering the color mode check on it thus far but i did manage to get your patch loading without any WAVE file errors by making the MCHASE.BAT file say "MCHASE.EXE WGOPA242" instead of "MCHASE.EXE WGOPA242F". seems that extra F caused me some issues. (How did you work that parameter out anyway so i can check on my end)

JJXB wrote:

ok, had no luck in reverse engineering the color mode check on it thus far but i did manage to get your patch loading without any WAVE file errors by making the MCHASE.BAT file say "MCHASE.EXE WGOPA242" instead of "MCHASE.EXE WGOPA242F". seems that extra F caused me some issues. (How did you work that parameter out anyway so i can check on my end)

I used Process Explorer. Launch the game exe via the launcher front end app, and when it's runnig, you can see the command line parameters of the game in Process Explorer (right click on the process, then Properties).

For the 8 bit color mode check, the easiest way is to launch the exe from Visual Studio and when the error-message box is popped up then break into the app. Select the main thread from the thread window.
The callstack will point into the internal of the 'MessageBox' API function but if you download the symbol files from MS for the system dlls then the callstack can be unwinded to the point in the game where MessageBox is called.
From there, investigate the surrounding game code to reveal the conditions of running onto the error-path (by putting additional breakpoints into the game code itself).
For desktop color mode checking, the usual case is the game calls GetDeviceCaps (hdc, BITSPIXEL) prior to branching to the error path and checks the return value against the required value(s).
Using system symbols are very useful for this kind of reverse engineering, but it requires some patience and time, and understanding x86 disassembly.

ah. i'll look at process explorer (since i have it installed anyway) and get back to you on the launch params that autorun gives mine.

and as for the disassembly, i'm using IDA Pro so the fact you just called out GetDeviceCaps is one of the most helpful things you could have said since i've been poking through the disassembled EXE for possible things (as i did with VF2's exe). been trying to remove cd checks from a bunch of games with it too (Nuclear Strike, Panzer Dragoon and Sonic 3D are a nightmare and a half since branching in the right place does get past the check but then they black screen)

Edit:
No luck on the GetDeviceCaps front (Would GetDC and SetCompatibleDC also be related?) because there's no branching jumps as far as i can tell. there's standard jmp instructions but to my knowledge those aren't conditional (unless i'm mistaken?) and mov instructions (which also aren't conditional afaik?)

i'd post some of the decompiled code for you to see what i mean but i don't know if it would run afoul of the board's rules or not. it doesn't help that the win32 debugger that's selected keeps running into c++ errors before it hits the relevant code.

also: checked with PE: MCHASE.EXE WGOPA242V for me when i use autorun. but as i said before, WGOPA242 also worked for me.