Messages

I pushed a change so that the D3D graphic driver setting is ignored on Linux and Mac (the mobile platforms don't evaluate the configuration file).

E: ^^^ I don't see what is wrong with that screenshot. ^^^

The script engine seems completely agnostic to the AGS version. Remember that the scripts are compiled into code for a virtual processor so you can add new features to the language and just output the appropriate low-level code in the compiler. Like your computer can run compiled C++ and C code because for the CPU it is just a stream of the same instructions in a different order.

Breaking backward compatibility might not sound like a big deal until you remember that it will invalidate all existing modules. What does a new game developer care more about: Fancy language features or a big library of ready-to-use code?

About the fixed types: There are instances when you absolutely need a variable size type, e.g. in the script engine. The registers of the virtual machine must be able to hold pointer values so they have to be 64 bit or 32 bit. On Unix-style systems this can be done by declaring them as long int (that is what is I am using right now) but on Windows a long int is always 32 bit and only a long long int is 64 bit. So for greatest portability the variable must be defined as an intptr_t.

The "back" hardware button acts as the ESC key.

I cannot test on the PSP anymore because I now only have a PSP 1000. It lacks memory to load big games like Gemini Rue. But I will try to figure out what could cause the error.

Resonance is probably too large for the PSP memory. It might not run on the PSP at all.

Blackwell Deception is made for 640x480 resolution, but the PSP can only load low-res games (320x200 and 320x240). Scaling down the screen would in theory be possible (like it is done on Android and iOS) but again the memory on the PSP is very limited and is just not enough for high-res games.

I made another update to the source, again in aastr, because I noticed that scaled anti-aliased sprites were drawn incorrectly.

I caved in and got the Blackwell games. The error was caused by the aastr library which used long* to access an int* value. Valgrind to the rescue again . I pushed a fix to the repository.

About the error, that BigMc mentioned: It would be great if some more people would test the 64 bit branch on their system. Right now we don't have a lead on what is causing the engine to be loaded to different addresses on his system. This is something that should not happen for several reasons (1) The engine binary is not PIE enabled. (2) PIE is deactived in the system settings. Still, it is loaded to a different address every time. This is a problem because the script interpreter relies on global variables being accessible with 32 bit long pointers. As BigMc said, I cannot reproduce the error. It only occurs for me when I explicitly compile the engine with PIE support.

I don't have the game, so I cannot check myself. Are there any other "exe" files beside game.exe and winsetup.exe in the folder? I guess there is unins000.exe (which should not be a problem), but are there others?

All game resolutions are supported and they are scaled to the screen size as necessary.

Speed of course goes down with higher resolutions. On my iPod 4g Snakes of Avalon still gets > 35 fps with the OpenGL renderer in the bar. The downside is that the OpenGL renderer does not yet support tinting of sprites and plugins that draw to the screen (like the D3D renderer on Windows).

Also the memory consumption goes up a lot with the resolution so it is possible that a hires game runs out of memory.

Legba, the game files go into /var/mobile/Documents/ags/game/

The main game file ("Gemini Rue.exe") has to be renamed to "ac2game.dat". You can take a look at the sample game files to get an idea.

The file permissions for the "ags" and all subfolders must allow writing by a standard user.

The 64 bit branch will also compile for 32 bit. I only created a branch instead of pushing to main because I am not yet sure if the engine is 100% stable and always behaves the same as the 32 bit version under all circumstances. Also, as I wrote, it lacks backward compatibility.

I will eventually merge the branch to main.

Tobihan also suggested changing the variables from generic int and long to the "right" ones, which are int32_t and intptr_t. This is a good idea and should ensure compatibility with different platforms (like Windows 64 which defines long long int as 64 bit, and long int as 32 bit).

There is now a native 64 bit version of the engine in the "64bit" branch of the repository: https://github.com/adventuregamestudio/ags/tree/64bit

At the moment it runs only games made with AGS 3.x.

There seems to be an issue with liballegro-4.2 on 64 bit that causes WAV files to fail to load. Games that use this file format and don't check for successful file opening will crash with a script error ("null pointer dereferenced"). The problem appears to be fixed in Allegro 4.4.

I think the length() function would be broken for cases like this:

Code: c

char buffer[100];
strcpy(buffer, "hello");

The actual length is 5 but the function would return 99, wouldn't it?

Nice, I've added you.

I have now split the engine from the launcher app. This means that the frontend can be more easily switched to a custom one for releasing a game on the market.

The engine part is now in /Android/library, the standard launcher in /Android/launcher_list. The engine is included into launcher project as a library through the "project.properties" file. I will later include a more basic example for a simple single-game launcher.

For a market release there is still the problem that the game files must somehow be placed on the memory card. Either through downloading them from the net in the launcher or by bundling them in the APK and unpacking them on first start. The engine cannot read the game files directly from the APK.

The repository is now on Github, so I will not update on gitorious anymore.

Anybody who wants to work on the source is welcome. There is also always the possibility of forking the source, working on something and then creating a pull request.

^Thanks!

I guess the branch has to be in the "ags" repository. Otherwise github will not understand that it is related to the the main repository which would be bad for merging (probably)?

So a new branch in "ags" it is.

I remember that you said that the script interpreter is the source of the 64 bit problems. Specifically that it uses ints for storing pointers. I wonder if the problem could be solved by introducing a translation table that maps these 32 bit values to their real 64 bit addresses. It would cost a bit of performance but the script engine is already slow and 64 bit CPUs are usually fast so speed would not be the problem there. Maybe it could be implemented as a macro around all such accesses. The macro then resolves to nothing on 32 bit and a respective function call on 64 bit.

There is of course still a possibility that some compiled-in library has 64 bit issues.

Edit: Is the problem mostly with these "inst->registers" accesses in csrun?

About the repository: I gave Crimson Wizard commit rights to it. monkey_05_06, let me know when you sign up and I will add you too. Also anyone else interested is very welcome.

So how do you want to organize this? Do you want to pull all of the branches of the refactoring fork into it or just the latest one? I am honestly not well-versed into how to do that correctly.

As for the forum builtin bug tracker: That is pretty cool! And I would be for just giving everyone admin rights. I think the risk of nobody stepping up for it now is higher than that of people invalidating each others work.

No, that option just causes the compilation to abort on the first error. You are confusing it with "-Werror" which causes all warnings to be treated as errors.

To me the error looks like you are trying to compile the engine for 64 bit (because only there an int is smaller than a pointer). You absolutely have to compile the engine into a 32 bit executable, it will not work otherwise.