Messages

Anyone opposing a beautifying of the whole code? I mean running a tool over it that cleans up the formatting.

I know this is controversial because you essentially lose the history. But: If we don't do it now it will only get worse. Right now the history is basically useless already due to all the splitting. There is no "perfect" time to do this, but I think now is the least bad.

Also this makes further meaningful changes more apparent in the history because they are not always intertwined with formatting changes.

I would only beautify the engine/common cpp, c and h files and not the library sources.

Thoughts?


Edit: I am still trying to build for Android, but the toolchain really likes to mess with me... The linker gives an undefined reference error for a symbol that is clearly defined in a source file that gets build.

Edit2: Are you kidding me? The file is shown as being successfully built while in reality the compiler creates an empty object file.

Edit3: Fixed I guess. It's always the most stupid thing.

Not a known issue yet as I have no means to test usb keyboard support. The closest I come is running android-x86 in VirtualBox. In there I can type and the Return key works (e.g. in the save dialog). There is no support for keys that are not found on the Android onscreen keyboard though. That means no ESC, F1-F12, Alt, Ctrl, Shift. I could look into adding those if that is what you mean.

In which game do you have problems with the Return key and in what context?

As an interface developer I like the elegance of the CRect approach. But as a user of the interface I hate it because 90 % of the time it makes life harder and causes unnecessary code bloat without offering a benefit.

I guess it would be better if the most usual cases (whole input image and whole output image) could be accesses without having to construct the rect yourself. This could be done by overloading the method. Well, or if CBitmap had a member variable holding its size.

All that said, I would go with CRect.


Something else: I am still in the process of making the refactoring branch compile for other platforms. At the moment I am taking care of Android. There is a very annoying bug in the Android toolchain that makes it impossible to include "debug/debug.h". Instead of using the files in the user include path it will include the respective file from the standard library So I have to rename the file. Any suggestion for a new name? Maybe "debug/agsdebug.h"? I know this is stupid, but I cannot help it.

Also I am strongly considering switching development to the refactoring branch. The original code is a mess and it gets worse every time I hack something in. An additional benefit would be that the refactored code is actually used and therefore checked for errors.

If I switch these are things I would like to do:

Remove unnecessary code:
- Memory allocation check because it is a joke. 4 MiB is not enough to load any game no matter how small it is.
- Path finder copyright "protection"

Refactor these:
- Moving the plugin interface into there own files and partially into the platform files. Right now it is totally backwards with the platform files calling the generic implementation which is then a nasty ifdef mess for all platforms. Also Linux plugin implementation is broken and the plugin stubs break games if they use the same script function calls.
- Removing the platform config file reading code and putting everything into acsetup.cfg albeit making the engine configurable on all platforms. Right now Windows, Linux and OSX don't have the advanced options of the other ports.
- Adding the OpenGL driver to the graphic driver list. Also adding the D3D render-to-texture driver.
- Removing the variables with which the port frontends control things like the game file. They should be replaced by constructing parameters to main().

Edit:
- Replace Sleep() calls with platform::Delay() everywhere. I already did that in the code I am working on.
- Replace the debug output system ASAP because it is a hassle to do debug output in a lot of files since they don't have access to the platform header and VS only understands OutputDebugString while *x*-like stuff needs printf and Android again its own thing and then my head explodes.

The Wii seems easy to program for. From what I saw the graphic API is very OpenGL like. An issue is that it is a bigendian PowerPC architecture which is basically unsupported since the PowerPC Mac port.

I was concerned about the available memory which is low with only 64 MiB. But due to recent changes (see the PSP thread), I think the platform could still be viable for a port. I won't promise anything, but I will look into trying to cross-compile the libraries and doing a basic Allegro port. Getting everything working might take some time due to the bigendian issues.

R9!

The new version gives more game compatibility because the memory footprint of the engine has been reduced quite a bit (about 12 MB). I did this by replacing the static array for the state-saving rooms (number < 300) by a dynamic allocation scheme. So a lot more games should now load on a PSP 1000 (I got Gemini Rue to run on it).

Resonance might now just be able to start if the additional memory is enabled. But I don't think that it will be playable for long.

The error in Ben Jordan 8 has been fixed (more liked worked around). It was in fact an FPU exception being caused by a multiplication with NAN. It seems to be related to the clock drawing in the library because the clock doesn't work. But at least the game doesn't crash anymore.

Download version R9 from http://jjs.at/software/ags.html


Edit: Fiddled around a bit more and now Resonance is down from ~105 MB to ~68 MB at the point where you take control of the character. These values are from my Windows build which has about a 35 MB overhead. So I suppose it would now run a PSP. Make sure the configuration file has these values:

Code: ini

[compatibility]
enable_extra_memory=1
clear_cache_on_room_change=1

I updated the R9 version and created a daily build. So either of them works as they are the same.

I changed the license to CC0.

Alright, I pushed the changes to the repo and uploaded new daily builds with the AGSSpriteFont plugin. As for the license, I added a readme saying that the code is public domain. That should be ok from what you wrote, if not I will change it. Thanks again for making the source available.

