Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
54 user(s) are online (43 user(s) are browsing Forums)

Members: 1
Guests: 53

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



« 1 ... 24 25 26 (27) 28 29 30 »


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5200
@Capehill
For sake of tests, try to replace in your test case, quads (or if it triangles_fans), on pure GL_Triangle : will then all works fine ? (taking aside wrong visuall rendering).

If it will be the same works fine with GL_Triangle, but works wrong when it quad/triangle_fan, then its 99% the same issue as i have in lugaru then

Btw, your quad_mystery test case are with pure glColors , no textures ?

_________________
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
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 658
@kas1e

Sorry, but it is using GL_TRIANGLES already. 2 triangles per draw call. No textures harmed. You have the sources :)

   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 11:31
From Russia
Posts: 5200
@Capehill

But at least it the same renders fine in first frames, and then make things messy after few frames. The same as in lugaru's case too. It should be something common between for sure ..

_________________
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:
2007/9/11 11:31
From Russia
Posts: 5200
@Capehill

Tried just with glColor's instead of textures : no issue. So issue happens when we have textures exactly : being it real textures, or dummy ones of filled colors does not matter.

I hope in end it will be not something about Sampler2D in the shaders ..

_________________
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:
2007/9/11 11:31
From Russia
Posts: 5200
@all
So i stripped it to pretty-pretty small test case (sure there still something to cutoff, but it should be at least more easy to read for most).

There is archive for tests:

http://kas1e.mikendezign.com/aos4/gl4 ... mes/lugaru/lugaru_bug.lha

Inside there is directory "bin" , in which just 2 binaries gl4es one and minigl one. Which use just 2 files from Data directory : config.txt and map/tutorial.

So to check how binaries reacts on your systems. ("esc" for quit).

Also there directory source, in which current stripped test-case , which is easy to build doing or "make -f Maekefile_mgl" or "make -f Makefile_gl4es" (necessary libSDL_gl4es, libGLU_gl4es and libgl4es placed in the root of source , from where gl4es makefile will take them, so nothing to worry).

Currently what we do there , is use for building those faces "GL_TRIANGLE_FAN" and dummy textures, content of which are colors (that all can be seen in skybox.cpp).

Give it a go, at least to see if on your systems its all the same as on my (i.e. minigl binary works fine, but gl4es one made wrong faces and co).

_________________
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/12/2 3:55
From Italy, Perugia
Posts: 3121
@kas1e

Tested MiniGL binary of course, i have a rotating cube with different colors per face, seems ok i think

Then after pressed ESC i have this output

Quote:
SDL_SetVideoMode() failed: No video mode large enough for 1920x1080
forcing 640x480...


   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2120
@kas1e

Quote:
Is there any way to speedup executing of the games, but still take the debug output ?:) Just with current output, it will be unpossible to run some games as it will take hour to reach menus, etc :)

The only way would be to let the debug log go to memory, and use dumpdebugbuffer to capture. Of course, you're only going to see the last part of the log.

Maybe you could do that, and then execute kdebug "console serial" for just the bit you actually want to capture.

Another option would be to try increasing the serial port's speed and hope that the other computer can handle it.

Quote:
You probabaly mess it with glClear(GL_COLOR_BUFFER_BIT); which i call before skybox.draw(); to clear the background when move camera. As far as i can see it happens like this:

No. Look closely at your slowed down video. After a number of seconds, the the left-most side goes a very dark grey, whereas the bottom one goes black.

Looking at your source-code, none of the sides are a dark grey, so where is that coming from? Is that your clear colour? Your video doesn't show all the sides, so I commented based on what I see.


Quote:
In post 513 i post the code, where i create 6 different textures of different colors.

Sigh. Why on earth did you do it that way? So yes, that's why I see a texture being created every single draw call. I didn't see post #513, so of course I thought I'd spotted something wrong.

Back to square one...

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2120
@Capehill

EDIT: Transferred this to a new thread, because this thread is getting too complicated. Click here to continue.

Hans


