Just was able to write it to Hans in answer on aw.net in comments about Polaris cards, but assume it can be interesting for everyone, and worth to note as another topic.
So .. We do have now only OpenGLES2, and do not have full OpenGL, which mean in most cases we can't port most of stuff, by any of reassons (smartfones and tablets all the time use java, all kind of bytecodes, modern c++11 threads and all other deps which we most of time didn't have).
But even on those smartfones and tablets developers have hard times when want to port legacy OpenGL stuff to, as they offten have only OpenGLES2, so that problem is not only our ones.
Lately, seeing what to port and how to make use of all this, i found that Emscripten, is the platform which we can consider as they also have only GLES2, and seems popular enough, and what they try to do, we, can try to do as well by following their routes.
Searching on the words like "OpenGL on Emscripten" , or "Legacy OpenGL on Emscripten" give us some threads where ppls discuss how they try to use that Regal on their os , so to mimic legacy OpenGL over OpenGLES2. For example:
Through, Regal do not see lately much updating. Seems its kind of undeveloped anymore, and it also seems unfinished. You may check those links above, key parts from them are :
You can consider building the codebase against the Regal Desktop OpenGL emulation library, which aims to support Desktop OpenGL features on top of OpenGL ES 2.0. This may work better or worse than Emscripten’s GL emulation depending on the project.
Sad to see about the Regal nonsupported features though, perhaps it's not that complete as we thought
From that we can read there , we can't expect FULL-BLOWN-BUG-FREE-OGLES2-OGL layer. But, it still can works in some forms, which can be better than nothing, and (maybe) it will be easy to fix regal in some parts, than wrote from scratch whole OpenGL (what no one will do, of course, sadly).
By idea , all what you need , is build libregal.a (or libregal.so, if shared version is need it), and in your pure OpenGL-Legacy code, replace #include <GL/gl.h> on #include <GL/Regal.h> , then just on linking stage add -llibregal, and all your GL calls will be replaced by necessary GLES2 calls.
Reading links above , you may find that it still will need some changes in code, like adding after window creation RegalMakeCurrent((RegalSystemContext)1);, but, if it only that, and all will works : that no problem, of course. Through as you can see from test in avove link, its still possible it will draw nothing, and you will have needs to invistigate how uncomplite and unfinished that all.
But anyway, for sake of interest i downloaded their repo and have a brief look on.
PART 2: Brief Look
For first, whole project structured well. It has bunch of different makefiles need it for all platforms (about 20 supported: linuxes, mobiles, windows, darwin (macos), cygwin, emscripten, etc). They all placed in the $root/config/ directory. Those makefiles which in the $root, are common makefiles for project, which take necessary platform specific makefile from $root/config/ when we specify one, like:
make SYSTEM=amigaos4 V=1
and then $root/config/Makefile.amigaos4 will be taken. So, that easy part: no big needs to tinker with.
Whole library builds by parts (modules): in $root/src/ directory you have bunch of directories, which is builds one by one, and writen as independent *.a in build process, which, when finished, will make from all of the libregal.a. Objects of modules compiles to the $root/tmp/ directory, and once one done, it is writen to the $root/lib/ as lib*.a
If you take a look at the Makefile in the root (main one), then you will see there:
Quote:
include build/common.inc
include Makefile.zlib include Makefile.libpng include Makefile.snappy include Makefile.apitrace include Makefile.glsloptlib include Makefile.pcrelib include Makefile.regal include Makefile.regalw include Makefile.glu include Makefile.glut include Makefile.glew include Makefile.glewinfo
# Examples
include Makefile.dreamtorus include Makefile.dreamtorus_static include Makefile.alphatorus include Makefile.tiger include Makefile.nacl
# Testing
include Makefile.gtest include Makefile.regaltest
# Misc
# include Makefile.expat
As you can see we will first build libzlib.a, then libpng.a, then all others and once all done, it will be just linked together to have one libregal.a (or .so, does not matter, but for first tests static is better of course).
Another good thing, is that whole source code can be compiled fine with our old GCC as well (i.e. 4.x is fine).
PART 3: AmigaOS4
--1: start compilation
Firstly, we create Makefile.amigaos4 in the $root/config/ directory. For first brief check i just make a copy of Makefile.emscripten , where i replace all CC, CXX, AR and LD things on necessary amigaos4 ones. So, now we can go to the $root, and do : make SYSTEM=amigaos4 V=1
Compilation of objects will start then.
--2: posix errors
Once first few modules compiles (easy ones, libpng, libzlib, libsnappy), it fail on apitrace module. Necessary makefile for that module placed in the $root/build/apitrace.inc. You can see there all objects which want to be compiled, and the failing one is $root/src/apitrace/common/os_posix.cpp
It fails because of "fork(), execvp(), siginfo_t, SA_SIGINFO, SA_RESTART", i.e. usuall unix stuff. Through, as you may see in the file above, there is bunch of platforms supported: win32, linux, apple, android) and functions in charge are:
So, one may try to add aos4 replacements , as that part is critical for sure (module called apitrace all in all).
--3: if skip that error
Then, if we just comment out os_posix object from needs to be compiled, then we meet with new errors about EGL from $root/src/apitrace/helpers/eglsize.cpp.
To start about from begining, EGL from Huno currently WIP, so some functions didn't work, some works, and its not "straigh away" recompile of EGL apps, so for this kind of big job, that no go at moment.
Apitrace module have that eglsize.cpp object to build as common for everything.
EDIT: found that EGL is used only for apitrace module, and that one can be skipped, see next messages.
Edited by kas1e on 2018/2/10 8:47:29 Edited by kas1e on 2018/2/10 8:48:09
@Hans I checked apitrace module more close, and its not just module, but 3d party app: Web page GitHub page.
Readme show that its pretty interesting tools for tracing all kind of GL/GLES/etc calls to a file, inspect state, view all in realtime (so GUI, that why it ask or EGL), etc.
Checked Regal source code, and that apitrace uses a lot internally (search for word "trace" in the src/regal/ directory). But it also seems that tracing can be disabled in configs, as well as there is "define REGAL_TRACE 0" can be set, which taken in account. But how good (or bad) Regal will be without tracing : dunno. Probably not important for us.
For sake of tests, i disable building of apitrace fully and make sure that have everywhere #define REGAL_TRACE 0.
Then another modules builds fine such as:
libglslopt.a libpcre.a (those are GLSL optimizer build in)
And then, when time come to build regal.a ($root/src/regal), then, it again trying to build apitrace (and so, give EGL errors again) as $root/Makefile.regal have that:
Quote:
ifdef REGAL.STATIC
include Makefile.apitrace include Makefile.libpng include Makefile.glsloptlib include Makefile.pcrelib
I comment apitrace build there as well, and next error come from $root/src/regal/RegalUtil.h about X11/Xlib.h not found :) So, i had to add -DREGAL_SYS_X11=0 to Makefile.amigaos4, and compilation goin next.
Then error about "endian.h" not found from $src/glsl/src/mesa/main/compiler.h. Of course that not whole mesa used there, just some files from, probably as support ones or something. So i just set in that file #define MESA_BIG_ENDIAN 1 instead of including endian.h, and all going well next.
Good news is that all "big" .cpp from $root/src/regal/ compiles without errors. And some files from it are REALLY big, tak a look:
Regal.cpp - 2.2mb of size RegalDispatchCode.cpp - 2.4mb of size RegalDispatchDebug.cpp - 1.1mb of size RegalDispatchEmu.cpp - 1.5mb of size RegalDispatcherError.cpp - 2.6mb of size RegalDispatchHttp.cpp - 2mb of size RegalDispatchLoader.cpp - 1.5mb of size RegalDispatchLog.cpp - 1.6mb of size RegalDispatchMissing.cpp - 1mb of size RegalDispatchStatistic.cpp - 1.6mb of size RegalDispatchTrace.cpp - 1.7mb of size RegalPlugin.cpp - 1.6mb of size
Probably lots of them we not need , like http one (probably for webgl), trace one (for tracing) , plugin one , and dunno what else.
Next error come from $root/src/civetweb/civetweb.c about sys/poll.h stuff. Civetweb is also 3d party tool, which aims to provide easy to use, powerful, C/C++ embeddable web server with optional CGI, SSL and Lua support. So, for us it didn't need it as well , so i disable it out in the $root/Makefile.regal
Then, libregal.a compiles, glut,glew,glex, wrangler, etc that all i disable at moment.
So ! Then tryed some simple test case:
Quote:
#include <GL/gl.h>
int main()
{ glBegin( GL_TRIANGLE_STRIP ); glEnd(); }
$ ppc-amigaos-g++ test.c -lGL
So it builds over our MiniGL, all right there.
Then ! I just replace <GL/gl.h> on <GL/Regal.h> , and :
2. When we link it : GL calls replaced by Regal ones, and as can be seen from link_errors, undefined symbols come from RegalDispatchStaticES2.cpp -> that mean its about to do what we need to do.
Probably undefined references can be fixed by just adding -lGLES2, but current Ogles SDK didn't have *.a stub, and i need manually open ogles library , probably somewhere in that RegalDispatchStaticES2.cpp. Through i tryied a little to hack there and there, but that didn't help, as it all different name spaces all around , so better to just have libgles2.a , and add -lgles2 on linking stage.
Long story short : Its all can be done more or less easyly, then. If it will be taken by any skilled developer who know even a bit of 3d code and os4, then probably few days of work and it can be done.
I can provide help and even pay from my own 200-300$ if someone will make it works.
Edited by kas1e on 2018/2/9 22:15:27 Edited by kas1e on 2018/2/9 22:16:41
Nice progress. Yes, the linker errors are because it needs to be linked to some kind of GLES2 *.a stub. Such a stub would have to automatically open the ogles2.library too.
@Hans Most important that at least in what i have now, all GL functions transfered to GLES2 ones. At least if glBeing/glEnd "eats" fine by Regal.h, and libregal.a want all those gles2 calls, then its right route from begining, and all boring work with makefiles and stuff undestandable and done.
Quote:
Yes, the linker errors are because it needs to be linked to some kind of GLES2 *.a stub. Such a stub would have to automatically open the ogles2.library too.
I wrote to Daniel few days ago about needs for libgles2.a , as it not only help to not open library manually, but also provide stubs and just make things easy, and he say he will do it all asap.
If it only was about opening a library, i can do so in regal itself, but linker stubs still bit of code, so better to have libgles2.a done. For Daniel its only need to use fdtrans/idltool to generate libgles2.a from .xml or .sfd.
@All Is it possible from only includes and interface file (*.i), create automaticaly by fd2pragma/idltool/fdtrans a lib.a with all necessary stuff ?
I know how to make it all when i have .sfd, .fd or .xml , but dunno if i can create anything of that sort from pure .h and .i files to avoid manual typing ?
@Hans In meantime found how in 2012 one man port Regal to the NaCl. Process described not very deep, but a bit of info present. In general he explain that indeed everything can be disabled out via swithches in command line (logging, tracing, debugging, anything). Some pictures how core works, how Regal works, and in whole it all looks positive enough, like it can do "everyhing we need".
Now, theoretically , i need to create very simple test case, which will draw triangle via GL1.x calls, but will not use any GLUT/GLES or SDL stuff, pure amigaos window and render to it.
Then, once it will works via -lGL (so minigl), i then will just replcae it on regal, and -lgles2. And, if it will renders, that mean Regal did the job, if not - then.. then as usuall :)
PS. If anyone have some source of example which draw triangle via minigl, but without GLUT / SDL / whatever, just pure amigaos window, etc. That will help for fast check.
@Hans I must have misunderstood he said he need without SDL/GLUT a simple window which MiniGL takes care of. I could create my own window but you wouldn't gain much as you would attach context to bitmap but you still need MiniGL. There is no raw OpenGL context example for Amiga as that does not exist.
@Kasie do you need a OpenGLES context for this library to use. Let me read this library a bit more and see how its supposed to glue to OpenGLES.
I am very interested in a solution that can easily port OpenGL 1.X and am willing to invest the time in make something like this work.
Ok I did a quick read through this entire thread and a quick look at the Regal source specifically regarding the context.
First off there is no standard for setting up a OpenGL context. I am familiar with Windows,Linux and OSX and all of them are platform specific(some easier than others). Based upon kas1e's defines for his build he is having Regal believe it is X11. I misunderstood and thought that had been solved with a minigl context he wrote.
So if our OpenGLES mimics X11 it should in theory work or at least be not bad to finish. I did see some references to C++11 threads and I am not sure how mature our thread lib is but there is probably some risk there. To get this to work I think this library is going to require Amiga specific modifications. I am not seeing good abstraction of system dependencies at first glance but it might not be too bad. It should be around defining a context.
I have been working on a port that had a abstract graphics API that i whipped up to MiniGL as it was easy almost done and I was about to start a Nova driver. Maybe when I finish my MiniGL stuff I can put together a OpenGL context and glue this together instead but this is probably multi-month project. The Nova would be better for my use case and probably easier but I can see the community valuing the OpenGL more. I just suffer from what all Amiga programmers do which is not enough time.
@Hans Example from DStastny is ok, it have glBegin/glEnd, and make all in minimal for minigl.
@Hans & DStastny Now,what i will try to do, its just replace in that example MiniGL specific functions , on OGLES amiga specific functions, i.e. instead of :
Instead of mglSwitchDisplay(), it will be ogles's aglSwapBuffers(); And mglGetWindowHandle() probably don't need, as with aglCreateContextTags() i should specify already opened window.
@DStastny I think you are wrong about X11 as necessarity. I build everything without it, and its only one of ways of render things. Regal by itself didn't create any context (that right), its instead just traslate one calls to another ones, but its programmer should create context he need (by amiga native api, by X11, by WGL, by EGL, by GLUT, by SDL, does not matter). Just in our case that simple test case rewriten on OpenGLES , but with keeping OpenGL 1.x calls will help to see if Regal translate that simple thing at all. And if so, then good.
As for c++11 threads : i do not know, i didn't see anything about, and all compiles already with gcc4.x on os4, which didn't have c++11 even enabled. And , even, and if, some module (maybe apitrace ?) want it, its easyly disabled as regal have
Quote:
-DREGAL_NO_TLS=0 # 1 for single threaded
Add to that, that Regal works on things which didn't have X11 at all.
Our main hope, is that Regal internally translate ogl1/2/3/4 calls more or less fine to ogles calls. How it all render in end not big problem, context can be any.
When you dont use Glut you must use (have) an Os specific function for creating a context It is called AROSMesaCreateContext on Aros wglCreateContext on Windows glXCreateContext on X
So seek in sources how is done wglCreateContext or better glXCreateContext to make an aglCreateContext for Amiga
@Theiler Yes, exactly. In Minigl we have mgl* calls for creating context : mglCreateContext(); In Ogles2 we have agl* specific calls for creating context: aglCreateContext();
All other stuff like glut, mesa, wgl, glx, does not matter for us at moment, as Ogles2 already provide amiga specific fucntions to create context.
@all So, i change provided test case above to the OGLES2 version, just keep render part OGL one (that what we want to check all in all), and only add clear of background by another color in render part , so to see how it works: glClearColor(0.5f, 0.3f, 1.0f, 0.4f);
At first run, it didn't crashes, but show me empty window. So, i had to add RegalMakeCurrent((RegalSystemContext)1); after context creation, as guys do on Emscripten (see it in the code above already).
Then.. Then, i don't see triangle, but i can see my blue background.
See screenshot (press open in other tab for full size). First window are minigl one (with triangle), second one, compiled with Regal, over gles2, with the same render calls as in minigl version (i.e. gles2 based source code above):
All of this mean that:
1). We didn't crash. Regal doing something already, and even function like RegalMakeCurrent() works.
2). As far as i see, the same functions which present and in OGL and in OGLES2 just works as it. I mean that if we will take a look at the Regal's RegalDispatchStaticES2.cpp, then at end of file, we can see how all functions "dispatches". But that to be checked.
3). But our lovely glBegin/glEnd combo to draw triangle didn't works, but we need exactly that, to be sure that it all start to works for real.
I see regal have some "logging" facility, will check this out, maybe will be possible to doing something with it. At moment just can see switches which enable it to build inside of library, but how to enable it later in the programm itself: dunno at moment.
PS. Any ideas welcome. Maybe there is some other "simple" functions which we can check, which present in full opengl , but didn't in ogles2 (i.e. something without glBegin/glEnd, so to see if conversion between done at all, or only the same calls works).
because RegalMakeCurrent((RegalSystemContext)1); seems to be used to recover a glut context
I don't use GLUT at all, as well as i build Regal without GLUT too. At moment its pure Regal library, without anything else like glut or glew or egl. By that reassons i use native amigaos api, to avoid all of this.
@All
I was able to enable some simple logging for now. Its just inbuilds into the binary, and prinfs when you run it, so that what we have currently:
Quote:
info | REGAL_LOG enabled info | REGAL_LOG_ERROR enabled info | REGAL_LOG_WARNING enabled info | REGAL_LOG_INFO enabled info | REGAL_LOG_APP disabled info | REGAL_LOG_DRIVER disabled info | REGAL_LOG_INTERNAL disabled info | REGAL_LOG_HTTP enabled info | REGAL_LOG_JSON disabled info | REGAL_LOG_CALLBACK enabled info | REGAL_LOG_ONCE enabled info | REGAL_LOG_POINTERS enabled info | REGAL_LOG_THREAD disabled info | REGAL_LOG_PROCESS disabled info | REGAL_FRAME_TIME disabled info | REGAL_FRAME_STATISTICS disabled info | REGAL_FORCE_ES2_PROFILE disabled info | REGAL_FORCE_CORE_PROFILE disabled info | REGAL_SYS_ES2 enabled info | REGAL_SYS_GL enabled info | REGAL_FORCE_EMULATION disabled info | REGAL_DEBUG disabled info | REGAL_ERROR disabled info | REGAL_EMULATION enabled info | REGAL_LOG enabled info | REGAL_DRIVER enabled info | REGAL_MISSING disabled info | REGAL_EMU_HINT enabled info | REGAL_EMU_PPA enabled info | REGAL_EMU_PPCA enabled info | REGAL_EMU_OBJ enabled info | REGAL_EMU_BIN enabled info | REGAL_EMU_TEXSTO enabled info | REGAL_EMU_XFER enabled info | REGAL_EMU_DSA enabled info | REGAL_EMU_PATH disabled info | REGAL_EMU_RECT enabled info | REGAL_EMU_BASEVERTEX enabled info | REGAL_EMU_IFF enabled info | REGAL_EMU_QUADS enabled info | REGAL_EMU_SO enabled info | REGAL_EMU_VAO enabled info | REGAL_EMU_FILTER enabled info | REGAL_EMU_TEXC disabled info | REGAL_FORCE_EMU_HINT disabled info | REGAL_FORCE_EMU_PPA disabled info | REGAL_FORCE_EMU_PPCA disabled info | REGAL_FORCE_EMU_OBJ disabled info | REGAL_FORCE_EMU_BIN disabled info | REGAL_FORCE_EMU_TEXSTO disabled info | REGAL_FORCE_EMU_XFER disabled info | REGAL_FORCE_EMU_DSA disabled info | REGAL_FORCE_EMU_PATH disabled info | REGAL_FORCE_EMU_RECT disabled info | REGAL_FORCE_EMU_BASEVERTEXdisabled info | REGAL_FORCE_EMU_IFF disabled info | REGAL_FORCE_EMU_QUADS disabled info | REGAL_FORCE_EMU_SO disabled info | REGAL_FORCE_EMU_VAO disabled info | REGAL_FORCE_EMU_FILTER disabled info | REGAL_FORCE_EMU_TEXC disabled info | REGAL_FRAME_LIMIT 0 info | REGAL_MD5_COLOR disabled info | REGAL_MD5_STENCIL disabled info | REGAL_MD5_DEPTH disabled info | REGAL_SAVE_COLOR disabled info | REGAL_SAVE_STENCIL disabled info | REGAL_SAVE_DEPTH disabled info | REGAL_THREAD_LOCKING enabled info | OpenGL vendor : A-EON Technology Ltd. Written by Daniel 'Daytonta675x' MьЯener @ GoldenCode.eu info | OpenGL renderer : Warp3D Nova info | OpenGL version : OpenGL ES 2 1.17 for Warp3D Nova info | OpenGL extensions: info | OpenGL v attribs : 16 info | OpenGL varyings : 32 info | Regal vendor : A-EON Technology Ltd. Written by Daniel 'Daytonta675x' MьЯener @ GoldenCode.eu info | Regal renderer : Warp3D Nova info | Regal version : OpenGL ES 2 1.17 for Warp3D Nova info | Regal extensions : GL_EXT_debug_marker GL_GREMEDY_frame_terminator GL_GREMEDY_string_marker GL_REGAL_ES1_0_compatibility GL_REGAL_ES1_1_compatibility GL_REGAL_enable GL_REGAL_error_string GL_REGAL_extension_query GL_REGAL_log info | Regal v attribs : 16 info | Activating emulation layer REGAL_EMU_FILTER info | Activating emulation layer REGAL_EMU_VAO info | Activating emulation layer REGAL_EMU_DSA info | Activating emulation layer REGAL_EMU_SO info | Activating emulation layer REGAL_EMU_QUADS info | Activating emulation layer REGAL_EMU_IFF info | Activating emulation layer REGAL_EMU_RECT info | Activating emulation layer REGAL_EMU_BASEVERTEX info | Activating emulation layer REGAL_EMU_TEXSTO info | Activating emulation layer REGAL_EMU_XFER info | Activating emulation layer REGAL_EMU_PPCA info | Activating emulation layer REGAL_EMU_PPA info | Activating emulation layer REGAL_EMU_HINT info | Activating emulation layer REGAL_EMU_OBJ
Will try to enable REGAL_LOG_APP, REGAL_LOG_DRIVER and REGAL_LOG_INTERNAL, maybe it will bring some good info.
That's not too bad as you have at moment glClear working. When I read the context.c code in Regal last night I would think there would still need to be some specific Amiga code in there but seeing glClear work it seems not. Does Regal expect something regarding default state management to setup that might not be correct. As that can mess up a simple triangle. I had issue with minigl defaulting depth testing on when it is supposed to be off according to documentation regarding OpenGL spec.
Good luck and hope this comes together.
As for explanations on X11 misread your undefine :)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
