amigaos4 build

[kas1e]

And there is another one :)

So i start to compile objects, they give me some warnings: quite a bit, but one is repeaded pretty offten about core/src/Color.h:

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/warnings1.txt

Then, im doing some other os4 fixes (that for later) till the moment when trying to compile 3D/src/GL2/gl2pixelshader.cpp, it bring that error:

/amiga/Eldritch-master/code/Libraries/3D/src/GL2/gl2pixelshader.cpp:33:19: error: invalid conversion from ‘unsigned char*’ to ‘const char*’ [-fpermissive] Length = strlen(pBuffer);

The same kind of errors (but more) are in 3D/src/GL2/gl2vertexshader.cpp, there is: http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/vertexerrors.txt

At this point it says it already compile about 22% of files, so chances that there will be lots of other errors are low (i hope)

[kas1e]

Tried with new commit : yeah, the string about Error: Unknown file extension for sample loading! are gone for sure, but crash in the CreateSampleFromOGG with eating up all the memory still there :(

[kas1e]

I can see in CreateSampleFromOGG() there is some alut functions used, like alBufferData(buffer, format, retval, size, freq); , maybe that one somehow related.. Will check, maybe it also can be endian related issue

[ptitSeb]

I don't see were this issue can come from. In line 64 of openalsound.cpp it would be interesting to printf Length, to see if Pack files are correctly handled or non.

[kas1e]

Printed. Before crash i have that output:

Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Length = 7905 Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Elected theme with 0.00 bias. Creating vertex declaration for signature 1033 BuildAllMeshes built 567 meshes. Length = 1313349

Oh, just in case it can make any difference : to be able to build Eldricth with amigaos4 sdk, i had to do some fix in Core/Libraries/Core/src/core.h:

#ifdef __amigaos4__ typedef signed char int8; #else typedef char int8; #endif

If it ok, add it plz as well, its on line 79 of core.h

[ptitSeb]

Ok, I added the int8 definition.

Now, for the sound issue, Lenght seems correct, but can you printf info->channels and info->rate line 76?

[kas1e]

1 and 44100 (so seems correct)

Its like something with realloc/memmove maybe ?

[ptitSeb]

there is nothing really extraordinary in the rest of the process. If you have doubts with the number of realloc, you can enlarge the buffer (change the long allocated = 4*1024*6; to something bigger, like 1024*1024 too avoid too much realloc... Also, you can try to printf the value of rc and size like 91.

[kas1e]

Not that i have doubts, its just there is nothing else which can cause eating of all memory in loop (imho). I mean it can be not realoc itself, just whole loop fail by some reassons maybe ..

I printf value of rc and size in line 91, and have all the time size = 2048 and rc = 2048 too. It going in the loop without any change (always 2048), till all the memory filled up and then crash.

[ptitSeb]

so ov_read is always successful in reading and expanding the OGG data? strange

[ptitSeb]

You used that lib ogg with Barony already, right? There must be something wrong with the Pack file, but the eader seems correct, so that's really strange.

[kas1e]

For Barony i use:

libSDL2.a libgl4es.a libGLU.a -lm -lSDL2_image -lpng -lSDL2_ttf -lSDL2_net -ljpeg -ltiff -lwebp -lfreetype -lopenal -lvorbisfile -lvorbis -logg -lpthread libphysfs.a -lauto -lz

For Eldritch just:

-lSDL2 -logles2 -lopenal -lalut -lvorbisfile -lvorbis -logg -lz -lpthread

They of course the same openal, vorbis and ogg libs. But difference is that i don't use "alut" for Barony, which, dunno if can cause any issues in that function ?

It is some port of Freealut 1.1.0 done about 10 years ago, so maybe i need to report it just in case (its probably just ./configure ; make will be).

But dunno if it can cause those issues there..

Just in case (maybe somehow related to those PackedStrema big-endianes issues): when i trying to port yesterday Code/Tools/FilePacker, then while binary builds fine, on running when i tried to unpack *.cpk, it says me:

4/0.Work:Eldritch/unpack> FilePacker -u eldritch-audio.cpk Assertion failed: "m_Header.m_MagicID == 'KPCD'" () in unknown function in /amiga/Eldritch-master/code/Tools/FilePacker/src/filepacker.cpp at line 84 terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

Not sure if it related of course, probabaly just in FilePacker.cpp itself need big-endian changes, but maybe it somehow related to issue we have with sounds ..

Will try to report alut library in meantime, just in case.

[ptitSeb]

alut is used only for WAV decoding, not OGG.

[kas1e]

Yeah.. Reported ALUT already, and tried - make no differences. Just in case i upload the log of how it looks like now (with those debug printfs):

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/full_log_debug_audio.txt

Its not all the time 2048, and begining all looks like more or less ok. Its then after all other initialisation done.

And that how looks like current openalsound.cpp (in case i mess something up with debug prinfs): http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/openalsound.cpp

[kas1e]

If i understand log right, first sample decodes fine (that one which length is 7705) through at end it also brings about 10-20 of those "2048" values. Then, second sound of length 1313349, first time it says 1152 and then 2048 till memory filled up.

[ptitSeb]

It's OGG files, that are decoded in memory at load. So it's normal small buffer expand in much larger ones. It should end to fill buffer, but an OGG of 1.3MB expand to several MB. I assume it still should enter in your memory. Try again with the large buffer of 1024*1024...

[kas1e]

Making long allocated = 1024*1024*16; instead of long allocated = 4*1024*16; seems make things be different : It also doing some of those "2048" , but in end, it didn't fill up 1.5gb of memory (only 30-40 mb), then also says at end:

rc = 76 size = 76 BuildMeshesForChangedVoxels build 24 meshes. BuildMeshesForChangedVoxels build 24 meshes. BuildMeshesForChangedVoxels build 26 meshes. Eldritch initialisation complete.

Then show me black window, and crashes. No stacktrace, just some lockup.

[kas1e]

Dunno what it mean, probabaly that ALubyte *tmp = static_cast<ALubyte*>(realloc(retval, size)); fail somehow..dunno..

[kas1e]

As far as i can see, in whole Eldritch code, realloc() used only there. Through Barony also use realloc() (just without static_cast). prototype dind't use realloc(), while fricking_shark use it in one place, but also, not as static_cast

[ptitSeb]

Maybe AmigaOS implementation of realloc is not too good, and that function should be used carefully, eating much memory (because of head fragmentation). I'll change the audio buffer for a larger value on amigaos4. Now you should try to get some bugfix on the shaders, because without seeing anything, it will be difficult to go further.

[kas1e]

But with empty shader it should't crash right ? I mean for now, it show black window and crashes with bad memory access.

And that thing with realloc looks bad yeah.. I will try to ask on our forums if there something to be carefull about.

Strange !

[ptitSeb]

Without a backtrace or any hint of what it is doing, it will be difficult to fix... Maybe with graphics, it woul dbe easier to understand what is happening. Now, you can probably try to track where the crash happens with printf ... but I'm pretty sure it will take some time to locate the function that crash.

[kas1e]

As i understand it crashes right when it should blit graphics, i.e only window showups, then lockup. So i cant move mouse, etc, which mean menu didnt work. But as i see from win32 version it should show just 2d title image with 3 menu items. And i also heard no menu music too (if there is any, need to check).

Will try to put more printfs.

[ptitSeb]

2D... yes and no. I remember having done some GLES2 capture of the beggining, and in fact, there is a full 3D scene that is drawn, and the 2D bitmap / manu and then paint on top of this. So it's more complicated then it look like...

[kas1e]

Aha got it..

I for now tried to run it and check if there is any sound come : yes, once black window happens, at the same time the sound ambiend sound can be heard. But crash already happens (probably sound going in just another thread).

I also got capture of SDL2 debug output before crash happens, there is: http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/sdl2_output.txt

At end i see there is :

[OS4_GLES_GetProcAddress] Called for 'glMapBufferOES' [OS4_GLES_GetProcAddress] Failed to load 'glMapBufferOES' [OS4_GLES_GetProcAddress] Called for 'glUnmapBufferOES' [OS4_GLES_GetProcAddress] Failed to load 'glUnmapBufferOES' [OS4_SetWindowGrabPrivate] Window 0x64395EF8 ('Eldritch') input was released [OS4_WarpMouse] Warping mouse to 0, 0 [OS4_WarpMouseInternal] Sending input event [OS4_HideWindow] Ignore hide request, window 'Eldritch' is destroying [OS4_SetWindowGrabPrivate] Window 0x64395EF8 ('Eldritch') input was released [OS4_DestroyWindowFramebuffer] Freeing bitmap 0x64463038 [OS4_DestroyWindow] Called for 'Eldritch' (flags 0x18) [OS4_RemoveAppWindow] Removing AppWindow [OS4_CloseSystemWindow] Closing window 'Eldritch' (address 0x64395EF8) [OS4_CloseScreen] Public screen, not closing [OS4_ShowWindow] Showing window 'Eldritch'

I.e. framebuffer destroyed, all closes, but then "showwindow" and crash. Quite strange ..

[ptitSeb]

[OS4_GLES_GetProcAddress] Called for 'glMapBufferOES'
[OS4_GLES_GetProcAddress] Failed to load 'glMapBufferOES'
[OS4_GLES_GetProcAddress] Called for 'glUnmapBufferOES'
[OS4_GLES_GetProcAddress] Failed to load 'glUnmapBufferOES'

This is probably an issue. Not finding those functions, not sure there is the code in place to not try to use them...

[kas1e]

I do set NO_VBO define (as you do for Pandora), and recompile all, and SDL2_output start to looks like this:

[OS4_GLES_CreateContext] Called [OS4_GLES_CreateContext] Depth buffer size 16, stencil buffer size 0 [OS4_GLES_CreateContext] OpenGL ES 2 context 0x6420A290 created for window 'Eldritch' [OS4_GL_SetSwapInterval] VSYNC 1 [OS4_SetWindowGrabPrivate] Window 0x64CAEFC0 ('Eldritch') input was released [OS4_WarpMouse] Warping mouse to 0, 0 [OS4_WarpMouseInternal] Sending input event [OS4_HideWindow] Ignore hide request, window 'Eldritch' is destroying [OS4_SetWindowGrabPrivate] Window 0x64CAEFC0 ('Eldritch') input was released [OS4_DestroyWindowFramebuffer] Freeing bitmap 0x6445D4A8 [OS4_DestroyWindow] Called for 'Eldritch' (flags 0x18) [OS4_RemoveAppWindow] Removing AppWindow [OS4_CloseSystemWindow] Closing window 'Eldritch' (address 0x64CAEFC0) [OS4_CloseScreen] Public screen, not closing [OS4_ShowWindow] Showing window 'Eldritch'

Closing of winow there mean that first little small window. So, it starts, i can hit keys and can heard that menu works. But whole look are this (of course):

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen2_no_vbo_no_shaders.jpg

Now need to check why SDL2 fail to load those glMapBufferOES/glUnmapBufferOES functions.

[ptitSeb]

At least you have the NO_VBO... Of course it would be better, for performances on the Amiga, to have VBO (to avoid BigEndian -> LittleEndian convertions on the GL datas), but the shaders need fix first, before aving access to VBO (plus, maybe there are supported, but not under this name, I don't remember your SDL2 version well enough).

[kas1e]

I tried for now just to put your fragment shader you use CC model , and woah, i even can see things and play in game ! Check this out:

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen3_no_vbo_simple_fragment.jpg

I can move, jumps, etc,etc. All looks just as it should. Through from exit it crashes in the function which should "save" some master file, which function imho also big-endian issue :( ?

I checked for glMapBufferOES/glUnmapBufferOES functions in includes , and in gles2/gl2ext.h i have:

ifndef GL_OES_mapbuffer

define GL_OES_mapbuffer 1

define GL_WRITE_ONLY_OES 0x88B9

define GL_BUFFER_ACCESS_OES 0x88BB

define GL_BUFFER_MAPPED_OES 0x88BC

define GL_BUFFER_MAP_POINTER_OES 0x88BD

typedef void *(GL_APIENTRYP PFNGLMAPBUFFEROESPROC) (GLenum target, GLenum access); typedef GLboolean (GL_APIENTRYP PFNGLUNMAPBUFFEROESPROC) (GLenum target); typedef void (GL_APIENTRYP PFNGLGETBUFFERPOINTERVOESPROC) (GLenum target, GLenum pname, void **params);

ifdef GL_GLEXT_PROTOTYPES

GL_APICALL void *GL_APIENTRY glMapBufferOES (GLenum target, GLenum access); GL_APICALL GLboolean GL_APIENTRY glUnmapBufferOES (GLenum target); GL_APICALL void GL_APIENTRY glGetBufferPointervOES (GLenum target, GLenum pname, void **params);

endif

endif / GL_OES_mapbuffer /

And in SDL2_opengles2_gl2ext.h i have:

/ GL_OES_mapbuffer /

ifndef GL_OES_mapbuffer

define GL_OES_mapbuffer 1

ifdef GL_GLEXT_PROTOTYPES

GL_APICALL void* GL_APIENTRY glMapBufferOES (GLenum target, GLenum access); GL_APICALL GLboolean GL_APIENTRY glUnmapBufferOES (GLenum target); GL_APICALL void GL_APIENTRY glGetBufferPointervOES (GLenum target, GLenum pname, GLvoid **params);

endif

typedef void* (GL_APIENTRYP PFNGLMAPBUFFEROESPROC) (GLenum target, GLenum access); typedef GLboolean (GL_APIENTRYP PFNGLUNMAPBUFFEROESPROC) (GLenum target); typedef void (GL_APIENTRYP PFNGLGETBUFFERPOINTERVOESPROC) (GLenum target, GLenum pname, GLvoid **params);

endif

Dunno what it mean, and should be those functions be implemented in the gles2 or, its some include wrapper over other ones ?

[ptitSeb]

Mmm, colors seems wrong. Maybe there are some bigendian stuff still to do, in texture (at the SDL_surface creation) or in color. Not sure.

The MapBufferOES stuff, it's an extension, meaning not all driver have it. You use, in SDL2, SDL_GL_GetProcAdress(...) function to get the function pointer. The question is, is this coded in SDL2 (the gathering of this pointer function in OGLES2 driver), and also, does this extension exist in OGLES2 driver?

[kas1e]

Yeah, it all looks like not as distored color but something which just have bytes swapped. Sure simple fragment shader can't give such a look. If it possible to make it to be of right look, game will be kind of playable already :)

As for those 2 extension functions, In sdl2 it can be easyly not done, at least there is SDL2's ogles2 files:

https://github.com/AmigaPorts/SDL/blob/master/src/video/amigaos4/SDL_os4opengles.c https://github.com/AmigaPorts/SDL/blob/master/src/video/amigaos4/SDL_os4opengles2wrapper.c

In the wrapper's one i can see only usuall set of ogles2 functions, nothing about OES ones..

But big question if it implemented in the ogles2 driver at all ..

[kas1e]

Btw, fragment shaders can cause color differences of such kind ? I just use your simple shader for every fragment shader (asking just in case, just to be sure its some endian issues)

[kas1e]

As other idea for colros issues, maybe in colors.h at end those defines need to be changed too ? For example those ones:

define SET_COLOR_R(c, r) (((c)&0xff00ffff) | R_TO_COLOR(r))

define SET_COLOR_G(c, g) (((c)&0xffff00ff) | G_TO_COLOR(g))

define SET_COLOR_B(c, b) (((c)&0xffffff00) | B_TO_COLOR(b))

define SET_COLOR_A(c, a) (((c)&0x00ffffff) | A_TO_COLOR(a))

[kas1e]

Some more interesting stuff about endianes: i grab main titles screen, check this out:

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen4_main_rotated.jpg

See in the word "Eldritch" all the letters rotated in wrong way : from bottom to top. So its not only colors swapped, but seems texture's pixels swapped a bit too as choords, not only as colors

[kas1e]

What is also intersting, that only failed shaders are fragment ones. Did i understand right, that there just some simple vertex-shaders used everywhere, so only fragment one are important for that game ? I mean, it strange that i have no errors about vertex shaders, was expected them to fail for sure :)

Also, i found the cause why "saveload" crashes: its that "./ thing :)

So, i found all places in Eldritch which has "./" , there they are:

Code/Libraries/Core/src/file.cpp, lines 480 and and 495 Code/Libraries/Framework/src/framework3d.cpp, line 898 Code/Projects/Eldritch/src/eldritchframework.cpp, line 1499

So i change it all on PROGDIR:, and game starts, create even "prefs.config" file in root , and i can exit from game and file saves. Through, when i trying to run game second time (so with prefs file + that masterslave file), i have at first error of such kind:

S/L: Flushing world files: Assertion failed: "Iter.IsValid()" () in unknown function in /amiga/Eldritch-master/code/Libraries/Core/src/map.h at line 554 Assertion failed: "m_Node" () in unknown function in /amiga/Eldritch-master/code/Libraries/Core/src/map.h at line 69

And then crash, of that kind:

Stack trace: Eldritch:ZN12SimpleStringaSERKS()+0x14 (section 1 @ 0x19DA54) Eldritch:_ZN12EldritchGame22SetColorGradingTextureERK12SimpleString()+0x24 (section 1 @ 0x11E604) Eldritch:_ZN13EldritchWorld4LoadERK11IDataStream()+0x23c (section 1 @ 0x14C398) Eldritch:_ZN16EldritchSaveLoad10LoadMasterERK11IDataStream()+0x6ac (section 1 @ 0x13E27C) Eldritch:_ZN16EldritchSaveLoad13TryLoadMasterERK12SimpleString()+0x2d8 (section 1 @ 0x13E818) Eldritch:_ZN16EldritchSaveLoad13TryLoadMasterEv()+0xe4 (section 1 @ 0x13EBE0) Eldritch:_ZN12EldritchGame10InitializeEv()+0x6c (section 1 @ 0x11BAF8) Eldritch:_ZN17EldritchFramework10InitializeEv()+0x1a0c (section 1 @ 0x10FA0C) Eldritch:_ZN11Framework3D4MainEv()+0x24 (section 1 @ 0x281FDC)

I.e. when game should do restoring/reading of that master file, but instead it crashes in thhat SimpleString() function which return progdir..

[kas1e]

Also tried your few minutes ago commited texture-conversion-big-endian-aware change, and while colors still wrong, things for sure start to be better. In the title i can see logo (before there was nothing), in the game, i can see red book and brown chair, check this out:

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen5_title.jpg http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen6_ingame.jpg

Its like, for now "black/transparency" thing start to be working as expected.

[kas1e]

I also got answer from one of our dev about that function which use realloc(), and that what he say:

ALubyte *tmp = static_cast<ALubyte*>(realloc(retval, size)); if (retval == nullptr) {

Should be probably:

ALubyte *tmp = static_cast<ALubyte*>(realloc(retval, size)); if (tmp == nullptr) {

Because here (one line below) you want to free the original memory.

Also note that there is a initial success check of malloc() missing.

I'm not sure if this explains your problem though but IMO there is a leak in case of certain failures in that code.

So, i just changed if (retval == nullptr) on if (tmp == nullptr) with keeping original long allocated = 4*1024*16; and yeah, now it starts, but something still wrong, as on decompression time it still eat up 1gb of memory (which then free once game starts). Can it be side effect of "initial success check of malloc() missing." ?

[ptitSeb]

Yes, right, there is a mistake there. But that doesn't solve the heavy heap fragmentation / consuption issue you have. But I'll fix the issue.

[kas1e]

At least with fixing retval on tmp mistake it eat up only 1gb of memory , not 2.. but still .. Dunno if that initiall succes sheck of malloc missing can cause such a big fragmentation .. (sure not..)

[kas1e]

And if i use just long allocated = 2048*1024*16; , its even eat not 100mb, but only 30-40 mb :) Funny !

[kas1e]

Ouch ! It seems just our realloc() implementation suck some amiga. Check that thread if you in interest: http://forum.hyperion-entertainment.com/viewtopic.php?f=14&t=1591&hilit=realloc

In brief, ppls have same issues, meaning "realloc() for their needs eats a lot of memory in process, which then freeds, but still". And we can't easly replace realloc() with out own replacement, as in newlib which we use as C library are shared library, and if in project we use inderectluy some mallocs() or other memory functions that will lead to crashes and issues , so solutions is only to replace all memory functions (madness).

For us it mean that or we can just keep 1024x1024x16 and be done with it (so we know it is not a bug, but "feature"), or get rid of realloc() in whole which is work for nothing, and better keep it as it.

In other words, the less reallocs, the less it takes memory in process. It then will be freed once reallocs done, but still. In our case with simple mistake it even leads to whole memory being eating up.

[kas1e]

So, some new progress: there wasn't glMapBufferOES/glUnmapBufferOES functions implemented in our gles2, but Daniel implement it already, so after some tests we have them working, and i already recompile Eldritch over it, an it works visually for sure faster. I can't say on how much, but sure faster. Did Eldritch have any fps counter somewhere , so i can see in console some output about speed ?

But, what curious us, is why there is usage of SDL_GL_GetProcAddress() at all ? I mean, Daniel just implement those 2 functions, and i just use them directly, without calling SDL_GL_GetProcAddress at all. Why there is needs for that function on Pandora ?

That what Daniel ask:

p.s.: I don't have any idea how SDL_GL_GetProcAddress is supposed to work anyway in our case here. It would need a string -> function pointer map. But it cannot have a valid one because I don't provide one and / or the new functions where not there this morning...

[ptitSeb]

I don't understand the question. SDL_GL_GetProcAddress is the standard way to get function pointer for GL extension when using SDL. This function is an Abstraction Layer for the underneath function, that can be glXGetProcAddress on GL/X11, eglGetProcAddress on GLES/X11 or wglGetProcAddress on GL/Windows. On the Pandora, I simply added a path where I don't use thoses function because they tend to make things slower on Pandora. But this extension is fairly common on GLES2 Hardware.

But again, I didn't understood the question.

[kas1e]

So its common way to get functions pointer to exactly extensions only ? I mean only for extensions ? That probably mean that extensions on other platforms done in a way which needs function pointer, but Daniel just implement them as usual functions of gles2 driver, which i just call as it, without getting any extension pointer

[ptitSeb]

It's the only way to get extension. Regular function can also be gathered like that (remember that lookup.c source in gl4es, it's exactly that, along with aglGetProcAddress I created, to be consistant with other platform).

Now, why is this this only way? : Imagine you don't use this mecanism, and use extension glMySuperFunction(...). You develop your stuff and link with this function. You are happy it work on you machine, with your driver. Now, you give the game to your friend, who have a different driver with a different hardware. And his driver doesn't have this extension. So the program will not load at all, because the symbol glMySuperFunction doesn't exist and the link at load time cannot be done... That why you get extension as function pointer. That way, you are not linked to the symbol, you just have a variable, and you get the extension at run time...

[kas1e]

Well.. At least for amigaos all so called extensions are not extensions , they implemented just as usual functions which works on every amiga hardware always, as driver are the same always. The just called extensions to be able to support what called extensions.

So, if those extensions present always in our driver on all hardware, there no needs to call SDL_GL_GetProc too.

Probably on other oses where not only different gfx cards (not only radeons as for us) and drivers can be from different vendors that can be need it, but for us those new functions will be always in driver since now.

And anyway, in Eldritch we dont use glMapBufferOES/glUnmapBufferOES extensions as something which may or may be not used on runtime, we use they like they should be, or nothing will works, right ? Or it will fallback on non extension way if extensions on some pandora driver will not found ?

[ptitSeb]

Not all games check if required extensions are present. Some just crash if the extension is not there because there is no fallback code...

Now, for amiga, if you want easier life when porting stuff, you should have some extension mecanisms (like lookup.cpp / aglGetProcAddress on gl4es, really, it's not complicated).

[kas1e]

I just can't get for now why it need for amigaos4.

I mean, for now, all what i do in the gl2vertexbuffer.cpp is:

#ifdef HAVE_GLES extern "C" { // void* eglGetProcAddress(const char*); // cannot include EGL/egl.h, as it conflict with other headers... void* SDL_GL_GetProcAddress(const char* proc); } #define eglGetProcAddress(aa) SDL_GL_GetProcAddress(aa) static int MapBufferInited = 0; #ifdef __amigaos4__ #define glMapBuffer glMapBufferOES #define glUnmapBuffer glUnmapBufferOES #else static PFNGLMAPBUFFEROESPROC glMapBuffer = NULL; static PFNGLUNMAPBUFFEROESPROC glUnmapBuffer = NULL; #endif

also this:

#ifndef __amigaos4__ #define GL_WRITE_ONLY GL_WRITE_ONLY_OES #endif

(as i have that define in ogles2 headers)

and this:

#ifndef NO_VBO if (!MapBufferInited) { #ifndef __amigaos4__ glMapBuffer = (PFNGLMAPBUFFEROESPROC)eglGetProcAddress("glMapBufferOES"); glUnmapBuffer = (PFNGLUNMAPBUFFEROESPROC)eglGetProcAddress("glUnmapBufferOES"); #endif MapBufferInited = 1; } #endif

And all works.

Extension mecanism probabaly already done in SDL2 already via that SDL_GL_GetPRoc, but i didn't use it, as it have no sense to use on amigaos4 imho ? I for sure can sound dump, just didn't get why need to do it for os4 : i mean, what benefits ? Driver always will have those extensions on all amiga hardware..

I also tryed to run now binary compiled with new library and code used those functions without calling SDL_GL_GetProc, just on older driver, which didn't have it implemented, and it start, and then crash when time to call those functions.

But that kind of expected, if there will be used SDL_GL_GetPRoc , it probably will not crash, but then just didn't works anyway , right and produce just black screen or something of that sort ?

[ptitSeb]

Well, if you don't want to bother with extension mecanism, that's fine.

Now that ALL OpenGL app that use shaders use extension, but as it's already supported in gl4es you are safe. It's only for pure GLES2 game here (and luckily in GLES2, shaders are not extensions, there are core).

[kas1e]

I will anyway ask Daniel to made it works with SDL_GL_GetProc as well (hope he can do it, just to avoid making even those little changes), but at least we can make it works already.

I also was able to screenshot first logo today:

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen7_logo.jpg

See, its not only wrong colors (but now they at least better than before your texture fix), but also whole thing in textures are mirrored and rotated.

And i also made a video of current state, so you can see how it all looks like, maybe will notice anything interesting from:

https://www.youtube.com/watch?v=erDiNPTipmI

[ptitSeb]

I don't think it's mirrored + rotated. My guess it's only "upside-down", and it's probably an issue with RenderToTexture (probably an issue with OGLES2 driver). But it would be better when colors are fully fixed.