@samo79
oops, done

@kas1e
done (also updated the precompiled binaries)

@Capehill
And, do you still recommend the Slimblade? I'm thinking of getting a trackball but right now I tend to favor some thumb-controlled device, mostly because I'd like to have mouse-wheel and buttons at the common locations. Do you have any issues with button clicking / wheel functionality?

@kas1e
Probably add the os4depot's current binaries into some "prev_version" folder to the new upload, just in case. After all, while there are many fixes and improvements we also know that there are problems with some games. I suggest to not leave people without a fallback.

@Raziel
Quote:
As I already told you: while ogles2.lib is mature enough, unfortunately Warp3D Nova doesn't support boolean uniforms as of now. I don't think that Hans is aware that you believe that this is a potential blocker for ScummVM, so maybe you should add a comment to that Mantis entry.

Or you could help yourself, because, as I said: ogles2.lib is mature enough and glUniformi (which is used to set bools and ints) works just fine with what Nova supports, namely ints, therefore you can easily work-around that problem by minor trivial modifications to the ScummVM's shaders to make Nova happy, no ogles2 or any other code changes required.

Just do the following in those shaders (scan #?.fragment and #?.vertex which contain "uniform bool", arent too many), e.g. replace

uniform bool textured;
...
if(textured) ...
if(!textured) ...

by this

uniform int textured;
...
if(textured!=0) ...
if(textured==0) ...

Or you can just take this zip which contains all of ScummVMs shaders already modified accordingly and the original ones, de nada, only took eight minutes, incl. being untested and eventual typos.

@nbache
Quote:
Yes. Those RadeonHD 4xxx - 6xxx have no real 3D support of any kind, with the exception of WaZp3D which implements Warp3D classic with a software- or compositing-backend (the latter gives you HW accelerated texturing). For some games this is good enough.

@samo79
@BSzili
Back then I tried to locate the modification which caused the Jedi problem (which may very well be a hidden sideeffect by my changes, although I was careful I cannot rule that out) but without luck, then I forgot about it. For now I have no interest to dig into it again.

@Raziel
Quote:
It's accessible for everyone, I don't see a problem here. Or did I forget to add one of those patches made for you to that trunk?

@kas1e
I can reproduce it with my SI setup (it's not just the bars shader btw.).
My tests indicate that it's a Nova 1.78 bug with practically 100% certainty, probably unique to SI, considering that it works just fine for you.

@eliyahu
Hi mate! That's a different construction site
The problem here is not ogles2 but MiniGL4GL4 which unfortunately is nothing but a very dirty hack with the primary goal to give Polaris users who are left without classic Warp3D support until now some last resort to play MiniGL games. If you have Southern Island and therefore native W3D classic support you should stick with the normal minigl libraries.

The thing with MGL4GL4ES is that it is pretty much just a GL4ES build with a MiniGL interface attached. Unfortunately GL4ES wasn't designed for being used inside a shared library which is why it's unstable as hell if being (ab)used this way. I'd have to make GL4ES fully reentrant first and replace all static and global stuff to make this a real alternative for old minigl. Until this is done (and I really can't say if or when I have time for this) it will have all sorts of issues, one of which is the screen-safer problem you're experiencing.

It's okay for many games which just open one window and without anything else running in parallel, but other than that...

@Capehill
I checked the GLSL compiler's preprocessor code, it's supported, so it should work. However I also found that the compiler's version which I'm using inside ogles2.lib apparently doesn't properly generate OpLine opcodes, so the ultimately reported line number is always 1...
This issue slipped through until now because due to Nova's formerly broken OpLine support it wasn't tested for real yet (I didn't receive the latest Nova yet which should be fixed accordingly) but only on my Windows test-environment where I used the latest official Khronos glslangvalidator to create test-SPIRVs.
Note: the reason why I'm using a rather old version of the GLSL compiler inside ogles2.lib is that later versions didn't support GLSL version < 1.4 anymore.

Anyway, I'll evaluate if I can update the compiler to a more recent version by now. If not I'll fix it to properly generate OpLine opcodes.

@magnetic
Of course the answer is a big no, requirements from page 1, 1st comment:
Quote:
This is a program that stresses even modern gfx cards.

@Capehill
Quote:
I'd recommend going for the exact JSON format which ShaderToy's API uses.

@Capehill
Great stuff, thanks! It's really becoming a killer app (and it certainly is the best offline Shadertoy viewer among all systems already)

@walkero
Only took a quick 10 minutes peek. Code appears to be straight forward rather old skool C++, this by itself shouldn't be a problem at all.
However, there's this big "dependencies.zip" which contains a ton of precompiled libs. Some are no problem (e.g. zlib, SDL, OpenAL, libogg), but some others, well, you'd have to check.
And of course the question remains whether the shaders can be handled by Nova.

@Lio
Sorry, no idea, I never tried, to be honest. I use Discord on my mobile phone.

@samo79
Ah, no, thanks for the reminder! Had no luck tracking it down back then and then totally forgot about it, sorry...

New Atomic Bomberman version 2.11 (network protocol version 13, unchanged) is now available (via auto-updater or get it from my homepage )
As always all relevant NG flavours (AOS4, MOS, AROSx86) and Windows are supported.

- networking: you can now manually enter an IP address. This allows you to play a network session if my homepage is down or if you're in an autarkic LAN or if your router causes problems with LAN sessions (NAT loopback anybody?).
Because I was too lazy to add new UI elements, the session-name is "abused" for this feature:
master: leave the session-name empty.
clients: type master's IP into the session-name field.
Note: only IPv4 is supported!
Cheers to Warzo for requesting!

And don't forget to join the Atomic Discord channel and / or the dedicated Facebook group!

Tchatching,
Daniel

@walkero
Thanks mate. Unfortunately:

@Templario
Oh my. Why didn't you listen to your friend? Will anything ever sink in?

Quote:
What? Can anybody make any sense out of this? WTF has Tower 57 to do with Cinemaware?
And what problem with Cinemare? Is he maybe talking of somebody else? Really, I have no idea.

Quote:
What? How often shall I repeat it: I have no problem with Cinemaware so far.
I. Did. Not. Ask. For. Money. Yet. Because. The. Game. Is. Not. Done. Yet.
When it is done and when I ask for money and get nothing, then I would have a problem with Cinemaware.
(Note: while I was typing, Olaf3's posts appeared)

Quote:
This implicates the possibility that I don't have my very own code ??? That doesn't make any sense at all again.

Quote:
Once again, the game is almost done, as everybody who is capable of downloading and running the demo versions can see.
Why would I ask another programmer who has no insight into the code to do the missing pieces? That's far beyond making any sense at all.

Quote:
What?

Quote:
Yeah, and I don't want to count to two trillions, but well, here we are.
And btw.: still no quotes which would back all your bs claims from before, incl. the nice racism claim.


@OlafS3
Quote:
You should concentrate on the party who started that discussion-mess.
But anyway, I really don't care if people don't like me because I'm talking to people like Templario or other suckers the way I do. Compared to this guy I'm as polite as an angel.

Quote:
If sb. accuses me of fraud (despite being told the facts many times in the past already), racism, and whatever other bs you may imagine, I tend to chose clear words. And if some people only want to see my reaction, for whatever reasons, be it so, even if I wanted to sell sth., which I don't.
I'm happy with the friends I got and I'm very confident that those won't turn their back on me because I lack politeness towards sb. who did everything so that he doesn't deserve it anymore.
But thanks for caring.

Quote:
Wow, that's news to me too, thanks for the info

Quote:
Okay, so according to the above there's nothing anymore indeed
For the process of the game it doesn't matter though:

Quote:
You don't have to speculate, I made my point clear many many times, here's the link again and this is the important part:
"And if you're worried what I'd do in the theoretical case that I don't get my share for whatever theoretical reasons: I'd certainly not trash the game..."

@Raziel
No, that's sth. completely different indeed.

Boolean uniforms are just uniform variables of type bool. Those are not supported by Nova yet, so when you try to use those inside a shader it won't compile.

This here is general support for arrays of uniform variables, like e.g. uniform float x[10];

Back in the early days of ogles2.lib I had blindly coded support for those, however Nova didn't support them at that time. As it turned out my code was partially buggy. The main problem was that the introspection system wasn't correct in terms of arrays, which prevented proper use of those.
This has now been fixed and improved.

@magnetic
Man, stop talking bs, please.
The idea for this project was announced at the Amiga30. That was end of October 2015. I had written a rapid teaser prototype for that event.

Quote:
When it's done.

@magnetic
Quote:
As if that had been the only silly thing Maybe you should have read who you defend.

Quote:
The project hadn't even started 5 years go
You can check out the demo versions by yourself which clearly show the almost finished state.

Quote:
I did not collect anything, nor did I get anything (yet). As you would know if you had read anything.

As I thought:
reading twice wasn't enough for you to get anything straight

What I am guilty of (and which I stand to, which you would know if you had read anything) is that I understimated this project largely.

@Templario

Trillions +10

Quote:
Is it maybe pathological?
Boy, I even made a list for you for a start some lines above, here.
And there's also this one which you carefully ignored too, of course.
Oh, and let's not forget your lovely racist claim.
There's more but backing those would be a good start.

Quote:
Facepalm x 2.
The first for not being able to find the snippet which you recently brought on the table yourself.
And the second for the fact that I never said that I didn't write it. Yes, I put your name in the T57 relnotes and you deserved it. But no, that's not what you are supposed to search for.

Quote:
I don't care how you prove your claims. You came up with those, now it's your turn to back'em up. Your problem.

Still waiting.

EDIT: that guy just wrote me a PM with the subject "eres muy tonto" I deleted it without further reading.

OpenGL ES 2 version 3.0 for Warp3D Nova / AmigaOS4 has been finalized.
It's available on my FTP for testers and A-Eon devs, as usual, for a last check.

- new aglSetParamTags / aglCreateContextTags2 parameter OGLES2_CCT_DEBUG_SHADER_LOG. If set to TRUE then the library asks Nova for extra shader compiler info. A detailed log will be returned even on successful shader compilation. If this flag is set to FALSE (default) then only the usual standard error log will be returned.

- extended the extensions string by GL_ARB_texture_non_power_of_two and GL_OES_texture_npot. The lib implicitely supported those since day one but not mentioning them explicitely in the ext-string could cause some progs to execute internal pot-scale workarounds or to fails needlessly.

- Fix: design flaw. Every shader had its own internal variable-cache. Which at first glance seems to be all good and which most often works. But actually it's wrong because that cache also handles the mapping of uniform locations. But those can vary for the very same shader if it's being used by multiple programs! So, this bug could cause all sorts of hard to track issues if the client used shared shader objects for multiple programs. Now the variable-caches have been moved into the program objects (simply spoken, in fact the shaders still have their own cache but the programs get their own autarkic set of dedicated variable-representations).

- while I was at it I trashed all the old program introspection code and rewrote it from scratch. As a result the lib now also supports uniform arrays. Sometimes trashing your old broken stuff is way better than trying to fix it - only to probably add more sideeffects. No, better accept your failure and start over

- extended the extensions string by GL_ARB_arrays_of_arrays. This is because the new introspection system didn't just add array support but multidimensional array support too.

- new aglSetParamTags / aglCreateContextTags2 parameter OGLES2_CCT_DETECT_UNINITIALIZED_GLSL_VARS. If set to 1 or 2 (default 0) then the library will analyze the generated SPIR-V code and look for uninitialized shader variables. If set to 1 then it will only put a warning in the log and continue, if set to 2 then glCompileShader will return with an error if something suspicious is being detected.
Note that the scanner is considered "good enough for us", it's certainly not perfect (well, it cannot possibly be without simulating all possible inputs and fully emulating the shader, so... it's just a ~200 liner ;) ). While it does analyze all different code-paths (branches, conditional branches, function calls, loops) it will not detect stuff like a vector variable being only partially initialized (e.g. a vec4 whose .xyz are initialized but not its .a won't be detected) or structs that are only partially initialized (e.g. struct s {vec2 a; vec2;b} won't be reported if a is being set but b is not). Other than that it gives pretty good results with only a minimal, practically not measurable, performance impact on glCompileShader (depends on shader size / complexity / num variables, but even checking real big ones didn't hit performance measurably so far).
Thanks to kas1e for requesting!

- glslangvalidator_redux shell tool extended by an equivalent -varcheck option to enable scanning for uninitialized shader variables.

- Fix: standard violation. If you attached a texture to an FBO then a resize of said texture using glTexture2D should be enough to trigger a resize of the whole FBO. Before that fix this led to gfx coruption because Nova doesn't automatically handle that case neither. The necessary workaround until now was to unattach and reattach the texture to force ogles2 lib into updating the FBO. Now all you need is glTexture2D.
Thanks to Capehill for reporting!

- new aglCreateContext / aglSetParam parameters OGLES2_CCT_SPIRV_OPLINES (bool) and OGLES2_CCT_SPIRV_OPLINES_OFFSET (int) which extend the uninitialized-variables-detector by optionally telling you the source-code's line where the shite happened. For that it tells the integrated glslangvalidator to generate SPIR-V which contains OpLine opcodes, which in turn is now handled by the detector. OGLES2_CCT_SPIRV_OPLINES_OFFSET is useful to e.g. make the output 0 or 1 relative or to compensate for any eventual prefix (e.g. ShaderJoy adds a static prefix and should therefore adjust the offset).
Note that this feature is being disabled if you don't have installed the latest Nova 1.76+. Reason is that among some others it didn't correctly handle the OpLine opcode, which in turn resulted in the whole shader not being compiled at all.

- !don't forget to download the new include-folder too!

- version set to 3.0 (14.9.2020) (yep, it's that much of an improvement ;) )

Thanks to kas1e and Capehill for testing!

Cheers,
Daniel