@tao

I never said anything on Hyperion cheating Devs. Your statement sort of implies I would have said this. But yes, the MacOS Sales were not really relevant. I think the games Hyperion ported to MacOS were too old for the Mac market.

And as most OS4 Devs will agree the one hindering OS4 development is not Hyperion but Cloanto.

@Maijestro

What I wrote here in the part you quoted does NOT apply to this GR.
According to the GR you posted it is NOT an Alignment exception but a DSI.

Did you check if your SDL2 settings are set to Compositing (as Marek wrote that his code required compositing) ?

If this does not help my suggestion would be to compile a debug version of the program to see if this gives more details of what exactly is going wrong.

Also maybe compare if the system where it runs and the system where it doesn't use the same version of clib4.library (myselves I did not do much with clib4, I usually use newlib).

And it seems the EmuPPC will be faster than Emu68. While right now it is just some benchmarks, for example the Mandelbrot benchmark indicated a speedup of nearly +50% compared to Emu68 (due to it being less hard work for the ARM CPU to emulate PPC than for it to emulate 68k which is much more complicated for it). Of course realworld app speed still needs to be seen.

ScummVM 3.0.0beta is ready for testing (Test Version against
Paypal donation to tirionareonwe@gmail.com). Currently only
Software renderer though I hope soon also the GL (MiniGL and
GLES) renderer will work.

68k version was now released on Aminet.

I think a big issue on that EULA thing is that in the US they CAN forbid it with an EULA, and they just ignore that in EU they cannot...

Actually I was told (and this was by a lawyer actually) that reverse engineering is legal in the EU. An EULA if it says anything different would be illegal. I actually reviewed this with ChatGPT right now, and it seems the claim that Reverse Engineering is legal (as long as no trademarks are violated) in the EU is CORRECT. It needs to be "cleanroom" though.

And I understand and accept both your views though for myselves I chose different (I was actually quite happy to see the video of smarkusg port so it was shown it can be done on OS4 too ^^).

@helloworld: Yes, the datafiles are freeware. Nothing about the source-code. And the guys from OldUnreal cited in that article you link signed a contract with Epic for that. Epic still preserved that compiles for new platforms need to be agreed by them. IMHO they should not have made it so complicated and just OpenSourced the bloody thing ^^ I think on that we all here agree.

And I think it is dangerous to assume that because one huge company doesn't care another huge company will behave the same way. But well it is your (Bszili) risk, not my business, really ^^ As I said - I hope nothing bad will happen.

This will be very interesting, how it performs on such a machine.

Today I again managed to do another Bugfix - this time the light effects which up to now shone through doors and walls were teached to "behave" and not to this behavior anymore (Problem only happened in the GL4ES Renderer, but now it is fixed).

If I got it right for the OpenSource version the original authors did some experiments with Shaders and other efffects which were not in the retail version (the GLES version says something on Shaders used on Startup, and there is some (optional) shader-reliant source-code in there).

The new version (Beta11) will still be looking better, as some graphics bugs will be fixed. There is still one graphics bug left (only in GL4ES version) which I will try to fix still.

After that only Betatesting is left. I will do a few weeks (probably, we have to see how it goes) of Betatesting here like with my commercial releases. Several people already contacted me, to be able to take part in the Betatesting.

From the available information I do not feel it was fearmongering.
Of course I might have been wrong on my assessment of the risk.

I also did not want to badword your great work - I just felt you did go into quite a risk and should warn about this. I admit the discussion went a bit out of hand.

As to Wipeout rewrite I was not aware until you told me it was a similar situation. But probably the thing is that in this case the ID Holders really don't care for it any longer (still myselves I would not touch it, but that's because I do porting of commercial titles myselves).

I found it BTW great you shared your fixes with smarkusg, even though this is probably "more stuff not allowed"

And I sincerely hope that nothing bad will happen due to the MorphOS version release.

I personally (!) think the way smarkusg handles it is fine though - he did a compile for himselves and did not release it to the public.

Personally I think they really should OpenSource this old title and get this whole discussions on many platforms done and over with. I am sure this issue does not only exist for AmigaOS and MorphOS...

@walkero

The glow came from a settings in the ini file incompatible
with our GL4ES implementation (in MiniGL Version it did
not happen).