Edited by Hans on 2019/3/29 6:39:02
_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2120
@kas1e

I've downloaded your minimal example, and added a few printf()s to the driver for just the calls I'm interested in. Here's what I see:

The first frame (six sides drawn):
BufferUnlock: wOffset: 0, wSize: 260
BindVertexAttribArray: buffer: 0x64743e18, idx: 0
BindVertexAttribArray: buffer: 0x64743e18, idx: 1
BindVertexAttribArray: buffer: 0x64743e18, idx: 2
BindVertexAttribArray: buffer: 0x64743e18, idx: 3
VBOLock: buffer: 0x64743e18, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 240
DrawArrays
BindVertexAttribArray: buffer: 0x64745a18, idx: 0
BindVertexAttribArray: buffer: 0x64745a18, idx: 1
BindVertexAttribArray: buffer: 0x64745a18, idx: 2
BindVertexAttribArray: buffer: 0x64745a18, idx: 3
VBOLock: buffer: 0x64745a18, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 240
DrawArrays
BindVertexAttribArray: buffer: 0x64743018, idx: 0
BindVertexAttribArray: buffer: 0x64743018, idx: 1
BindVertexAttribArray: buffer: 0x64743018, idx: 2
BindVertexAttribArray: buffer: 0x64743018, idx: 3
VBOLock: buffer: 0x64743018, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 240
DrawArrays
BindVertexAttribArray: buffer: 0x64743718, idx: 0
BindVertexAttribArray: buffer: 0x64743718, idx: 1
BindVertexAttribArray: buffer: 0x64743718, idx: 2
BindVertexAttribArray: buffer: 0x64743718, idx: 3
VBOLock: buffer: 0x64743718, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 240
DrawArrays
BindVertexAttribArray: buffer: 0x64745318, idx: 0
BindVertexAttribArray: buffer: 0x64745318, idx: 1
BindVertexAttribArray: buffer: 0x64745318, idx: 2
BindVertexAttribArray: buffer: 0x64745318, idx: 3
VBOLock: buffer: 0x64745318, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 240
DrawArrays
BindVertexAttribArray: buffer: 0x634c6718, idx: 0
BindVertexAttribArray: buffer: 0x634c6718, idx: 1
BindVertexAttribArray: buffer: 0x634c6718, idx: 2
BindVertexAttribArray: buffer: 0x634c6718, idx: 3
VBOLock: buffer: 0x634c6718, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 240
DrawArrays

The next frame:
BufferUnlock: wOffset: 0, wSize: 68
BindVertexAttribArray: buffer: 0x634c7c18, idx: 0
BindVertexAttribArray: buffer: 0x634c7c18, idx: 1
BindVertexAttribArray: buffer: 0x634c7c18, idx: 2
VBOLock: buffer: 0x634c7c18, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays
BindVertexAttribArray: buffer: 0x634c8318, idx: 0
BindVertexAttribArray: buffer: 0x634c8318, idx: 1
BindVertexAttribArray: buffer: 0x634c8318, idx: 2
VBOLock: buffer: 0x634c8318, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays
BindVertexAttribArray: buffer: 0x64745318, idx: 0
BindVertexAttribArray: buffer: 0x64745318, idx: 1
BindVertexAttribArray: buffer: 0x64745318, idx: 2
VBOLock: buffer: 0x64745318, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays
BindVertexAttribArray: buffer: 0x634c6718, idx: 0
BindVertexAttribArray: buffer: 0x634c6718, idx: 1
BindVertexAttribArray: buffer: 0x634c6718, idx: 2
VBOLock: buffer: 0x634c6718, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays
BindVertexAttribArray: buffer: 0x634c7c18, idx: 0
BindVertexAttribArray: buffer: 0x634c7c18, idx: 1
BindVertexAttribArray: buffer: 0x634c7c18, idx: 2
VBOLock: buffer: 0x634c7c18, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays
BindVertexAttribArray: buffer: 0x634c8318, idx: 0
BindVertexAttribArray: buffer: 0x634c8318, idx: 1
BindVertexAttribArray: buffer: 0x634c8318, idx: 2
VBOLock: buffer: 0x634c8318, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays

