@kas1e
Very well, crossing fingers

@kas1e
Quote:
Your asumption seems to be correct (could also be function parameters being corupted).
I modified the shader to not use the circle function but inlined that code:


Then it works.
That's a fatal error. Return values (or function parameters (or even general variables??)) not being even near reliable is a show-stopper. This should have the top priority on the Nova fix list!

@kas1e
Quote:
Despite what Hans said somewhere above, there is no such issue. Both syntaxes are valid, both are handled by glslangvalidator / ogles2.lib, both result in the very same valid SPIR-V code sent to Nova.
The other two things however are two apparently seperate Nova bugs.

Valentin made a live recording on Youtube of a 5 player network session
In other news: in addition to the atomic Facebook group I just created a Discord channel to simplify teaming up for online matchs.
Tchatching

@Hans
Quote:
No, doesn't look like this.

Quote:
It does. You can disregard that idea. A simple test reveals that whether you use 1.0 or 1 or 1.0f doesnt matter. glslangvalidator_redux and ogles2's internal glslangvalidator produce the same SPIR-V output in all cases. And if you run that through a disassembler you can see that it correctly creates float constants.

Quote:
Which is also legal (although I wonder why it's allowed). glslangvalidator produces and uses 4 float variables, just as to be expected.

@kas1e
Quote:
No, undefined is undefined. If you assign fix values to those glslangvalidator will of course generate constants.

Quote:
Not strange at all, it's all converted to the very same floats, see above.

All in all there apparently is no problem on the GLSL -> SPIR-V side or in the generated SPIR-V, Nova simply has problems handling correct SPIR-V sometimes.

New Atomic Bomberman version 2.9 (network protocol version 12) is now available (first via auto-updater, manual downloads will follow asap, or get it from my homepage)
Contains all the stuff that has been noticed yesterday evening

- Fix, networking: the master was allowed to continue even if not every connected client selected at least one color. This in turn resulted in a deadlock when starting a level. This bug could be trigger only if multiple players shared one client machine.
Thanks to aPEX for tapping into it yesterday

- Fix, networking: the master was still listening when the game had already started. This could cause undefined behaviour on the server if another client made a connection attempt on an already running match, which in turn resulted in the clients to appear frozen (in fact the clients survived when the server was restarted, but well, academic ...).
Thanks to nujack for tapping into it yesterday

- Fix, cosmetic: the last used text input field remained active (cursor blinking) even if you already moved the row-selection to another input field, controls and network menus.

- the win screens are now being displayed for at least 2-3 seconds. Before that it was possible to practically skip them by an "accidential" button-click...

- "About Atomic Bomberman" section extended

- networking: the master can now hit F9 to toggle some sort of "on the toilet" or "baby doesn't want to let daddy play a few rounds" mode... This has the effect that the win-screens etc. are auto-skipped after some seconds so that the session can go on without delay.

- networking: for joining there's no need for a password anymore. The password is now meant as a key for the master only - so that only he can start new sessions for that game name. Otherwise somebody who wanted to join the game but accidentially hit "start" effectitvely hijacked the session.
Note: the web-server component has been modified, older versions won't anymore!

- when we now played the first online matchs yesterday I found it pretty hard to get people to join in time. And sometimes one client connected but soon quit again when nobody else joined. Most of all this is a matter of timing: we tried to arrange our sessions via Facebook events, not by direct live chat. So naturally people would join at slightly different times. To make it all a bit easier I added a timer: the master can set a countdown which every client sees. When it drops to zero the game begins.

Tchatching!
Daytona675x / Inqui / Daniel

@samo79
yes, unfortunately I didn't have time to look for and fix this one yet. It would have been in the release info

For father's day a new Atomic Bomberman version 2.8 (network protocol version 11) is now available (first via auto-updater, manual downloads will follow asap, or get it from my homepage)

- Fix: a debug-relic caused the game to always try to enter fullscreen mode on startup even if you previously chose to use window mode. This one slipped through because I always play in fullscreen
Thanks to jabirulo for reporting!

- in the following I added some more game-play options. Unfortunately there wasn't enough space left in the level select menu. The only option for lazy coders was to decrease the vertical gap between those menu items. But this again reduced readability too much. Which is why I added an orange row highlite. For consistency I added this to all screens (only exception being the main menu because I didn't want to change the original look here).

