@kas1e Hmm, too bad, would have been an easy solution to the problem that you don't see quads because you forgot one vertex
Quote:
That probably can explain not accurate emulation of polygon :)
No, actually emulating GL_POLYGON via triangle-fans is the most common and a pretty good way to do it (and that's actually the way it is implemented in many drivers anyway).
Quote:
but in MiniGL, even that "broken" code works
No need to put the "broken" into quotation marks, it *is* broken and it actually should not render anything AFAIR the standard even says that incomplete primitives are not being rendered.
This looks plausible, two triangles are being drawn to emulate the quad. Your coordinates look okay too, the winding is the same as for your triangles, so it should not be culled. Unless Regal creates two triangles with the wrong binding?! What happens if you glDisable(GL_CULL_FACE) before the glBegin()? Other than that: no idea.
No, actually emulating GL_POLYGON via triangle-fans is the most common and a pretty good way to do it (and that's actually the way it is implemented in many drivers anyway).
Strange then why it looks different visually on the same 640x480 area.
Quote:
What happens if you glDisable(GL_CULL_FACE) before the glBegin()?
No difference..
Quote:
Other than that: no idea.
Its just something general and its for sure somewhere in the RegalQuads.cpp/RegalQuads.h. Maybe some endianes differences arise somewhere.
Congrats on getting this far! GLSL arrays support is definitely top priority for Warp3D Nova.
Nothing sticks out as wrong in the Regal logs. The vertex and index array data are what you'd expect them to be, and the glDrawElements() call looks right.
I'm surprised how wasteful Regal is, though. There's no reason to be creating all 16 vertex attrib arrays when you're only using one. I'm pretty certain that Daytona's MiniGL reloaded will be faster for legacy pre-shader stuff...
Mind you, Regal's quite an ambitious project, and there's a lot more that they're supporting than just the old fixed pipeline.
then it calls glBufferData(GL_ARRAY_BUFFER,...) for the vertex array: driver | glBufferData (GL_ARRAY_BUFFER, 1024, ..., GL_DYNAMIC_DRAW)
That should work, but it's a very odd order of operations. Normally you'd do this: driver | glBindBuffer (GL_ARRAY_BUFFER, 257) driver | glBufferData (GL_ARRAY_BUFFER, 1024, ..., GL_DYNAMIC_DRAW)
Perhaps the binding of the element array between those two is confusing our GLES2 lib?
It's a long shot, but worth taking a quick look at...
@ Daytona675x >That's all wrong. >from the stoneage.
Could you have answers not so raw and pretentious (in a word "not so german") Hans & Huno certainly have as much skill as you and always show a Zen attitude By advance thanks to you : It's only to make life better to everyone
I'm pretty certain that Daytona's MiniGL reloaded will be faster for legacy pre-shader stuff...
Yes, MiniGL Reloaded creates pretty optimal shaders and the whole lib is much more compact / tuned for performance. Quote:
Regal's quite an ambitious project, and there's a lot more that they're supporting than just the old fixed pipeline
Yes, MiniGL Reloaded's aim is somewhat different to Regal's goal: My MiniGL Reloaded "simply" wants to be a turbo-booster for MiniGL programs, using what we got now, whereas Regal wants to bring full desktop-OpenGL to systems with full OpenGLES2 / GLSL support.
Quote:
Perhaps the binding of the element array between those two is confusing our GLES2 lib?
While ogles2.library should not be confused by that command order I can of course not rule out that something goes wrong in my lib
@thellier Nehe tutorials are from the stoneage and what you said was wrong and involved bad advices that had the potential to put kas1e into more trouble, therefore clear words were adequat. Plus I don't like you for reasons you certainly know, so I won't try to use even nicer wording just to make you feel more comfortable. But I'm sure you can live with that. Now back on topic:
@kas1e Please mail me your stuff (executable of the quad example is enough) so I can take a look here with a diagnostic build of ogles2.library!
This is not legal ES 2.0 code, GL_UNSIGNED_INT is clearly not supported by the specs and therefore not in my ogles2 implementation. This glDrawElements - call will fail if it is parametrized like that.
However, it wouldn't be too hard to extend the library to swallow this.
EDIT: can confirm that probably you are right. I just for first trying do swap GL_UNSIGNED_INT on GL_UNSIGNED_BYTE - nothing draws, but then, i swap it on GL_UNSIGNED_SHORT - and it draws, just not quad, but some kind of triangle, but that expected imho, as short/byte 8 and int 16.
@Hans Quote:
I'm surprised how wasteful Regal is, though. There's no reason to be creating all 16 vertex attrib arrays when you're only using one. I'm pretty certain that Daytona's MiniGL reloaded will be faster for legacy pre-shader stuff...
I will put it all in next few days on github, with all amiga-ready-to-build stuff, so anyone will be able to clone it, and just "make SYSTEM=amigaos4 MODE=debug V=1" and library will be ready to use.
Then, any of us can "speedup" it even a bit. For example that what you notice "creating all 16 vertex attrib arrays when you're only using one".
@All
How to measure FPS in easy way without much code ? I have for SDL SDL_Ticks(), which i can use with SDL like this:
Through, i do check on glDrawElements() in whole Regal sources, and there is quite a lot of place where it called, and, with GL_UNSIGNED_INT all the time :(
Sure, it's out of specs, but will it worth of to change library's code so it will take INT's too ?
EDIT: checked 2.0 specs and 3.0, 3.1 and 3.2, starting from 3.0 and up, it takes GL_UNSIGNED_INT.. So probably author of Regal or take it as granted, or, realisation of drivers where he work on, even if give GLES2 drivers, use some bits of GLES3.
But at least it will be not hack if you add INT, just again work to make ogles2 be ogles3 :))
Great - and phew because it's no bug in my lib but a bug in Regal. Since Regal claims to be a OpenGL layer explicitely for ES 2.0 this specs violation is a clear bug.
However: you should *not* change Regal's code here and better revert the changes you just did for the purpose of this test.
I will tell Matthew about this issue and suggest to quickly enhance my OpenGLES2.library to support uint32 indices too, although that's OGLES 3 and not OGLES 2.
I will tell Matthew about this issue and suggest to quickly enhance my OpenGLES2.library to support uint32 indices too, although that's OGLES 3 and not OGLES 2.
Yep ! Just he should know how important that are, to make fixes to support Regal.
Btw, maybe it worth to rename ogles2.library to ogles.library then ?:)(current software which used it, can rename it not big deal). Just it already has some gles3 features, and probably (?) will have more with time, so we will have ogles.library which currently mean ogles2 with partial ogles3, and someday maybe ogles2+ogles3 (and, SDL2 no need to be changed as well, when and if there will be ogles3.library) :)
Btw, maybe it worth to rename ogles2.library to ogles.library then ?
No, it'll remain ogles2.library, because that's what it is and what it will still be. OpenGL ES (alone, without 2 or 3) is sth. *completely* different, it is a fixed function pipeline implementation much like desktop OpenGL 1.x
@Capehill :)) if he will do what i ask him, then we will have 2 wrappers :) but when i yesterday works on it code layout much worse and hacky in compare with regal
I want currently test some examples over mgl and regal-gles2, which give fps counter. Maybe you have some for mgl without glut ?
BTW, the shader compiler bug that prevented uniforms from being multiplied together is already fixed.
So the biggest barrier now is lack of array support...
Quote:
Then, any of us can "speedup" it even a bit. For example that what you notice "creating all 16 vertex attrib arrays when you're only using one".
Sounds good, although fixing it is harder than it sounds. MiniGL actually does something similar, where it has a static vertex structure that's designed for the max number of texture units. So the vertex array that's sent to Warp3D consumes more memory than needed, meaning it's less likely to fit in CPU caches and can't take advantage of fast consecutive memory reads.** This is especially true with CPUs that have smaller data caches.
Hans
** Reading memory in ascending order with no gaps tends to be very fast.
@kas1e I just added the OGLES3 feature to support uint32 indices with glDrawElements to ogles2.library. It's available on my FTP for ogles2 beta-testers now, including you. Give it a try
@All In meantime, i do check speed differences. As example i take nehe's lesson5 example (which, can be crap of course, but as we test speed of emulation can be ok).
So, i port it to mgl and to regal->ogles2 from sdl and you can download binaries and sources there:
You just run it, wait let's say 20-30 seconds, and then close by close gadget, and in console (from where you run them), you will see printfs about fps and stuff.
For me, in current form, and on that example, regal is slower :(
My results:
MiniGL:
Quote:
27488 frames drawn, for a total of 10097.000000 milliseconds Took approximately 0.367324 milliseconds per frame Avarage FPS: 2722.392790 Took approximately 0.470714 milliseconds per frame (with swap) Avarage FPS (with swap): 2124.430018
Regal over GLES2:
Quote:
32814 frames drawn, for a total of 16080.000000 milliseconds Took approximately 0.490035 milliseconds per frame Avarage FPS: 2040.671642 Took approximately 0.587737 milliseconds per frame (with swap) Avarage FPS (with swap): 1701.441460
As can be seen , minigl give 2124 fps, regal->ogles2 1700. I was in hope to see something like 5000 for regal->ogles2 at least :)
Through, to note, that is with fix about gl_int/gl_shorts which we tests yesterday, but imho that can't be reassons of that difference.
@Daniel If you can, maybe you can throw minigl binary version over your minigl-reloaded, to see what we will get with ?
@kas1e Such simple benchmarks are pretty useless. The number of vertices is so small that the time spent in MiniGL's software TCL->W3D-code is probably lower than Regal's Emu->OGLES2->Nova-code. Also note that the very first frame may probably take quite some extra time for Regal, because that's the frame where it will prepare the required shaders.
However, here are my results (sam460ex, some low-end SI):
Quote:
Regal: 21046 frames drawn, for a total of 23359.000000 milliseconds Took approximately 1.109902 milliseconds per frame Avarage FPS: 900.980350 Took approximately 1.285803 milliseconds per frame (with swap)
Quote:
MiniGL: 31525 frames drawn, for a total of 15411.000000 milliseconds Took approximately 0.488850 milliseconds per frame Avarage FPS: 2045.616767 Took approximately 0.621570 milliseconds per frame (with swap)
Quote:
MiniGL Reloaded: 34108 frames drawn, for a total of 19509.000000 milliseconds Took approximately 0.571977 milliseconds per frame Avarage FPS: 1748.321288 Took approximately 0.692096 milliseconds per frame (with swap)
So here Regal is by faaar the slowest. Classic MiniGL is fastest. My MiniGL Reloaded is close.
MiniGL Reloaded and Regal have to do the same job in that case here (and both will suffer from the first frame being significantly slower than the others).
But in contrast to Regal my MGLReloaded sits directly on top of Nova, so it has one layer less.
However, ogles2 already contains optimizations MGLReloaded still doesn't have, it's still work in progress and actually not optimized at all yet... (e.g. in this example here ogles2 will detect that the internal vertex-arrays didn't change so it won't issue a VBO update).
So if you want to draw a conclusion out of those tests then maybe that if comparing Regal vs MGLReloaded one can asume that Regal itself is coded very sub-optimal.
Quote:
Through, to note, that is with fix about gl_int/gl_shorts which we tests yesterday, but imho that can't be reassons of that difference.
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
AFAIR the standard even says that incomplete primitives are not being rendered.