Played a bit of Patchwork on my phone: outstanding production values there! I recommend using the standard hardware renderer for best performance.

Nice, thanks! I will add it to the repository. Should I assume the same license as for AGSBlend?

In the current ports it returns windows because some of the engine functions like plugins rely on it being so.

The engine could technically return the real operating system to the game. The real problem is that some games make assumptions based on the returned value that are untrue or just don't work properly. E.g. some games disable plugins if the returned value is not Windows and Gemini Rue doesn't play background sound on the main screen (you don't want to know how long I tried to "fix" that because I thought it was a bug in the port).

Ideally games should not query the operating system at all. Asking the engine for the availability of a feature would be much better, but even then I don't know a real usage scenario for that. Personally I would like it best if games would just go ahead and assume that the engine does the right thing.

I get the following error with Patchwork:
unresolved import 'SetVariableSpriteFont' I'm guessing it's an unsupported plugin for higher resolution sprites?

The plugin is for drawing bitmap fonts, but yes that is essentially the reason.

With Barely floating, here's the error I get:
Error: load room: unable to deserialize prop schema

The error occurs because I don't include the agslua plugin (yet). But the game won't work regardless because it is made with a modified AGS engine (to support widescreen resolution).

The .NET framework versions are completely separate, so you have to explicitly install the 2.0 .NET framework. The 3.x and 4.x frameworks don't include it.

Not feasible at all because the CPU of the PSP does not have an MMU. This means there is no hardware to translate virtual addresses into physical memory. A software-only MMU replacement would theoretically be possible but hard to implement and absolutely unusably slow at the same time.

Edit: Please don't mess around with flash0! It will not help at all and I don't want you guys to brick your PSP.

The only real problem on the PSP is the limited RAM. 64 MiB is just not enough. Cpu-wise it can run most games just fine unless they have a lot of scripting.

E: From the exception log it is pretty clear that Resonance runs out of memory.

It will be hard for me to work on this error without the device

But the logcat of the device could give some information on what causes it though. Can you run a game that shows the bug and then upload the log from your device? You need a logcat reader for doing that (e.g. https://play.google.com/store/apps/details?id=com.nolanlawson.logcat&hl=de). Also enable the "write log" debug option in the settings of the Android AGS app. The log contains all kind of system messages, you can crop out everything before and after the game.

Also how much of a sound gets played before it cuts out? Is the behaviour always the same or does it randomly play more/less?

What version of Android do you run?

The bug preventing Gemini Rue from loading should be fixed in the newest daily build. Please try Resonance again because the bug would affect it too.

Also thanks for the save file and the description for MMD. I can reproduce your error, but I don't have a lead on what causes it yet.

Anyway, with MMD, I do have a save game.  It is right at the end just outside the door to the lab.  If you need a short walk through of what to do, let me know. Where can I send the save.  I might need a few days to get it to you.  Thanks.

You can send it to jjs@jjs.at, thanks! A walkthrough from that point or a hint on where exactly I am in the game so that I can look it up would be very much appreciated.

Ben Jordan 8 starts well, but when you want to go to the library the first time it gives you the blue screen on R8

Can you post the exception log?

I got the plugin running on Android. The changes to the plugin source are in here: https://github.com/jjsat/Lua-for-AGS

Changes are mostly for making GCC happy and enclosing the windows.h include and the MessageBox code in #ifdefs. Also I commented out the unused mutex as it doesn't seem like it is used anywhere.

Can you review the code and maybe merge it into your repo if it doesn't break anything?

Here is the error I get with the latest daily for Gemini Rue

I cannot see what causes this from the error message. When does this crash happen in the game?

First, on the onscreen keyboard, the number 6 appears twice.

Doh! I will fix that.

On the screen where I select my team, if I hit the left or right buttons which I have mapped to F2 and F3 respectively, the game crashes and gives me this error.

This is a scripting error in the game. It is also present in the original Windows version.

Lastly, there is a scripting problem at the end of the game.

Probably a backward compatibility problem in the engine. Do you have a savegame that demonstrates the error? I would rather not have to play through the whole game myself

Since regular psp games seem to work on the VITA, does this mean that AGS could possibly work in its current state once a CFW is made for the VITA?

If either a Vita CFW or a CFW for the PSP emulator of the Vita is released, AGS should run the same as on the PSP.

Monkey Island 3

The AGS engine is not really optimized for low memory devices. Also game authors might do things with scripts that are faster but use more memory because memory is not a concern for the PC anymore. ScummVM engines are written from scratch with the constraints of the lower powered devices in mind, so they are better optimized in that regard.

Ok, thank you! It is not a problem to use 5.1.4, I just wanted to know what version I should use as a base because they need different patches.

I have a quick question on compiling the source: Is the version of Lua used (5.1.4) critical or would the plugin also work with Lua 5.2.x?

Any chance this will be added into the engine ports: https://github.com/duncanc/Lua-for-AGS

I'm on it