@AmigaOldskooler
I will make all taborized executables available for free download.
So everybody who owns the respective game can just replace the exe to be served.

@Raziel
Quote:
You are such a someone

@Raziel
@Capehill
Both of you got a permanent link to the latest ogles2.library 3.4 wip builds.
This link didn't change, so you can always download the very latest wip versions for your tests.

@Raziel
Quote:
I often don't have time to process "please test" mails immediately because of real life (which is also the reason why I rarely publish any ogles2 wip news; and it's also one of the reasons why you got that link to be able to serve yourself).
And sometimes when I get such a mail, I just put it into some Amiga folder for later and then occasionally forget about it.
This is why your preferred option should be to simply report an issue into the aeon mantis, there it won't be forgotten and every other tester can easily check it out too.
Also, if possible use the latest ogles2 wip version and provide a glSnoop log containig ogles2 and Nova calls.

Quote:
Regarding your concrete issue:
I don't see any problem, background is fine, mouse cursor is fine.
Probably / likely (I didn't bother to compare with previous builds) your issue is already handled by one recent fix regarding a falsely optimized-away Nova Submit call.

@Capehill
Quote:
Highly unlikely.

@all
FYI, current ogles2 3.4 wip state looks as follows:

- Added support for texture formats GL_RG and GL_RED. Added GL_EXT_texture_rg to the extensions string.

- Fix: an FBO's scissor-rect was set to 0,0,0,0 right after creation which essentially disabled any drawing, including clearing. This happened because the necessary scissor-reapplication was only invoked when binding the FBO. But by the time of its 1st bind the FBO's width / height is still 0... So if you didn't rebind before drawing then your draw-commands would effectively become noops. Unfortunately (in this case only) a common code-path is to pre-create FBOs and then use them later (by using a explicit bind), which explains why this bug remained unnoticed for so long. Thanks to Capehill for reporting.

- Fix: while I was at it I found and fixed another one in that area: if you changed the dimensions of a texture which was used as a render-target then this change didn't immediately invoke a scissor / viewport adjustment.

- speed up for glReadPixels from an FBO with texture-attachment by integrating the GL-required vertical image flip into the render-to-bitmap pass.

- the strategy of handling GL state changes has been modified. In a nutshell the actual application of those changes is now deferred until just before the next draw-command. The new state handler is able to detect and ignore all redundant changes. Before it was only able to detect simple stuff like glDisable(GL_BLEND) followed by another glDisable(GL_BLEND). Now it can also detect and ignore stuff like glEnable(GL_BLEND) ... Draw() ... glDisable(GL_BLEND) ... glEnable(GL_BLEND) ... Draw() ... glDisable(GL_BLEND). Here the two useless "inner" state changes are ignored. This may dramatically increase performance for some games. Thanks to Steffen for reporting a performance issue with Heretic which was caused by this (not that uncommon) pattern.

- Fix: at least one fragment shader managed to drive the integrated unused-variables-detector into an endless loop. A safety mechanism has been added. Thanks to Capehill for reporting.

- Fix: ogles2.h now respects the AmigaOS namespace for OGLES2Base too. Thanks to Andrea Palmate for reporting.

- On the A1222 the texture wrapping modes were falsely applied. Actually, supposedly pretty much all parameters set via glTexParameteri were affected. In case of the wrapping mode a translated GL_REPEAT magically became a W3DN_CLAMP_TO_EDGE (which happens to be the value 0) instead of W3DN_REPEAT. The reason for this weird issue was a LTE issue (therefore blacklisting ogles2.library was a valid workaround). ogles2's code used a C union at the critical area to "merge" a uint and a float. This was merely done to underline mutual exclusivity for those two variables. While that code was absolutely valid, it obviously "irritated" AmigaOS4's LTE on the A1222. Consequently removing the union did the trick. Thanks to Eldee for reporting and testing.

- Fix: it is crucial for good framerates to reduce Nova submissions to a minimum. However, certain operations require a submission. ogles2.lib's internals try to get a good balance here. However, the last time I optimized things here I introduced a bug where I made such a necessary submission due to certain state changes but falsely marked the used-objects list as empty - which in turn caused another required follow-up submission not to be executed. The results could be anything from textures at wrong places or whatever because e.g. Nova would then use a newly bound texture for a PREVIOUSLY issued draw-call. Yes, be glad that you don't have to use Nova directly...

Unofficial:

I also added a feature that's private to me for now and which isn't available in the current wip builds for testers yet:

- Introduced ogles2_patch.json. Such a file can either reside in LIBS:ogles2/ or in the respective client app's main folder (the latter's content has higher priority). This mechanism allows for global and / or per-app tweaks of ogles2 and will be filled with concrete functionality in the future.

