Indiana Jones and the Fate of Atlantis Amiga

Many WHDLoad v2.0 and v2.1 variants were unpublished to make the list of variants shorter now that WHDLoad v2.2 slaves has been imported.

I've tested the WHDLoad v1.4 0342 variant here, and seems to work fine. Registered whdload 17.1. Opensuse 12.3, FS-uae downloaded from Opensuse repo (repo is for 12.2, there is not yet repo for 12.3). Note, the variant I tested was the DE language version of course.

"so i am aware that 1304 is the partypooper here and as long as it is the switch to whdload to 16.9 seemed valid to me. but ofcourse the ministry of truth had another idea xD: "

You obviously missing the point of a central database. It should work for all user, not only for you. Leaving the database seems a bit hasty then, if you rethink the whole story.

well i think fs-uae isn''t to blame here. i suspect the problem more in the flavor. you know different didtris use different kernels,libraries and whatnot (well you know it). and *buntu1304 seem to be more picky then then 1210 and various other older distries are. all of them are the amd64 flavors, running on on nonoverclocked i7 3770.

i have installed the latest devel version off your ppa. so no own compiled version (especially because the gcc4.7.2 which 1304 ships acts quite funny in some cases).

to reproduce the the exception which lead the slave to want to make a coredump noly on the german install and only on the 1304 flavor is to simply start the slave. right after the the whdload splashscreen disappears.

so i am aware that 1304 is the partypooper here and as long as it is the switch to whdload to 16.9 seemed valid to me. but ofcourse the ministry of truth had another idea xD:

so this is all the info i can give you. and as i requested you to remove my access there i wont be able to post anything else here.

so so long and keep on rocking with fs-uae.

ps: for the paranoid , no my whdload isnt a "cracked" one but one out of 10 or so i bought over time from wepl to support whdload xD

Thank you for putting my concerns in better words Frode

Hi, it looks like the debate is getting somewhat heated here. I hope I can cool it down rather than add fuel to the fire.

An important point to keep in mind is that a principle behind FS-UAE is that it should behave identically on all platforms. I.e. with the same disks / files, and the same config, you should get the same emulation result. So when this is not the case, we should classify this as a bug and try to find out what the problem is.

@thevoice I think it is wise to await changing the config when it is unclear if the problem is the config, or whether there is a bug in FS-UAE - either generally, or only occuring on your computer. I'm sure everyone believes you when you say it doesn't work. Surely we could change this config so it works on your computer too, but this means that the real problem is not solved, and the problem may then re-appear for other games, causing frustration for everyone - including you. Ignoring the real problem is not a good solution!

I will of course help with trying to find the root cause of the problem, and I need some information to be able to investigate further: - What operating system version you are using (and specifically also what CPU architecture). - What version of FS-UAE you are using (version number, and also which one of my packages you have installed). - What kind of crash/problem is it? You mentioned "exception" once, but later you called it a "core dump". - Is the problem easy to reproduce on your computer? Does it happen at the same spot? After a short, but random amount of time? Is there a set of steps one can perform to trigger the problem reliably?

@Retro-Nerd: The Linux version is not likely to be more buggy than OS X / Windows versions in general, quite the opposite I would say, since I primarily develop it on Linux. But of course, there are many Linux distributions out there, and Linux users are more likely to compile their own versions (possibly incorrectly), which can account for some tales of failure. But I have not had any reports about Linux-specific problems. If you participate in forums where claims of instability with the Linux version is put forth, please encourage them to file bug reports (by whatever mean, e-mail, posting in support.FS-UAE, etc)

If you don't get that hunting down numerous problems due to a bad build on Linux is fruitless rather than fixing the issue that causes the initial problem, I'm sorry, but I don't want to waste my weekends re-confirming your bug reports I hope that the 'root problem' can be found soon enough and that unnecessary changes to configs won't be needed anymore.

