ptitSeb / gl4es

GL4ES is a OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android, Emscripten and AmigaOS4.
http://ptitseb.github.io/gl4es/
MIT License
673 stars 152 forks source link

quake3 on amigaos4 #52

Closed kas1e closed 6 years ago

kas1e commented 6 years ago

@ptitSeb Was able to build quake3 from your sources, for both, minigl and gl4es. In minigl version everything looks and works correct. In gl4es version, games starts , first image anymation come fine (that one with ID shoot in), and then when there should be shown "CD KEY , please enter your cd key, ACCEPT", i have instead nothing , just still ID there. If i then press "enter" again, so to go to menu, then i see, that something start changes visually, but all distorted and wrong. Have a look at screenshot:

http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/first_run.jpg

And there is console output: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/first_run_console_output.txt

At moment it is yesterdays's version with enabled workoround we do and almost without debug enabled (only fpe one seems so).

So i will for now try to build latest commit version (where we have no workorounds), as wel as will enable whole debug everywhere.

ptitSeb commented 6 years ago

Not much things in that log, but the workaround is used. So without it, it will probably not run fine without the fix in the driver.

I'll build ioquake3 with GL driver on my side tonight also.

kas1e commented 6 years ago

Uhm, last version can't build:

libgl4es.a(fpe.o): In function builtin_CheckVertexAttrib': fpe.c:(.text+0x1310): undefined reference toisBuiltinAttrib' libgl4es.a(fpe.o): In function builtin_CheckUniform': fpe.c:(.text+0x1400): undefined reference toisBuiltinMatrix' libgl4es.a(shader.o): In function redoShader': shader.c:(.text+0x1cb0): undefined reference toConvertShader' libgl4es.a(shader.o): In function glShaderSourceARB': shader.c:(.text+0x20b0): undefined reference toConvertShader' collect2: ld returned 1 exit status

Probably because of new changes about preproc.c stuff, etc ?

kas1e commented 6 years ago

Ah, that because shaderconv.c can't compiles:

src/gl/shaderconv.c: In function 'ConvertShader': src/gl/shaderconv.c:220: error: 'pBuffer' undeclared (first use in this function) src/gl/shaderconv.c:220: error: (Each undeclared identifier is reported only once src/gl/shaderconv.c:220: error: for each function it appears in.)

kas1e commented 6 years ago

Ok, it was DBG(printf("Shader source%s:\n%s\n", pBuffer, fpeShader?" (FPEShader generated)":""); , so commented out at moment, rebuild quake3_gl4es, run.

Visually almost the same, maybe little differences:

http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/screen2.jpg

And full debug output:

http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/output_full_debug.txt

Can be that it just other issues, not related to vertexattribs. All in all its just menu, not game itself..

kas1e commented 6 years ago

As i can see from log, shaders are simple and primitive ones (so just for menu that understandable). And mostly only usage of textures going on. So probably it can be indeed some other issues

kas1e commented 6 years ago

By the way, i tested Cadog without workoround : it of course draw a bit wrong things, but it works. Some parts just missed, but no mess of course like in quake3.

ptitSeb commented 6 years ago

I have fixed the issue with DEBUG.

Now, for the menu, I have to check tonight at home. quake3 engine can use lots of different type of texture, so maybe one type is not bigendian friendly yes.

ptitSeb commented 6 years ago

Mmmm, after checking the log, I see no exotic texture. Only regular RGBA/UBYTE here...

kas1e commented 6 years ago

Yeah, there really not much happens, just a menu. Same quake code works ok with minigl, so code is ok too(what mean ppc related parts in games code also ok). Also if cadog and letters fall kind of works with my hacked sdl1, then quake should too, imho..

To add, i do not use pandora's settings from your makefile, but my own. But imho there is nothing gl4es special in quake's code was done, pure as pure ?

ptitSeb commented 6 years ago

Yeah Pandora settings on the Makefile are for activating ARM Cpu optimisation, special keymap, and activating GLES 1.1 renderer. You need nothing of that so custom settings sounds good to me.

I'll test tonight with GLES2 backend to see what is happening. (you can try to run it with the environnement variable LIBGL_MIPMAP=1 maybe, to force all texture to use mipmap).

kas1e commented 6 years ago

Tested with settins LIBGL_MIPMAP to 1 : no differences. Maybe a little different looks of distortion, but still the same.

It also need to be noted, that whole game's logic works: i.e. if i press "enter" few times, i can see changes in that distorted mess, etc (so i go to the game). I also can heard sounds.

I also can for example press "2 times enter, 1 times up, then "y" " , and so to exit from game.

I even can press after running "4 times enter, 6 times down, 2 times enter", and game kind of starts, but its all looks reall straaaaange: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/ingame3.jpg

And music start to be "jump" (probably because of sync with frame rates which broken).

But as you say that it works for you with GLES1.1 renderer, then it may be that GLES2 renderer need fixes ? But that to be seen once you build your version over GLES2, and we will know where to start :)

