I'm happy to see these results on X1000. don't worry about being late, there was no priority, you were right to take advantage of your family. thank you again for all the very precise tests that you carry out
hello, first you must give us the versions of your libraries (opengles2, warp3d nova and your graphics driver). it is important to remove any old version of doom3 because this new version has new options. we are waiting for your feedback, thank you.
Here on my X5000 and my X1000 it exits fine and I continue to work on my system with no issues. Moreover during my development phases on my X5000 I quit and restart the game a good number of times and always without blocking the system
Yes the glsl version will be slightly darker and indeed having modified some parts of the shaders there may still be small problems with triangle type rendering, sorry I haven't finished yet. As for getting 50 fps... in the current state there is a light problem that I can't isolate on amigaos4 (my engine under Windows runs wonderfully). The lights effects drop the engine from 20fps which is huge so to answer your question 30fps will be achievable and if we find that problem with the lights well… yes for 50fps
Like you said, we're moving in the right direction.
New version betatest 5 is on your link, download now !!!
News on this version:
Big work on glsl renderer (W.I.P) 3 renderers working now : Arb simple renderer opengl without spécials effects Arb2 use native arb2 shaders with all effects Glsl use modified glsl shaders with all effects Now by default use gamma in shader Brightness working on direct renderer with gamma in shader mode active Patch lights on shaders for speedup engine Patch internal image loader Egl_wrap for speedup convertion rgb -> rgba
Please replace your doom3.cfg and shaders dirs by my all datas on this release (on doom3-configs)
Now on glsl renderer on fullHD with all effects 26 fps
I continue to working on shaders and EGL_wrap (now on static)
yes it's normal, the shaders you see in the console are for the future glsl version (in writing), I will remove it in the next test version to avoid problems. as for your reaction to rtcw you are absolutely right and i also suspect a big bottleneck which is the lights and shadows. in the ARB version they are not there and you have seen how fast it goes.
Many thanks for this video of Dhewm3 on your X5000 040 I am happy with the progress of the work already done, but there is still more to do to keep it 100% playable.
Thank you again for your video broadcast which shows users that this is progressing and that it is real and not misinformation.
I didn't know about this warning about using both types of library. I use static libraries and shared objects simultaneously in all my projects on a daily basis and I have no problems. Just in your makefile you declare the statics first and last your shared objects and everything goes. For the moment it is not planned to make a static library but I could do a test for you so that you can test.
Excuse me for my somewhat late response. Yes as Kas1e said there were small problems at the time via egl_wrap to initialize native egl but now it works correctly (a triangle example proves it). As for the sdl1 and sdl2 part, everything also works wonderfully via my library (the examples are also there to prove it). On the other hand, it is necessary to respect the order of the code As for the example, it should work at compile time For my part, I have not yet migrated to a gcc higher than 4 (for lack of time) and I think that your compilation is with a higher gcc, hence the problem. Try a lower version and tell me.
This is not shader removal but simple ARB rendering which does not use native shaders. Users asked me to make this version to compare at the same level as the MORPHOS version (but my version is much worse than the MOS version and slower). that's why I marked for fun because this rendering will not be supported in the future. for information there will be 3 renderings: ARB, ARB2 (native shaders) and GLSL (opengles 2.0)
to answer your question: yes I am rewriting part of EGL_wrap to speed up GLSL rendering
Unfortunately, I cannot answer this question, having never worked on this tabor. Looking at the specs I think it would run slow, it would all be CPU related I think. but as we always say 'will have to test and we'll see'