Things to note about WHD Dragon's Lair

[MethodGit]

As if testing out Addams Family wasn't enough, I also played about with stand-alone Dragon's Lair last night. The test system was the P96 edition of the latest ClassicWB, with all its default settings applied (but with me using Kick 3.1 r40.70 (A4000) rom). It includes WHDLoad 16.7, and yes, uae-configuration is in C:.


Now, without any uae-config settings, the game seems to play fine (I had CUSTOM1=2 for Movie Mode btw), but during the second half of the final act, as soon as Dirk jumps away from the dragon's claws, WinUAE crashes and makes one of those minidump thingies. This happens every time.


So, I decided to experiment with uae-config for this one. After first starting out with cpu_speed, cachesize and immediate_blits applied together, and rooting them out one by one, my findings came as follows:


uae-configuration cpu_speed real
It appears cpu_speed alone makes things worse - it now makes WinUAE crap out at the start (or more accurately when the screen starts to bring the "A Randy Linden production" text up). Every time.

uae-configuration immediate_blits true
Now, this one doesn't cause WinUAE to die out on its behind, but it seems to render the game pretty unplayable before you've even started. It gets past the Randy Linden and Don Bluth text at the start (at a noticably faster pace than normal), but then when it's supposed to bring the Dragon's Lair title screen up, it instead just stays there on a black screen, seemingly forever (and causing the CPU processes to make more noise for some scary reason). Quitting out with * seems to be the only option left to me.
Bizarrely however, if I use this in conjunction with the cachesize setting (below), then it gets to the title screen without a problem and I'm able to play (or watch, rather) the game through to completion.

uae-configuration cachesize 0
This seems to be the safest option. No reported funny goings-on when it's just the JIT being adjusted. This also, like I mentioned, prevents the immediate_blits setting from fucking up the game's starting-up sequence.


All in all, JIT seems to be the simplest problem to sort out, and cpu_speed is a bonafide emulator-killer when it comes to this game. All this happened on 1.4.0. Yet with 1.4.1 only the cpu_speed problem seems to persist, with everything else working correctly as they should. Perhaps we need to compile a list of uae-configuration settings to use with particular WHD games that are known to be fussy about what it finds in the (virtual) hardware settings?


Also, are you supposed to do something with those minidumps it spews out whenever it chokes on access-fault errors or whatever?

[MethodGit]

Oh btw, I have a question to ask about Escape From Singe's Castle (for CFOU if he reads this board regularly) - will there be an option added to disable Dirk's resurrection/disintegration scenes? They're disabled under 512k machines for one thing, and they start to get repetitve and annoying after a short while, particularly when it's so easy for you to screw up for the umpteenth time.

[Marcuz]

thanks for the pointers on running the game, i have half an idea of giving it another try. I used to play Timewarp up to before the final confrontation, but it's long since, and the times i've tryed with whdload, i've experienced some lack of control due to the issues you report.

[dlfrsilver]

Dragon's lair is a game using encryption Methodgit when encryption is ON
then JIT is meant to be OFF. Same as Dragon's lair here.

Why don't you try to use a normal A1200 configuration instead of JITted
config ?

[killergorilla]

Why don't you try to use a normal A1200 configuration instead of JITted
config ?

That'd be too simple :)

[Marcuz]

it depends on the point of view: me too i don't want to use customs configurations anymore, not when i can try to make the game work with classicWB or a given standard custom hard disk + whdload.

moreover, i don't see no evil in ask for features or further tuning in whdload installs with winuae in mind: whdload may have been born with the goal to work on the real hardwere, but now i guess that a large part of the people who has registered it uses it solely on winuae, so to ask for tuning in regard, for instance, JIT, it's not out of one person' rights.
the fact that the installs writers are volounteers, then means only that if they don't agree or simply don't want to add that feature or whatever, they may say "no", but to ask is perfectly ok imho.

[killergorilla]

Well from my experience installing whdload games there are many games which have problems with JIT.

Trying to get all of the slaves updated to get around this rather just turning JIT off seems a bit silly to me.

[Retro-Nerd]

The most WHDLoad patcher don't care about emulation, and i can fully understand this. There are to much possible problems, not worth the trouble.

But some things are probably easy to fix:

I asked DJMike ages ago for fixing the freeze in Dogs of War (Players selection), works flawless in WinUAE since the last slave update. ;)

[Marcuz]