kas1e commented 6 years ago

Some good news !

After i lower every possible settings to minimum, it starts !! Menu works, games works ! Through it slow like hell (1 fps), probably because of enabled debuggin.

So for first will try to disable debugging, and for second will try to found what options exactly give problems for us.

ptitSeb commented 6 years ago

A texture size issue?

Note that you can trigger some internal texture shrinking also, with gl4es, using LIBGL_SHRINK=10 (10 is an example, there is a lot of possibility, refer to the USAGE.md file for detail). Shrink is not usefull here, as the engine as integrate downsizing, but it's interesting that reducing size of Texture make it work.

kas1e commented 6 years ago

Ok, with disabled debugging, it give 5fps only :( On the same place where minigl give 22fps.

Thats very strange, i expect to have about 60-80 fps at least in compare with MiniGL...

ptitSeb commented 6 years ago

Yeah, something is wrong. Also, I checked texture size with previous log, and they are not that big. Max is 512x512, so it's not big. All textures are POT. some are not sqare, but there is really not much pressure on the texture side.

What did you disabled in the config exactly?

kas1e commented 6 years ago

Found also, that its the GL Extensions, which make it looks messy. Once i disable them, all works, once enable all in mess.

But most important question is : where is FPS :)

kas1e commented 6 years ago

I mean, it should be about 50-100-150 fps, as MiniGL have 22 (at that with software TCL, etc)

ptitSeb commented 6 years ago

It should at least be 20fps, and probably more, not 5.

What GL Extension seems to break rendering?

kas1e commented 6 years ago

Do you think it should be on pair with MiniGL ? I mean, minigl are TCL in software, so, all gl4es stuff which use more that few arrays should be faster a lot. At lest in 2-3-4 times for sure ?

As for what GL Extensions : dunno, just ioquake3 have options "disable / enable gl extensions", which ones exactly dunno, i just do disable them from minigl version, and then can run gl4es version.

kas1e commented 6 years ago

I also was able to build some version of quake3 we have on os4 without SDL1 at all (pure minigl), so there i swap on creating gl4es-ogles context, etc : same 5fps :( So we can rule out SDL1 as potential perfomance penalty.

ptitSeb commented 6 years ago

Well, Transform and Lighting will be done in some Vertex Shader with gl4es. If vertex shader are executed in the GPU, then yes, you should see some improvement. But vertex shader can be implemented on the CPU (not the Fragment Shaders), in that case, speed will not change much.

I'm home, I'll build ioquake soon and see how it runs o the Pandora.

kas1e commented 6 years ago

But vertex shader can be implemented on the CPU (not the Fragment Shaders), in that case, speed will not change much

But probably not with our case, as gl4es works over ogles2, which works over warp3d which all the shaders implement over GPU only.

That why i think it should be around 50 fps at minimum. Also our MiniGL is done a bit "wrong" in terms of coding, so not only TCL is impact, but just in whole all should be better.

I was thinking about SDL1 being problem, but as i post in previous message, i build version without SDL1 at all, which give same 5fps.

Through, from good news , is that there is almost no visual glitches. I.e. gl4es/ogles2 render all practically correctly.

Main problem for now is where FPS :))

ptitSeb commented 6 years ago

About the extension, looking at the log, here is what ioquake find:

Initializing OpenGL extensions
...ignoring GL_EXT_texture_compression_s3tc
...GL_S3_s3tc not found
...using GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array
...GL_EXT_texture_filter_anisotropic not found

So there is 3 candidates: GL_EXT_texture_env_add, GL_ARB_multitexture and GL_EXT_compiled_vertex_array.

kas1e commented 6 years ago

I also change in the quake3 option "lighting" , from "lightmap" to the "vertex", it then give 10 fps. But then, minigl with the same settings, give 40fps.

As for extensions, yeah.. but that for sure can't be reassons of low fps ?

ptitSeb commented 6 years ago

No. I have no explanation for the low fps for now.

But it would be interested to understand wich extension. Multi-texturing may have a big impact on fps, and having it disabled is not good.

kas1e commented 6 years ago

Related to extensions: from another side, when i press on "driver info" in the quakes3 settings, it bring me a lot of extensions from gl4es. But not sure if they will be used of course (but maybe it try, and crash because of it ?)

ptitSeb commented 6 years ago

No, the "glinfo" gives all the extension present in the driver. The one used are simply the few I listed.

kas1e commented 6 years ago

That what i have in MiniGL version when press on the "driver info" in quake3 settings: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/mgl_extensions.jpg

