@Cowcat:

Thanks for this new version!

I have graphic bugs at menu and loading game (menu and progress bar)

Mouse seems don't work too (only right button to jump and middle button to zoom)... (Maybe SDL2 problem?)

X1950 Pro here

How to activate r_renderer ARB2 option please ?

[EDIT] Seems i have activated with "doom3 r_renderer ARB2" in a shell
I have WARNING : R_AutospriteDeform: autosprite had odd index count
Maybe could help...

[ Edité par Papiosaur 05.09.2022 - 14:01 ]

@Papiosaur

From console type in the command.

The mouse bug is probably the same that happend with the old "rogue" version. It could be what I disabled months ago but never showed in my system. It's on sys/morphos/glimp source:
SDL_SetWindowGrab.

Someone could recompile/test with his system and re-enabling this function again, before releasing a new binary.

For further stuff related to D3, better its own thread.

@bigfoot

What kind of shaders support in for now ? Pure binary ones ? Or GLSL 1.1 (or so) supported ? And if so, how full GLSL support are ? Or it's all about old ARB shaders for now ? If it still GLSL ones, did you wrote your shaders compiler from scratch from GLSL to SPIRV (or whatever at lowlevel tinigl use) ?

In other words can you a bit explain "shaders support" , just so to understand how far it all to be able to made morphos versions of some of my stuff.

I tried to check examples directory, and while there is ready to run "shader_test" binary, there is no source code for. All i can found in the "shader_test" binary by simple cheking content in , that there is just old ARB shaders, and not GLSL or SpirV ones. That correct ?

Thanks for answers

[ Edited by kas1e 05.09.2022 - 13:35 ]

Quote:

Added extensions to the latest tinygl archive are GL_ARB_fragment_shader/GL_ARB_fragment_program and GL_ARB_vertex_shader/GL_ARB_vertex_program. GLSL support is GL_ARB_shading_language_100.

It's GLSL 110 then, which sadly not very decent :( But i assume those who will works on shaders can migrate from todays shaders to v110, just need a bit of rewrite..

Probabaly there were reassons to go for v110 firstly and made it all as extensions ?

What intersting me most, how complete GLSL support even of 110 are, and were there written GLSL parser/converter from scratch or something else were used ?

@kas1e I'm not sure of my answer but i test actualy the new tinygl with ScummVM
and ScummVM detect GLSL 1.20.

I found that and if i understand correctly, tinygl go to OpenGL 2.1.
https://www.khronos.org/opengl/wiki/Core_Language_(GLSL)#OpenGL_and_GLSL_versions

[ Edité par beworld 07.09.2022 - 07:38 ]

Quote:

The Radeon monitor being updated is to address a small bug fix for R200 to make cube maps work. For R300, the Radeon monitor from MorphOS 3.17 will work fine. However, the Radeon monitor from MorphOS 3.7 might be a bit too old.

That Radeon 9800 Pro, is that the Mac edition or a flashed card?

If you send me an email (see my signature), then we can try and see if we can figure out why newer Radeon monitors don't work right for you.

Quote:

Thanks! I didn't actually get to test a lot on R200 for this release, so I missed this one. I'll check it out and get it fixed in the hopefully not too distant future :)

kas1e,

TinyGL now supports GLSL 1.20, which is what is mandated by OpenGL 2.1, which is the newest version of OpenGL that R300, R400 and R500 can support. GLSL 1.30, which is what is mandated by OpenGL 3.0, introduces for example integer variables in shaders, which the R300/R400/R500 does not and cannot support. So until the R600 driver is done, no newer version of GLSL can be supported.

beworld has been super helpful and tested a lot of things with shaders already, which has lead to a bunch of bugs being found, which will be fixed in an upcoming TinyGL update, which again will almost certainly be ready this week. What this means is that unless you want to be on the bleeding edge of testing, you can easily wait a little bit and let others test and get bugs ironed out before trying it yourself.

@bigfoot
Thanks for answer !

Did you wrote your own GLSL parser to binary data or it's done by some 3d party stuff like glslangvalidator or so ?


Btw, to find all the possible bugs in GLSL shaders will be nice to have something like ShaderJoy tool we have on os4: http://os4depot.net/share/graphics/viewer/shaderjoy.lha, which can use shaders from https://www.shadertoy.com. With this one i find hundred bugs which devs later fixed and that all improve GLSL support a lot in our drivers. So maybe it worth making something simple-easy at least to be able to load up those shaders just for bug-hunting.


@beworld
Sounds good! Lately i bug-report scummvm guys in terms of shaders and they did fix all of them (at least those which used in Grim, Myst, Wintermute3D, et) so they works on big-endian fine. If GLSL1.20 will works as it on morphos, it mean morphos port should works as it without issues too with "opengl with shaders" renderer.