Btw: You even re-tested one problem on another machine and it was working, so I really would say that the problem on Ubuntu should be fixed rather than changing a lot of entries in the database because of that issue.

no i use the binaries frode builds. and i am aware that different plattforms can cause different results. my problem is even IF on my olattform is the only one on the planed which causes an coredump with whdload 17.1 and a simple versionchange "fixes" this issue for me while it dont break it for anybody while doing so i would say its ok xD.

th issue is that a problem which dont exist for you isnt existing at all. winkwink colonels bequest. which worked fine while you said it doesnt until i posted you screenshoots over at eab where it even runs under wine which is an emulation in an emulation . but it cant be what cant be. and once again. when i make a change because i have an issue with a certain install then you can believe me i have an issue with that certain install. aswell as i retest things when a new version of fs uae is released or whdload gets updated. but anyway to make a long story short.

since you have the exclusive right to harvest the fruits of the tree of knowledge i am happy to step back and let you testing while i use my weekends for some more cool stuff.

so farewell and thanks again for developing fs-uae,frode

Thanks for the test Goingdown @thevoice: Did you compile FS-UAE yourself? It's most likely the other way around... your machine is the exception. I most of the time ask other people to confirm and I have two machines here to test. As seen a few times you get different results than at least 2 or more other FS-UAE users. Something is wrong at your end and certainly Frode needs to have a look at the problems.

Under Opensuse 12.3 x64, played about one hour with no crashes. WHDLoad v1.4 variant, whdload 17.1

No, but from what i've read in other forums the Linux port is indeed a bit buggy.

well, i can tell you that it still drops out with an exception when i use whdload 17.1. and since you reverted the whdload variant back to 16.9 i assume we only take your machine and your setup as the standard setup fot testing the variants.

I just finished Tikal, got back to Iceland and am now on the Azores with 1.4 DE using WHDLoad 17.1. No crash. I'm beginning to think that the Linux build of FS-UAE is broken. Far too many phantom problems that can't be reproduced on Windows or MacOS.

@thevoice: You should write at which point the WHDLoad versions crashes with v17.1. I had no problems to go ingame at least.

The new ones are also problematic: A couple are from the PC version, one has JPEG compression artifacts, and two have not cropped away black bars on the sides. Don't worry, I'll restore the original screenshots.

OMG!! That's right! I'll see, if I get screenshots with better resolution! My shame!

@nexusle Looks like you must have saved the thumbnail versions of the screenshots and re-uploaded them. The in-game screenshots should be 634x400 or 317x200.

Changed some entrys for better understanding.

This game doesn't need AGA, but WHDLoad runs faster on A1200.

Have changed the chipset of the WHDLoad versions to AGA so the game runs on A1200. This fixed the problems with some WHDLoad versions and speeds up the game a lot!

Have sorted the pictures a little bit so they match the timeline of the game

Ok. I understand this!

file_list is currently set to [{"name": "Dummy", "sha1": "0000000000000000000000000000000000000000", "size": 0}] to the launcher won't bork at the invalid JSON in an empty file_list. All empty values is supposed to be treated as non-existing, but the setting of file_list to manual.pdf (and re-setting it to blank) broke the Launcher. This file_list key can be cleared later when the Launcher is updated.

Yes, if manuals are found in a systematic place on the file system - either by game name or game uuid, the launcher will be able to find them. The advantage of game uuid is that this will never have to change, but game names are sometimes tweaked. But file_list is used exclusively to locate the files required to run the game and should not be used for other purposes. Also, if the Launcher should simply look on the disk in an "expected place" for the manuals, no information needs to be added to the database at all.

We now need only a way to show PDFs under FS-UAE. :0)

Hi Frode,

have tried so make a sensful behavior for the file_list feature. In this case, I've saved the Manual of the game as PDF under ~/Documents/FS-UAE/Files/1/189085d9-79da-55be-a2cd-e864703daef9/manual.pdf

So the user must save the manual locally on hard disk. In this case, we get no copyright problems.

What do you think about it?