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]

I assume that me making all fragment shaders as your simple one :

version 100

precision mediump float; uniform vec4 Gamma; // Used as float vec2 FixUV( vec2 UV ) { return vec2( UV.x, 1.0 - UV.y ); } uniform sampler2D Texture0; // Diffuse uniform sampler2D Texture1; // Color grading LUT varying vec2 PassUV; void main() { gl_FragColor = texture2D( Texture0, FixUV( PassUV ) ); }";

can't cause that color problems ?

As for RenderToTextur,is it done as some function in Eldritch ?

[kas1e]

With new change about textures it just crashes on loading, in initialising part, in the CreateTexture() :(

[kas1e]

If i remove ifdef amigaos4 from CreateTexture(), then next it crashes in the CreateTextureFromDDS(). So seems in both cases crashes the same on BigEndian_ConvertRGBA

[kas1e]

With new fix still crashes the same in the same BigEndian_ConvertRGBA(). Maybe put some prinfs in, to know what exactly issue is ?

[kas1e]

With "third attempt" no crash, and colors changes to be like this:

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

[kas1e]

As i see from "ingame" screenshot : the 4 things at left (heart, keys, energy-metter ,etc) are of correct color now. While other ones are not. Maybe also hands more or less correct. And in "menu" when it starts, background is black (as expected) and logo is white (as expected too).

I.e. seems some some textures right, some (most of them) are not. Maybe its differences betweeen DDS and non DDS textures there ..

And when log appear first time, it looks like this: http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/Eld_screen10_logo.jpg

(so or it draw all at once, or, didn't delete logo after)

[kas1e]

Played a bit with : and seems that its DDS ones which cause issues at moment. Standard CreateTexture() is that one which make left-things be of correct color (as well as colors of logo and background), as once i remove ifdef amigaos4 from CreateTexture, but keep one in DDS, they start to be of wrong color.

[kas1e]

Yeah, seems conversion in the CreateTextureFromDDS() make no differences for texture colors, but, it make difference on logo-menu looks : it just with conversion show the logo, and then menu screen, without conversion it show me menu screen right away.

Quite strange !

[ptitSeb]

Is it better with now, with 88b2920a5e9cdb18f3754bf1b7a3c874017e5bef

[kas1e]

With last commits have:

decompress.cpp:94:25: error: too few arguments to function ‘void littleBigEndian(void*, int)’

Its because littleBigEndian (void *x, int sz) { , but everywhere in code it used one argument

[kas1e]

So with latest fix all compiles, and there is good and bad news:

1). In game everything the same:

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

2). In the title screen, while Eldricht banner still have wrong colors, at least the main 2d picture (at least what we can see of it) : fat lines at top and fat lines at bottom, have correct colors. Probabaly black part is that one which overwrites by the Eldritch banner, and as colors wrong, it give no transaprency and we have all black in the middle. See screenshot:

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

[kas1e]

I made some experiment : i comment out ALL code inside of every function in decompres.cpp. I mean absolutly all code, so all funtions are empty. Then rebuild, and while it have impact on the menu's title screen, it made no single difference to textures in the game itself. Just like nothing in the game itself from that "decompress.cpp" are used ..

Maybe it mean that uncompressDXTc() in the gl2texture.cpp , didn't switch formats properly ?

I mean, if the whole game based on the DXTc (right ?) , then strange that commenting out everything inside of decompress.cpp make no single difference to the game's look.

Or maybe game engine didn't based on those DXTc, but on "plain" ones ?

[ptitSeb]

I don't know if the whole game is based on DXTc texture. Maybe it isn't. I really cannot say, as I haven't analysed the ressources of the game. You don't get any errors o loading now? So probably texture are correctly fetched (maybe be add some printf in texture loading, to be sure texture are either load as DDS, or other formats). Note that game texture are, for most part, pretty low-res. It as a "minecraft" look, with 8bits lowres textures... So DXTc is not really usefull on small textures. About the shaders, what exactly did you do?

[kas1e]

For shaders i just do that: http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/gl2vertexshader.cpp

See there at top i define amigaos4 as well (to have that simple fragment shader be in use), but then , at end of conversion function , and before pandora's ifdef, i just do:

#ifdef __amigaos4__ if (strstr((char *)Tmp, "gl_FragColor")) { // for every shader whuch has gl_FragColor (so every fragment shader), we just use simple one. strcpy((char *)Tmp, SimplePixelShader); } #endif

So every fragment shader will be of that "simple" kind. Maybe that really wrong , because you replace it for CC on pandora not for every fragment one, but for those which has gl_FragColor = Calibrate( ColorGrade( texture2D( Texture0" in.

And as fragment ones are also have impact on colors, it pretty possible that because of that it looks that bad.

[kas1e]

As for loading, yeah, no errors about loading of textures at least, only those warnings at top about

ReverseHash: Hash collision detected between "UI" and "Si"! ReverseHash: Hash collision detected between "Ir" and "LB"! ReverseHash: Hash collision detected between "Si" and "UI"!

Also

Invalid type requested for UIScreen LeaderboardsScreen. Warn failed: "false" (Invalid UIScreen type requested.) in unknown function in /amiga/Eldritch-master/code/Libraries/UI/src/uifactory.cpp at line 50 Assertion failed: "pUIScreen" () in unknown function in /amiga/Eldritch-master/code/Libraries/UI/src/Common/uimanagercommon.cpp at line 43 Creating vertex declaration for signature 211

And bunch of

Invalid type requested for WBAction Award_ACH_Lore. Warn failed: "false" (Invalid WBAction type requested.) in unknown function in /amiga/Eldritch-master/code/Libraries/Workbench/src/wbactionfactory.cpp at line 35 Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore. Invalid type requested for WBAction Award_ACH_Lore.

But no other errors.

[ptitSeb]

Yeah, I suspect that Shader change to do weird stuff on screen. The "Pandora CC Hack" is a speed hack. For one particular shader, I use a simplified version (without color correction if I remember correctly), because the CC model simply doesn't have the GPU power for this... You should dump the shaders to the console, instead of changing them (or just use the CC hack if you want), and have the shaders errors fixed first. We look at the texture once shaders are working, because maybe the textures are already fine... (probably not, but it's too difficult to say in current state)

[kas1e]

Yeah, i dump them all before, and about 4-5 fragment shaders have that error (an no other errors):

INTERNAL ERROR: Source parameter is missing it's CG Object: 133: OpVariable: SampledImage(Image(Float))*: Texture1: storage class: UniformConstant Decorators: RelaxedPrecision, DescriptorSet(0)

There is one of those example shaders:

http://kas1e.mikendezign.com/aos4/gl4es/games/Eldricht/6.frag

And yeah, i at begining trying to use your CC hack, but that produce nothing and just crashes, as failing fragment shaders didn't compiles and give errors.

[kas1e]

I also tried to replace all fragment shaders by dummy ones (i.e. pure void() main()), but that produce some green trash on screen and nothing more :) So yeah, i assume firstly shaders need to be deal with.

I asked Hans when he can deal with, he say that now he very busy, and can't say when exactly.. So probabaly it can take weeks as well :(

Probabaly if found from what error come, and get rid of it, it can be possible to add the same kind of change code when convert shaders, but for now i don't understand what cause that error.

[ptitSeb]

I don't see what wrong with the shader, and I don't really understand the error message anyway. Maybe it doesn't like sampler2D as a function parameter? What OGLES2 driver developper says about that?

[kas1e]

Shader of course correct one, just warp3d shader compiler fail. Daniel can't say much about as he use inside of gles2 driver the same code which has glslangvalidator, and via glslangvalidator that shader compiles fine. It fail later, in the warp3d's shader compiler, and probabaly because of optimisation that warp3d's shader compiler trying to do.

If you in interest, there is bugreport i create to Hans about yesterday :

http://www.amiga.org/developer/bugreports/view.php?id=385

In second post, you can see "-n" output of warp3dshaderinfo binary (which, do check how shader compiles via warp3d's shader compiler), and with -n give more verbose output.

[kas1e]

Yeah, problematic line are : vec4 FogValue = GetFog( PassPositionWS, Texture1 );

previous line are ok , that one : vec4 DiffuseColor = ConstantColor * texture2D( Texture0, PassUV );

Dunno where is bug, will wait Hans to asnwer about.

Btw, as side note, while play with sources, found that gl '3D/src/GL2/gl.h':

#define GL_DEPTH24_STENCIL8 GL_DEPTH24_STENCIL8_OES

In GLES2/gl2ext.h its as :

#ifndef GL_OES_packed_depth_stencil #define GL_OES_packed_depth_stencil 1 #define GL_DEPTH_STENCIL_OES 0x84F9 #define GL_UNSIGNED_INT_24_8_OES 0x84FA #define GL_DEPTH24_STENCIL8_OES 0x88F0 #endif /* GL_OES_packed_depth_stencil */

I.e. that part with framebuffer not working with that GL_DEPTH24_STENCIL8 on both pandora and aos4 drivers, maybe because its just not implemented on both as it kind of extension again ?

[ptitSeb]

The extension "GL_OES_packed_depth_stencil" is implemented on the Pandora. According to the specs (https://www.khronos.org/registry/OpenGL/extensions/OES/OES_packed_depth_stencil.txt ) it should work on a Renderbuffer, but I had trouble with this, so I disabled its use...

[kas1e]

Right, so its just some luck that it didn't work for you before, as we don't have that extension implemented on our side seems so, and your fallback can be happyly reused for us :)

Btw, in meantime i got final version from Daniel, where he implement just those 4 functions:

glMapBufferOES, glUnmapBufferOES, glGetBufferPointervOES and glGetBufferParameterivOES

And everything compiles fine now as it in Eldritch, without any new amigaos4 ifdefs.

He also add new function to GLES2 , real aglGetProcAddress(), so once it will be released in public, we probabaly can reuse it in gl4es (as well as i will reuse it in SDL2 too), just to avoid that custom stuff we have now.

[kas1e]

Some more news: Daniel go futher and add OES_packed_depth_stencil, which he at moment didn't test well, so something can be wrong of course still, but, i tryed with, and still have 8cd6 / incomplete attachement. It may be very well issues on our side too, but can it be something with game's code as well ?

I also can see, that now, when i have that extensions implemented in our gles2 driver, and while i still have that 8dc6 error, i can see how first scene of game engine renders. I then can't move, can't doing anything, but pressing "esc" for menu works, and i can see first scene. So something for sure was implemented in our side, just still that 8dc6..

[kas1e]

Oh, before you answer Daniel deal with. So we have now implemented that GL_OES_packed_depth_stencil extensions in our gles2 driver, and i just remove ifdefs amigaos4 in Eldritch to check if it works: all works fine.

Through dunno, what way is better : the way you we have now, or that Extension 24bitdepth_stensil one ?

[ptitSeb]

I'll remove the ifdef then, better to use the extension (packed stencil depth are supposed to be more optimized)

[kas1e]

Yeah, if there will be anything wrong later then it can be fixed by Daniel, or we can put ifdef back in worst scenario.

In meantime btw i found 2 bugs (or features :) ) , in compare with win32 version (at least in os4 build).

1. If you press esc (to menu), and then again esc (back to game), then , focus looses. Character is like move to some other side. Then again esc , and again esc , and character focus again moves somewhere. The more you press esc/esc , the more character loose initial focus. On win32 version focus stay as it was all the time.

2. When you start, go to the mirror, and press "f", in win32 version that character in the mirror moves a bit, on our version (at least on os4 one), it didn't moves, just stay in one position. Other functionality works through, i can press on buttons and changed hair/dress/ etc.

[ptitSeb]

For 1. I'm not sure I understand what is happening, but I guess it has to do with mouse warp... For 2. I don't think it will move unless you use the correct shaders.

[kas1e]

Aha ok, for #1 i mean you have that little white dot which mean your focus. When you press "esc" to menu, and then again "esc" back to game, then, its like you do move mouse, and move character to some way (but you didn't). Then you press again esc to menu, and again esc back to the game : and character again moves somewhere, while you of course didn't move it.

[ptitSeb]

So yeah, Mouse Wrap. I'll check later. Not a high priority bug.

[kas1e]

Also if you have few mins, can you also 3 things:

1. stack cookie for 1mb as we do everywhere in other projects

2. replace all words 'List' on something like "Lista" or "ListEnv" or anything which will looks sane to be on all platforms. Reasson is that in our SDK we have already defined List , and i had to rename in about 10 files List to Lista. I.e. not make it amigaos4 ifdefed, but just generally, so it will works the same as before everywhere, and for aos4 i will have no needs to replace it manually all the time. The files which need to be changed are:

.h files:

Core/Libraries/3D/src/animationstate.h, line 115 Core/Libraries/3D/src/renderercommon.h, line 127 Core/Libraries/Core/src/clock.h, line 111 Core/Libraries/Core/src/configmanager.h, line 227 Core/Libraries/Core/src/consolemanager.h, line 61 and line 68 Core/Libraries/Core/src/list.h, lines: 7,9,11,13,16,20,34,110,113 (in 2 places),115, 121,123 (in 2 places), 125, 303 Core/Libraries/Core/src/multimap.h, lines: 32,33,128,158 Core/Projects/Eldritch/src/eldritchparticles.h, lines: 174

.cpp files:

Core/Libraries/Core/src/clock.cpp, lines: 195, 234 Core/Libraries/Core/src/configmanager.cpp, lines: 649, 668, 687, 725,806 Core/Libraries/Core/src/configparser.cpp, lines: 192, 228, 248,558 Core/Libraries/Core/src/consolemanager.cpp, lines: 11

It sadly need to be changed manually, as automatically there words like Listener, and other ones which no need to change.

3. Add amigaos4 ifdef for PROGDIR: in those files:

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

With that changes, configs creates, masterslave file too, just on loading it crashes when save file present and it trying to parse it, but with that we can deal later.

Thanks a bunch !

[kas1e]

Hi! I again take some of your time from box project :) So there is some news: since the last post, I found a way to deal with that List cross-references with our SDK and just find out a way to get rid of it by simply putting some special flag for GCC -D__USE_AMIGAOS4_NAMESPACE__.

So, only what is left is to set Stack Cookie as we do usually, and add "PROGIDR:" thing in file.cpp, framework3d.cpp and edlritchframework.cpp

Now, I also receive an updated warp3dnova.library, where fragment shaders are no more crashes. They compile fine now. But! Not all that good :) Now, once I run a game with working fragment shaders, it's just simple lockup after 2-3-4 seconds. I.e. nothing happens, no crashes, just simple lockup. And does not matter where I am are: in the first title window, or in the menu, or game starts. Just simple 3-4 seconds passed = lockup.