The frame after that:
DrawArrays
BindVertexAttribArray: buffer: 0x634c7c18, idx: 0
BindVertexAttribArray: buffer: 0x634c7c18, idx: 1
BindVertexAttribArray: buffer: 0x634c7c18, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x64743e18, idx: 0
BindVertexAttribArray: buffer: 0x64743e18, idx: 1
BindVertexAttribArray: buffer: 0x64743e18, idx: 2
VBOLock: buffer: 0x64743e18, rOffset: 0 rSize: 0
BufferUnlock: wOffset: 0, wSize: 192
DrawArrays
BindVertexAttribArray: buffer: 0x634c8318, idx: 0
BindVertexAttribArray: buffer: 0x634c8318, idx: 1
BindVertexAttribArray: buffer: 0x634c8318, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x634c7c18, idx: 0
BindVertexAttribArray: buffer: 0x634c7c18, idx: 1
BindVertexAttribArray: buffer: 0x634c7c18, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x634c8318, idx: 0
BindVertexAttribArray: buffer: 0x634c8318, idx: 1
BindVertexAttribArray: buffer: 0x634c8318, idx: 2
DrawArrays

The next few frames also have one VBOLock and BufferUnlock call despite having 6 quads to draw, and only three VBOs to store the vertices in (DrawArrays is always DrawArrays(W3DN_PRIM_TRIFAN, 0, 4), so each VBO stores only one quad's vertices at a time). So, some quads have started to be drawn with the wrong vertex data.

Eventually the frames are just something like:
DrawArrays
BindVertexAttribArray: buffer: 0x634c7c18, idx: 0
BindVertexAttribArray: buffer: 0x634c7c18, idx: 1
BindVertexAttribArray: buffer: 0x634c7c18, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x634c8318, idx: 0
BindVertexAttribArray: buffer: 0x634c8318, idx: 1
BindVertexAttribArray: buffer: 0x634c8318, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x64745318, idx: 0
BindVertexAttribArray: buffer: 0x64745318, idx: 1
BindVertexAttribArray: buffer: 0x64745318, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x634c7c18, idx: 0
BindVertexAttribArray: buffer: 0x634c7c18, idx: 1
BindVertexAttribArray: buffer: 0x634c7c18, idx: 2
DrawArrays
BindVertexAttribArray: buffer: 0x64745318, idx: 0
BindVertexAttribArray: buffer: 0x64745318, idx: 1
BindVertexAttribArray: buffer: 0x64745318, idx: 2
DrawArrays

At this point no new vertex data is being uploaded at all. Since only three VBOs are used and none are updated, only three quads are visible.

I can now conclusively say that the bug is upstream from Warp3D Nova.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   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 11:31
From Russia
Posts: 5200
@Hans
Quote:

Looking at your source-code, none of the sides are a dark grey, so where is that coming from? Is that your clear colour? Your video doesn't show all the sides, so I commented based on what I see.


Yeas, its a clear-color. On that slow video i don't show all the sides because it very slow to even move mouse when capture log, i was hope, that you watch previous video, where clear color the same, and i show all sides :)

Quote:

Sigh. Why on earth did you do it that way? So yes, that's why I see a texture being created every single draw call. I didn't see post #513, so of course I thought I'd spotted something wrong.


I will put creating of dummy textures to the load() function, so there will be no lots of the same things, and probably it will make log more readable then.

_________________
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:
2007/9/11 11:31
From Russia
Posts: 5200
@Hans
Quote:

I've downloaded your minimal example, and added a few printf()s to the driver for just the calls I'm interested in. Here's what I see:


That mean also you was able to build gl4es version with no problems ? Good !

Quote:

I can now conclusively say that the bug is upstream from Warp3D Nova.


Dunno if i right translate that phrase, but you mean its can be Nova in end ? If so, can i help more with this ? I can reduce it pretty much more for sure

_________________
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:
2007/1/26 21:48
From New Zealand
Posts: 2120
@kas1e

Quote:
That mean also you was able to build gl4es version with no problems ? Good !

No. I added the printf()s to the driver.

Quote:
Dunno if i right translate that phrase, but you mean its can be Nova in end ? If so, can i help more with this ? I can reduce it pretty much more for sure

No. It's upstream from Warp3D Nova. The bug is NOT in Warp3D Nova.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   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 11:31
From Russia
Posts: 5200
@Hans
Quote:

No. It's upstream from Warp3D Nova. The bug is NOT in Warp3D Nova.


Sign.

Just yesterday we with ptitseb added looots of debug output, to see all the VA transfered, etc , everything clear and fine:

http://kas1e.mikendezign.com/aos4/gl4es/games/lugaru/log3.txt

So i will continue to strip test case then..

Also now, we need some debug output from ogles2 too.

@Daniel
Can you build ogles2.library which will printf all the stuff like VA, dbos and whatever ?

_________________
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:
2007/9/11 11:31
From Russia
Posts: 5200
@Hans
Btw, just in case, can you check via the same printfs you put to the driver, the Capehill's testcase , where he draw 4 quads, and then, after few frames , 3 of them just disappear (just to see, if it the same issues or not).

There is that test case (pure ogles2):

http://kas1e.mikendezign.com/aos4/ogles2/quad_mystery.lha

If it will produce the same strange things like with lugaru bug, then we can rule out gl4es at least.

_________________
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:
2007/9/11 11:31
From Russia
Posts: 5200
@Hans
Also checking warp3dnova log more, we see there ctxCreateVertexBufferObject, but gl4es don't create any VBO (i.e. it's using default VBO 0).