well if you add JIT, MUI, Scalos etc. incompatibilities with Whdload, there's a bunch of installs that would require some fixing.
using the last ClassicWB i turn JIT and Scalos off as you say, but on the other hand, i would like to see better written installs often.
as i said, writing them is a volounteering job, but nevertheless...

@ Retro-Nerd: well i would say that while understandable the stress at the bigger mole of work is not exactly excusable to disregard emulation entirely: the registrations to whdload by emulators users are exactly good as the ones of the real hardware users.
I would like to know how many whdload regged users there are in both the areas

[Mad-Matt]

Jit really is the only option that needs toggled. all thats requred is an extra tool type for those games that need it. Pure lazyness on the players behalf if they cant be bothered to add the tooltype or press f12 to toggle the option.

[killergorilla]

Drifting a tad OT here, but you turn Scalos off in ClassicWB? What do you mean by that?

[Retro-Nerd]

Jit really is the only option that needs toggled. all thats requred is an extra tool type for those games that need it. Pure lazyness on the players behalf if they cant be bothered to add the tooltype or press f12 to toggle the option.

I can't confirm this for AIAB, AmigaSYS or AmiStart packages. JIT is not enough to fix all games. Some needs a special CPU timing or works only without glitches with the immediate blitter. I've tested tons of games under this fast emulated amiga setups. Then i gave up, to much trouble. Using a real machine now.

[Marcuz]

Jit really is the only option that needs toggled. all thats requred is an extra tool type for those games that need it. Pure lazyness on the players behalf if they cant be bothered to add the tooltype or press f12 to toggle the option.
i don't agree: for one you assume that every setting of the emulated hard drive is the same, while as retro-nerd rightly says, there are many and different.
i can point you to the eye of the beholder threads in AGF sections, with pages dedicated to understand what it did not worked in the Whdload install and CFOU! sayng all was ok on his own computer. it is not always so easy to check and fix.

moreover if one of the goal of whdload is to assure a consistent facility of emulation use, like plug the install in and play it, to spend time finetuning each configuration or tooltips etc AND do it everytime that a new release of whdload comes out, welll i think it's a goal that it is at least partly failed.
don't mistake me, i love whdload, but to say that it's perfect and that the users are lazy and henceforth are wrong...

[Marcuz]

Drifting a tad OT here, but you turn Scalos off in ClassicWB? What do you mean by that?
with the last ClassicWB, if when resetting you keep pressed left (or right?) mouse button you get booted up to a standard Workbench 3.0/3.1 (depending what you have installed) + many classicWB features but scalos-free.
it is needed for some installs to work, for instance Eye of the Beholder...

[killergorilla]

Ah right, with you now marco :)

Not really tested any of the RPG type games properly as I don't really like that style of game.

I've never had a problem running a game on Scalos over WB but I haven't tested EOB (for example) half as much as I'm sure you have :)

[Marcuz]

hehe :)
scalos doesn't produce major errors, as far as i've found in games, but graphic glitches here and there. in EoB there are many using it, because of its (eob') hectic use of palettes.

[killergorilla]

Ah I see.

That'll be why I never noticed!

I actually only have ClassicWB setup on my 2nd partition of my real amiga as my A1200 is set up to play games (and have workbench/scalos on standby when/if I need it.)

All games are run from a menu without actually loading WB/Scalos so I encounter VERY few errors :)

[Mad-Matt]

moreover if one of the goal of whdload is to assure a consistent facility of emulation use, like plug the install in and play it, to spend time finetuning each configuration or tooltips etc AND do it everytime that a new release of whdload comes out, welll i think it's a goal that it is at least partly failed.
don't mistake me, i love whdload, but to say that it's perfect and that the users are lazy and henceforth are wrong...

The goal has always been to make sure the games are compatable on a real amiga. compatability with emus is by pure chance unless the slave was developed in uae in the first place which isnt rare and does allow some thaught to go into uae compatability for new stuff. For the old stuff...its a case for the emu to get better.

emu setting should be that different between users. at least 020,nocycleexact,fpu is allowed,jit,aga and imediate blits. thats a fast wb and near as compatible to real that the emu allows. in this case whdload will run near flawless, but if oddeties occur then it just a case of toggling jit for the most part. if its still duff, then its just plain incompatable.

[Retro-Nerd]

I've played EOB only a few minutes in WinUAE, but the immediate blitter fixed all graphic glitches during the test under AmiKit.