For sake of tests, I put some "simple" fragment shaders inside of Eldritch (so just my simple one used), and while a look of the game wrong, I have no crash.

An idea which I had now, is to catch all the shaders via our glsnoop, then, in the eldritch code add checks on all of them, and replace firstly all on "Simple" ones, and one by one uncomment, to see what one start to made lockups. And then at least it will be something to deal with... Maybe it will be easy to just bypass crashing one.

What do you think about it ?:)

[ptitSeb]

So, I'll add the Amiga specific stuff later.

Now, why it crashes after a while, I have no idea. The point is, some of the shaders used in Eldritch are fairly complex, with many unifor matrices (used for bone animation of monster). Also, even when you are at the logo, the "world" is also there and drawn, behind the logo, so thoses heavy shader might be already loaded and used. They maybe the cause of the freeze.

[kas1e]

I will try just to check shader by shader when freezes stop (by replacing one by one on empty ones) so I can then at least have something to think about. If I remember right, there wasn't a lot of shader in eldritch itself.

[kas1e]

Hi PtitSeb!

We got at least new ogles2 and warp3nova, where all fragment shaders work fine, and no freezes anymore. Now I want to make a proper finished amigaos4 port , and want to ask you, if you in interest if I will donate you 150-200$, so you can help me to deal with the last endian issues and some other small stuff?

