Messages

Alright, let's make sure that we got a compatible game and that the folders are set up correctly.

For example your game from here: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=43962.0

The AGS engine must be extracted to the GAMEs folder. I think you've done that right, but still:

The folder "x:PSPGAMEAGS_Runtime_for_PSP_3.21" then contains these files:

Code: ags

P:PSPGAMEAGS_Runtime_for_PSP_3.21>dir
 Datenträger in Laufwerk P: ist A

 Verzeichnis von P:PSPGAMEAGS_Runtime_for_PSP_3.21

12.05.2011  13:58    <DIR>          .
12.05.2011  13:58    <DIR>          ..
19.07.2011  08:19    <DIR>          Project 304 style
17.07.2011  23:04         3.226.402 ags321.prx
17.07.2011  23:04           232.765 EBOOT.PBP
17.07.2011  23:04             2.466 exception.prx
17.07.2011  23:04             2.958 kernel.prx
17.07.2011  23:04             9.547 License.txt
17.07.2011  23:04               709 psp.cfg
17.07.2011  23:04             7.782 readme.txt
               7 Datei(en),      3.482.629 Bytes
               3 Verzeichnis(se),    366.051.328 Bytes frei

And the folder "x:PSPGAMEAGS_Runtime_for_PSP_3.21Project 304 style" is where you extract the game files from your download:

Code: ags

P:PSPGAMEAGS_Runtime_for_PSP_3.21Project 304 style>dir
 Datenträger in Laufwerk P: ist A

 Verzeichnis von P:PSPGAMEAGS_Runtime_for_PSP_3.21Project 304 style

19.07.2011  08:19    <DIR>          .
19.07.2011  08:19    <DIR>          ..
07.07.2011  13:47        23.166.419 PMQ.NO1.exe
07.07.2011  13:47            57.368 winsetup.exe
09.07.2011  02:26               314 acsetup.cfg
07.07.2011  13:47         3.072.825 audio.vox
09.07.2011  02:02            74.112 pass3.png
               5 Datei(en),     26.371.038 Bytes
               2 Verzeichnis(se),    366.051.328 Bytes frei

When I run the port with this setup, everything works as expected for me. The error you are receiving sounds like the files are still in the wrong place, so can you please check that?

You just copy the whole folder that contains your AGS game into the folder with the EBOOT.PBP file.

For example you got the port in "x:\PSP\GAME\ags\", then you copy the data files of a game into "x:\PSP\GAME\ags\my ags game\". That folder then contains the game exe, audio.vox, speex.vox, etc. Every game you want to add gets its own folder.


Unfortunately I spoke too soon for QFG II, that game seems to randomly crash from lack of memory later on (the fix was for making it start at all).

Made a small update after a bug report from here. The King's Quest I and Quest for Glory II remakes now run without crashing. There were still parts with misaligned pointers in the scripting engine and I had forgotten to update apeg when I switched from libvorbis to libtremor. The update is available through the same URL as before.

Btw. LimpingFish, I tried Dead Hand on my Go and it runs there. Unfortunately the 3d is too much for the PSP so that it only displays at 1 fps.

Would it be possible to build a version of this that compiles everything as an eboot? What I mean is, can a version that loads a single game automatically, bypassing the need to load a game from a seperate GUI, be implemented?

If you put the data files in the same directory as the eboot and rename the games executable to "ac2game.dat", the launcher will directly start that game.
Also it is possible to compile the engine as an eboot, so that you don't even have to include the launcher at all, only eboot.pbp (and exception.prx unless you are sure that your game never ever crashes the PSP .)

Some PSP emulators use a cache file system to avoid the PSP1000's memory limitations. Could something similar be used here?

I don't know about that. The PSP lacks an MMU and therefore "virtual memory" cannot be implemented in an efficient way. The difference between a 1000 and the other models is having about 17 MB and 48 MB heap respectively.
Unless really digging into the source code and changing the way it uses memory I don't think anything can be done for the 1000. Even the other models run out of memory with large rooms, e.g. Eternally Us crashes in the first room because it is gigantic and Of The Essence runs out of memory for the pathfinder.

This is a follow up post to the initial PSP port I presented in the engine release thread.

Now that the port has matured a bit and can be considered almost complete and more user-friendly here is a proper release thread for it. Still, this is a port of the 3.21.1115 runtime engine to the PlayStation Portable. To play it you need a PSP 2000/3000 or Go with a Custom Firmware or Homebrew Enabler. The engine will start on a PSP 1000 but due to the lower total available memory, you cannot run most AGS games.

Games can just be copied as they are into the ports folder on the PSP, no more renaming to "ac2game.dat" as in the initial version. Now the game data is autodetected. If the game data is compiled with an incompatible AGS version, the launcher will tell you so.

There are various options that can be configured in a text file. See the Readme for details please.


Source code is available on gitorious as a clone/branch of the Linux engine port:
https://github.com/adventuregamestudio

Binaries are available from my website:
http://jjs.at/software/ags.html


UPDATE

If you want to stay on top of the newest developments, you can get intermediate binaries from my daily build site:
http://jjs.at/daily/

I will put an updated version there whenever I make changes to the source.

Also there is a bug tracker here:
http://jjs.at/tracker/

Please also post feature requests and bugs there.

[Please use the updated version from this thread.]

Finally, here is an initial AGS runtime port to the PSP.

There are some restrictions, especially this port cannot run high-res games because the native resolution of the PSP is only 480x272 pixels. Also memory demanding games will run out of memory and crash. More about this is written in the readme.

