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.

Great stuff and a big "eat that" to all the nay-sayers and those oh-so-well informed people who repeatedly claimed that there was no activity
Thanks to all involved!

@Capehill
Quote:
That's because the first FB pixel is at the bottom-left, much in contrast to most textures that come from files where the first pixel is at the top-left.

@kas1e
Quote:
And for others it will become visibly faster
That's because some such textures' values are not meant to be interpreted as pure colors but are actually texture-encoded input parameters to the shader's logic and thus may influence its runtime.