Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
80 user(s) are online (69 user(s) are browsing Forums)

Members: 0
Guests: 80

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 2 (3)


Re: The OpenGL ES 2.0 thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 840
Added GL4ES link.

   Report Go to top

Re: The OpenGL ES 2.0 thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 840
@Daytona675x

1) Are you able to compile GLES2/gl2ext.h? I just tried and I had to add this kind of hack:

#define GL_KHR_debug 0
#define GL_NV_draw_vulkan_image 0
#define GL_NV_gpu_shader5 0
#include <GLES2/gl2ext.h>


2) About GL_ARB_texture_rectangle: I couldn't find define for GL_SAMPLER_2D_RECT_SHADOW. It was mentioned here https://www.khronos.org/registry/OpenG ... ARB_texture_rectangle.txt

3) About GL_EXT_texture_lod_bias: I couldn't find define for GL_TEXTURE_FILTER_CONTROL_EXT. It was mentioned here https://www.khronos.org/registry/OpenG ... /EXT_texture_lod_bias.txt

4) About GL_ARB_provoking_vertex: is QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION missing the GL_ prefix?


   Report Go to top

Re: The OpenGL ES 2.0 thread
Not too shy to talk
Joined:
2015/6/11 8:51
From Cologne
Posts: 288
@Capehill

1) hm, yes, I can (if I include gl2.h before, of course), but who knows, maybe there is some side-effect with your concrete use-case somewhere. Please upload a project incl. your makefile for me to try.

2) our ogles2 doesn't support the GL_EXT_shadow_samplers extension as of yet. Therefore the rect-texture extension lacks the shadow-part too - which is why I didn't care about such defines as of yet

3) we are in ogles2, there is no "texture environment". Therefore there aren't defines for parameters which are required only for not-existing functions like GetTexEnvfv, GetTexEnviv, TexEnvi, TexEnvf, Texenviv, and TexEnvfv.

4) yes, thanks, fixed!


Edited by Daytona675x on 2019/12/11 8:20:00
_________________
[Facebook] [YouTube Channel]
   Report Go to top

Re: The OpenGL ES 2.0 thread
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 840
@Daytona675x

1) Fixed by including GLES2/gl2.h - thanks. I was only including proto/ogles2.h before. https://github.com/capehill/glsnoop/co ... e48c7593f690f410062cd5aec


   Report Go to top

Re: The OpenGL ES 2.0 thread
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5779
@All
I am not Daniel, but as there is XMAS time and everyone is busy, and news on amigans.net is didn't appears with changelog, there is what was changed since v2.9 up to current 2.11:


- Fix: glScissor didn't gracefully handle negative XY or height. Thanks to Kasie Kasovich (kas1e) for reporting.

- Improvement: under certain circumstances, ogles2 could be triggered to resize its internal client-RAM-emu-VBOs multibuffer to very very large values, in fact so large that Nova allocated almost all VRAM for those. At least on some Nova/RadeonHD.chip/graphics.lib setups the VBO resizing also triggered a crash bug in Nova's DeleteBuffer function under such low VRAM conditions. This improvement therefore also acts as a workaround for that issue. This fixes all such issues with some of kas1e's Irrlicht engine examples. Thanks to Kasie Kasovich (kas1e) for reporting.

- Fix: there was a bug in the copy-converter for 8bit and 16bit index arrays (Nova doesn't support 8bit indices and is very slow with 16bit indices, therefore those are converted to 32bit internally, even if the ogles2-client passes them inside his own VBO, then a "hidden" 32bit clone is prepared and used) which in theory could result in the indices not being updated at all. It was extremely unlikely to happen and AFAIK it never did, but anyway: fixed.

- Workaround/Fix: if you attached a GL_BGRA_EXT texture as color render target to an FBO, then the texture's red and blue channels would appear to be swapped when you later used that texture for rendering. The reason for this is that the BGRA texture's internal pixel format is actually RGBA, only that its channels are "swizzled". At the moment Nova ignores that swizzle setting when rendering to the texture. The current workaround is to reset any eventual swizzle to the defaults if the texture is being used as FBO render target, so simply spoken an BGRA texture becomes an RGBA texture if you use it as render target. This fixes color bugs in e.g. an irrlicht demo and Tuxkart. Thanks to Kasie Kasovich (kas1e) for reporting.

- maintenance, C++ modernizations: all attribute initializations moved from constructor initializer lists into the respective class definitions. Makes the code smaller and it's harder to forget something (and oops, I actually found one uninitialized attribute during the process (uncritical though)...).

- maintenance, C++ modernizations: "auto" return-value replacement run on all inline functions, where appropriate.

- (small) hashing functions speed-up (without hash quality loss).

- Fix: a bug in the uniform shader variable handler resulted in same-named (and thus logically identical) vertex- and fragment-uniforms to eventually be assigned different virtual location numbers. If the user issued a glUniform(location_number,xyz) call then the lib would only find and set the vertex-shader's uniform and skip the writing to the fragment-shader's uniform because it would simply not find it. OpenGL doesn't distinguish between such same-named but physically different uniform variables in the shaders of a GPU program - in stark contrast to Nova, where all that info is shader and not shader-program based. Consequently Nova's ShaderGetObjectInfo, which is used to query uniform variable information, works on shaders only. Also, Nova only gives us a GLSL / GL compatible "location" info if that has been explicitly defined inside the shader, otherwise, it doesn't generate one but only returns W3DN_NOLOCATION. Because of all this ogles2.lib has to generate such location Infos by itself, in a GL compatible way. This means that in case of a same-named variable in both of a program's shaders the same uniform location has to be enforced. Which is where the flaw was. In gl4es this bug manifested in a fog not working. Thanks to kas1e for reporting and testing!

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


« 1 2 (3)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project