I now adapted the installer (changed the default settings
file) which fixed the issue in the GL4ES renderer.

Best regards,
Steffen

https://www.youtube.com/watch?v=5VzPmPZhJ1Q

This is the GL4ES renderer

Engine only release

Only serious Sam Classic The First encounter and
The second encounter supported. No idea if this package
with the Enhanced Engine uses the same datafiles.

Principially cdrom/steam/Gog Version are supported,‘
featuring an installer where you can directly install the
Game without needing a preinstall. Myselves I used the
old CD, one Tester uses steam, another Tester Gog Version.


The second encounter does not run yet but I hope to
get second encounter running today ;)

What Are your configs? On x1000 it runs absolutely smooth.

I got the Full Version (not only Demo Version) of first
Encounter Running ;) second encounter not yet..

Working on bugs. Thanks to Marek on help with
the cmake Crap ;)

Hi!

After the AmigaOS4 and the MorphOS version I now also released RetroArch for WarpOS. It is found on Aminet in misc/emu/RetroArchWOS.lha. There is a second archive with additional Cores.

MagicSN

Thanks for your comments (and screenshots). I wrote you a private message today on here

@BSzili

Possibly I was overthinking it, and SDL2 would have been able to produce the symbols which I extracted from the static library with my changed code then.

Right now I got the problem that

_pFileSystem->GetExecutablePath(strExePath, sizeof (strExePath)-1); (EDIT: This problem fixed, a remainder from Linux version - now it fails at " LoadStringVar(CTString("DefaultMod.txt"), _fnmMod);" - I do not see a DefaultMod.txt file also, maybe an issue of my game installation ? )

returns null (maybe using PLATFORM_LINUX was not the best idea, and I should have set up a real PLATFORM_AMIGA there). And I think I have still similar issues in other locations. Right now debugging what goes on there.

Best regards,
Steffen

@smarkusg

How did you handle the GL Stuff ? Myselves I did a (because the version from the github loads the gl functions dynamically and on OS4 we have it statically), did you do this similar, or different ?

static void OGL_SetFunctionPointers_t(HINSTANCE /*hiOGL*/)
{
const char *strName;

#if defined(__amigaos4__) && defined(AMIGA_STATIC_GL)
/*
On AmigaOS we link GL, so:
- for REQUIRED entries, bind to the (possibly remapped) linked symbol;
- for OPTIONAL entries, leave the pointer NULL (don’t take &name).
*/
#define DLLFUNCTION(dll, output, name, inputs, params, required) \
do { \
if (required) { \
p##name = (output (*) inputs) &name; \
if (p##name == NULL) FailFunction_t(#name); \
} else { \
p##name = NULL; \
} \
} while (0)
#else
/* Default (ELF) path: resolve through SDL. */
#define DLLFUNCTION(dll, output, name, inputs, params, required) \
do { \
strName = #name; \
p##name = (output (*) inputs) SDL_GL_GetProcAddress(strName); \
if ((required) && (p##name == NULL)) FailFunction_t(strName); \
} while (0)
#endif

/* If building for MiniGL, you can optionally ask gl_functions.h to skip 3D texture entries.
(Only needed if those entries were ever marked REQUIRED there.) */
#if defined(__amigaos4__) && defined(USEMINIGL)
#ifndef GL_FUNCTIONS_SKIP_TEX3D
#define GL_FUNCTIONS_SKIP_TEX3D 1
#endif
#endif

#include "Engine/Graphics/gl_functions.h"
#undef DLLFUNCTION
}

for the GL function pointers, I hope this works (I am now basically at the point where I need to install the game and test, everything compiles and links).

Also how do we continue from here ? Not that we in the end do two OS4 ports ^^

My own idea would be to do this like I did for OpenMohaa (while this was not ported by me), complete with installer which installs directly from the PC version, nice icons and everything.

My question is if you plan to continue or if this was just a quick try.

I will probably do a test today, if it works.

Did you do with GL4ES or MiniGL BTW ? I used GL4ES (didn't get MiniGL working yet, but the plan was to look into a alternate MiniGL version later - MiniGL having some problems with variable type clashes, while on GL4ES it compiles directly).

Best regards,
Steffen