Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
100 user(s) are online (65 user(s) are browsing Forums)

Members: 0
Guests: 100

more...

Headlines

 
  Register To Post  

« 1 ... 24 25 26 (27) 28 29 30 ... 42 »
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Just can't stay away


See User information
@kas1e

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

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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...


Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Not too shy to talk
Not too shy to talk


See User information
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.

Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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
Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Home away from home
Home away from home


See User information
@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!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 ... 24 25 26 (27) 28 29 30 ... 42 »

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project