- Default bomb countdown was 3 seconds whereas the original's is 2. No idea how this difference could remain unnoticed for 10 years
Thanks to Valentin for reporting!

- However, those 3 seconds don't feel bad at all. Therefore I made this a new game-play option and 2 seconds is the new default value, possible values range from 1 to 4

- In the original certain considered "powerful" extras don't appear for the first 40 seconds of a match. The golden flame and the trigger are considered "powerful" in that context. IMHO this behaviour is questionable. E.g. personally I find the red glove to be at least as powerful as the trigger. Anyway, for "original-purists" I added yet another game-play option so that you can adjust that delay. Values range from 0 to 50 seconds.
Thanks to Valentin for reporting!

- the red glove punch action is now also triggered if you don't simultanously press a directional button. This was a another significant difference to the original game. So you can now punch away a nearby bomb without sliding into it.
Thanks to Valentin for reporting!

- extended the About / Credits area and added a donor-thanks section

- all Amiga lha archives are now patched so that the executable protection bits are set. Also, the AROS version is now also packaged into an lha instead of a zip. From now on this is also true for all my other projects.

Tchatching & cheers,
Daytona675x / Inqui / Daniel

@jabirulo
That's more of an outdated feature of the framework. The idea back then was that you always get a chance to change the screenmode just in case. However, the requester should not show up when you explicitely chose to stay in window-mode before, of course. That's actually debug-relic that remained inside unnoticed because I always run it in fullscreen mode... Thanks for reporting, consider it fixed for the next version!

@BSZili
Ahh, I think I got it now! That story from the dark ages? Oh boy

@samo79
Thanks for reporting! Sounds like some deadlock when cleaning up. I once had sth. like that myself but it only happened once so I didn't investigate further. aPEX reported sth. similar some days ago, but for him it only seemed to happen if he ran some other game before, so I dismissed it again. But now I'll take a close look So far every occurence of this symptom was AOS4 only, so I'll concentrate on the AOS4 system specific code first.

@all
Latest updater stats revealed that the game is played actively mostly by Windows users (~ 70%). C'mon guys

@jabirulo
@samo79
Before I release it I better make sure it doesnt destroy lhas in other cases

@BSzili
Don't get it, what do you mean?

@all
Version 2.7 is now available (first via auto-updater, manual downloads will follow asap):

- new disease: invisible. Well, a little bit of your shadow remains visible
Apparently this one was planned for the original PC version (there are sound effects for it, which are now used too, of course) but never made it into the final game AFAIK.

- one second after the last opponent has been blown up, the hurry-wall stops and bombs don't explode anymore. The idea is to reduce the chance of draw-games especially in very tight situations (which most likely means that an intense battle happened). The original has something like this too, thanks to Valentin for reporting!
Until now the game simply waited for 2 seconds before it would end the match and switch to the end-screens, so this is a subtle change. Can make quite a difference though.

Tchatching,
Daniel

@samo79
I wrote a little windows tool LhaExePatcher which scans a lha archive for a certain file and then adjusts its flags to become an AmigaOS executable and included it into my toolchain.
I patched the files on my homepage, maybe you want to give it a try.

Maybe this tool will be useful for others too, so I will release it incl. source once I tested it a bit more in depth and cleaned it up a bit.
I mean, as every half decent coder capable of self-reflection knows, the fact that it "works for me" with my handful of archives here (which also all happen to have a lha2 header in case of the executables) doesn't mean that it's not buggy...

@samo79
cd AtomicBomberman
protect AtomicBomberman +e

If you use unarc then the execute flag wont be set. Reason is that I use a Windows lha in my cross toolchain to pack everything together.
This problem can be avoided if you use the comand line lha version 2.15 AOS4.

@khayoz
Cheers

