A new stable version of the EasyRPG Player was released recently, so I built new executables. To see what's new, check out the official blog of the project:
https://blog.easyrpg.org/2018/10/easyrpg-player-0-5-4-antidote/
As usual everything is available for on my site.

If using the C library is not a problem, then you can replace it with system(), which will always wait for the command's completion.

This is just a shot in the dark, but have you tried -std=gnu++11 instead of -std=c++11? The missing thing above might be part of the GNU extensions, not available in strict ANSI C mode.

@walkero
They have a fairly old list on their site, but you can try any RPG Maker 2000/2003 game, and give them feedback if something doesn't work.

Grab pixman from os4depot, or aminet:
http://os4depot.net/index.php?functio ... y/graphics/pixman_lib.lha
http://aminet.net/package/util/libs/pixman_lib

EasyRPG Player is a program that allows to play games created with RPG Maker 2000 and 2003.

You can get the OS4 version from my website (or here's a direct link).

If you don't have MIDI setup for SDL_mixer you can get the some MIDI patches from here, and dump them next to the executable.
Info on the compatibility, project status, etc. on the official site on the project: https://easyrpg.org/player/

I only tested it in WinUAE / OS4FE classic, so your mileage my vary.

Pixman library:
http://os4depot.net/index.php?functio ... y/graphics/pixman_lib.lha

@thellier
That's basically a non-portable way of achieving the same thing.

@thellier
You can't change buffers without FBOs unfortunately, and no Warp3D driver supports that. Only the old ways work, i.e. rendering whatever you need for your "framebuffer" first, and then creating a texture from it with glGetTexImage, which you can overlay your scene with.

@LiveForIt
It's not related to emulation, it happens with native programs too. This has already been identified as an R200 driver issue a long time ago.

@nubechecorre
I don't doubt that, but you also said that a long known issue didn't get fixed, because Peg2 users didn't "complain enough", which sounds funny to me.

@nubechecorre
Complaining will definitely not help, unless you are glutton for punishment :) BTW, didn't A-Eon acquire Warp3D a while back?

@broadblues
The Multiscan mode is broken in the ScreenMode prefs test as well. I guess the only way to make sure it's not an emulator problem is to use the very same winuae config with OS3.1. I have it in WinUAE, it's just that it's not on proper RDB hardfile, so it only work with uaehf.device and not the emulated IDE controller.

edit: I tested it, and on the very same UAE config Multiscan works under OS3.1 but not under OS4.1FE.

@broadblues
Yes, I have the Multiscan monitor in devs:monitors on OS3.1. On OS4 I don't have the PAL monitor in there just PicassoIV, but the native PAL modes work fine, I'm only had issues with Multiscan one. I'll copy my 3.1 setup onto an RDB hardfile to see what it does on the same UAE config.

You are right about all the possibilities, I didn't mean to state it's 100% an OS4 bug. After all, I'm working with the sample size of 1 :)

@broadblues
Yes, BootVGA is for the early boot menu, but it's not required. From the kicklayout:
Quote:

I tried it, and the boot menu shows up on a PIV screen, no issues there.

As for the emulation issues, I didn't have any problems with the Multiscan monitor in OS3.1. I can also see the mouse pointer sprite with the correct palette, it's just the actual screen contents that won't show up.
I can see the rationale behind Multiscan being a better fit given that I only specify the nominal width/height. It wouldn't be a problem if that mode worked.

I'll try to play around with the tags later.

That wouldn't be a fix either, because the the multiscan screen modes would still be broken. They are both workarounds.
This only affects the classic version with the VGA boot option enabled, which is not even used if you have a graphics card, and most OS4 classic users do.

@smf
A million thanks! I commented out that line in the kicklayout, the multiscan modes went away and now BestModeID returns "regular" PAL/RTG modes :)

@kas1e

I feel your pain, but it's difficult to compare things this way, so everybody keeps guessing. You could take Hieronymus and collect some profiling data to see what takes up the CPU time.

If vertex array were available, Jedi Outcast and Jedi Academy would be better test cases, since they have high poly models. When running MOS and OS4 on the same machine the performance gap gets smaller if you lower the model detail. With glBegin/glEnd you would end up with a gazillion function calls, again more work for the CPU while the GPU sits idle :(

@kas1e
Makes you wonder why the entire industry moved to H/W TnL in the early 2000s if it makes no difference. You are comparing apples to oranges, and your heaviest test case (Quake3) doesn't even have that many triangles.

@broadblues
I checked, and I have nothing but PicassoIV in DEVS:Monitors, everything else is in the Storage. Despite this I still have pal and multiscan VGA modes in the ScreenMode prefs. Those are probably always available in Classic. I tried enabling the fake native modes, but that doesn't seem to be possible on classic.

I made another test program that prints the modeid's returned by BestModeID, BestCModeIDTags and p96BestModeIDTags, when only the nominal width/height and depth is defined. CGFX matches graphics.library, but the P96 function returns something else regardless of what resolution I specify: 0x00f9024. It looks similar to the VGA productivity mode.
For 16 and 24 bit I get the correct screen modeids from all 3 functions, only 8-bit is broken, I don't get the 640x480 CLUT8 RTG modeid from either of them.

In summary the problem is twofold: the multiscan VGA modes are broken and only show garbage, and in BestModeID the multiscan modes have preference over CLUT8 RTG modes. Wew.


https://drive.google.com/open?id=1JzU-fRAyY08smw5zkMcfQFAXIUtA2R59

The plot thickens. When I go into the ScreenMode Prefs, the PAL modes seems to work just fine. It's BestModeID that's returning some odd 320x200x8 modeid for me: 0x00039000

edit: For 640x480x8 (which also works in the ScreenMode Prefs, it's a PIV mode) BestModeID gives 0x00039024