- Added shader-extraction feature to ogles2_patch.json. If the new "extract-shaders" flag is set to true then all the shaders are extracted to RAM: for now.

- Added shader-replacement feature to ogles2_patch.json. This allows you to replace an app's shaders. Use the shader-names from a previous extraction-run for replacement.

Cheers,
Daniel

Alright, I officially suck at our own game
On the other hand, I never played it with a trackball before. Maybe I can still do better than those embarrasing 190445:

@AmigaOldskooler
Since you had fun with good old VoxelBird - go for VoxelNoid

Currently I use this one:
TESmart HDMI KVM (8 port, 4k 60Hz support)
Works perfectly with all machines here (X5000, A1222, sam460ex, MOS G4, Aros PC, and std. PCs / Macs).
Current input devices are a Logitech G213 and a Logitech MX Ergo trackball (btw.: I use another MX Ergo to control my two A1200 via Rys MK II, the MX Ergo can switch between two devices on the fly ).

I can not recommend this one and would therefore not recommend any Aten products:
Aten CS1768 (8 port DVI)
- apparently not enough power to support my old Logitech Prodigy. Sometimes it got lost during boot, no lighting, no multimedia key support, etc.
- mouse emulation not working.
- stupid non-configurable hotkeys.
- always dumb OSDs.

In general I can also recommend switches by Uniclass. I had several DVI switches from them (AL-204A, RD1086). They did the job, but all in all I'd go for the TESmart any time again.

Let's not forget the most obvious bottleneck:
unoptimized shaders in the game itself.
E.g. I analyzed Spencer shaders and there's huge optimization potential!

@Lio
Quote:
No, that's incorrect.
There just happens to be a Discord fan group, much like a FaceBook group or a Whatsapp group chat. People talk there about the game, make suggestions and sometimes date for a match, that's all.
Of course that's in no way mandatory for playing the game.

@VooDoo
Quote:
Looks as if you are trying to run the Warp3D version on a system without a Warp3D-capable gfx card.
Get the latest matching version from here and try again!

https://www.goldencode.de

@rjd324
We cannot be 100% sure what the original purpose was as the code is illegal. Not just because of the casting/++ abuse but also because it guarantees misaligned data accesses which may be a problem depending on the target CPU.

Anyway, apparently the intention is to grab and store chunks of data of different types which are linearly tightly packed into some structure.
And because of lazyness the original coder tried to use the same UBYTE pointers for all different access variants.
It's of course dirty crap. However the old compiler obviously allowed to increase the pointers depending on the type they were casted to, so if it was casted to a temporary UWORD* the ++ operator would increase the original UBYTE* by sizeof(UWORD).

Your


has the same semantics as


and defeats that purpose as it grabs a UWORD but then increases chunkbuf by sizeof(UBYTE) instead of sizeof(UWORD). So the next access would grab parts of the previously read value...
I strongly doubt that this was the original intention.

@kas1e
Of course my union solution doesn't fix potentially misaligned data access.

@kas1e
OMG, delete all you did
For simplicity you could go with a union like this:



Untested TM

Regarding Grim Fandango returning 0 for red, green, blue, alpha bits when using FBO:
if there's no valid color-attachment when querying those infos then you'll get 0. This seems to be the case here because you get the same result on Win32.
However, there was a bug in ogles2.lib which resulted in also returning 0 if there was a valid texture color-attachment (for non-texture attachments it worked correctly). This has been fixed in upcoming ogles2 3.3.

@alfkil
I'm currently working on adding proper share-group handling to ogles2.library.
This might be of interest for you and your QT6 project because it should allow sharing of textures etc. among contexts which didn't really work until now.
When I say "should" I actually mean "likely it already does" with the latest wip version 3.3. I guess I'm done but it's not really tested yet

