Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (Daytona675x)

Bottom

« 1 ... 17 18 19 (20) 21 22 23 »

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/20 12:50 #381

Not too shy to talk

@Hans

Quote:

I've already got >= 13 tests covering various if/else use-cases, so it's likely to be some obscure issue.

Hehehe, the famous last words of every programmer, including me, of course

Or as I prefer to say: "it works for me TM"

However, here is a simple freezing vertex-shader example.
With "if" it freezes. Without it works.
I think it can't be more minimal and obvious.


attribute vec4 vPosition;

uniform float freezer;

void main()

{

   gl_Position = vPosition;

   // use the following line to experience a Nova freeze

   // if(freezer>0.0)

   gl_Position.x +=freezer;

}

Here's an archive with two exes with the respective variants plus source (sorry, ugly, my std. messy modified mini test).

EDIT:
Digged out my serial cable and this is what I get if I wait a couple of seconds before doing a hard reset:


RadeonHD.chip (0): wait for 8 fifo entries failed (5 available).

Status:

RadeonHD.chip (0): GRBM_STATUS: 0xA01014A5

RadeonHD.chip (0):      FIFO_AVAIL: 5

RadeonHD.chip (0):      SRBM_RQ_PENDING_bit

RadeonHD.chip (0):      CF_RQ_PENDING_bit

RadeonHD.chip (0):      GRBM_EE_BUSY_bit

RadeonHD.chip (0):      DB03_CLEAN_bit

RadeonHD.chip (0):      SX_BUSY_bit

RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit

RadeonHD.chip (0):      GUI_ACTIVE_bit

RadeonHD.chip (0):

RadeonHD.chip (0): GRBM_STATUS2: 0x04000002

RadeonHD.chip (0):      SMX_CLEAN_bit

RadeonHD.chip (0):

RadeonHD.chip (0): SRBM_STATUS: 0x200000C0

RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): TC_STATUS: 0x00000000

RadeonHD.chip (0): TD0_STATUS: 0x00000000

RadeonHD.chip (0): TA0_STATUS: 0x00000000

RadeonHD.chip (0): TA1_STATUS: 0x00000000

RadeonHD.chip (0): TA2_STATUS: 0x00000000

RadeonHD.chip (0): TA3_STATUS: 0x00000000

RadeonHD.chip (0): wait idle failed. Status:

RadeonHD.chip (0): GRBM_STATUS: 0xA01014A5

RadeonHD.chip (0):      FIFO_AVAIL: 5

RadeonHD.chip (0):      SRBM_RQ_PENDING_bit

RadeonHD.chip (0):      CF_RQ_PENDING_bit

RadeonHD.chip (0):      GRBM_EE_BUSY_bit

RadeonHD.chip (0):      DB03_CLEAN_bit

RadeonHD.chip (0):      SX_BUSY_bit

RadeonHD.chip (0):      GRBM_STATUS__CP_BUSY_bit

RadeonHD.chip (0):      GUI_ACTIVE_bit

RadeonHD.chip (0):

RadeonHD.chip (0): GRBM_STATUS2: 0x04000002

RadeonHD.chip (0):      SMX_CLEAN_bit

RadeonHD.chip (0):

RadeonHD.chip (0): SRBM_STATUS: 0x20000AC0

RadeonHD.chip (0): VGT_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): PA_CL_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): PA_SU_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): PA_SC_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): VC_CNTL_STATUS: 0x00000000

RadeonHD.chip (0): TC_STATUS: 0x00000000

RadeonHD.chip (0): TD0_STATUS: 0x00000000

RadeonHD.chip (0): TA0_STATUS: 0x00000000

RadeonHD.chip (0): TA1_STATUS: 0x00000000

RadeonHD.chip (0): TA2_STATUS: 0x00000000

RadeonHD.chip (0): TA3_STATUS: 0x00000000

When using the no-if-no-freeze shader variant then nothing is put on the serial.

RadeonHD.chip version 1.17
Warp3DNova.library version 1.43
Those are the latest versions I got from Matthew. If you have newer ones, please mail them to me.

Cheers,
Daniel

