Messages

Because the Pi has a very fast and modern GPU (graphics processor) but only a somewhat outdated old ARM main CPU. The fast GPU of course helps with 3d games but won't do anything for 2d graphics that are drawn by the CPU.

Edit: I should add that there is an OpenGL driver for AGS (like the Direct3D driver) but it is not yet working on Linux and the Pi also does not (currently) offer hardware accelerated OpenGL in the X window system. Even with that there is still the issue of script-heavy games hammering the CPU.

The Linux port already compiles and runs on the Raspberry Pi (I got one) under Debian. But it is very slow. There is a new hardware accelerated X driver that is currently in testing which improves performance somewhat. But still even low-res games struggle to maintain > 30 fps. Graphically advanced games or ones with a lot of scripting don't run acceptable.

Edit: Technically no effort was required to make a Raspberry Pi port. Any ARM specific problems that might have been there are already dealt with (because of the Android and iOS ports) and there is no real difference between a Debian on x86 or on ARM. The system provides the same libraries on all platforms.

Sounds good

I uploaded another update. It is essentially the same but with a further change for task switching. The config file should not be necessary, ideally the game would run without it or when setting

Code: ini

threaded = 1

in it. So for testing the setting should be set back to this default value.

It is interesting that you don't see a sound stutter. The ipad 3 is probably fast enough so that this does not become a problem usually.

E: All changes are now pushed to the source repo.

I only wonder, why are they so huge related to windows saves :/.

Do you mean they are smaller if you load a game and then save it again in Windows or if you start a new game in Windows and then save it. Because savegames become larger the farther you get in the game since they contain the roomstatus of every room you have visited so far.

E: Well, beaten.

So, the problem with these saves was crashes in sound system, right?

Yes, some of them crash in the sound routines after loading.

The Oceanspirit Dennis games are all open source: http://www.adventuregamestudio.co.uk/forums/index.php?topic=43979.0

Thank you for the log!

The crash happens in the audio callback but I think it is for a different reason than in the stackoverflow thread. I updated the port, maybe it cures the problem.

If it still crashes, I probably have to look at the full crash report. I suppose the crash always happened the same way as in the crash you posted?

You can post new logs using the {code} tags so that they use less room or send to my email jjs@jjs.at.

Can you verify that the config file is actually read by setting

Code: ini

[sound]
enabled = 0

This should disable sound completely.

I was under the impression that the crash is sound related but if that config file doesn't make a difference, it must be something else. No idea what it would be though. But since you can reliably reproduce the crash we should be able to figure it out eventually


Edit: Ok, maybe I know a way to find out more about the crash. Since you have a jailbroken device, can you get me the crashlogs from the device? They are stored at this location with a plist extension:

Code: AGS

/var/mobile/Library/Logs/CrashReporter

Because they have to match the debug symbols that I currently have, I would only need the crashes from today.

Edit2: Actually it looks like the crash reports get synced by iTunes, so depending on your situation it might be easier to get them from the PC. A guide is here: http://www.trilinkee.com/crash_logs.html

I updated the port to the latest source version. Please try with that, it potentially has a fix for the crashing. Unfortunately it doesn't happen for me (ipod 4) so it is a stab in the dark.

If this does not help with the crash, please place a configuration "ios.cfg" into the game directory ("/User/Documents/ags/game/ios.cfg") with this content:

Code: ini

[misc]
config_enabled = 1
[sound]
enabled = 1
threaded = 0
cache_size = 10
[debug]
show_fps = 0
logging = 0

You should notice that sound starts stuttering on room changes but it probably also removes the crashes.

Interesting question. Right now the plugins read/write in native byte order which is indeed not the best way. Since plugins can save any kind of data (which is just a binary blob to the engine) they have to do the endianness conversion themselves I think.

Maybe - instead of a raw buffer - the plugins should receive a MemoryStream object to which they can write data with endinaness translating methods. Just like the engine does with the game data.

BTW, I could miss something, where can I see those Maniac Mansion saves?

Sorry, didn't know you wanted them too. I uploaded them here now: http://jjs.at/temp/Maniac_Mansion_Saves_AGS.zip

I guess the "dead" comment was more about the PSP port than AGS in general. Honestly I find it pretty hard to keep all the ports working. Somehow they seem to erode over time and even though I think nothing has changed that would break them, they still break either in building or (even worse) while running.


Edit: About plugin compatibility. The opensource snow/rain and flashlight plugins by default save in their own format. While loading they support three cases:
1. No plugin data saved. This happens when the plugin stub is used, that means no plugin was loaded and the plugin functions were just dummies inside the engine. Before the plugins were written this was the only way the ports saved the plugin data.
2. New plugin data. Can be loaded as is.

Then there is a compatibility mode (enabled by a define, only for snowrain) where they will just read as many bytes as the original plugin on loading and write as many 0 bytes on saving. This is just so they can load files that were saved with the original plugin and it is not enabled by default.

Ideally the plugin should detect that it is supposed to load old plugin data but I remember the problem is that there is no interface for seeking back in the savefile exposed by AGS. Just taking the FILE* pointer given by AGS directly still works on the PSP though but not on Windows IIRC.

Really, the best way to have this plugin interface would be that the engine knows exactly how much data a plugin has written and just reads that on load and passes it as a buffer to the plugin. Then on save it should also receive a buffer and write that itself. Then it would be trivial for the engine to just skip a plugin when loading and a plugin could do whatever with the whole saved data.

