Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
110 user(s) are online (70 user(s) are browsing Forums)

Members: 1
Guests: 109

BSzili, more...

Headlines

 
  Register To Post  

« 1 ... 8 9 10 (11) 12 13 14 ... 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
@Daniel

Dunno if it good or not, but with new ogles2 (and with usage of new aglCreateContextTags2), bug still here as you say, but visually a bit changes.

I.e, now, when there is debug prinfs before aglCreateContextTags2 , bug are the same : no background:

Resized Image

But, when i remove debug prinfs before aglcreatecontexttags2, it is now show background broken like this:

Resized Image

Definately something shifts somewhere.

Should i also upload new cadog_archive with aglCreateContextTags2 or it is enough to have first version ?

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
@kas1e
It's simply not the culprit, just like every 2nd adjustment here and there it may simply change the symptoms somewhat. That's the way it is when there's some undefined stuff happening somewhere.

Quote:
Should i also upload new cadog_archive with aglCreateContextTags2 or it is enough to have first version ?

Thanks, no need to, first version is enough, as being said: whether you use old aglCreateContextTags with the non-conforming tag-IDs or aglCreateContextTags2 with the new ones makes no difference for what's happening under the hood and it's not the source of the problems.

EDIT: both your builds (as the ones before) produce correct looking results here, no menu distortion at all.

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
Quote:

EDIT: both your builds (as the ones before) produce correct looking results here, no menu distortion at all.


And that what i was fear of . As you didn't have memory trashing issues with LettersFall, you didn't have issues with Cadog's test-case.

But to add, not menu should be distored, but background picture of menu (white background / no white background).

Probably it will make no sense indeed to upload version where bug shifts , as it again, probably will not show ups on your setup.

Did you test it on x5k 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
@kas1e
That's what I meant, no background or whatsoever distortions at all here with cadog (only checked sam460 so far, will check x5000 later too).
Yes, doesn't come as a surprise to me neither
Go on, upload what you got, the more the merrier

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:

only checked sam460 so far, will check x5000 later too).


Maybe different memory layouts cause differences. Will be interesting if you have the same on x5k.

@Daniel , Georg

I follow Georg's suggestion, to try to recompile whole libgles with -O0 and -fno-strict-aliasing. And found that when i compile that list.c file from gl4es:
https://github.com/ptitSeb/gl4es/blob/master/src/gl/list.c


Just only with -O0 instead of -O2 , then i have on linking stage those errorrs:

Quote:

libgl4es.a(list.o): In function `rlVertex4f':
list.c:(.text+0xe838): undefined reference to `rlVertexCommon'
libgl4es.a(list.o): In function `rlVertex3fv':
list.c:(.text+0xe938): undefined reference to `rlVertexCommon'
libgl4es.a(list.o): In function `rlVertex4fv':
list.c:(.text+0xea14): undefined reference to `rlVertexCommon'
libgl4es.a(list.o): In function `rlNormal3f':
list.c:(.text+0xf780): undefined reference to `rlNormalCommon'
libgl4es.a(list.o): In function `rlNormal3fv':
list.c:(.text+0xf800): undefined reference to `rlNormalCommon'
libgl4es.a(list.o): In function `rlColor4f':
list.c:(.text+0xf860): undefined reference to `rlColorCommon'
libgl4es.a(list.o): In function `rlColor4fv':
list.c:(.text+0xf8f4): undefined reference to `rlColorCommon'
collect2: ld returned 1 exit status


Which for first kind of surprise, as if optimisation switch can cause such errors, then ..

And for second those words like "vertexcommon" and "normalcommon" make me think about our workaround we add for q3 before, where it was about "normalisation" as we think of.

In other words, can that shit be culpit ? I of course ask gl4es guy about as well , but more to know about the better.

EDIT: with -O1 also build fine, just with -O0 give those undefs.

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
@kas1e
Quote:
Will be interesting if you have the same on x5k.

Just like on my sam460ex I have exactly zero issues with any cadog build version. No distortions at all. The only true difference on our both systems is the RadeonHD.chip driver version (well, and the concrete gfx-card), IIRC. Mine is 1.17. Maybe we should try what happens if we temporarily exchange yours by mine.

EDIT:
For whatever reason the compiler apparently gets confused by the "inline" of rlVertexCommon.
Looks like with -O0 it doesn't inline it but creates a function call to it inside rlVertex4f etc., however it doesn't create this function which makes the linking fail.
Maybe you can make it link by adding a static in front of the inline. Or temporarily remove the inline hint.
What compiler (version) are you using?


Edited by Daytona675x on 2018/3/20 10:09:51
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
Issue with -O0 and undefs on linking was just because of glitch of our GCC version: with -O0 it remove inline function but somehow still want the inline version for linking. I remove those "inline" in front , and all builds fine.

