Click Here
home features news forums classifieds faqs links search
6072 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
60 crawler(s) on-line.
 22 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 Gunnar:  24 mins ago
 adrianebrown:  29 mins ago
 pixie:  35 mins ago
 amigakit:  41 mins ago
 Karlos:  44 mins ago
 Hammer:  1 hr 38 mins ago
 michalsc:  2 hrs 16 mins ago
 cdimauro:  2 hrs 50 mins ago
 retrofaza:  3 hrs 14 mins ago
 MEGA_RJ_MICAL:  3 hrs 41 mins ago

/  Forum Index
   /  MiniGL
      /  MiniGL and GL4ES Support in Parallel
Register To Post

PosterThread
MagicSN 
MiniGL and GL4ES Support in Parallel
Posted on 15-Jan-2023 17:49:48
#1 ]
Hyperion
Joined: 10-Mar-2003
Posts: 662
From: Unknown

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



 Status: Offline
Profile     Report this post  
pavlor 
Re: MiniGL and GL4ES Support in Parallel
Posted on 16-Jan-2023 17:21:37
#2 ]
Elite Member
Joined: 10-Jul-2005
Posts: 9568
From: Unknown

@MagicSN

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

 Status: Offline
Profile     Report this post  
MagicSN 
Re: MiniGL and GL4ES Support in Parallel
Posted on 19-Jan-2023 13:10:10
#3 ]
Hyperion
Joined: 10-Mar-2003
Posts: 662
From: Unknown

@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.

 Status: Offline
Profile     Report this post  

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle