Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
66 user(s) are online (56 user(s) are browsing Forums)

Members: 0
Guests: 66

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



« 1 ... 26 27 28 (29)


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: 235
@Hans
yes, really and yes, exactly
Took me quite some time to finally make them adjust their "article" back then (it's not just months but ~ a year ago btw., time flies), annoying.

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

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Joined:
2012/10/17 19:42
Posts: 76
@Daytona675x

I made wrong assumptions, I thought that EGL_Wrap was an OpenGL ES 2.0 wrapper for Nova just like yours. Should I stop reading Amiganews.de?

Apologies.

   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: 635
@Kamelito

Nah, don't stop reading if you enjoy the site. Just stay critical and ask questions when they need to be asked.

@Daniel

Great summary of a slightly confusing topic.

   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: 5136
@Hans,Daniel
As Capehill progress well with tracing of ogles2.library, i come back to fricking shark issue. Now with ogles2.library v2.4 it crashes on the same place, but crash a bit changes. I.e. the same stack trace, but while before it was lbzu r6,1(r8) where r8 = 0xffffffff , now it crashes on lwz r9,0(r4), where r4 = 00000000.

While 0xffffffff mean end of memory, 0x00000000 mean unitilized memory, which probably can point us on some other direction ..

I rechecked twice : with ogles2.library v1.22 we have 0xffffffff, with ogles2.library v2.4, we have 0x00000000. Probabaly issue just shifts a bit, but at least now its not end of memory, but unitialized memory (maybe it was even with 0xffffffff).

There is current crashlog:

Crashed processGameEngine_lto (0x6FE60DA0)
DSI verbose error descriptionPage not found in hash table (page fault)
Access not allowed by page protection (protection violation)
Access was a load operation
 0
00000004 60D04BC0 00000002 5AFC9020 00000000 00000004 00000010 00000008
 8
00000008 7F964490 00000000 00000010 00000004 61A6194C 660CF9B4 00000000
16
00000001 00000018 00000001 00000040 60D04C10 00000000 00000010 61A07888
24
62C60C04 00000000 61A07888 62C60C04 00000001 00000001 60D04C10 62C928C0
CR
42224848   XER00000000  CTR00000004  LR7F94BD70
DSISR
00000000  DAR00000000

FP0 
FFF80000A2028100 3FDAAAAAE0000000 4010000000000000 4052000000000000
FP4 
402A000000000000 405E000000000000 4038000000000000 3FF0000000000000
FP8 
3FF0000000000000 BFF000D1C0000000 4330000080000048 0000000000000000
FP12
BFF0000000000000 0000000000000000 2148120531251314 CA001F207AB0C790
FP16
943105273903CD3C 0F1446FB74B3E2C4 0A86924B501CC9B0 3FF0000000000000
FP20
4010000000000000 0000000000000000 405E000000000000 4010000000000000
FP24
4038000000000000 4052000000000000 0000000000000000 3FC5555560000000
FP28
BFE5555540000000 3FE3333340000000 3FE6AAAAA0000000 3FC9999A20000000
FPSCR
A2028100

Disassembly of crash site
:
B:Missed IRQdiff 2116
 7F964494
54C6003A   rlwinm            r6,r6,0,0,29
 7F964498
54E7003A   rlwinm            r7,r7,0,0,29
 7F96449C
4D820020   beqlr-
 
7F9644A07CA903A6   mtctr             r5
>7F9644A481240000   lwz               r9,0(r4)
 
7F9644A891230000   stw               r9,0(r3)
 
7F9644AC81240004   lwz               r9,4(r4)
 
7F9644B07C843A14   add               r4,r4,r7
 7F9644B4
91230004   stw               r9,4(r3)
 
7F9644B87C633214   add               r3,r3,r6

Kernel command line
serial munge debuglevel 0

Registers pointing to code
:
r9 module LIBS:ogles2.library at 0x7F964490 (section 0 0x2046C)
r13GameEngine_lto:__GLeeGLLoadFunction()+0x34 (section 23 0x7AE0)
r16module GameEngine_lto at 0x00000001 (section 0 0xFFFFFFDC)
r18module GameEngine_lto at 0x00000001 (section 0 0xFFFFFFDC)
r28module GameEngine_lto at 0x00000001 (section 0 0xFFFFFFDC)
r29module GameEngine_lto at 0x00000001 (section 0 0xFFFFFFDC)
ip module LIBS:ogles2.library at 0x7F9644A4 (section 0 0x20480)
lr module LIBS:ogles2.library at 0x7F94BD70 (section 0 0x7D4C)
ctrunknown (0x00000004)

Stack trace:
(
0x60D04BC0module LIBS:ogles2.library at 0x7F9644A4 (section 0 0x20480)
(
0x60D04C00module LIBS:ogles2.library at 0x7F94BD70 (section 0 0x7D4C)
(
0x60D04C70module LIBS:ogles2.library at 0x7F944B08 (section 0 0xAE4)
(
0x60D04CA0GameEngine_lto:gl4es_blitTexture_gles2.constprop.0()+0x1cc (section 1 0x36AEB0)
(
0x60D04EF0GameEngine_lto:gl4es_blitTexture()+0x3f0 (section 1 0x36DEA4)
(
0x60D04F80GameEngine_lto:bitmap_flush()+0x2ac (section 1 0x3239C4)
(
0x60D05020GameEngine_lto:gl4es_glViewport()+0x1e4 (section 1 0x323F38)
(
0x60D05040GameEngine_lto:_ZN13COpenGLRender22UpdateProjectionMatrixEv()+0x44 (section 1 0x1820A4)
(
0x60D05070GameEngine_lto:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x1a0 (section 1 0x139F1C)
(
0x60D05210GameEngine_lto:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x800 (section 1 0x13A57C)
(
0x60D053B0GameEngine_lto:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x800 (section 1 0x13A57C)
(
0x60D05550GameEngine_lto:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x800 (section 1 0x13A57C)
(
0x60D056F0GameEngine_lto:_ZN15CGameGUIManager12RenderWindowEP14IGenericRenderP11IGameWindow9SGameRect()+0x800 (section 1 0x13A57C)
(
0x60D05890GameEngine_lto:_ZN15CGameGUIManager8OnRenderEv()+0x104 (section 1 0x13A7F4)
(
0x60D059A0GameEngine_lto:.LTHUNK20.lto_priv.2069()+0x244 (section 1 0x1570FC)
(
0x60D05A40GameEngine_lto:main()+0x974 (section 1 0x28DDA0)
(
0x60D05D20native kernel module newlib.library.kmod+0x00002520
(0x60D05D70native kernel module newlib.library.kmod+0x00003234
(0x60D05F20native kernel module newlib.library.kmod+0x00003558
(0x60D05F50GameEngine_lto:_start()+0x170 (section 1 0x1920)
(
0x60D05F90native kernel module dos.library.kmod+0x00026724
(0x60D05FC0native kernel module kernel+0x0006b268
(0x60D05FD0native kernel module kernel+0x0006b2b0


Edited by kas1e on 2019/4/6 21:14:38
_________________
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: 2074
@kas1e

Attempting to load data from 0x00000000 is a null pointer error. AmigaOS doesn't set uninitialized memory to null, so this isn't necessarily uninitialized memory. A pointer may really have been set to null.

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: 5136
@Hans,Daniel,Capehill

About that fricking-shark issue: with help from Capehill we patch and ogles2 and warp3dnova, and we catch those functions:

from ogles2:

glCompileShader
glGenBuffers
glBindBuffer
glBufferData
glBufferSubData
glDeleteBuffers
glEnableVertexAttribArray
glVertexAttribPointer
glDrawArrays
glDrawElements

from warp3dnova:

CreateVertexBufferObject
DestroyVertexBufferObject
VBOSetArray
VBOGetArray
VBOGetAttr
VBOLock
BufferUnlock
BindVertexAttribArray
DrawArrays
DrawElements

And there is log (with stripped at begining about 25mb of data while game starts, show first screen, etc, just last 2mb till crash happens):

http://kas1e.mikendezign.com/aos4/gl4 ... w3d_and_gles_patching.txt

As can be seen, all data still looks sane (right ?) , and seems it crashes right after VBOLock().

Also see what happens after crash: 6 bad access and then our BufferUnlock. Then again after VBLock() 6 bad acess, and BufferUnlock. Its repeated 4 times and then all continue fine since then.


I do compare it with pure debug version of warp3dnova, and there is also point out on crash after VBOLock() , but with sane values, there is:

http://kas1e.mikendezign.com/aos4/gl4 ... shark/whole_w3d_debug.txt


After seeing logs, ptitSeb says that it seems the crash happens while filling the VBO with new data (because BufferUnlock() hasn't occured yet). Also, don't forget gl4es doesn't create any VBO, ogles drivers does.

And as it all about texture in stack-trace, that Texture 0 is a valid texture. It's not used for the blitTexture function, but it's used sometimes in games. And blitTexture doesn't create any texture anyway. The texture is already created, bitTexture only create a few vertex array and use glDrawArrays to draw the texture.


Edited by kas1e on 2019/4/6 21:28:39
_________________
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: 5136
@all
As Daniel says in ogles2 topic he fix issue with fricking shark, cawabanga ! Thanks all for time :)

_________________
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: 5136
@Daniel
Found that since ogles2.0, in quake3 i can see some blinking textures there and there. Retested many times that with 1.22 it works, and that since 2.0 with every next release (and included 2.6) issue still here. There is video over ogles2.6:

The issue visibly on the gate's main textures, but also sometime you can see how some "line" draws all over the game. Looks exactly the same as it was with foobillard++ before (while foobillard works fine with 2.6 in all modes).

Start watching from 25 second:

https://youtu.be/xKPWCviyQbw

Those blinks remind me the same blinks i have with foobillard when disable batching mode in gl4es, but which you fix lately in 2.4 & 2.5. It looks like it can be the same kind of issue just hiding somewhere else ?

I also notice the same kind of issue (i think its the same) in RTCW Reboorn when checking those sky-bugs , but its too dark in that place to video-capture it normally. But it looks exactly just in q3 on video above, just in some other places.

_________________
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: 635
@kas1e

Is the FPS counter behaviour normal for gl4es build? I don't remember seeing that kind thing earlier, like bouncing between 80 and 120 FPS (or whatever the readings are).

   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: 5136
@Capehil
Yeah its normal. The same for your sdl2 minigl build 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
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5136
@Daniel
Another issue we find when ptitSeb made some new changes in GL4ES:

Issue is with the default value of MAG filter for texture, that should be GL_LINEAR and not GL_NEAREST (we look at the spec here: https://www.khronos.org/registry/OpenG ... /xhtml/glTexParameter.xml for the default for other parameters).

So, ptitseb made some commit where he don't change Texture parameter if unneeded, and gl4es expect Mag filter to be GL_LINEAR , which in end cause some visuall differences as seems that GL_NEAREST is our default.

_________________
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: 5136
@Daniel,Hans
That bug in Quake3 with blinking textures which didn't happens in 1.22, but happens from 2.0 till 2.6 of ogles2.library, seems have no connection to the bug i see in RTCW Reborn (as i was in hope that it the same) , as at least with 1.22 of ogles2.library bug in RTCW still here, so, it can be also and not ogles2 as well.

I was able to catch the video of that bug too , there is:

https://youtu.be/nBVKit7tPPU

Also i was able to catch those "white lines on the walls" bug on the same place where we catch sky-bug before, and this time i can come very close to place where it happens and can be seen that it looks like as some missing/trasnaprent line, but not white one. It was white on the walls before because it was sky which trying to showups over transparent line.

There is:

https://youtu.be/nBVKit7tPPU

Strange through that it happens very rare. I see it only one time on floor, few times on the walls,etc. Maybe there is more, just maybe it visibly only when sky is under the hood, so "white" color can be seen.

@Hans
Can that transparent-lines be same issues as was in quake3 with "lighting beams" some time ago ? Maybe not the same, but close to it ?


Edited by kas1e on 2019/4/11 19:02:24
_________________
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: 2074
@kas1e

The flickering textures looks a bit like "z-fighting," where one surface occasionally ends up with a coordinate just above the other, so it ends up drawn on top. Alternatively, is something inverting the order in which those surfaces are rendered? That would have the same effect.

EDIT: Or, did the z-buffer get switched off temporarily?

I doubt that the transparent/white lines are similar to the old Quake 3 lines. If you look closely in the videos, you'll see that the line appears to come from an outer wall, but it appears on-top (or through) the inner wall. Look closely at the line visible from about 11-15s in the first video from your last post.

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
Just popping in
Joined:
2015/6/11 8:51
From Cologne
Posts: 235
@kas1e
https://youtu.be/xKPWCviyQbw
Please upload the respective savegame to my ftp. While I'm a pretty good UT99 and DukeNukem3D player (well, at least I was ~20 years ago) I always hated Quake and for some reason always get a headache and the need to vomit real quick with it :P

The other vids I have no idea what this could be, looks like a combination of z-fighting with object sorting order changing.




_________________
[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/9/11 11:31
From Russia
Posts: 5136
@Daniel
Quote:

Please upload the respective savegame to my ftp.


Your ftp/reports_here/q3config.cfg.lha

Unpack that file to quake3/baseq3/ (overwriting old q3config.cfg)

Then once start, choice "single player", and there Q3DM7 (so level 7). Once game starts, you not always will be spawn on the same place as on video, but level itself veeery small (just few rooms), so you can easy found those gates in case they not always will be starting point. Sure that blinking error happens not only on gates, just on them it most of time easy reproducable if walking/run/jumping around them.

@All
About those "White lines" in the RTCW Reborn, i just put link to the wrong video (see in post 572 there the same youtube links 2 times), second one where lines shows quite clear should be that one instead:

https://youtu.be/_6YQq9mHxiY

_________________
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: 235
@kas1e
Quote:
Your ftp/reports_here/q3config.cfg.lha Unpack that file to quake3/baseq3/ (overwriting old q3config.cfg)

Thanks! I can reproduce it. Interesting: it only happens if r_ext_compiled_vertex_array is 1.

EDIT: fixed it (ogles2_wip on my ftp). Comes at a significant performance loss though. The bug existed prior to 2.0, only that since 2.0 it became much more likely to show up.


Edited by Daytona675x on 2019/4/15 14:00:01
Edited by Daytona675x on 2019/4/15 14:02:34
_________________
[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/9/11 11:31
From Russia
Posts: 5136
@Daniel
Yeah, bug fixed, and yep, perfomance loos is pretty big everywhere :( There some results:


q3 1024x768 : speed loss ~ 12 fps
q3 1600x1200 : speed loss ~ 7.5 fps

fricking shark speed loss ~3fps

neverball: speed loss ~5 fps
neverputt: speed loss ~15 fps

foobillard++ : speed loss ~1.5fps

rtcw reborn 1280x720: speed loss ~3fps

Maybe even better didn't fix that bug and keep it as it ?:) At least in all other apps it didn't happens visually, only in q3.

_________________
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: 235
@kas1e
Quote:
Maybe even better didn't fix that bug and keep it as it ?

Nay! If you look at the absolute numbers the speed loss is measurable, yes, and therefore it is significant, but it's certainly not even near as severe as is the bug that got fixed...
I mean, AFAIK it's e.g. Friking Shark 100 -> 97, Neverputt 390 -> 375, Foobillard 55 -> 53.
Sorry, but those few fps really don't justify to keep that bug inside.

Quote:
At least in all other apps it didn't happens visually, only in q3

Luck. Well, not exactly, it depends on many factors. Yes, depending on how a program's rendering strategy / code looks like, the chance for the bug to reveal is higher or lower. And yes, for some games it actually is 0. At the moment!! Some future code change (even in Nova) may very well change that... The transition to ogles2 version 2.0 was such a chance-increaser.
So all in all I'd not even recommend to add some glHint to optionally disable the fix.

_________________
[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/9/11 11:31
From Russia
Posts: 5136
@Daniel
Yeah, only visibly real speed los is q3, in which we just collect fps by fps and once we was able to won over minigl, we again jump back :)

But sure, that all right, less bugs less problems.

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


« 1 ... 26 27 28 (29)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project