Edited by Daytona675x on 2018/2/20 14:02:18
Edited by Daytona675x on 2018/2/20 14:03:04
Edited by Daytona675x on 2018/2/20 14:17:21

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/19 10:36 #382

Not too shy to talk

@kas1e
I won't have time until tonight, I guess. Drop me a note please if you came up with a test-bed by yourself in the meantime.
However, considering this

Quote:

dd = vec3(0.0);
dd =(nVP * gl4es_Color.xyz *_gl4es_LightSource_0.diffuse.xyz);

and

ss = vec3(0.0);
ss = (_gl4es_FrontLightProduct_0.specular.xyz);

Then no crash.

I'd say that it's pretty clear that the problem is inside Nova and related to if/else ?: just as we guessed. If that would crash too then a faulty DBO setup by ogles2 would probably have been a candidate too, but since it doesn't crash when removing the if/else construct only...

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/19 8:47 #383

Not too shy to talk

@kas1e
Glad that struct support works well now

I also asked Entwickler-X to test the new lib (quite some messy changes under the hood) with their very complex game projects: no issues, phew

@Hans
Quote:

Perhaps you need an aglDestroyContext() call before the IIntuition->CloseWindow() to make sure that happens first...

You don't need to close the window / invoke window closure with this example. Any desktop activity like clicking anywhere or moving the window will freeze the system here with that test-prog. It is not bound to window closure or so.

Btw. for ogles2 it doesn't matter if you forget the aglDestoyContext or put it behind the CloseWindow here; it won't touch the invalid window anymore, also not during auto-destruction of any active contexts on lib-close.
Of course using it in the correct order is recommended nevertheless ;)

Quote:

The shader compiler's if/else functionality is fairly well tested, and those if/else sections are pretty basic. Plus, the vertex shader compiles just fine when I do it manually.

I once had similar freezes with if / else in MGLReloaded (which uses Nova directly). However, back then it was an unnecessary if / else which I optimized away anyway. Apparently it also depended on overall code-structure, another if / else at a different place would work.
The defunct shaders always compiled / linked fine for me too, of course. Which is why I told kas1e to try to temporarily get rid of the ? : construct and see if that helps when he sent me those shaders.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/18 13:51 #384

Not too shy to talk

