@Daniel Tested new library, results are : both irrlicht engine example and q3 with enabled extensions start to show things and almost works ! I.e. they works, just something with colors happens.
That how irrlicht engine looks like (our hacked binary at left, and non hacked, but over new patched ogles2.library, at right). It looks about correct, just colors differs (looks like endianes issues?). See in patched version it more "black", and hello world words at left-top are purple:
(press rmb in new tab for full size)
And that how looks like q3 with enabled extensions:
@kas1e With extensions enabled? Note that this first workaround-version only tackles the situation if you don't use VBOs of any kind (by that I mean ogles2 VBOs)! So what this first workaround is supposed to patch is if e.g. gl4es does a call like
where "pointer_to_first_color" is really a pointer and no VBO is bound. So it's the typical old-school vertex-data-via-client-RAM-pointer setup.
Your statement about "enabled extensions" somehow sounds as if you're trying to use VBOs? That's not done yet.
Anyway, for the above situation ogles2 already has to manage an internal (hidden) Nova-VBO. Therefore the workaround is not that hard (it only costs performance and RAM is being wasted): if such a glVertexAttribPointer call is made, then copy-convert to float (incl. eventual normalization) and tell Nova that it now got std. floats in the internal VBO, instead of simply copying it over.
I have no idea where endian-issues should come from (just as I don't know why not supporting uchar8 x 4 has anything to do with any endian-issues in the first place). For Nova those are simple floats now, just like e.g. the xyz coordinates.
Anyway, check out the fresh version on the FTP. I found a typo that probably was the reason for this ;)
Sorry for the confusion. I'll do my best to clarify, and also correct what I've been saying (got myself confused too ).
1. The big endianness issue concerns VBOs containing data of mixed sizes. If you try mixing byte, 16-bit and/or 32-bit data in one VBO, then it will fail. However, stick a 16-bit index array in its own VBO (or a VBO with only 16-bit data), and it *will* work. I just checked the code, and that is handled correctly.
So the "32-bit data only" statement isn't strictly true any more, and hasn't been for a while. Will have to update that...
NOTE: DBOs are still 32-bit only.
2. The second limitation is that the driver used to treat all Vertex Attributes (VAs) as 32-bit floats. The latest beta sets the VA's attributes correctly now, so it'll treat ints as ints, uints as uints, etc.
This is where I got a myself confused because I thought the hardware would treat floats and ints differently. However, 32-bit ints and floats are handled the same way: they get passed on to the shader unchanged (i.e., int VAs must go to an int shader input). So, 32-bit int VAs have probably been working all along.
The latest beta also correctly sets the VA descriptor for 8 and 16-bit attributes, including whether it's normalized. So, it should work provided you restrict each VBO to having one data size only (8-bit data in one VBO, 16-bit data in another, etc.). I haven't tested that, though, because I'd completely forgotten that my endianness handler was a bit more sophisticated than "32-bits only." Let me know what happens if you try it...
Quick summary: restrict each VBO to data of one size each (8-bit data in one, 16-bit in another, etc.). The latest beta sets the VA descriptors correctly based on type, so VAs of all types might work provided the restriction above is observed (untested so far).
My apologies for the confusion and gaps/errors in the docs. I hope that it's clear now, and will update the docs.
Anyway, check out the fresh version on the FTP. I found a typo that probably was the reason for this ;)
Yes! Now irrlicht engine exampe and q3 with enabled extensions (so use the gldrawelements, not glBegin/glEnd route) works fine ! There current results:
@kas1e Great! Did you check the performance impact of the workaround (by comparing it to a version where you did the ubyte-float-conversion of the color inside gl4es)? Next to come is the workaround for VBOs. Do you have sth. for testing here too?
@Hans Quote:
Wish I'd thought of the existing Nova limitations sooner.
And I wish I had not overlooked this limitation info in this readme
Quote:
Sorry for the confusion. I'll do my best to clarify, and also correct what I've been saying (got myself confused too ).
And sorry for my initial rant Although it's a real hefty limitation that came as a big surprise to me, it was my fault to miss the note in the first place.
Quote:
NOTE: DBOs are still 32-bit only.
Luckily that's no problem. The respective commands of ogles2, namely glUniformXX, only operate with 32bit-floats and 32bit-ints. So this limitation "only" affects VAs, and out of those only VAs that are defined via glBufferXXX and glVertexAttribPointer (the glVertexAttribXf functions only work with floats).
Quote:
Quick summary: restrict each VBO to data of one size each (8-bit data in one, 16-bit in another, etc.). The latest beta sets the VA descriptors correctly based on type, so VAs of all types might work provided the restriction above is observed (untested so far).
I could do this for the internal client-RAM-emu-VBOs, since I have full control over those. However I already made the workaround for that situation, which seems to work well looking at kas1e's latest feedback, which essentially patches the data when the emu-VBO is being built up internally, no need for extra VBOs here.
For "real" VBOs supplied by the user via glBufferXXX etc. this could be exploited though. However in my current wip workaround for this I already took another route: when I detect that a VBO contains critical element-types, then I create one additional internal "sub"-VBO and copy-convert the critical data over to that one when a draw-call with that VBO is being issued and if there have been data modifications since the last sub-VBO-refresh. So it's one sub-VBO with x float-arrays for all x critical arrays of the user-supplied VBO. Patching the original VBO is a no-go, of course. Just imagine the fun if somebody does a partial glBufferSubData... Adding the patched arrays at the end of the original VBO is no good idea neither, this just complicates all the internal book-keeping. The solution I'm implementing now is the "easiest" in this regards.
In both cases interleaved and linear memory layouts are supported, of course.
However, I won't put too much effort into optimizing those workarounds. I hope that this is only a temporary necessity and that it can be removed rather soon again
Great! Did you check the performance impact of the workaround (by comparing it to a version where you did the ubyte-float-conversion of the color inside gl4es)?
In case with q3 exactly, in 1600x1200, differences is about 3fps. I.e. workaround done in ogles2 better, and give 3+ fps in compare when we has workaround in gl4es. Probably when it all will be done in hardware, in warp3d, and without workarounds, it will give us another little speed increase for few more fps ?
Quote:
Next to come is the workaround for VBOs. Do you have sth. for testing here too?
Not sure to be honest.. ptitSeb added some initial support of VBO some time ago, when we test q3, but at that time it give no speed differences at all (and i rechecked now, its still make no differences in quake3 at least), so i just think it didn't works at moment in gl4es.
As i understand all VBO support in gl4es for now emulated. And that what was added as "initiall support of VBO" , or not works , or works wrong. I will ask him about again, maybe now he can have a look at this more deeply.
Luckily that's no problem. The respective commands of ogles2, namely glUniformXX, only operate with 32bit-floats and 32bit-ints. So this limitation "only" affects VAs, and out of those only VAs that are defined via glBufferXXX and glVertexAttribPointer (the glVertexAttribXf functions only work with floats).
That'll change when uniform booleans are finally supported.
Quote:
However, I won't put too much effort into optimizing those workarounds. I hope that this is only a temporary necessity and that it can be removed rather soon again
Yes, hopefully.
@kas1e Quote:
Not sure to be honest.. ptitSeb added some initial support of VBO some time ago, when we test q3, but at that time it give no speed differences at all (and i rechecked now, its still make no differences in quake3 at least), so i just think it didn't works at moment in gl4es.
I'm pretty sure that Quake III does NOT use VBOs. GL4ES might use VBOs when implementing the compiled vertex array extension, though.
@Hans Yeah, i mean usage of real VBO in gl4es when compiled vertex array is used, and that should made difference in q3 as well when extensions enabled, and that what i test when says about VBO.
Anyway, ptitSeb say it isnt done yet, so all VBO in gl4es in whole only emulated for now, and that what was done as initial support of VBO, was just fast-test-hack, so -> no VBO at moment
That'll change when uniform booleans are finally supported.
Yes, if Nova / the damn SI then expects 1-byte DBO data internally (and from what you told me it will ), then this will become an issue. Luckily the respective DBO-update-code is well isolated inside ogles2 and integrating a type conversion of this kind should be rather (!) easy.
@kas1e Quote:
In case with q3 exactly, in 1600x1200, differences is about 3fps. I.e. workaround done in ogles2 better, and give 3+ fps in compare when we has workaround in gl4es.
Hehe But yes, actually something like that was to be expected after looking at the workaround in gl4es. ogles2.lib does the conversion on the fly while copying the data to the internal VBO. That this is faster than to loop over the memory twice is no wonder.
Quote:
Probably when it all will be done in hardware, in warp3d, and without workarounds, it will give us another little speed increase for few more fps ?
Of course it will be faster to don't do those workarounds, but I can't say by how much. It depends on how often the respective game or lib triggers it per frame and how big the data is (that's of course also of interest when it comes to sending that stuff to VRAM, e.g. 4 bytes vs. 16 bytes per color per vertex). And it depends on how the game works: if a game would use true VBOs (which aren't modified all the time) then the impact would probably be near to zero, because all the conversion and sending to VRAM would ideally be done only once per polygon-soup.
Quote:
Anyway, ptitSeb say it isnt done yet, so all VBO in gl4es in whole only emulated for now, and that what was done as initial support of VBO, was just fast-test-hack, so -> no VBO at moment
Alright, then I'll stick do my boing-ball test for now
Do you have in mind new progs or games that may now be ported to OS4 with a working GL4ES ?
In general everything opensourced, which fit our deps (like no XWindow, no QT5, no heavy boost usage, but which use SDL1/SDL2 and opengl up to 3.x).
Probably everything which done for minigl before and was slow can be reported for sake of tests, to keep those ones which will be faster. But in case with minigl probably better wait once Daniel's minigl-reloaded will be done. So everything will works over ogles2/nova, and no need to recompile (and gl4es version probabaly will be no faster than Daniel's minigl-reloaded).
From top of head the new things which can be ported over gl4es are:
New version of Blender (at least version 2.68 for sure was tested with gl4es, and it works. ptitSeb through didn't tests latest ones which needs shaders, but should work. Of course, if those shaders will not use arrays, as arrays in shaders didn't supported in nova at moment).
Everything which done over Irrlich Engine. Almost all examples from it already works, and i even ported supertuxkart 0.8.1, which half of working, but that not because of problems with gl4es, but because patches boredom in that version of supertukkart are ugly. They somewhere used "//", somewhere "\/", somewhere another way, and there no single rule, all looks like mess, but game in terms of rendering of graphics for sure works. Through, without game's shaders, as they use arrays, and nova didn't support them. But game can be runs without their shaders anyway.
Also those ones works over gl4es: Foobillard++, Zyn-Fusion, OpenRA tiberian sun, Astromenace , freeorion, Minecraft, OpenMW, SeriousSam (both First and Second Encounters), RVGL (ReVolt GL), parsec47 and so on.
In other words, there almost no restriction about opengl now, except one: shaders in Nova didn't support arrays, so, any opengl stuff which use shaders, which use arrays, will not works till arrays support in nova not done. In others: no restrictions anymore. Sure, some quirks can arise, but if they gl4es related ptitSeb fix it all fast always.
All work there done by 3 persons: Hans, Daniel and ptitSeb. All i do its only put pieces together and report bugs, nothing more :)
You're undervaluing the work you're doing. Thanks to you we have a GL4ES port progressing, which will open up a lot of extra software. Plus, it's helped test GLES2 and Warp3D Nova more extensively, and that's resulted in both fixes and improvements.
* Warp3D Nova and OpenGLES 2 library have had major updates including significant work towards enabling the recent GL4ES wrapper and game ports to work **
@Spectre660 Yes, now when its all in hands of users, i can at least release quake3 and neverball/neverputt ports :) While quake3 didn't offer any speed wise improvements (even a little slower than minigl ones), but it give better rendering in few places. But in the same time, neverball/neverputt are 2x times faster, which is worth of course.
In reality, in what i hope now, is that now i can just make LettersFall game port public and fix issues in it: distored and buggy textures in game on my setup, but not on Daniel's setup, which mean its something random and dunno to what related. On other (non amiga) hardware all is ok of course. Maybe with more tests from other's we will be able to find the roots of issue.
Ok, let's start from the buggy ones (as find out roots and fix problems is more important than rereleasing another time quake3 :) ).
So, all the tests should be done on latest ogles2.library and warp3dnova.library. ogles2.library should be 1.22, and warp3dnova.library should be 1.58. It is very important to have those versions , as if not, tests may not help.
There is how it looks like on my setup when i choice "options" or "howtoplay" or "highscores" or start a game (you can see distorted textures of text, they like doubled and shifted randombly):
My setup is x5k with HD VERDE (branded as some r250 if i remember right) and RadeonHD.chip 3.4 (some beta one, but bugs the same with all other previous versions too).
What is interesting, Daniel on his setup (if i remember right its some Sam), do not have this issues. Which mean it is kind of random at moment.
Will be nice if some of you can make tests on their setups. That bugs not always shows right away, you just need to go to the options of game , and try to navigate by "up/down" a bit, etc.
There is how it looks like on my setup when i choice "options" or "howtoplay" or "highscores" or start a game (you can see distorted textures of text, they like doubled and shifted randombly):
It's the same with me My config X1000 & Radeon R9 270 (RadeonHD v2.22).
I would add that in the case of Neverball compilations, which you threw on the server in March, I did not notice any changes in plus. The game starts without crash maybe once per 5 attempts, and then there are graphics corruption.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
).