There's a new aglCreateContext2 tag OGLES2_CCT_SHARE_WITH <ogles2-context-pointer>. This optional tag instructs ogles2 to share the same internal Nova-context (with a different render-state-object) and the same set of textures, VBOs, shaders and shader-programs of the given other gl-context.
So you create context 1 and then use its handle with OGLES2_CCT_SHARE_WITH for the creation of another context. The number of sharing contexts is unlimited and you e.g. may destroy context 1 and the resources will still be available for context 2. And the handle of context 2 can of course also be used to create another shared context.

Check it out (if you don't have an account there, contact Matthew to get one):
http://www.amiga.org/developer/bugreports/view.php?id=896

@Georg
Yep, you're right and I was blind.
So, no bug in GL4ES, it was a bug / specs violation in ogles2.lib after all.

EDIT:
Updated the lib accordingly. The helper tag has gone again, now the changelog reads like that:

- Fix: specs violation. The IDs returned by glCreateShader and glCreateProgram were independently generated. However, the standard says that the shader IDs' "name space is shared with program objects", a fact which I overread, grrmbl. For an OpenGL ES 2 implementation by itself this violation isn't really a problem but it turned out to be the source for an issue related with GL4ES:
In std. GL, which GL4ES implements based on OGLES2, there's a function glGetObjectParameters which accepts shader- or program-IDs as first parameter. Now due to this bug in ogles2.lib those IDs were not unique, so that this function was not able to distinguish between shader- and program-IDs, which in turn resulted in nonsense behaviour.
Thanks to George for rereading the OGLES2 specs and correcting me on that, as I asumed a bug in GL4ES here.
Now the the IDs returned by glCreateShader and glCreateProgram are unique in the shared UINT32 number space.

EDIT:
It was a specs violation in ogles2 after all, disregard my stuff below, I was wrong.


@kas1e
As I said: there's no word about that in the OpenGL ES 2 specs (unless I'm totally blind). So an implementation may chose whichever ID generation algorithm it may like. There is no rule that shader-IDs and program-IDs are related in any way. Which is logical because there's no critical function like glGetObjectParameters in GLES2.

So it was no bug in ogles2.lib.

It's a bug in GL4ES because it asumes something in its OpenGL ES 2 based implementation which the OpenGL ES 2 standard doesn't guarantee. GL4ES was just lucky so far with those other GLES2 implementations which apparently chose to implement ID generation differently.

To fix GL4ES the following would have to be done:

- glCreateShader and glCreateProgram functions must be wrapped and the IDs returned by the respective ogles2 functions must be mapped to GL4ES-internal shared IDs. Those other IDs must then be returned to the caller.

- in each function which accepts a shader- or program-ID the reverse mapping must be done and then the original ID must be passed to ogles2.

Because it was easy for me to artificially restrict ogles2.lib so that it creates IDs which work with GL4ES, I chose to do so. It also has no performance penalty. Fixing GL4ES is certainly a bit harder than that and would require this extra ID translation.
The bug in GL4ES persists of course, but it doesn't affect the ogles2.lib-code-path anymore so it doesn't matter to us anymore.

@Capehill
Quote:
Nothing. ogles2.lib uses dedicated pools which complies to the standard.
But you are right, this is incompatible with GL4ES' glGetObjectParameterARB API. Therefore I modified ogles2.library. From the change-log:

New context creation tag OGLES2_CCT_UNIQUE_SHADER_AND_PROGRAM_IDS.
This is a helper tag to allow APIs like GL4ES' glGetObjectParameterARB to work with ogles2.library.
This API asumes that the shader- and program-IDs generated by glCreateShader and glCreateProgram share the same ID pool. Note that this rule does not apply to OpenGL ES 2 (and not even 3 AFAIK).
When this tag is set to TRUE then ogles2.lib will essentially half the ID-space for shaders and programs and return values from the lower half for programs (ID & 0xFF < 128) and values from the upper half for shaders (ID & 0xFF >= 128).
Note that TRUE has been made the default value for that new tag for convenience. That way GL4ES doesn't have to be rebuild.

Of course I didn't test this at all. A fresh lib build is available at the link which you should have.
If you find this to not work as expected, please file a std. bug report.

@kas1e
Starting with WinUAE 3.6.1 I got pretty high performance (PicassoIV emulation) and nice overall emulation (prior versions had sound issues for me).
It ran my ported and optimized Tower57 at almost the same fps as the original native x86 version on the same machine, LOL :D
However, Compositing was very slow (maybe that was improved in the meantime).
BGR24 screen-modes were much faster than anything else. Hicolor screen-modes were particularly slow.
Other than that I don't remember any pitfalls.
I still have the UAE config file but unfortunately deleted the virtual HDD so I cannot give it a try with a newer UAE right now.
I'll mail you the config, should be a good starting point.

