Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
87 user(s) are online (68 user(s) are browsing Forums)

Members: 1
Guests: 86

RussellB, more...

Headlines




« 1 ... 37 38 39 (40) 41 »


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

I don't understand...is gl4es different to ogles2?

Does that mean that even if i use the GL4ES wrapper, i cannot use it with an app that assumes ogles2?

That would lock ScummVM out from using the GL4ES wrapper?
otoh i wouldn't have to waste any more time trying to make it compile and concentrate on SDL1/2 and OpenGL.

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@Raziel
GL4ES mean to be pure GL replacement, not GL ES replacement or analog. It's just the same GL 2.x. For scummvm in this regards it mean that instead of minigl you use GL4ES. It's just on our side GL4ES works over OGLES2, but this is not OGLES2 per se.

If scummvm wants to build with GL, you choose minigl or gl4es. IF scummvm wants to be built with ogles2, then you use OGLES2 directly.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

Ah, i see.
Mixing OpenGL/MiniGL and ogles2 doesn't work...that would explain the minigl errors i get.

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

g++ -athread=native -Wl,--export-dynamic -L/sdk/local/newlib/lib   -U__STRICT_ANSI__ --Wno-unused-parameter -Wno-empty-body
-fno-operator-names -std=c++11 -gstabs -fvar-tracking-assignments -pedantic -Wno-long-long -Wno-format ./scummvm-conf.cpp -o
./scummvm-conf -L/SDK/local/newlib/lib -lSDL2 -I/SDK/local/newlib/include/SDL2 -D_REENTRANT
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_GetProcAddress':
SDL_os4gl4es.c:(.text+0x34): undefined reference to 
`aglGetProcAddress'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_CreateContext'
:
SDL_os4gl4es.c:(.text+0xec): undefined reference to `aglDestroyContext'
SDL_os4gl4es.c:(.text+0x178): undefined reference to 
`aglCreateContext2'
SDL_os4gl4es.c:(.text+0x18c): undefined reference to `aglMakeCurrent'
SDL_os4gl4es.c:(.text+0x198): undefined reference to `glClear'
SDL_os4gl4es.c:(.text+0x1b0): undefined reference to 
`glViewport'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_DeleteContext'
:
SDL_os4gl4es.c:(.text+0x270): undefined reference to `aglDestroyContext'
SDL_os4gl4es.c:(.text+0x2c8): undefined reference to 
`aglDestroyContext'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function `OS4_GL_MakeCurrent'
:
SDL_os4gl4es.c:(.text+0x32c): undefined reference to `aglMakeCurrent'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function 
`OS4_GL_SwapWindow':
SDL_os4gl4es.c:(.text+0x3b4): undefined reference to `glFinish'
SDL_os4gl4es.c:(.text+0x3d8): undefined reference to `aglSwapBuffers'
/SDK/local/newlib/lib/libSDL2.a(SDL_os4gl4es.o): In function 
`OS4_GL_UpdateWindowPointer':
SDL_os4gl4es.c:(.text+0x43c): undefined reference to `aglSetParams2'
return code1

What am i missing?
I'm pretty sure i have everything installed.



EDIT:
What about libGLUT.a?
Do i need to remove/rename that too?


Edited by Raziel on 2021/9/23 14:10:01
_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@Raziel
-lSDL2 should be special gl4es version of sdl2, so: -lSDL2_gl4es

As for libglut, nope, no gl4es version of it at the moment.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

Please bear with me as i think i may have still an error somewhere or a misunderstanding.

You wrote in your readme:
Quote:

If you want to use SDL1/2, then there nothing that need to be changed, only
compiling lines changes from -lSDL -lGL -lGLU , to -lSDL_gl4es -lglu_gl4es
-lgl4es , or to -lSDL2_gl4es if SDL2 in use.

Does that mean that, if i want to compile an SDL2 app i *only* need to change the linker line to use -lSDL2_gl4es and it will pick up the other needed linker libs automatically (-lglu_gl4es, -lgl4es)?
Or do i still need to change all the linker libs to -lSDL2_gl4es, -lglu_gl4es,
-lgl4es?

Another thing is with renaming.
You wrote that
Quote:

One may ask, why to remove MiniGL includes, and why not put GL4ES includes to some directory like GL4ES instead of GL (so to not touch MiniGL ones): yes, you can do that. Just when you will later work with GL4ES, then everywhere and every time you will be in need to change include of OpenGL includes from GL to GL4ES directory. And when sometime in your sources you will forget or miss to do so, then you will have name conflicts and clashes.
But you can choose the way you want, of course. I just find it easier to have it in GL.

Does that *ONLY* comply to the GL directory?
Or is it meant to also work when i rename all of the gl4es linker libs?

Right now i use a script that takes care of all the renaming (and renaming back) automatically when i want to compile a gl4es project (but as you can see above, it doesn't work)
/*
    Prepare the original libraries and header files (only SDL2 for now).
    */    
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2.a as SDK:local/newlib/lib/libSDL2.a_MGL'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2.so as SDK:local/newlib/lib/libSDL2.so_MGL'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libGLU.a as SDK:local/newlib/lib/libGLU.a_MGL'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libGL.a as SDK:local/newlib/lib/libGL.a_MGL'
    
ADDRESS COMMAND 'rename SDK:local/common/include/GL as SDK:local/common/include/GL_MGL'
    
/*
    warning: libSDL2-2.0.so, needed by /SDK/local/newlib/lib/libSDL2_net.so
    Rename .so for all possibilityst, so it will use .a instead.
    */
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2-2.0.so as SDK:local/newlib/lib/libSDL2-2.0.so_MGL'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2_net.so as SDK:local/newlib/lib/libSDL2_net.so_MGL'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2_net-2.0.so.0 as SDK:local/newlib/lib/libSDL2_net-2.0.so.0_MGL'
    
/*
    Prepare OGLES2 specific libraries.
    */
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libSDL2_gl4es.a as SDK:local/newlib/lib/libSDL2.a'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libGLU_gl4es.a as SDK:local/newlib/lib/libGLU.a'
    
ADDRESS COMMAND 'rename SDK:local/newlib/lib/libgl4es.a as SDK:local/newlib/lib/libGL.a'
    
ADDRESS COMMAND 'rename SDK:local/common/include/GL4ES as SDK:local/common/include/GL'


I don't want to touch the source for changes, since everytime it changes i will have to change the linker line back, so i'd rather go with renaming (if that is even possible)

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@Raziel
Quote:

Does that mean that, if i want to compile an SDL2 app i *only* need to change the linker line to use -lSDL2_gl4es and it will pick up the other needed linker libs automatically (-lglu_gl4es, -lgl4es)?
Or do i still need to change all the linker libs to -lSDL2_gl4es, -lglu_gl4es,
-lgl4es?


No, no automatically you need to change all libs.

Quote:

Does that *ONLY* comply to the GL directory?
Or is it meant to also work when i rename all of the gl4es linker libs?


Yes only for GL directory, SDL2 includes keeping the same

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

Slowly getting back my time to test and play around.

If i have the GL4ES SDK correctly installed i should be able to do a simple
Quote:

gmake -f makefile

with the included examples and they should compile, right?

Because i get an error there too, which leads me to believe the SDK is incorrectly installed.

ppc-amigaos-g++ -athread=native -Wall example01.cpp -o example01 -lSDL2_gl4es -lgl4es -lglu_gl4es -lpthread
/T/ccC0wWkJ.oIn function `glBegin':
example01.cpp:(.text+0x1a): undefined reference to 
`mini_CurrentContext'
example01.cpp:(.text+0x1e): undefined reference to `mini_CurrentContext'
example01.cpp:(.text+0x26): undefined reference to `mini_CurrentContext'
example01.cpp:(.text+0x2a): undefined reference to 
`mini_CurrentContext'
/T/ccC0wWkJ.o: In function `glClear'
:
example01.cpp:(.text+0x72): undefined reference to `mini_CurrentContext'
/T/ccC0wWkJ.o:example01.cpp:(.text+0x76): more undefined references to 
`mini_CurrentContext' follow
gmake: *** [all] Error 1


Do i need those libraries installed too?

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

I've had a *little* success today...but only by jumping through many hoops (seems it's too big of a hassle to automate it, but manually changing it all the time is also too much work...for me)

Quote:

LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Apr 17 2021 23:02:30
LIBGL: Using GLES 2.0 backend
LIBGL: Using Warp3DNova.library v1 revision 85
LIBGL: Using OGLES2.library v3 revision 1
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Targeting OpenGL 2.1
LIBGL: NPOT texture handled in hardware
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: Current folder is:Development:Porting/ScummVM/static
LIBGL: Shuting down