@all
Version 2.6 is now available via auto-updater (only that way for now, I'd like to know the distribution among systems):

- Trigger bombs are now converted to normal bombs if the player who planted them dies or picks up an extra which makes him lose the trigger.
Thanks to Valentin for reporting this pretty significant difference to the original game!

- Fix: shadows weren't correctly premultiplied by alpha. Only the trained eye should have noticed though

- added one of the original's cheat-modes Well, at least it was planned to be inside the original game, however I didn't manage to actually activate it. But, yeeeehaaaa, this remake supports it (I modified the joypad sequence a bit though, have fun looking for it ) Thanks to Valentin for pointing me at that one

Tchatching!

@Capehill
Quote:
Nova doesn't support those as of yet.

@Capehill
Not really necessary, I just deleted that text fragment out of my above comment
ogles2 will detect that your vertex data is the same and use the already prepared internal VBO. Providing your own will in theory still be faster but in practice this difference will hardly be measurable. The point is: in neither case will vertex data be sent to the GPU more than once.

What you see there is ogles2's internal GLSL-to-SPIR-V compiler (glslangvalidator) complaining about the function not being supported. The reason for this problem is the #version you are using. Try e.g. ""#version 430" and the noiseX function calls will compile. Yes, all that #version hick-hack sucks hard with GLSL.

However, that still won't give you the desired result. I checked the source of the GLSL-to-SPIRV-compiler "glslangvalidator" (which is the reference GLSLcompiler) I use internally (and which is also used for my stand-alone build that ships with Nova) and found that it's handling it as a dummy.

So, what you get is effectively this
float a=/*noise1*/(b);
vec2 c=/*noise2*/(d);
etc.

As far as I can tell from a quick peak into the source even the latest glslangvalidator version doesn't emit anything real.
However, at least some years ago hardware support for the noise function was rare at best, I don't know if anybody implemented it at all, never used it.
The thing is that you can achieve the same if not better results if you implement your own noise function, usually consisting out of a noise-texture-lookup, thus being trivial to do and very fast.

glslangvalidator (or ogles2) could emit self-made noise functions, but a decent noise can be pretty costly, which is why they didn't do it at all, I suppose. So you end up with the above.

@328gets
Cheers, pal

@all
If you use Facebook (please, don't start a discussion about why you think FB is evil or not here, thanks ):
I prepared this little group here. Main purpose is to have a place to arrange online match dates.

Tchatching,
Daniel

@kas1e
Quote:

No. Here having DMA / GART makes almost no differnce here because nothing but some bytes are being sent to the GPU each frame (maybe 100 in worst case, depending on DBO layout and on which uniforms change).
We don't measure any sending of fragment shaders neither. Those aren't sent per frame. It's compiled once and sent / activated once when you select the desired effect.
What's measured here is the fragment-shader being run for every fragment (which in this case means for every pixel, because we only draw a window-sized rectangle), that's it (well, plus some rather static function call / OS overhead etc. of course). So the current AmigaOS-brakes don't apply here.

@Capehill
Quote:
No, it's rudimentary: it supports iResolution, iGlobalTime, iTimeDelta iFrame and iMouse. Back then I was too lazy to add some sort of texture-manager, so no iChannel The variable list on the top right is just a reminder

@kas1e
Note that with ShaderJoy you only measure fill-rate / Nova's fragment shader performance, pretty much nothing else: the geometry is just a static quad, the vertex shader is minimalistic, the shader program never changes. The only thing that changes per frame and therefore is being sent to the GPU is the DBO with the handful of uniform variables.

Would be very interesting to see how those fps numbers compare to a Windows rig with the same gfx card.

Here are my results:
X5000, ogles2 3.0 (wip), Nova 1.68, passively cooled R7 250 1GB:

default (blue window): 1049

capehill/amigaa: 1046
capehill/bars: 862
capehill/gear: 1046
capehill/helloh: 1033
capehill/helloh2: 1016
capehill/mandelbrot: 42
capehill/nuts: 1045
capehill/ripple: 1048

shadertoy/dueling_mandelbulbs: 363
shadertoy/foot_torus: 11
shadertoy/kissing_donuts: 14
shadertoy/sunset: 909
shadertoy/yetanother_torus: 18