@kas1e
Yes, the issue apparently is that ogles2.lib has trouble with the uniform structs in the shaders (which is not really a surprise because there's no support for those inside yet).
On it, but it's unlikely that this is going to be added in such a short time as fix from above

So I suggest you do sth. more useful with this Sunday until you got mail from me

EDIT: just put an test lib update (1.19)on the ftp which
- should behave as before for stuff that worked as before.
- supports structs (also nested). So sth. like this "works for me" TM


// GLSL:

struct MyStruct {

  vec4 a;

  vec4 b;

};

uniform MyStruct x;



// C/C++

GLint loc=glGetUniformLocation(prog,"x.a");

glUniform4f(loc,1.0f,0.0f,0.0f,0.0f);

With a modified boing-test it works fine, but your test-app still crashs, reason unknown to me.

Edited by Daytona675x on 2018/2/18 20:26:10
Edited by Daytona675x on 2018/2/18 20:27:19

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/18 13:05 #385

Not too shy to talk

@kas1e

The only thing that pops to my mind is that you are using GL_UNSIGNED_INT for indices.
While ogles2.lib was just enhanced to support that, maybe gl4es does not? Looking at the log it ultimately issues a glDrawElements-call with GL_UNSIGNED_SHORT indices.
So maybe it creates wrong indices when doing the conversion it obviously has to do.
Change your test prog to use GLushort / GL_UNSIGNED_SHORT indices please.

Other than that: maybe Nova doesn't like the created shaders. In the past sth. like that could easily result in a freeze.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/18 11:56 #386

Not too shy to talk

@kas1e & ogles2.lib testers

Just fixed a bug with ogles2.library regarding glGetActiveUniform / glGetActiveAttrib:
A bug in the variable info translator Nova -> GLES2 caused malfunction of those. The returned size was in bytes instead of logical units and for glGetActiveUniform the returned type was most often 0.
Update is on my ftp (and in your mail, kas1e

)

However, regarding the freeze for that other example:
no idea so far, not even if it's ogles2 related or not. Have to dig deeper for that one.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/18 11:08 #387

Not too shy to talk

@kas1e
Quote:

did you recieve reports on mail about glGetActiveUniform(...) and glGetActiveAttrib(...)?

Just saw them now. Yes, most likely you found two (well, most likely it's just one) bug in ogles2.library. I'll see that I fix it now!

p.s.: sorry, forget my normal-problem talk from before. Obviously my quick look was too quick

You are calling glNormal and not glNormalPointer, so it's all good with the code in that area.

Edited by Daytona675x on 2018/2/18 11:28:03

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/18 8:12 #388

Not too shy to talk

@kas1e
Quote:

As for crash: sure, gl-code-wise it can be wrong, but it works copy of minigl example,

The normal array has to be larger and filled with correct normals, otherwise you are at least doing illegal memory reads with potentially trashed data.
And you know what trashed data for a normal likely is? Most likely not a normal anymore

And a normal which is not a normal may easily provoke crashs on code which asumes that it is a normal.
Please fix the normal-array and try again.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/18 7:37 #389

Not too shy to talk

@kas1e
Now, this looks even more promising as Regal

Checked your binary on my sam460:

Quote:

LIBGL: Initialising gl4es
LIBGL: v1.0.5 built on Feb 17 2018 23:41:49
LIBGL: Using GLES 2.0 backend
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Hardware test disabled, nothing activated...
LIBGL: Targeting OpenGL 2.0
LIBGL: Current folder is:RAM Disk:
20457 frames drawn, for a total of 11217.000000 milliseconds
Took approximately 0.548321 milliseconds per frame
Avarage FPS: 1823.749666
Took approximately 0.652686 milliseconds per frame (with swap)
Avarage FPS (with swap): 1532.130018

So on my side all the msec results for this test are (smaller = better):
Quote:

MiniGL: 0.488850
gl4es: 0.548321
MGLReloaded: 0.571977
Regal: 1.109902

So with this test it's a bit faster than my current MGLReloaded and, no surprise, slower as original MGL.

Didn't compare Regal vs gl4es, but if the feature-set is more or less identical I would concentrate on gl4es if I were you

(also because the author apparently is both active and helpful)

Quote:

So, once i try to run it as it, it freeze amigaos. But not all the time on the same place.

From a quick look, you only defined 6 normals for 8 vertices.

Quote:

glFlush();
IOGLES2->aglSwapBuffers();
glDrawBuffer(GL_BACK);
display();
glDrawBuffer(GL_FRONT);

What is that supposed to do?
It should just be:

Quote:

display();
IOGLES2->aglSwapBuffers();

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/17 9:43 #390

Not too shy to talk

Quote:

Probably for more accurate test, i can just skip first frame from fps calcualtion ?

Yes, in such simple tests that should do. If your test has several "stages" of such simple tests (e.g. first a rotating colored cube, then some texture effect, etc.) you should not measure the first frame of each sub-test.
IIRC we had a similar effect here once with some SDL-speed-test.

Quote:

But, i assume that its only like that for such a small test case , for big ones it should make a differences in positive side ?

As soon as MiniGL spends more time in its software TCL than Regal/MGLReloaded need to eventually update the internal VBOs / DBOs / whatever-bookkeeping, MiniGL will become slower. One can asume from the previous test that this turning-point X is reached significantly earlier for MGLReloaded than for Regal.
However, at some other point Y, if the workload is high enough so that the time spent by the GPU outweights the time spent in the respective library significantly, I expect Regal and MGLReloaded to give more or less similar results. More or less

Because then the quality of the shaders will become interesting and looking at Regal's shaders MGLReloaded will certainly beat it

I have no idea about concrete values for X or Y though

(also system-dependent, of course, just look at your and my results).

Quote:

I just can't imagine that regal will be slower than minigl :)) Its kind of make no sense then.. Only as some "slow emulation for legacy OGL" :))

As being said, it's no surprise that MGL is faster if the TCL workload is low. However, the gap certainly shouldn't be thaaaaat large. But then again: Regal's primary aim is not performance and looks like nobody cared about that aspect.

Quote:

Do you have maybe by hands some example, which we can put on mgl, mgl-reloaded and regal to see _real_ difference, i mean maximum which we can expect.

First of all you could massively increase the vertex-count here. Just put a nice for-loop around the glVertex-calls so that it creates some thousands of vertices. Other than that you could also make the TCL calculations more complicated. Most simple: move the objects to the edges of the viewport so that only half of them is visible. This will force MGL to modfiy / add triangles. And if smooth colored / textured shading is enabled it will also force it to create new color / tex-coord values.
You could also add lighting / more lights. However, then MGLReloaded's results will likely become useless because I didn't implement all features accurately yet, so I'd not recommend that for now if you want to compare all three variants. (oh, I forgot: won't work for now anyway because Regal uses arrays when doing lighting).

Quote:

arrays ... I ready to test any alpha, beta, when and how you wish, of course

May well be that ogles2.library will require some adjustments for array support too.

Edited by Daytona675x on 2018/2/17 10:21:54

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/16 8:41 #391

Not too shy to talk

@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.

No.

Edited by Daytona675x on 2018/2/16 8:59:49

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/16 7:34 #392

Not too shy to talk

@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

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/15 14:34 #393

Not too shy to talk

@kas1e
Quote:

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

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/15 13:15 #394

Not too shy to talk

@kas1e

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.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/15 12:31 #395

Not too shy to talk

@kas1e
Try this:

- change line 283:
GLuint indices[EMU_QUADS_BUFFER_SIZE * 6];
to
GLushort indices[EMU_QUADS_BUFFER_SIZE * 6];

- change line 329
dt.call(&dt.glBufferData)( GL_ELEMENT_ARRAY_BUFFER, n * 6 * sizeof( GLuint ), indices, GL_STATIC_DRAW );
to
dt.call(&dt.glBufferData)( GL_ELEMENT_ARRAY_BUFFER, n * 6 * sizeof( GLushort ), indices, GL_STATIC_DRAW );

- change line 331:
dt.call(&dt.glDrawElements)(GL_TRIANGLES, n*6, GL_UNSIGNED_INT, 0);
to
dt.call(&dt.glDrawElements)(GL_TRIANGLES, n*6, GL_UNSIGNED_SHORT, 0);

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/15 12:00 #396

Not too shy to talk

@kas1e
That may be it:

From the OGL ES 2.0 specs (which I comply to),
glDrawElements, type parameter:
Quote:

Specifies the type of the values in indices. Must be GL_UNSIGNED_BYTE or GL_UNSIGNED_SHORT.

But in Regal's quad emu you find this (RegalQuads.cpp, line 331):
Quote:

dt.call(&dt.glDrawElements)(GL_TRIANGLES, n*6, GL_UNSIGNED_INT, 0);

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.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/15 9:16 #397

Not too shy to talk

@Hans
Quote:

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!

Edited by Daytona675x on 2018/2/15 9:35:00

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/14 21:03 #398

Not too shy to talk

@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.

From your quad-log
Quote:

glDrawElements (GL_TRIANGLES, 6, GL_UNSIGNED_INT, 00000000)

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.

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/14 17:13 #399

Not too shy to talk

@kas1e
GL_QUADS, GL_QUAD_STRIP and GL_POLYGON are not supported by OpenGL ES 2.

If those quads don't work with your simple single-colored tests then Regal's mandatory emulation is probably flawed here - which would be kind of a surprise if it failed with sth. that basic!

Actually it would be such a big surprise that I don't believe it

Because of that and because your log output smells like it (3 lines being drawn...):

May it be that you try to draw a quad with only 3 vertices... ?

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Daytona675x

Re: Regal: OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Posted on: 2018/2/14 13:18 #400

Not too shy to talk

@kas1e
Congrats

[Facebook] [YouTube Channel] [Atomic Bomberman Discord]

Topic | Forum

Top

« 1 ... 17 18 19 (20) 21 22 23 »