That seems to indicate ogles2 is used, right?

Who is responsible for the above ogles2 log code?

Because the typos in there are pretty awkward
Quote:

LIBGL: OGLES2 Library and Interface opened successfully

Quote:

LIBGL: trying to use VBO

Quote:

LIBGL: Shutting down

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@Raziel
"undefined reference to `mini_CurrentContext" means you build an app with minigl includes, instead of gl4es ones. More precisely it means that your GL directory somewhere in SDK (and maybe in few places?) contains minigl includes instead of gl4es ones. Easy way to find out : try to find in whole SDK dir all "GL" dirs, to be sure there is only one place (and if not, delete it everywhere). And then, rename it to GL_MGL, create an empty GL directory, and put gl4es includes instead.

Quote:

That seems to indicate ogles2 is used, right?
Who is responsible for the above ogles2 log code?


Yea, there gl4es (all with LIBGL: at the beginning coming from gl4es) says to use that ogles2 and warp3dnova were opened fine, etc, etc. So it's output from gl4es.

Quote:

Because the typos in there are pretty awkward


Not sure what kind of typos you mean as for me seems all 3 quotes look correct.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

Nice, so next step is to try and compile ScummVM with it

Errm, yeah, the three quotes on the bottom of my post are the ones i already fixed

Look them up in the big log at the top of my post, here they are merged together:
Quote:

...
LIBGL: OGLES2 Library and Interface open successfuly
...
LIBGL: try to use VBO
...
LIBGL: Shuting down

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@all

I have a question...just for clarification.

Does the pure OpenGL we have make use of the "enhanced" gfx memory, *if* it is available to the system through the enhancer gfx driver?

Reson for asking is that i compiled a OpenGL app explicitely without gl4es and i still see the "enhanced" gfx memory being used.

I know that gl4es is NOT in use because
a) there is no indication in the debug console (no LIBGL, only OpenGL)
b) i have the gl4es link libraries renamed and even if they were picked up it shouldn't be available due to a)
c) I never really looked at the docky, that shows the "enhanced" gfx memory usage, before today, so i could have easily missed the fact that OpenGL does.
d) *IF* i compile the project explicitely with gl4es, i get shader compile errors everytime i run it, so, again, i doubt it's really used.

Thank you

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@Raziel
Quote:

Does the pure OpenGL we have to make use of the "enhanced" gfx memory, *if* it is available to the system through the enhancer gfx driver?


Yes, a very good example of old opengl being used too (i mean minigl), is BSzili's port of Jedi, which works with enhanced gfx driver on maximum details and eats up about 1 GB of video memory.

But it is used only for uploading GFX data to video memory. In real life, it means uploading of game/app's textures. So if the game has lots of textures, and wants to load them to the video memory, then enhanced drivers there help of course.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

I see.
Awesome. Thank you.

I was afraid I mixed something up (again) while configuring and "it just worked" like so many times before.

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@all

Someone please remind me wht the name of the program was i can run to see what gl4es is doing.

I need more debug output since ScummVM only displays a white screen when using gl4es (no more shader errors in the LIBGL output)

I faintly remember @capehill wrote something along those lines...

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2009/6/11 2:19
From Germany
Posts: 155
@Raziel

glSnoop. But maybe this doesn't helps you much here as the output only contains the translated GLES2/W3DN calls. For additional GL4ES logging/options see gl4es/SDK/Documentation/GL4ES/USAGE.md

LIBGL_DBGSHADERCONV
LIBGL_LOGSHADERERROR

you can set them in CLI like:
setenv LIBGL_LOGSHADERERROR 1

   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@IamSONIC

I knew about the envvars, but i somehow missed the DGBSHADERCONV one.

Have it on now...does anyone can read anything out of the below?
Maybe a reason why i don't get a picture?