We also may try to update to the latest code of Eldritch, maybe it will be worth as well?

[ptitSeb]

Hi kas1e!

It's been a long time. So you have an improved gles2 driver? Good :) I can help, but you I have less time because of all my active project. About Eldrich, yes, I should update, but I'm afraid this will take a bit a of time. I need to work on that.

You should check latest gl4es, I have now ARB "old style" shaders support, I remember that was a question you had (maybe you can try that on DooM III sources, I think they build on PowerPC)

[kas1e]

Yeah :)

Well, newer sources of not a big deal for sure :) Currently, the issues I had, it's that even with all working shaders, the rendering in the game itself is "blue". That can be (and probably is) not only because of endian issues in the game itself but maybe in the shaders? Because I remember to see all in blue issues before with ogles2 renderer in SDL2 which we fix by some hack like this:

https://github.com/AmigaPorts/SDL/commit/3545dc33cfea94e1168d13a747de8ee099ecc817

Anyway, I first need to take all the latest stuff now in the place, build from scratch Eldritch from your repo, and so can point out on issues. Offer for 150-200$ when we made it works is valid of course :)

Thanks for the response, will write back once test it all from scratch.

[kas1e]

Ok, so I just grab the code we have in the repo and build it without any code changes. Just all we have in the repo. Issues which I noticed immediately:

