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

@MagicSN

Nice! As Pegasos 2 user I really appreciate ports for older GFX drivers.

@pavlor

It depends of course on the titles. For nearly (!) everything
available on Amiga today shaders are not required and
source-code is done in a way that it can be with minimal
changes adapted to both MiniGL or GL4ES.

Newer titles on PC on the other hand would require
shaders so MiniGL would be not enough (anything
„Beyond Quake 3“).

Source code which has been directly implemented on
ogles2.library also would be hard to impossible to adapt.

My current titles all use GL in a way compatible to
both MiniGL and GL4ES and i have both renderers
running for all my 3 current Amiga projects.

And writing one renderer when i have the other already
was - minimal work only.