LIBGLInitialising gl4es
LIBGL
v1.1.5 built on Apr 17 2021 23:02:30
LIBGL
stacktrace will be printed on crash
LIBGL
Using GLES 2.0 backend
LIBGL
Using Warp3DNova.library v1 revision 86
LIBGL
Using OGLES2.library v3 revision 1
LIBGL
OGLES2 Library and Interface open successfuly
LIBGL
Overide version string with "2.1" (should be in the form of "1.x")
LIBGLTargeting OpenGL 2.1
LIBGL
NPOT texture handled in hardware
LIBGL
Not trying to batch small subsequent glDrawXXXX
LIBGL
: try to use VBO
LIBGL
Force texture for Attachment color0 on FBO
LIBGL
Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL
Log to the console Error compiling shaders
Log to the console all shaders before 
and after conversionBefore  After  Vertex  Fragment  
LIBGL
Current folder is:Development:Porting/ScummVM/test
LIBGL
Hardware test on current Context...
LIBGLHardware Full NPOT detected and used
LIBGL
Extension GL_EXT_blend_minmax  detected and used
LIBGL
FBO are in core, and so used
LIBGL
PointSprite are in core, and so used
LIBGL
CubeMap are in core, and so used
LIBGL
BlendColor is in core, and so used
LIBGL
Blend Substract is in core, and so used
LIBGL
Blend Function and Equation Separation is in core, and so used
LIBGL
Texture Mirrored Repeat is in core, and so used
LIBGL
Extension GL_OES_mapbuffer  detected
LIBGL
Extension GL_OES_element_index_uint  detected and used
LIBGL
Extension GL_OES_packed_depth_stencil  detected and used
LIBGL
Extension GL_EXT_texture_format_BGRA8888  detected and used
LIBGL
Extension GL_OES_texture_float  detected and used
LIBGL
Extension GL_AOS4_texture_format_RGB332 detected
LIBGL
Extension GL_AOS4_texture_format_RGB332REV detected
LIBGL
Extension GL_AOS4_texture_format_RGBA1555REV detected and used
LIBGL
Extension GL_AOS4_texture_format_RGBA8888 detected and used
LIBGL
Extension GL_AOS4_texture_format_RGBA8888REV detected and used
LIBGL
high precision float in fragment shader available and used
LIBGL
Extension GL_EXT_frag_depth  detected and used
LIBGL
Max vertex attrib16
LIBGL
Max texture size16384
LIBGL
Max Varying Vector32
LIBGL
Texture Units16/16 (hardware32), Max lights8Max planes6
LIBGL
Extension GL_EXT_texture_filter_anisotropic  detected and used
LIBGL
Max Anisotropic filtering16
LIBGL
Max Color AttachmentsDraw buffers1
LIBGL
Hardware vendor is A-EON Technology LtdWritten by Daniel 'Daytona675x' Müßener GoldenCode.eu
LIBGL
GLSL 300 es supported
LIBGL
GLSL 310 es supported and used
Shader source
#version 310
attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;

uniform mat4 projection;

varying vec2 texCoord;
varying vec4 blendColor;

void main(void) {
    
texCoord    texCoordIn;
    
blendColor  blendColorIn;
    
gl_Position projection position;
}
:

New 
Shader source:
#version 100
precision highp float;
precision highp int;
attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;

uniform mat4 projection;

varying vec2 texCoord;
varying vec4 blendColor;

void main(void) {
    
texCoord    texCoordIn;
    
blendColor  blendColorIn;
    
gl_Position projection position;
}

Shader source#version 310
varying vec2 texCoord;
varying vec4 blendColor;

uniform sampler2D shaderTexture;

void main(void) {
    
gl_FragColor blendColor texture2D(shaderTexturetexCoord);
}
:

New 
Shader source:
#version 100
precision highp float;
precision highp int;
varying vec2 texCoord;
varying vec4 blendColor;

uniform sampler2D shaderTexture;

void main(void) {
    
gl_FragColor blendColor texture2D(shaderTexturetexCoord);
}

Shader source#version 310
attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;

uniform mat4 projection;

varying vec2 texCoord;
varying vec4 blendColor;

void main(void) {
    
texCoord    texCoordIn;
    
blendColor  blendColorIn;
    
gl_Position projection position;
}
:

New 
Shader source:
#version 100
precision highp float;
precision highp int;
attribute vec4 position;
attribute vec2 texCoordIn;
attribute vec4 blendColorIn;

uniform mat4 projection;

varying vec2 texCoord;
varying vec4 blendColor;

void main(void) {
    
texCoord    texCoordIn;
    
blendColor  blendColorIn;
    
gl_Position projection position;
}