What this port can do is run games requiring certain plugins like snowrain because the plugin exports are implemented as function stubs. This means you can e.g. run Gemini Rue with this (without the rain effects of course).

http://www.jjs.at/temp/AGS_for_psp_3.2.1.zip

Edit: Please use the updated version from this thread.


Are there plans to release the 3.1 and 2.7 source too? Edit: I guess that was already answered. I will stay tuned.

It would make sense that this is a crash on quitting because the message that gets drawn on screen (the one from the screenshot) says that speech.vox is not available. After dismissing this box with a keypress the game quits.

You asked for other test cases, what I did was compiling some games myself which are open source like ! and the Oceanspirit Dennis games. Also of course the demo game that comes with AGS. Other games for 3.2x are (in no particular order or reason for selection): Aeronuts, Beacon, Eternally Us, Hardspace, The Hamresanden Chronicles II: The Black Prism, Of the Essence, The Lurking Horror, Next to Evil, Fountain of Youth Demo/Arcade Fighter, Gemini Rue, etc. Really a lot of games, especially also newer MAGS ones.

I am working on a PSP port right now, which is basically done except for the onscreen keyboard and customizable controls.

The PSP has a MIPS processor and you may have the same problem on ARM. The script engine regularly casts values to int pointers which are not 4 byte aligned. That is not allowed on the PSPs processor. So I replaced these instances with memcpy functions.

Also the bitmap font rendering uses unaligned pointers.

Here is a patch (against the SVN) that works for me. It includes some PSP specific changes too. But every single change is documented, so you should be able to gain something from it if the problem is in fact the same.

http://jjs.at/temp/pointer_alignment.patch

Edit: It might also be important that I can build all source with -O2 optimization except for ac.cpp which has to be with -O2 -fno-strict-overflow -fno-strict-aliasing . Otherwise there are strange scripting errors.

Since this an early version, I am not sure what kind of feedback is needed but:

- If you start a game download and quit Nexus before it finishes, the game vanishes from the game list and the partial download stays on disk.
- If a game is removed from the list while it downloads, the download continues in the background. It is possible to readd the game to the list, but it will not show the download status or the name. When eventually the game is downloaded it will be unpacked. If you then again click on the "install game" button, it will reappear in the game list.
- Deleting a game only removes the folder, not the download archive.
- Regarding the last point: Maybe there could be an option to have a downloaded game "uninstalled" (i.e. not unpacked) but still appearing in the menu (as "preloaded" or something). That way it would be quick to reinstall it without another download.
- Sometimes, a game will not be successfully added to the list if you try to install it. There will be a list entry created, but it its description is empty. Also no file is downloaded. When you click on it, it will take you to the games page though. This seems to occur at random.
- Running a game from winsetup.exe will not make the game show up as "in game" in the list (it shows as "Ready").

Crashes on start because of this exception:

Code: ags

Eine nicht behandelte Ausnahme des Typs "System.IO.DirectoryNotFoundException" ist in Microsoft.VisualBasic.dll aufgetreten.

Zusätzliche Informationen: Ein Teil des Pfades "C:\Users\JJS\Documents\Nexus\Settings.ini" konnte nicht gefunden werden.

If you manually create the "Nexus" folder in "Documents", it starts fine.

Windows 7 x64 btw.

It would nicely tie in with this:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=40132.msg533721#msg533721

This sounds like a pretty big problem because you cannot lock surfaces that are created with D3DPOOL_DEFAULT such as the back buffer, only those in main memory (D3DPOOL_SYSTEMMEM).

Just speculating, but do you really need to lock it? I mean you don't ever need CPU access to the texture because you only want to apply a shader to it. If the destination surface of LoadSurfacefromSurface is also in the graphics card memory, the operation should actually be quite fast. But if you already create the surface with D3DPOOL_DEFAULT and it is still slow, then I don't know.

I guess this whole scenario is quite rare because you either use render to texture for this or want the image in main memory (for a screenshot).

I actually only have experience with OpenGL, but you probably want to set your world matrix to the unity matrix.

I cannot find anything quickly, but this explains some basics:
http://www.toymaker.info/Games/html/matrices.html

Just a guess: Do you reset the worlview and modelview matrix before drawing? If not, every coordinate is interpreted relative to the last used matrix, which in this case seems to be the one the character is drawn with.

Yes, I mean doing all rendering on a texture instead of the screen surface.

So the rendering would then consist of:
- Creating a texture in the games original resolution e.g 320x200
- Setting this texture as the render target
- Setup the viewport etc. as if you were drawing on a 320x200 screen
- Drawing everything
- Switching the render target to the screen and rendering a quad with the texture

Google turned up this: http://www.two-kings.de/tutorials/dxgraphics/dxgraphics16.html

I don't know how the high quality scaling filters are applied, but I guess they can operate on a single texture.

I don't think so. The purpose of the D3D driver seems to be having hardware accelerated drawing to ease the load of complex drawing operations (e.g. particle system, transparency). Correct me if I am wrong here.

If the Direct3D way of rendering to a texture is anything like the OpenGl way, there is no real difference between it and drawing to the screen surface. All hardware acceleration is still being used.

The final rendering pass to the screen is also fairly lightweight with two triangles and one small(ish) texture that is already in the graphics cards memory.

That's basically what it does in software mode with the DX5 driver. But as far as I'm aware it's not possible to do something like that with D3D hardware acceleration, as there is no concept of a temporary sprite.

It should be possible to first render the whole scene to a texture in the games original size and then render a quad with that texture to the actual screen.