[ Edited by kas1e 07.09.2022 - 13:00 ]

I'm not sure if Capehill would be open to letting ShaderJoy be ported to MorphOS but it's worth an ask.

Edit:

There's an open-source version of ShaderToy for iOS here.

[ Edited by Samurai_Crow 07.09.2022 - 11:52 ]

> letting ShaderJoy be ported to MorphOS

ShaderJoy requires OpenGL ES 2.0, of which there is no implementation on MorphOS, so it wouldn't be a straightforward port at least.

I updated TinyGL to the latest public beta and run my 4 programs wich use 3D acceleration. Everything looks correctly.
I also updated SDK and rebuilt my current project. The result is perfect. No problems detected!

Thank you for backward compatibility. :) Currently this is very important for me.

Re:ShaderToy source

A quick search on Brave Search revealed this GitHub project. I don't know if it's any more straightforward than the iOS source I linked above in ObjectiveC.

Quote:

At least a magnitude more straightforward to port.

Still, probably 99% of shadertoy shaders will simply fail to work on our totally outdated GPU. Keep in mind that those R200/R300/R500 belong to the very first programmable GPUs with GLSL.

For example, R300 has 64 instructions limit (and even less for R200), no loop, limited conditional, no jump, no native sin/cos instruction (it is emulated but takes a fair number of instruction to do so), no support for integer, just float (FP24 for r200/r300, FP32 for r500).

{precison}
After some deeper inspection, vertex supports native sin/cos instruction but fragment doesn't and must emulates those instructions.
{/precison}

It still can do wonders but with 20 years old shaders.

For example, this kind of shaders are more likely to be working :

https://graphics.cs.wisc.edu/WP/cs559-sp2016/2016/03/08/glsl-shader-examples/


[ Edited by Tcheko 08.09.2022 - 14:50 ]

I've released another version of the TinyGL update. It is mainly a bugfix update, fixing some (but not yet all) of the many issues found and reported by beworld. Thank you for the testing and the reports!

Thanks bigfoot and BeWorld for this new release!

Quote:

So that mean most of today's shaders can't work until there will be support for more or less modern gfx cards ?

@beeworld

Is ScummVM's shaders works on current tinigl-beta ?

Fantastic! Another week, another update!

@kas1e
"all to be able to made morphos versions of some of my stuff."
Great. What program have you in mind to port to MorphOS?

Quote:

Maybe Irrlicht Engine or FoobillardPlusPlus?

Quote:

not yet...

Quote:

That's a correct summary. The less is superfluous nonetheless ^^.

Today's shaders are more like in many thousands of instructions when compiled... Some are even doing raytracing with...

For example, NVidia RTX3080 have 8704 shading units (ie kind of cpu executing vertex/fragment program) and 272 TMU (Texture Mapping Unit). Comparatively, R300 runs 8 vertex shaders and 4 fragment shaders and has only 8 TMU.

Also, current GPU runs in the 4 to 10GB VRAM ballpark...

Anyway, we will probably do wonders with that old hardware :)

@Tolkie,waldiamiga
Quote:

IrrlichtEngine surely at first (this one can works with very minimal shaders support or even without at all, just need to be opengl 2.x at least), foobillardplusplus also very possible. Things which use lots of shaders probably will be no go for current supported gfx cards: for example Words game quite heavy in terms of shaders support, Eldritch also do use some heavy shaders.. But of course, all depends on the level of GLSL support and the latest/better gfx card which will be supported on Morphos. Even old GLSL shaders of 110-120 version usually big enough with all those things which Tcheko descibe above, which if emulated, will made things with shader be slower than without.

For now for example i works on some port for os4 based on irrliht engine, which use just one single shader, this one: https://github.com/elnormous/RealisticWaterSceneNode

See there in directory shaders 2 glsl shaders, which while not big enough by code, still when i use them as it in the game, it drop the FPS in whole game play radically, even if it works and renders as expected. So i tried to optimize it as much as possible => by all this i mean, that even if shader works, it's to be seen how fast and good it is, as it can make things even worse if it written bad in compare with no shader usage at all. And it's quite common that things with shaders can be even slower (and on Windows/Linux that the same), than without. And if many things in shader will be emulated in software, then imagine how slow it will be and better go "no shaders" way.

In other words once bigfoot and co done, this will be very interesting to play with

@bigfoot: why Cube Map example up my G5 (X1950) to 100% please ? Bizarre no ?

Quote:

Of course! If these updates (or any MorphOS update) breaks anything that used to work before, then it's a bug. In that case, please report it to me (or use MorphOS' built-in bug report tool) so it can get fixed as soon as possible!