Now, i tested letters fall with gl4es compiled with -O0 and -fno-strict-aliasing: the same damn issues.

@Daniel

Yeah, will try now with 1.17 you send me

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
@Daniel
With 1.17, issues in letters fall a bit changed (less visibly), but they still here. Try to go to the "options", and play with it (up/down many times, press on gadgets, etc ,etc). At least then i see distortion.

EDIT: about your edit about compiler issue: right, it was inline. But sadly -O0 -fno-strict-aliasing change a shit :) I use 4.4.3 one

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
@kas1e
okay, if it's still there then revert your system and forget about the RadeonHD.chip idea.

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
We probably mostly in interest to reproduce it on your system, as if you have no bug, how you can works with..

What a ..(amiga1200 (and 4000 too))..

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
@kas1e
Oh, I *have* a bug. I only have to start that Q3 build. The thing is simply that by "luck" Cadog shows no symptoms here.
Btw.: please also upload the Q3-hack-version which shows no symptoms on your side.

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
Yep, just with striped version of cadog it can be easer than with q3. Will upload hack-"fixed" q3 in few hours as well as some small example from irtlicht engine with and wuthout hack (as it behave on my side as q3)

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

Uploaded:

ioquake3_hacked.lha:
2 binaries inside, build with the same (last) versions of gl4es, just one version build as is, and other one with our hack.

irrlicht_example.lha:
That one is one of their demo examples which come with their engine. The same 2 binaries hacked and not hacked. But run them as they are: they placed in bin/amigaos4/ , and they will ask for "media" directory in root. I.e. just unpack all as it and run from where they are.

Just in case we will have differences on our setup, that how looks like that example without hack on my setup:

Resized Image

And that how it looks like with hack (and how it should be):

Resized Image


All the bins compiles with libgl4es compiled with -O0 and -fno-strict-aliasing, just in case, as maybe optimisation will make it harder to play with, but probably not worse anyway :)

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

Quote:

But yes, I do parse those manually


Seriously don't do that! Always use the Utility.libary tag AP to handle tags. It's so lightweight and easy to use , there is no excuse for writing your own code.




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
@broadblues
I think this little (in this case even uncritical) issue already has been covered in great depth when I said "Nice great stupidity by me indeed" and "I just fixed it for the next lib release."

@kas1e
Performance is a desaster, it has extreme hickups, but well, -O0 and your hack's temporary array alloc/free may easily be the explanation for this.
Q3 looks good that way here too (those other issues like wireframe-effect and depth-buffer-sky-issues aside), so at least here we seem to have more or less matching results



Edited by Daytona675x on 2018/3/20 19:28:41
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
Yeah, when we test that hack it was clear that perfomance will drop.

Did you check irrlicht example too ? Just to know if it also copy pattern as on my setup.

In meantime i port another simple opengl game called "dragon memory" and that one didnt have issues, sadly.

Will try something heavy, to see if there anything which can help us

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 popping in
Just popping in


See User information
@kas1e

I looked a bit around in cadog source. What happens if in sdlgl.c you comment out all calls to SDL_FreeSurface().

I don't really know GL, but what I see in there is code like this:

if (SDL_MUSTLOCK(img)) SDL_LockSurface(img)
glTexImage2D(img->pixels);
if (SDL_MUSTLOCK(img) SDL_UnlockSurface(img);

And my thinking is this: if glTexImage2D() is hw accelerated/asynchronous (no idea if it is), then after unlocking, the glTexImage2D() could still be in progress when the img == BitMap() is being killed/freed from memory. So img->pixels is valid when glTextImage2D() starts, but it may not be valid until it completes.


Go to top
Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just popping in
Just popping in


See User information
@kas1e

dprintf: do you have it set up to show up in console window (sashimi)? What if you make it go into file or NIL:?

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
@Georg
Thanks for looking at , but that probably not Cadog's problem, as same Cadog's code build over MiniGL give no problems (with the same SDL). Its something or with gl4es , or ogles2, or warp3dnova, or sdl1, or the way how i add it to sdl1.


Quote:

dprintf: do you have it set up to show up in console window (sashimi)? What if you make it go into file or NIL:?


I have real seral cable connect to pc with putty, so log everything on pc notebook, without setting up any additional sw on os4. In our case dprintf its just #define to IExec->DebugPrintfF.

It even not very much dprintfs , it also pure printf can shift the issues. Its like you add some function call somewhere (any fucntions, not exactly printf or dprinf) and behaviour may or may not change. Some random crap..

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
Tried to port CUBE2 for our tests for memory trash errors, and while binary runs:

Resized Image

Game sadly fail to start because of our shaders not supported arrays :) Shaders created for that game are very small ones, but still all of them use arrays.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top

  Register To Post
« 1 ... 8 9 10 (11) 12 13 14 ... 42 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project