Updated the port with a suspend fix. It should now be pretty stable. The crashes are not really occuring later because of the changed script interpreter though. Problem is that files which are open while suspending don't normally get reopened and repositioned after resuming. So the next time a resource is loaded (a sprite, music, new room) the game crashed with a blue screen or showed an engine error about corrupted sprites etc.

Also added another fix for multithreaded audio. This does not help with the crashing MMD savegames but it is related to the same problem. So hopefully it doesn't occur in the future.

The PSP is not very fast to begin with (333 Mhz MIPS with small caches) so it could never run script heavy games at full speed (not even close). As an example, the main menu of Beacon has a water effect on it that causes now 4 fps max while with the old script interpreter it was about 7 fps. Gemini Rue is another problem because it plays a lot of sound effects in the shooting scenes combined with scripting. Since the PSP is very slow while reading from the memory stick this is of course problematic.

I think inventing new instructions is a good idea if it gives more speed.

Of course implementation really has to be done carefully because a register that appears to be temporary could theoretically be reused later. But I don't know if the compiler is smart enough to do this or if it emits the stack push/pop operation every time it accesses a variable.
Also it has to be clarified how much the compiler interleaves instruction blocks, this will influence how easy it is to automatically identify the meaning behind the code for rewriting.

I will look at the crashes. And I didn't do anything about possible standby problems but this is always a problem on the PSP. Usually I have the extra memory enabled in the config file and therefore I cannot use suspend mode anyway :-)

I uploaded the Gemini Rue saves here: http://jjs.at/temp/grsaves.zip Since they are from the PSP version, I am not sure if they will restore correctly in the Windows build because it uses different save data for the snow/rain plugin. But I tried and they show the "audio types" error before that becomes a problem.

Did you already send me the MMD saves?

What about this bug in Gemini Rue?  Was this one fixed in that build?  This is kind of a strange one as it never happened before.  This is when starting a new game too... not just when loading a save game, which currently doesn't work at all.

I have a hard time reproducing this. The game never "freezes" for me when skipping cutscenes, but it takes a long time to get to the next playable section. What I mean is that when I skip the "operation scene" it takes about 20 seconds, then skipping the next scene (which ends with "MH, where are you?") takes more than 40 seconds. These times might well we longer now than in previous versions because the script interpreter lost a bit of speed.

Where did you want me to send these?  I usually just emailed them to JJS.
I can send all of them as there are only 6 max I think.

You could use some file hoster like rapidshare or megaupload. Or mail them to me, I will host them on my server.

Looks like this is the last thing to make it completely playable.
I might not be able to test the compatibility fix until this is fixed.

Can you easily reproduce that crash? If so, I would be interested in save games that crash like this. The one savegame you provided loads fine for me.

When trying to load some save games, not all, I get the blue screen of death.

This crash happens in the audio code, not sure why yet.

As far as the other general backwards compatibility bug, I am just waiting on getting that fixed so I can play through the first maniac mansion on the psp with the other characters.  I don't have much time to play through it on my computer and it looks much better on the psp due the smaller screen.

Should be fixed in the newest build.

The problem was that SetPlayerCharacter() behaved differently on 2.61 and lower. It would set the new character and change to its room regardless of whether that character was already the player. Newer versions of the engine just ignore the command if the new character is the same as the current player character. Interestingly the documentation to SetPlayerCharacter() does not mention this.
Because of this behaviour, the end scene never triggers as it runs in the room where "Dave" is. But if "Dave" is already the player, the room switch never happens.

No, it is about this bug (quote from a few pages back):

Lastly, there is a scripting problem at the end of the game.  If I use Dave, the main character, to beat the game, when the ending shows, it freezes at a certain point and the mansion blows up.  Basically what happens is when you enter the lab, a timer starts ticking and you have to do certain actions before it runs out or the mansion blows up.  Even when I complete the said actions, it just freezes at a certain point until this timer, which is supposed to stop, runs out and shows what would have happened had I not completed what I was supposed to in time.  I hope this makes sense.  Now this does not happen if I beat the game with one of the other 2 kids.  I think it is because Dave appears in the ending, and if he is used to beat the game, it activates this glitch...  If you use another kid, he is available to show up in the ending.

I think it is fixable, but as of yet the reason for the bug is not known. It might be because a change in room switching logic maybe.

Maniac Mansion bug is a general backward compatibility problem.

The two latest bugs were indeed only present on the PSP. The "red screen" crash was due to a too small stack size on the audio thread, the other one unaligned data (see previous post).
They should both be fixed now.

I wonder if the situation was better if the game data was not attached to the exe. While an access to an executable file could always trigger a virus check, maybe an access to a random data file would not be checked. Usually the exe is only touched once when it is being loaded by the operating system, not constantly for loading resources. Just speculation at this point but may be worth investigating.

Yes, I found three problematic instances in runtimscriptvalue.cpp. All of them write/read int32 to/from global data. I added a new #define that enables the memcpy() procedure since it is not necessary on x86 and - by the looks of it - ARM.

But there is still something wrong. I get a very bad crash that unfortunately takes out the whole system including the debugger. It shows the same exception address in all games I tried but it doesn't point into the text segment. It might be wrong though, or there is a jump to the same invalid address somehow. Edit: Yeah, that would be the other crash lestat666 mentioned.