Conquest of the longbow - sierra

[ascp]

I know this game has a whdload install, but the game itself is unplayable slow and it doesn't seem to help with any accelarator. No other sierra game on amiga behaves likes this - is there any way the whdpatch could help in speeding up the game and make it playable?. I noticed someone did put a patch request for this a couple of years ago but it was closed with no answer. http://mantis.whdload.de/view.php?id=1724

[jotd]

Well, I closed the issue with "will not be fixed". I could have added an explanation: I don't want to spend a lot of time trying to optimize the engine. It may lead nowhere, all this energy for a single game.

BUT, when I check the loaded segments, I'm seeing that some segments are loaded into chip memory:
- segment 1, segment 53

but:

- there are plenty of fastmem available (up to 2MB)
- "multiview" on the executable / disassemble does not show any "CHIP"-forced section (I already boosted some games like UBBCD32 by somehow clearing the chip flag)

Strange!! any ideas?

[StingRay]

Not worth the effort, could as well code the interpreter from scratch again.

[ascp]

Thanks for the explanation. As the other Sierra "modern i.e that last batch that came out for amiga" games (SQ 1 remake, SQ 4, KQ 6) run pretty decent also using the Sierra SCI-interpreter I can't understand why this particular game is so sluggish. They all use the SCI1 versions of the Sierra SCI-interpreter. Also, the other works better and better the more cpu they get.
Whats the difference in this game compared to the others - did sierra re-port their SCI-interpreter code for every different game so this particular one just got a dodgy SCI1-port.
It uses SCI1 http://wiki.scummvm.org/index.php/Si...1_.28middle.29

[Retro1234]

Would it work with Novacoder's Scummvm?

[StingRay]

Originally Posted by jotd

BUT, when I check the loaded segments, I'm seeing that some segments are loaded into chip memory:
- segment 1, segment 53

but:

- there are plenty of fastmem available (up to 2MB)
- "multiview" on the executable / disassemble does not show any "CHIP"-forced section (I already boosted some games like UBBCD32 by somehow clearing the chip flag)

Strange!! any ideas?

The only possible reason for this is that there's no fast mem block with suitable size available (due to fragmentation) so the data will be loaded into chip mem.

[jotd]

With 2mb of fast ram? Doubt it. I could log the allocmem calls.

[wXR]

Could Revolution's rather fast and awesome engine from King's Quest VI be applied to this? Is it a full SCI1.1 engine?

[ascp]

I did a speed comparison between the whdinstalled version and a regular installed version on my a1200, aca1233 with game settings full speed, lowest details, and the whdload version is much slower, whereas the regular install is playable. So, something seems to be odd with the install:

Regular install no whd. https://vid.me/pmxj

Whdinstalled version, same machine, same ingame settings (also tried with NOCACHE etc)
https://vid.me/0zQa

Originally Posted by wXR

Could Revolution's rather fast and awesome engine from King's Quest VI be applied to this? Is it a full SCI1.1 engine?

I dont think so, they used their own virtual reality engine for KQ VI and just ported the game to that - so KQ VI is one of the few (the only?) Sierra Amiga games that doesn't use an SCI-engine. Oh, I think there's another one, wasn't Sierra Soccer written in Amos.

But as video comparison shows above the non whd-version is playable with an accelarator and mem, its just the current whdversion that has some kind of issue.

[dlfrsilver]

must be also noted that this game uses 64 colors (written on the floppy disks).

[StingRay]

Originally Posted by jotd

With 2mb of fast ram? Doubt it. I could log the allocmem calls.

2 MB is not that much so fragmentation is easily possible. The only other possible reason are memory allocations to chip so logging the AllocMem() calls is not a bad idea.

Originally Posted by jonathan

Whdinstalled version, same machine, same ingame settings (also tried with NOCACHE etc)

Try with CACHE instead of NOCACHE, maybe it helps.

[jotd]

And novbrmove

[Amiga1992]

There was an open source AGI interpreter laying about, maybe it's best for someone to work on that like Stingray said.

[Wepl]

If the game runs faster without WHDLoad than with there must be something wrong with the install.
A quick look shows that the game code lies in Chipmem and caches are only enabled for Expmem. So this game runs without caches under whd.
Games seems to do strange memory allocations before LoadSeg the SCI.

Attached Slave should be faster because caches enabled.

[ascp]

Originally Posted by Wepl

If the game runs faster without WHDLoad than with there must be something wrong with the install.
A quick look shows that the game code lies in Chipmem and caches are only enabled for Expmem. So this game runs without caches under whd.
Games seems to do strange memory allocations before LoadSeg the SCI.

Attached Slave should be faster because caches enabled.

Yes, it's faster now! but still not as fast as the original without whdload.
It's now approx. as fast as in-between to two videos I posted to above. (Original vs First Whdinstall).
Oh, it's ok to play this from harddisk without whdload anyway, but maybe theres an interesting problem hiding.

[Wepl]

The exe is still in chip but this should make less difference than half speed.
How much memory do you have?
Are you using latest whdload (because since 18.0 it enables burst too)?

[jotd]

This is strange: I just disassembled the game, and no "CHIP" section appeared at all.
The memory is more than enough: $80000 chip, $C0000 fast. Even with $200000 fast the section is still in chip.
The key issue with speed is code in chip, that's clear.
Maybe game allocates a lot fastmem and ends up in chipmem!!

Edit: I think I found something. I compared the resource.cfg file and it had some strange (minHunk/minChip) parameters that I did not see in other sierra games (codename iceman for example).
Like Bert said, it seems like the "robin" launcher checks memory (using AvailMem) and allocates it until there's nothing left!! I have a hunch this is caused by the extra parameters (minHunk/minChip)

minHunk=255
minChip=255

I removed the "255" lines. Now file contents is just:

videoDrv=
soundDrv=amigasnd.drv
kbdDrv=
mouseDrv=YES

I scanned chipmem before and after my fix. Seems like before my fix, there were code in the $52000 region: jumptable addressing up to $7xxxx in chipmem, mixed with jumps in fastmem, like the game ran out of fastmem during the allocation process.
After my fix, the code in chipmem is nowhere to be found, replaced by data.
I did not try on a real amiga so I cannot compare the speed, but that seems to be a good lead. Can someone test it with the new cfg file?

[Wepl]

It moves the code in fast
Cannot tell much about the speed as I think this is game is slow anyway.
On my 68060 there are some minor blitter bugs, probably missing waits.
I think for full speed it should be checked that also data is going to fast mem as far as possible (MEMFREE option in kickemu).

[ascp]

Originally Posted by Wepl

The exe is still in chip but this should make less difference than half speed.
How much memory do you have?
Are you using latest whdload (because since 18.0 it enables burst too)?

Latest whd, memory 128 mb. ACA1233 accelerator.

Doing as Jotd suggested and removing
minHunk=255
minChip=255

seems to make it a bit more responsive, still not as "fast" as the install without whdload on the same computer.
(Regular install no whd. https://vid.me/pmxj - Robin can walk quite fast.)

[dlfrsilver]

indeed, the speed is good in your video !