When we use gl4es we are lower than with glew + egl_wrap, as you say a simple game but what you forgot… is that it is a game coded for Windows or Linux initially, our system requires some additional optimizations and we would surely have to rewrite some parts of the game to be able to gain a few frames per second. Then we use wrappers, which is a little more greedy too so there are still some lost images. Natively (shaders) we are at the top and the game is running at full speed.
As for the disappearance of the alignment, I also don't understand why it is this function which causes the engine to crash.
To use shaders it is actually integrated into my new version egl_wrap For information it is the gl_render.c rendering but there are a lot of corrections to be made because the shaders are not completely compatible with our system, currently I am correcting a color problem and it took me a little time to be able to have a rendering.
When we use gl4es we are lower than with glew + egl_wrap, as you say a simple game but what you forgot… is that it is a game coded for Windows or Linux initially, our system requires some additional optimizations and we would surely have to rewrite some parts of the game to be able to gain a few frames per second. Then we use wrappers, which is a little more greedy too so there are still some lost images. Natively (shaders) we are at the top and the game is running at full speed.
I can understand it with Doom3, but not with Wipeout which works even on old classic amigas and radeon9250 on 60 FPS with no problems. Re-written code can acts worse of corse, but not _that_ bad..
Also, if we check MorphOS's thread, with this WipeOUT rewrite they do have:
Quote:
between 100-60 fps (closed spaces vs wider scenery) on fullscreen 1280x1024 @ 24bit on a PMAC 1.4GHz 256MB Vram 9800Pro AGP 2x. It's ultra smooth, to say the least, amazing! Old version resulted to system freeze after quitting but latest one is bug free.
So i not sure how with RadeonRX geennaam had 30-50 fps..
Quote:
On version pure shaders i have 140fps on my X5000
Did geennnaam test some other version, and not the correct one with shaders where you had 140 fps ?
@Huno Can't download from wetransfer sadly, but why there need for glew and egl_wrap in there ? I mean, why not just gl4es ? More layers can cause issues as well, for legacy build there no needs not for glew, not for egl
it's not an overlay as you say, I correctly integrated gl4es into egl_wrap and you must have missed an episode because the version compiled at the very beginning of the thread runs at 30fps with gl4es I run at 90fps with egl_wrap in wrapper GL without native shaders so much better. sorry for the archive. Can someone share it at kas1e?, thanks
@Huno Did i understand right what you say , that when you compile with GL4ES you have 30 FPS, but when you compile with EGL_Wrapper on top of GL4ES you have 90 FPS ?
Quote:
because the version compiled at the very beginning of the thread runs at 30fps with gl4es I run at 90fps with egl_wrap in wrapper GL
The only reason why it can be faster with your additional layers, is that you hardcore change GL4ES for your own use, so to reduce functionality or something in favor of better speed, that correct ?
Quote:
My legacy build use Glew by choice
What i mean, that Glew it's additional layer on top of all other layers. And this can make things behave different.
If you say, that pure GL4ES build with Legacy code give 30 FPS, and your build with GL4ES integrated with EGL_Wrap and Glew give 90 FPS, it only means that or you don't go Legacy route in the game, or, that you change the GL4ES itself for your own use via customizing internal shaders gl4es build or/and via reducing functionality/quality.
I mean, if you use something, and have 30 fps, and then add on top of it 2 more layers, and it gives you 90 fps, then it means that our you change gl4es, or you go another code-route for handle GL in the game.
@kas1e I simply use gl4es for native gl calls and functions, when I am in egl_wrapper I go directly via ogles2 with proprietary internal shaders and of course glew use egl_wrap that's why. then the version which was used for games at 30 fps uses an old version of egl_wrap not really optimized
When I am in egl_wrapper I go directly via ogles2 with proprietary internal shaders
As so, that explain it then. It just means not original gl4es, but a modified .. Maybe worth to update original gl4es with such changes as well ? All other gl4es builds can benefits from then
I don't think it's beneficial for other systems because it remains native to AOS4 and what's more it's very proprietary, especially for the egl_wrap part. My library will be available this weekend and you can have fun with it and do benchmarks if you wish, more than 4 years of development and additions of all kinds to have an all-in-one library (which continues to be improved)
I don't think it's beneficial for other systems because it remains native to AOS4 and what's more it's very proprietary, especially for the egl_wrap part. My library will be available this weekend and you can have fun with it and do benchmarks if you wish, more than 4 years of development and additions of all kinds to have an all-in-one library (which continues to be improved)
Will be very interesting to test, that for sure :)
Btw, the new version will help to gain some more fps in doom3 as well ?
I'm working on multithreading for doom3 and yes of course we will gain some Fps (I haven't been able to test this part yet). I mainly focused on glew which will allow us to make good games and I hope that more users will use my egl_wrap for their work
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
