It also supports gl4es which at least
Amigas with RadeonHD and RadeonRX
have available;)

Maybe i have a look at it sometimes. But still
busy with H2 right now.

Currently:

- Heretic 2

Lots of detail work with tiny issues, mostly to do with
installer and localization.

- Secret project

Waiting on licence negotiations as soon as there is
a signature betatest will start the same day

- Quake 2 update

On hold for now, will start again once H2 is finished, there is
a limit on how many projects when this is not the
main job anymore

@Capehill

>IExec and IDos is already opened for normal programs, if writing >real Amiga libraries you need to open the libs, as then the normal >startup code is not called.

As to IExec this is only true for normal executables.

For .so Libraries this is not true. So it is a good idea if a linker library using AmigaOS functions initializes IExec so it can be used inside a .so library without having to recompile the linkerlib with an "adaption" (this is what I did to get gl4es running with the Heretic 2 Renderer for example - modifying the gl4es source code to initialize IExec correctly - of course I also gave my changes back to the project and they integrated it).

IDOS has no such issue though. It is only for IExec where this problem exists.

Steffen

BTW - anyone knows if there was ever a french and spanish version of H2 on PC which included native language samples ? Or only localized intro/outro video and subtitles ingame ? (Those I have, as well as the "whole deal" for German, Italian, Russian and english).

Did anyone compare those new 68k/68kEmu things (PiStorm, Vampire) to a decent PPC setup this way ?

Hi!

address 4 is still a thing.

And if you are doing stuff with libdl.a and calling AmigaOS functions from inside a so library you have to do

IExec = (struct ExecIFace *)(*(struct ExecBase **)4)->MainInterface;