And that what i have in GL4ES version when press on the "driver info" in quake3 settings: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/gl4es_extensions.jpg

ptitSeb commented 6 years ago

That's quite some extensions supported in gl4es ;)

ptitSeb commented 6 years ago

Just to be sure it doesn't try to use an OpenGL 2.0 renderer, can you launch it with environement variable "LIBGL_GL=15" to force OpenGL 1.5 and not 2.0

kas1e commented 6 years ago

Seeting LIBGL_GL enveronment to 15 make no differences. Also when i build quake objects, i can see that only "renderer1" ones is builded. Or you mean its gl4es may try to use opengl2.0 by default ?

But then, setting LIBGL_GL environment to 20, change nothing at all. Same looks, same 5 fps.

ptitSeb commented 6 years ago

You should try to find wich extension break things: reactivate the extensions in ioquake3, and mess with the exentions string in gl4es so iq3 doesn't find them. It's in src/gl/getter.c. Then reactivate the extensions one by one to see wich one break rendering.

kas1e commented 6 years ago

Ok, will try now.

But interesting to know, how it runs for you over gl4es / gles2 :) Maybe there some general problem.

ptitSeb commented 6 years ago

It's not built yet... The Pandora is just an Arm @1Gz, it's not super fast...

kas1e commented 6 years ago

To add, in MiniGL i have 22 fps with disable extensions as well. With enabled it give 23 fps, which jump most of time back to 22, so probably no differences at all.

But i will try to find which one mess the things.

kas1e commented 6 years ago

Ok, probably found right from begining, i just doing that in getter.c:

"GLEXT!!!!compiled_vertex_array "

So, when i enable gl extensions in quake, i have: multitexture: enabled compiled vertex arrays: disabled texenv addd: enabled compressed textures: disabled

And then, no trashing. Rechecked again with gl4es where i didn't mess that extension in the getter.c , and it trashes. So its cleary GL_EXT_compiled_vertex_array which mess things up. Will report that one to Daniel.

But then, as in case with MiniGL, those extensions almost make no differences.

kas1e commented 6 years ago

By the way, in the MiniGL version compiled vertex arrays is disabled as well (just to rule out gl_extensions as perfomance penalty).

ptitSeb commented 6 years ago

Finished building on my side.

Working perfectly on GLES2 backend on the Pandora. Graphics are just fine, and the demo runs at 40fps, with some parts lowing down to 22, and sometime up to 60fps...

kas1e commented 6 years ago

That kind of bad news then ! My machine are 2ghz cpu, with some good radeon (2 years old only), so it should be about 100 fps then.

uhm ! strange !

ptitSeb commented 6 years ago

So that GL_EXT_compiled_vertex_array extension ensable the use of glDrawElements(...). Without it it use glBegin(...)/glEnd() blocks. So this is consistant with the issue with vertex size.

ptitSeb commented 6 years ago

I'm still unsure why it would be that slow. Are you able to do some profiling?

kas1e commented 6 years ago

Daniel ask me to pack everything up, so he can profile it , let's see. But as you have on 1ghz machine results even better than with minigl.. Then it shows !

Btw, when i say "22 fps", i mean you just run the game, and go to the first strage, and once it loads, you didn't move. What you have then there ?

kas1e commented 6 years ago

Also, you set no special environments ? All just works as it ? With latest commit of gl4es ?

ptitSeb commented 6 years ago

Ah yes, at main menu I'm only at 10fps. Strange, I think I remember it was (much) faster on GLES1.1 backend.

Also yes, it run without setting enything, with all default settings (geometry high, light map...)

ptitSeb commented 6 years ago

The slow down seems to be caused by the large mirror in front of starting point. If I move and look else were, fps jumps at 40fps.

kas1e commented 6 years ago

Ok, 10 fps with lighting lightmap or vertex ? It can be, that gl4es give us that framerate for example ?

kas1e commented 6 years ago

I mean its strangely the same fps for both of us

ptitSeb commented 6 years ago

I have done a quick profile, and most time was spent in actual drawing (in gles2 driver). Nothing really wrong, I'll see if I can get an GLES2 Trace of that.

kas1e commented 6 years ago

Same for me . If i move away from mirros, fps in some places can be even 70 (if you move back from mirror), and if you move left-right from mirros , around 30.

But that pretty bad values. Our minigl which is coded real bad, have 22 fps when i wath in the mirror, 80 when i move to the left, 100 when i move to the right, and 90 when i around so mirros at my back.

Can you check with GLES1.1 as well ? Maybe its just GLES2 rendering slow things down (some slow shaders, or something)

ptitSeb commented 6 years ago

I have just checked with gl4es but using GLES1.1 backend. That should be equivalent to your MiniGL. I get 22fps looking at the mirror... I'll try to get a GLES2 Trace of that rendering, to see what is happening.