@salass00
Quote:
No, Motorola gave us EXG ;)

Quote:
We can't be sure about that without digging deeper. Maybe he did it on purpose and the BEQ tests the condition before the movea and he wanted to happen the move in any case.
Maybe he just forgot the nullptr check.

@kas1e
That's why this here would be an unintrusive way to add a nullptr check:



You can comment in / out the first BEQ.W. If the behaviour doesn't change for sure then salass00's asumption that the coder falsely asumed that movea changes cc is likely to be correct.

@walkero
I don't see this happening happen. The current covid numbers and tendencies, Ireland's as well as Germany's, don't make me optimistic at all. Anyway, I'm of course fully vaccinated and will even be boostered in one week and I'm pro-mask. So if travelling will be allowed I'd be willing to take the risk for myself and others can be pretty sure that I'm no risk for them. That's why subscribed to the notification list for Amiga Ireland and I'll get a ticket if / when they become available. If it get's cancelled it will be a donation at least

@Breed
Have fun

Atomic Bomberman Remake received several updates recently. You can find the latest versions on my homepage.


v2.12 (17)
- highly improved player movements mechanics. Walking around corners feels much better now.

- Hockey Rink sliding improved.

- Hockey Rink sliding strength is now adjustable from 0 = no sliding up to 4 = super slippery.

- Hockey Rink now with arrows. Yeah, I totally overlooked for ~ten years that the hockey playfield contains arrows too. Although it's a different arrow layout compared to the Ancient Egypt map.

- data file validation disabled.

- Windows: no glew.dll required anymore.

- Windows: updater was broken due to a compiler bug, thanks again Embarcadero. Their new 64bit compiler produced pure garbage, I couldn't believe my eyes when inspecting the structures during debugging: variables on the heap would just become 0 when returning from a function, stuff like that (and no, the code was valid; actually it was happening inside the good old unzip code).
Solution (unbelievable but true): remove unzip.cpp from the project and include it instead of unzip.h, so it gets compiled in the same unit as the caller


v2.13 (18)
- improved a subtle but significant controls glitch which kicked in if you were pushing horizontally and then added vertical input (or vice versa) in a diagonal fashion and if your movement was blocked in that secondary direction (phew):
then the player would not turn into that "new" direction. This was no problem when it came to regular movement because, well, you were blocked in that direction anyway, after all. BUT:
if you were just punching and wanted to change your direction via diagonal input for the next punch, the player wouldn't turn and the next punch would go to the previous direction... Therefore punch-escaping situations in which you were surrounded by bombs didn't work well, if you used diagonal input.
Similar problem when you were holding a bomb in such a blocked situation: diagonal movement wouldn't make you turn, so you'd probably accidentially throw the bomb in an unwanted direction.

- the above required a remedy in combination with transport bands and sliding. Otherwise the animation for the "original" input direction would play for one frame again after the direction-correction kicked in

- Fix: no idea how this one slipped inside (had nothing to do with the above changes at all): when you carried a bomb you'd eventually just drop another


v2.14 (19)
- Fix: network protocol wasn't extended to transfer the new hockey rink slide option, which could cause clients to get out of sync.


v2.15 (20)
- Networking: scheme files (maps) are now transmitted from the server to the clients. So if the server has modified or additional scheme files, those will work now without manually installing and syncing those files among all clients beforehand.

- Fix: it was possible to cancel / skip the initial setup screen by pushing ESC or equivalent buttons... Of course with pretty fatal consequences later on. Thanks to gpsoft for reporting.

- Cosmetic fix: during presentation mode (auto cycling through menus and intro if input idle) the music stopped when auto-entering the extras description screen.


@samo79
Before you ask: no, I still didn't find the cause of this problem.

Tchatching,
Daniel

@kas1e
Quote:
If Nova supports it then there is nothing to do inside ogles2.lib. A correct #version should be enough.

@kas1e
In general: you cannot really mimic gl_VertexID unless you manually setup an extra vertex attribute and fill it with your own IDs.

Other than that you cannot really rewrite that shader here without a gl_VertexID equivalent and expect it to produce something anywhere near the originally desired output. Unfortunately there's no other shader input that seems to be appropriate to derive the missing info.