for it to work. Here you see the address 4 (You don't need this if you are doing a normal exe).

Best regards,
Steffen

Currently doing another Mame port is not something I would consider. I have enough projects running right now. In the future it might be possible, but more like something like "somewhen late 2023" than in any immediate future. If I do it.

And if I do it it would definitely not been a simple recompile of old sources (and would be adapted to recent Mame sources).

@Reynolds

As I said, this opinion "The more setups supported, the better for all of us." is exactly the reason for my post.

Remember we have some boards only supported by MiniGL, and if someone does not have NovaBridge on the new systems he can only run GL4ES.

As I explained it is easy to support both (if directly using ogles2.library this is not an option of course, or if needing shaders or multitexturing).

None of my current projects has such requirements. They all run with both. And I think some projects which currently only support MiniGL could easily be updated to also support GL4ES.

@Reynolds

You misunderstood my post. My point was not to
stop supporting MiniGL, my post was that it is easy
to support both. I described only the gl4es changes
as i assume 3d developers will already know how to do
it with MiniGL. It is maybe extra effort of 1h to support
both (unless you need special features only one of them
offer - direct control of the 3d state machine which only
MiniGL offers or shaders or multitexturing which only gl4es offers.

My point was „why only support one if it is easy to
support more hardware?“

My assumption was it was due to many developers
not knowing HOW.

At the shortness of my tutorial you see how easy it
actually is.

You might have wondered that you did not hear what's going on about Heretic 2 OS4 anymore.

I fixed a lot of bugs and our issue list is now down to 4 items. I won't disclose what but most of it is minor items.

I was mainly busy with some issues with the savegames lately. OS4 is not as forgiven with faulty pointers as OS 3.x was (the whole savegame code was in the original PC code written very "Amiga unfriendly" using things which is true on PC - but only on PC, having to do with memory handling).

Anyways, this sort of stuff should be fixed now, but it REALLY held up Betatest (as long as you cannot use savegames, you cannot betatest much...). So I made it an absolute priority to fix this bug.

I think this will be the best gameport I have ever written!

Also performance optimizations. On my x1000 with RadeonHD7770 in 1920x1080 it still runs pretty smooth (GL4ES Renderer used for this test, with enabled Multitexturing).

Ah, and *S*ecret project was the first time tested also on MiniGL Renderer successfully. Not only GL4ES as before. Runs in both absolutely smooth.

Hi!

As I now did three ports (not yet finished) with support for both MiniGL and GL4ES I thought I write a small tutorial of how to support both.

I often see ports which only support one - the extra work to support the second is really MINIMAL.

Step 1: Preparations

Sadly both use the include path GL. I fixed this by changing the GL/ from MiniGL into GL2/. Of course then also the includes inside the MiniGL Includes - and in your game or demo - need to be adapted. You still need two source paths, but to a large part the main difference is that you include GL/GL.h for GL4ES and GL2/GL.h for MiniGL. I think I had to rename one lib file too, not sure anymore.

Step 2: Actual coding

The actual source difference asides from GL path are minimal. Basically is

- How to init opening a display
- How to close display
- How to doublebuffer
- and some other minor differences

On MiniGL there are probably enough tutorials (but if you do not know how to do it from MiniGL side, feel free to ask), so I mainly focus on the GL4ES side here.

Open a display:

(Assuming you already have a standard intuition Window open, with the variable name window (this example uses a 16 Bit Color screen).

struct TagItem contextparams[] =
{
{OGLES2_CCT_WINDOW,(ULONG)window},
{OGLES2_CCT_DEPTH,16},
{OGLES2_CCT_STENCIL,8},
{OGLES2_CCT_VSYNC,0},
{OGLES2_CCT_SINGLE_GET_ERROR_MODE,1},
{OGLES2_CCT_RESIZE_VIEWPORT, TRUE},
{TAG_DONE,0}
};

ogles_context = IOGLES2->aglCreateContext2(&errCode,contextparams);
if (!ogles_context)
{
closeWindow();
return false;
}
IOGLES2->aglMakeCurrent(ogles_context);

glViewport(0,0, 500, 500);

This completely REPLACES the MiniGL part of creating a miniGL Context or whatever. You still need to open ogles2.library before you call this codepiece.

Closing (the method closeWindow above) should do:

IOGLES2->aglDestroyContext(ogles_context);
ogles_context = 0;

and then close the Window and screen etc.

Screen Refresh now looks like this:

IOGLES2->aglSwapBuffers();

A lot of the stuff MiniGL does here you simply DO NOT NEED. Just one call is needed.

Other minor differences:

- Where you had glBegin(MGL_FLATFAN); for MiniGL you write glBegin(GL_QUADS); for GL4ES.
- Remove mglUnlockDisplay/mglLockDisplay for GL4ES
- MGL_PERSPECTIVE_MAPPING stuff - remove it and hope your code still looks good A range of other "changes to the state-machine" also is not supported by GL4ES, but most games/demos should not need them anyways.

If possible do as many stuff as possible inside one big GL_QUADS. If not, it still should be fast (or possibly FASTER) even if you do not optimize here.

This is ALL.

And if you say "I do not have the hardware to run it" - I wrote the GL4ES Renderer for Quake 2 when I did not yet have fitting 3D Hardware. Just sent it off to a Betatester then and he confirmed it works

Note on GL4ES you have a range of extensions you did not have on MiniGL (Multitexturing for example).

Personally I think both should be supported for any new Amiga Game/Demo using 3D Hardware. It is not so hard to do. And there are systems which only support MiniGL and there are systems only supporting GL4ES (also GL4ES has big advantages).

If anyone still got questions, feel free to email me at tirionareonwe@gmail.com

Steffen "MagicSN" Haeuser

Personally I would expect it somewhat in the middle between the two benchmarks. I think the Graphics Board plays a huge role for this game.

GL4ES Renderer 640x480: 74.5 fps.

Software Renderer 1920x1080: 9.9 fps.

Beides wieder auf dem x1000.

Okay, software renderer 640x480 is 39.5 fps on the x1000.

Yes, that was the timedemo I used. Wow, if I look at the speeds of these old systems...

to be comparable I do a round in 640x480, and also one in software renderer still.

The timings were the timedemo one (so the upper table), not the timerefresh one.

Timedemo results with x1000 with RadeonHD 7770 (multitexturing enabled gl4es Version): 67.4 fps

Needed one Arkadiusz Hucko to talk me into it

Fairly said though before I had too many projects with overhour work at the job to have time left for Amiga. Might happen again. Still, 5 days per week homeoffice helps (before "Covid-Time" when this was not possible I was over 1.5h on the road per day, can do some Amiga stuff in that time, now I need rarely to go to the office).

Some added progress:

In the meanwhile the gl4es renderer got Multitexturing support added, that gave the gl4es Renderer around 20% speedup compared to the MiniGL Renderer. MiniGL Renderer seems to run in similar speed to the WarpOS version of the game running.

Numbers I got of my "x5000 with a heavy beast of a 3D Card equipped Betatester" was 118 fps timedemo for MiniGL, 130 fps for gl4es renderer without Multitexturing, 140 fps with multitexturing (but that was not yet having multitexturing included everywhere where it could, the final version probably still will have a few fps speedup comparing to those 140 fps). On my own x1000 with RadeonHD I do not reach these numbers, but it is extremely smoothly running on this system too.

In the meanwhile also all three renderers (software, MiniGL and GL4ES) run in both fullscreen and Windowed mode.

And it seems I found one of the major elusive bugs just a few minutes ago.

Still a few more bugs to hunt though.

Was this the WarpTGEmu I did ages ago ? Or a different port ?

If it was my port I might have a look eventually (But as samo wrote the "author left Amiga" - he knows I am back - I suspect it is about a different port).

And definitely any work on Emulators by me would have to wait till H2 and Q2 Update and *S*ecret 3D Game are finished. Don't want to split up myselves too much

Hi!

BTW - I just got the gl4es renderer running

It is still more or less an Alpha Version of the gl4es renderer, but the rest of it should not be that much of a problem.

Best regards,
Steffen