@AmigaMark: base clock. How much faster it is on
overclock I have no Numbers yet (soon). Also working
on optimizations.

If it is a cm4 it Runs playable on that already.
Donate 10 eur to tirionareonwe@gmail.com on Paypal and
get access to the Beta ;)

while roundup is probably only for released software - there has been a lot of development on Dungeonkeeper for OS4 end of April ^^

OS4 version is in Beta stage. It seems to run great so far.

Donation to PayPal -> Beta Version.

For 68k Version I *hope* a rewrite to SDL1 will bring enough speed to make it viable (we will see if this is success).

Hi!

My latest project reached Beta stage for AmigaOS 4.

It is Dungeonkeeper (note this is independent from Papiosaur's great efforts to port Dungeonkeeper to MorphOS, we did not share source code so far - I like the GUI he did for his port ^^).

Asides from the OS4 version I try to make a 68k version (currently Pre-Alpha, it "runs" but so slow that not even on a beefy i7 in UAE it is playable, on PiStorm it does not run good enough).

Current efforts:

1) Currently my port is based on an "in-between" Commit on the Alpha Version which is annoying for installation and basically prevents a good installer. I am focusing right now on porting my changes back to the stable version (1.3.2). Might even be I get that done today. I will also write an installer then.
2) In parallel I work on an AROS 64 Bit version which probably will see it's first test today (again based on that in-between version)
3) Once steps 1+2 are done, the plan is to port the SDL2 to SDL1. This hopefully should make the 68k version playable. This will also make the game run in 8 Bit (in SDL2 it is "8 Bit but converted to 32 Bit on-the-fly" - worst-case-scenario for 68k ^^). Note this is NOT a trivial step.
4) Once step 3 is done the plan is to remove OpenAL and replace it with SDL1 or - more likely - magicsystem. This is NOT a trivial step. According to the authors of the PC version this should also reduce the memory footprint. Currently we are beyond 900 MB RAM. They think it should reduce it to 512 MB, with some luck to 256 MB RAM. Lower than 256 MB RAM will be impossible, so while it might be possible to get an AGA version with step 3, most AGA systems will still be locked out (independent of performance) due to memory requirements.

MagicSN

There is still some stuff to do though. A lot of stuff actually ... but as you can see progress is now faster after the principial issues sort of are cleared up. Many of them anyways.

In meantime the triangles are not only colored, but fully textured. So next step done (of course there is still a lot to be done).

https://www.indiegogo.com/en/projects/ ... em_CgYqM6DudRlYjS1EALGJuQ

Hi!

The PiStorm 3D Project (Crowdfunded) shows first results.

An example program using the current version of the PiStorm 3D Library draws a rotating colored triangle into an Intuition Screen now.

https://discord.com/channels/784428461 ... 86513/1481730628960649397

The reason why all takes so long is that only the 3D Chip of the Pi3 is publicly documented, for the Chip of the Pi4 all information has to get taken from Mesa3D Driver Source Code and similar sources. No real documentation exists. At least not available for Amiga-related people.

But now as the most tricky stuff ("how to get something displayed, how to get the shader stuff running") is done I expect progress comes much faster.

Next step will be finding out how to texture.

Best regards,
Steffen

@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