Shader source#version 310
varying vec2 texCoord;
varying vec4 blendColor;

uniform sampler2D shaderTexture;
uniform sampler2D palette;

const 
float adjustFactor 255.0 256.0 1.0 / (2.0 256.0);
void main(void) {
    
vec4 index texture2D(shaderTexturetexCoord);
    
gl_FragColor blendColor texture2D(palettevec2(index.adjustFactor0.0));
}
:

New 
Shader source:
#version 100
precision highp float;
precision highp int;
varying vec2 texCoord;
varying vec4 blendColor;

uniform sampler2D shaderTexture;
uniform sampler2D palette;

const 
float adjustFactor 255.000 256.000 1.00000 / (2.00000 256.000);
void main(void) {
    
vec4 index texture2D(shaderTexturetexCoord);
    
gl_FragColor blendColor texture2D(palettevec2(index.adjustFactor0.00000));
}


btw, it makes no dofference if i manually change the #version to 300/310 in the shader source.

Thank you

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@Raziel
At least you go far enough with gl4es already :)

So, now, when you certainly have running gl4es build as can be seen, you need to be sure you don't have shader-compilation errors.

What you need, is to enable output of not original shaders, but shaders generated by gl4es (internal ones and re-generated from shaders coming with scummvm if there is any). So then you grab then one by one, and firstly by using glslangvalidator port from Daniel (last one from latest warp3dnova releases) compile SPRV files from them (to see, that syntax all correct and so on), and then, after, you use Hans's W3DNShaderInfo (coming with warp3dnova in example/Shaderinfo/). To see if it bring errors.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2006/11/26 21:45
From a dying planet
Posts: 4341
@kas1e

Yeah, not only is it hard to understand, but it also is so illogical sometimes...

I'll have to put this on hold in the meantime, anyway.
There seems to be some missing extensions, which would normally be included if the backend uses GLEW (which we don't).

Have to wait for some PR getting merged and then try again.

Will surely get back to you all

Thanks for the help so far

_________________
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 7078
@All

Want to resurrect this thread with some interesting info which I know those who are interested in 3D on OS4 (especially on x5000), will be interested in the info above.

So, yesterday I just tested some beta components: the latest kernel and the latest Radeon RX driver. The kernel I tested doesn't mean being multicore, just the usual kernel with some improvements mostly from Thomas, and just the next version of the Radeon RX driver by Hans.


Resized Image


Together kernel and new gfx drivers bring some unbelievable speed up in ports i do via GL4ES (which use Warp3DNova and ogles2.library). MiniGL apps also have some speed up, but not that big as with GL4ES apps.

For example, take the quake3 and 1920x1080 fullscreen / all settings max / usual "timedemo 1/demo four running 3 times" on my X5000:

MiniGL version on RadeonHD SI: ~75 FPS
GL4ES version on public components on Radeon RX: ~78 FPS
GL4ES version on beta components on Radeon RX: ~133 FPS (!)

Yes, +55FPS!

I retested more games, and there are results:

"Quake3"'s timedemo1/demo four: +55fps
"HCraft" vary, from 30 to 50 fps more
Worlds: vary, in general from 15-30FPS more
SuperTuxKart : +15 FPS more
FooBillard++ : +25 FPS more
NeverBall : + 100 FPS more
NeverPutt : + 150 FPS more
Friking Shark: +50 FPS more
Irrlicht_demos: Quaketest + 25FPS, shaders tests + 800FPS, meshviwer test + 200 fps, "demo" example + 35 FPS.

In other words, it is just something unbelievable. I find out that speed increase comes from both kernel and Radeon RX drivers. About 30% come from Kernel (probably once Thomas add "dcbz only use half cache lines on X5000") and 70% come from Radeon RX change which is "Reduced overhead of getBMBytesPerRow(). It used to lock and unlock the bitmap, which is rather slow". Not sure that authors expect such a massive change, but that comes as a real unexpected bonus.

To see it all in action, you can watch a video made (as usual with comments and stuff) where I test 7-8 GL4ES game ports, so you can see the figures of FPS and compare if you are in interest.

There is:

Resized Image Beta tests of 3D graphics on X5000 in november 2011. 1920x1080 full HD


Yeah, I still can't believe in such massive change. That of course without real DMA, which should bring even more at the end.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


« 1 ... 37 38 39 (40) 41 »



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project