Taking in account our gl4es trace above there drawing command were the same all the time.

So, if VBOs seems to created by ogles2 driver, we need some trace from ogles2 to go forward. Because what we see from warp3dnova log and gl4es logs, things looks different.

So hope Daniel will be able to build version which print all those va, dbo, and whatever else can help us to see what and where going wrong

_________________
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:
2007/1/26 21:48
From New Zealand
Posts: 2120
@kas1e
Quote:
Btw, just in case, can you check via the same printfs you put to the driver, the Capehill's testcase , where he draw 4 quads, and then, after few frames , 3 of them just disappear (just to see, if it the same issues or not).

Something similar is happening. After the first few frames, the VBOLock calls disappear.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   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 11:31
From Russia
Posts: 5200
@Hans
So, if it similar, and in case with quad_mystery its pure ogles2 without gl4es, we probabaly can rule out gl4es then.

Now we need Daniel with debug version of ogles2.

If you can post the same output of warp3dlogs as you do for stripped lugaru-bug, maybe that will help Daniel as well ?

_________________
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
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 242
Oh my god, one trillion new posts... Luckily I don't have to read them
You can stop it now, I found and fixed the issue on my side when handling another remaining problem reported by Capehill a week ago. This turned out to be the cause for this here too.
The problem was in a quick-step data hasher which caused the hasher to produce identical hashs for very small only slightly different data packets.

_________________
[Facebook] [YouTube Channel]
   Report Go to top

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2120
@Daytona675x

Phew! Glad this one's finally done. Hopefully we won't have any more really strange ones like this.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   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 11:31
From Russia
Posts: 5200
@Daniel
Quote:

You can stop it now, I found and fixed the issue on my side when handling another remaining problem reported by Capehill a week ago.


Omg, that cool !

That remaining problem reported by Capehill was that "quad_mystery" thing ? (its just in last pages we find connection and the same symptoms between lugaru bug and quad_mystery)

@Hans

Quote:

Phew! Glad this one's finally done. Hopefully we won't have any more really strange ones like this.


Easy bugs probabaly fixed long ago, the remaining ones will be harder and harder imho :)

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


« 1 ... 24 25 26 (27) 28 29 30 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project