Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
79 user(s) are online (68 user(s) are browsing Forums)

Members: 1
Guests: 78

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



« 1 ... 14 15 16 (17)


Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
Just can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1949
@kas1e

Quote:
Yeah, just some games done like this, and its good if they can works as well without total rewrite :)

Of course. My hint is for developers writing their own apps/games.

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:
2009/7/7 3:34
From Toronto, Canada
Posts: 2258
@kas1e wrote:

"Ok, let's start from the buggy ones (as find out roots and fix problems is more important than rereleasing another time quake3 :) ).

So, all the tests should be done on latest ogles2.library and warp3dnova.library. ogles2.library should be 1.22, and warp3dnova.library should be 1.58. It is very important to have those versions , as if not, tests may not help.

There is test archive of that LettersFall3 game:

http://kas1e.mikendezign.com/aos4/gl4 ... fall/find_the_bug/lf3.lha

There is how it looks like on my setup when i choice "options" or "howtoplay" or "highscores" or start a game (you can see distorted textures of text, they like doubled and shifted randombly):"
------------------------------------------------------------------------------------------

On my X1000 all screens look and work normal...screen resizing too went well

my setup:Corsair GS800 800w PSU, Western Digital 250 GB SATA HDD (model:WD2500YS), 4GB Ram, Radeon HD7950-3GB GDDR5- Dual Slot, Lite-On RW DVD/CD, On-Board Nemo sound,8139B NIC, Catweasel MK4+

_________________
_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

   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: 4544
@328gts
Quote:

On my X1000 all screens look and work normal...screen resizing too went well


That because you didn't play with settings a lot. Sometime there needs to go from/to many times to get trashing and that probably related to the amount of memory installed on gfx card.

But that anyway not important anymore, as Hans already fix that issue.

Now we fight with the same issues which was happens in quake3 and irrlicht engine before, to which Daniel add workaround before, but we want to be it without workaround and all necessar conversion code be in Nova (so, maybe it will give another speed up, if all goes 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:
2009/7/7 3:34
From Toronto, Canada
Posts: 2258
@kas1e

sounds good ..be happy to try out any other beta versions as well

_________________
_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

   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: 4544
@all
Currently Hans add necessary conversion code, so all almost works without Daniel's workaround, but just need some tweaks from ogles2 side, so we wait when Daniel will back from his trip.

@Hans,Daniel
Another new facts interesting to discuss about speed of q3 over gl4es/ogles2/warp3dnova.

Surprisingly, we think before, that "compiled vertex arrays" extension give us some fps in gl4es , but its not. I mean at all, its pure placeholder. That what say gl4es author:

Quote:

Really, that compiled vertex arrays extension is not usable by gl4es. What it does is tell the opengl driver that the vertex data (and only the vertex data) are set and will not change between glLockArrays(...) and glUnlockArrays() so a opengl driver that don't have hardware transform can transform the vertices... But has gl4es use Hardware T&L (in shaders), it's just useless.
And quake3 make changes to other arrays (colors, textures UV) in between, so I cannot really build anything stable...


What it mean, that it just placeholder, and doing nothing for us.

All the speed we gain when enable gl extensions in q3 in gl4es version, come from "multitexture" extension: it give 10fps+. And another speed up we have when just use glDrawElements() instead of glBegin/glEnd route (another 10fps+ only).

compiled vertex arrays extension - does nothing as author say.

texture_env_add - dunno if does, but add nothing in q3 as well.

Soo.. Problem is that author of gl4es can't come up with anything good to make that glLockArrays (compiled vertex arrays) extension. He already tried a few things, but it's really only good when you have to transform the vertices in full software, and he have not been able to do anything usefull with it.

Maybe any of us can give any ideas so he may try to implement it ?

Official spec of that extension here:
https://www.khronos.org/registry/OpenG ... compiled_vertex_array.txt

The problem with this extension is that we can enable Vertex Arrays after the Locking... Making this extension pretty unusable.

If we look here for example: https://github.com/ptitSeb/ioq3/blob/m ... derergl1/tr_shade.c#L1279

We see the call to glLockArrays(...) and then the engine enable GL_TEXTURE_COORD_ARRAY and GL_COLOR_ARRAY. That means those 2 arrays are not Locked, but still used for drawing (and the values of thoses 2 arrays will be changed between the Lock and Unlock)...

So the client software can enable Arrays that are not locked, so that make the Lock/Unlock mecanism useless (for gl4es at least), because a drawing command is part on locked Arrays (like Vertex coordinates) and part on unlocked Arrays (like vertex colors or UV).

If anyone have any ideas how to make anything usefull with gl4es with that extension, any idea can help us.

_________________
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 can't stay away
Joined:
2007/1/26 21:48
From New Zealand
Posts: 1949
@kas1e

Quote:
Maybe any of us can give any ideas so he may try to implement it ?


A few possible ideas:
1. Put the vertex position data into non-interleaved arrays in a VBO. Then you can update the colour & texture coordinates more efficiently (better with caches and non need to upload the positions again)
2. Put the vertex positions in a separate VBO. Again, you'll be able to update the colour & texture coordinates more efficiently

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: 4544
@Hans
ptitSeb answer about:

Quote:

No sure I understand but you mean I do:

1. Create a VBO with vertex position, color, texcoords, normals, but non interleaved. And only update changed color / texcoords.

2. Create a VBO with only vertex position. Color and Texcoords and Normals out of the VBO.

?

Well, for (1) I can probably try to implement, but that seems to be quite some work, and I'm unsure of the performances gain. Plus I don't know what vertex attributes (color, how many texcoords, normals) will be needed for drawing.

For (2) I'm unsure how standard this thing is: some vertex attributes in a VBO and some in another VBO. While I can probably try to implement that, again, I'm unsure of the performances gain (as you still need to transfert colors and other VA) and unsure how various GLESv2 driver will accept this kind of things.

Has this optimisation are only for old engine, and those engines probably are running pretty well on most hardware already, I don't think it's worth the risk of slowing other stuff down, and not worth the added complexity of the code.


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


« 1 ... 14 15 16 (17)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project