1). When we start, it starts to check the screen mode available. And I see in log that:

Enumerating SDL display modes ...
Enumated mode 1920x1080
Enumated mode 1280x768
Enumated mode 1024x768
Enumated mode 800x600
Enumated mode 640x480
UIScreenEldSetRes info:
  ScreenWidth : 1920
  ScreenHeight: 1080
Invalid type requested for UIScreen LeaderboardScreen.

On the win32, the screen by default sets to 1280x720 (which screen mode I have also) but for some reason seems we fall back to the 800x600 Because of that, I think I have 2 black border lines on top and at the bottom (you will see it on the next screenshot). I assume that because it should show 1280x720 by default, but for some reason can't and fallback to something else.

2). On the title screen, the sprite of "Eldritch" is of the wrong color, see:

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

3). I don't see any letters on the menu. Just empty, see:

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

4). If I just hit 2 times "enter enter" I can go to the game, but all blue:

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

And the same didn't see letters on the menu. And all blue mean whole world, items on top like "health measure" , etc, and the map seems of the correct color.

5). There is a crash when I quit from the game (i assume it's because little-endian writes to the save file or something ?)

Imho, better start from the first 3? As they may look more or less easy to deal with

[kas1e]

Tested on win32 build, and when I set to 800x600, I also have some black lines at top and bottom. So, black lines are no issue. But why it fails to set 1280x720 by default... (besides, it's a window mode)

[ptitSeb]

So, I rebuilt Eldritch on my pandora. I used GLES backend for a first test. here are the correct pictures:

(it's not the intial starting point).

I'm building a GL version now, to check if it works (as gl4es should handle most bigendian differencies in texture already).

[kas1e]

Yeah, i also use gles backend, but know if gl4es also handle it will be intetesting.. But seems then endian issues in games code..

[ptitSeb]

For now, it seems I have broken GL backend. I'll try to fix it first...

[ptitSeb]

The OpenGL version now build properly. It doesn't work on the Pandora tho, the "splash screen" is disturbing the process. It way work on the Amiga anyway, give it shot, just in case...

[kas1e]

Will check now GL version too. At least it may give us some more info indeed!

[kas1e]

Sadly can't build the GL version, because it needs GLEW, which we don't have on os4 :)

Interestingly why on gles2 version main image shown fine, but the sprite at the top is of wrong colors and missing letters everywhere (and they usually white, so maybe the wrong endian swap can explain that too)

[ptitSeb]

Ok, we'll stay on GLES2 version then.

[kas1e]

Watching your and my screenshots, I assume the easer way will be to deal with "why in the title screen, the image ok, but the "eldritch" logo on top is of the wrong color ". Maybe that automatically will deal with everything else.

It didn't look through like the wrong byteswap, it's like the color a bit shifted (see no transparency where it should be, and colors of sprite not that different from as they should be).

[ptitSeb]

It maybe one of the decompression of S3TC, especially the dxt1 with alpha. I have to check.

[ptitSeb]

I have pushed a small update to the s3tc decoder. Maybe it fixed the transparency issue, can you test?

[kas1e]

Well, nope, things even start to be a bit worse: i.e. colors didn't change, but there some new visuall trash added:

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