@Raziel
Nothing has changed. What I said here is still valid.
It's still almost done When will it be fully done? I can't say.

My motivation on this thing is low (which is what happens if you massively underestimate the workload and a project takes muuuuuuuch longer than you thought), I have other things to do too, I want to do other things too, and I'm not married to Wings (last not least because I didn't ask or take any preorder-$ so far; I'll ask for my share once it is fully done).
Occasionally I work on it, but not too often. However, some weeks ago (4.1.2020) new demo versions were published. Those reflect the current dev state. Feel free to give those a try:

Wings Demo AOS4 Warp3D
Wings Demo AOS4 Warp3D Tabor SPE
Wings Demo MorphOS
Wings Demo AROS x86
NEW: Wings Demo AOS4 MiniGL for MiniGL4GL4ES
(please don't link to these files directly, link to this comment instead. Also, please don't upload those files elsewhere. Thanks!)

Also please note that asking the same question over and over again at different places won't change anything at all and won't speed things up neither. Sorry, but that's how it is and it is as it is.
So once and for all, there are two options:

1. wait until it's done. And it's done when it's done and when I say that it's done. But yes: some day it will be done. Simply because I don't trash a game that's almost done
2. cancel your preorder at Cinemaware Retro (and no, I'm not in touch with them) if you don't want to wait.

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
If you'd not derail this thread instead of asking in the Wings Remastered thread over here (which somebody derailed into some sort of minigl thread... ), then you'd actually get a real answer, thanks.

Version history



v2.10:
- new gameplay option: no sleepy players. If a player has been inactive for 15 seconds, it will auto-drop a bomb... Highly recommended, especially for network games!

- networking: the master can now manually increase / decrease the waiting-for-clients-countdown by tapping left / right. Yesterday we had a situation where I missed exactly that feature: ErnstEiswürfel was about to join but only 15 seconds remained, so he just missed it and everybody had to quit and rejoin.

- Fix (was uncritical, but...): "toilet mode" isn't a configurable input mapping anymore Forgot to set the non-editable flag for this fixed mapping, which is why the auto-configuration system of my framework made it configurable in the controls menu.

- (maybe) fix, networking: ddni and ErnstEiswürfel reported a weird issue that to me looks as if their network connection was sometimes so instable that some crucial state change packages would pile up - and then suddenly be executed one after the other without any delay. That resulted in situations where it looked as if the scenery was changing all of a sudden - although other players experienced it as what it was: matchend, result-screen, next round. But for them it was more like matchend (or shortly before matchend) -> next round, the result-screen would essentially be skipped or visible as a black screen for one frame. Well, that's my guess because I don't have another explanation So to work around that I extended the network protocol by dedicated sync-commands for those screen-changes. Crossing fingers, untested
Thanks to ddni for recording a video of that phenomenon!

- (maybe) fix, networking: for some Amiga players at least a hard master drop would result in their client to appear frozen. It didn't crash though, it was simply waiting for a TCP timeout on the socket which was closed by the master. Apparently it's no good idea to rely on the TCPIP stack's error handling here. Therefore the master now sends an explicit "server-death"-message to all clients before shutting down. Only tested on Windows so far.
Thanks to ErnstEiswürfel and ddni for reporting!

- made 4711 the default network port for no particular reason other than that I chose it for testing Yes, I know that it's used by other services (just like probably every TCP port) and I don't care at all.

- Windows, auto-updater: the self-deletion of the update installer eventually triggered some stupid antivirus software :P Disabled the self-deletion step, hope that does the trick.
Thanks to Valentin for reporting and analyzing!

- Windows, auto-updater: now 64 bit executable.


v2.9:
- 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

- 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

- 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.


v2.8:
- 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.


v2.7:
- 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.


v2.6:
- 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


v2.5:
- punch animation is now played no matter if there's a bomb to punch away or not. This was a minor difference to the original game. This behaviour has one benefit: you can easily check if you still got the puncher... Thanks to Valentin for reporting!

- team mode: original player colors are now being used during the first seconds of a match before they are being switched to white / red team colors. Before you had a hard time figuring out who you were...

- somewhat adjusted explosion segment offsets, those were a bit off. Well, they still are, but less than in the original and less than before. The thing is: unbelievable but true, they are totally off in the original: it's all shifted by some useless pixels to the right and some asset the segments often simply don't fit well.

- explosion-animations are now repeated once and played at twice the speed. Closer to the original.

- detail: if you have the kicker you cannot stop kicked bombs with the 2nd button anymore if you also got the jelly!

- new disease: swap player position with a random opponent. For whatever reasons I forgot about this one, saw it in a Youtube video of the original game now

- disease timing modified to be more closely to the original. Especially the duration decrease when you pass a disease has been changed: before it was 1 sec., now the remaining disease time is cut in half for you. Thanks to Valentin for reporting!

- improved texture modes, depending on your hardware. In general this improves the playfield's and animations appearance. If possible the washed out bilinear filtering is avoid in favor or an filtered scale2x variant.

- some graphics, namely bricks, use purple as a transparency indicator. However, for some this color-key is slightly off, so that here and there a single purple pixel remains. Was very well visible for the lilys in that trampoline world. The purple-check is now somewhat fuzzy so that stuff like that is gone.
Windows users: the game will ask for UAC rights elevation to create a new set of patched decrunched assets.

- angel death animation: angel now flying upwards

- death animations fade out on last frame, simply looks better than those original abrupt endings.

- extras explanation screen: extra-icons now without bilinear washed out filter look.

- for upcoming updates the online update mechanism has changed. Before the game would only check for an update once per day. Now it does always on startup. The reason is that for an online session all players have to be on the same update level...

- teleporter sound effects added.

- trampoline sound effects added.

- many more generic extra-pickup voice-overs added.

- many more hurry voice-overs added.

- many more frag taunt voice-overs added.

- sound when punching a bomb.

- sound when picking up bomb.

- sound when a thrown bomb is bouncing around.

- generic disease voice-overs added.

- poops sounds added.

- even more sounds added

- new sound effects manager to gracefully handle this giant amount of sounds even on low end hardware.

- put original's dedicated tune in the waiting-for-net-players screen.

- optimization: extra color analyzation to avoid creation of sometimes rather useless secondary textures (useless in terms of: you won't spot the difference...) -> less VRAM used, faster texture generation step.

- optimization: if the hardware supports it, the game will now create and cache NPOT textures, which means less VRAM used and faster texture generation.

- optimization: tuned texture atlas generation parameters for the different atlas types (animation, world preview, playfield, extras). Makes quite a difference, until now all used the most effective but most costly variant best suited for the animations, which is overkill for the other variants.

- optimization: texture atlas creation moved to the initial startup phase.

- textures now with premultiplied alpha if the hardware supports it (should be pretty much all but Compositing). Above all this gets rid of those little filtering artefacts here and there.


v2.4:
- online update server has been configured and activated for this game for upcoming versions (for all but AOS4 the game should auto-update to this version already, forgot to enable a special-treatment-build-flag for AOS4 which is necessary because of the extra Compositing version for Polaris users and other poor souls without Warp3D).

- Trigger bombs can now be triggered one by one instead of all at once. No idea how this significant difference to the original could survive for so long Thanks to Valentin for reporting.

- network sanity check improved.

- new option in level-select menu: optional short "get ready" message before match start. Its only purpose is to reduce the probability that people accidentially plant a bomb immediately on startup because they are still tapping the fire-button to begin the match. The playfield is also darkened a bit during that time.

- more start position options (N is the number of active players):
0. map default ignore colors (like before)
Linearly uses the first N start-positions in the order defined in the map.
1. random ignore colors (like before)
Radomly uses the first N start-positions in the order defined in the map.
2. original map default
Uses the start positions dedicated to the respective player color.
3. original random
Random positions, but only picked from the set of active player colors.
4. fully random
Randomly uses all available start positions.


v2.3:
- Fix: conveyor belts didn't transport players anymore
This bug was introduced with v2.0 when the core logic was modified to use fix-point math instead of floats for networking and slipped through unfortunately. Thanks to Valentin for reporting!

- when fixing the above bug the player movement logic was improved too. Funny enough all this also made the rewrite a bit more exact by "accident": in the original the conveyor belt has no impact if you try to move in an orthogonal direction, this is now correctly replicated.

- new gfx option "stretch" to disable the aspect correction. For those who prefer blown-up bombermen and no black borders like Valentin.

- network sanity check: only identical program versions can connect for an online match. If you try to join a session with a different version, you'll be kicked immediately.


v2.2:
- further improved network game join behaviour.


v2.1:
- cleaned up the network menus.

- join-online-session won't block if the server isn't yet reachable.

- Windows installer: readme is installed and gets its own start menu entry.


v2.0:
- due to the Corona crisis I had to add this: online matchs
*** BETA *** There may still be flaws, only tested a bit

- credits, thanks and greetings added.

- disabled some random backgrounds pictures which aren't well suited for text.

- Erhard asked for it, here it is: a pause function (via pause or help key, or F12 on Macbooks which don't have any of those other keys ). The intermediate result-screens can be paused too.

- Fix: default key mapping was wrong, up and down keys toggled Thanks to Erhard for reporting!


v1.2:
- team-mode added! In contrast to the original game this rewrite also supports kills-win-matches in team-mode. Consequently the kills of all team member are accumulated and presented on the result screen too. In team mode the players are either part of the white (odd player #) or red (even player #) team. Btw.: the crappy AI tries to avoid killing team members

- new game-play mode "Annihilation". If this is activated, then every player has the glove, the punch and a 10000 jelly bombs stock from the beginning Also, if you lift a bomb then you'll immediately throw it away again ( = autofire). This is truely hardcore!

- Player-select-menu now with clear-all-assignments-button.

- Player-select-menu now with unused/AI-toggle-button.

- Player-select-menu now with assign-by-fire. Consequently a dedicated "Start"-button has been added to this menu.

- Fix: Match-select-menu, ?translation mixup. It wasn't the conveyor-belt's size but the stomping wall's size

- Fix: Results-stats-screen now shows the correct dedicated background picture.

- Fix: the explosion's last "south" element was missing Forgot to adjust one layout file. Funny enough nobody noticed so far Added that one when I prepared the new Amiga ports for public release...

- Fix: the punch-up animation was wrong, it was the same as the punch-down animation. Reason was that there are several name conflicts with the original's unpacked asset names. This was one of those (a redundant set of punch-down anim frames would overwrite the true punch-up anims...) and in this case I forgot to set a patch. Now I did Funny enough nobody noticed so far Added that one when I prepared the new Amiga ports for public release...

- Fix: the internal multi_frame command eventually didn't load all anim frames. Affected some death animations.

- Fix: it could happen that two (or more) floating bombs ended up resting on the same field. I made a subtle logic change to prevent this. However, this had some interesting side-effects which I had to compensate for. Let's hope I cought'em all!

- Fix: bouncing bombs outside the actual playfield eventually made it into the next match.

- Fix: last Windows-installer was broken, files missing.

- Fix: Windows-version now correctly handles UAC when it comes to decrunching.

- RAM and VRAM requirements massively reduced.


v1.1:
- CD DATA detection improved.


v1.0:
- initial release.

Hi, dear bombing aficionados!

A blast from the past! Literally
Daytona675x, the best equipped man in code business, is proud to present his latest lucubration:
(sorry Andreas, I couldn't resist when I saw the Hollywood news )

Some weeks ago I released my fan rewrite of the Win95 game Atomic Bomberman (originally from 1997 by Interplay). And just yesterday I released an update which fixes a few issues and also adds some extra features.

It has been coded from scratch, just by watching and playing the original game on an antique Win98 machine. Much care has been taken to make the gameplay feel exactly as if you were playing the old original game.
Actually I coded this "rewrite" in 2011 already, so that we (my old university friends and I) could meet at my place every quarter of a year and play it on the big screen again. The problem was that the original game didn't properly work on modern Windows machines anymore. That was before I even knew about NG Amigas and such

End of 2018 I quickly ported it to AOS4. It was meant to be a contribution to Amiga Ireland 2019. Later in 2019, at the Amiga Future's stand at the Gamescom 2019, it was the audience magnet. It really attracted hundreds of people to the stand I also carried it to Amiga34, Amiwest 2019 and Amiga Ireland 2020. It's really the definitive party game Note that it's not meant to be played alone. While there is some rudimentary AI, it's just no fun.
Friends and booze and bombs, that's the correct setup

This rewrite / player program is free to use, at your own risk, maybe your computer just explodes, who knows.
However: The original game data files of the original Windows CD are required to play this game!

If you don't own it yet then you may buy it here or here for example.
Check the game's readme for further instructions.

Requirements:
+ lots of USB joypads (Geeekpi SNES style pads work well; be aware: many of those cheap pads DONT work with Amigas!)
+ original Atomic Bomberman game CD
+ one of the following:
- AmigaOS4: >= 4.1 FE, Warp3D
- AmigaOS4: >= 4.1 FE, Compositing (if you don't have a Warp3D-capable card)
- MorphOS: >= 10, TinyGL
- AROS: x86, e.g. Icaros >= 2.2.0, Mesa 3D

Or get it from my homepage. There you'll also find the Windows version.
And here's the dedicated Youtube playlist which contains all the dev recordings so far.

If the game doesn't start on Amigas: make sure the executable flag is set (protect AtomicBomberman +e).

One question to those who give it a try:
on ddni's X1000 (and so far only on this machine) the W3D version produces a tiny frame of uncritical but ugly pixel garbage around the picture. If this happens on your system too, please drop me a PM with your specs! Thanks!

Tchatching,
Daniel

@Capehill


@all
Update for MiniGL4GL4ES is now in the os4depot upload queue (together with two great games with which it has been successfully tested, namely Aquaria and Equilibrio, ported to AOS4 by Andrea Palmatè ).

Version 3.5 (6.1.2020)

- removed experimental delayed glClear hack which had been added to work around some pixel garbage in some games. Has too many potential side-effects though.

- internal bitmaps are being cleared on creation / resize. Yet another experiment regarding those rare pixel garbage situations. Seems to do the job.

- GL4ES: some internal code cleanup regarding env var handling (wow, about 4k redundant code is gone ).

- mglut.library's version set to 2.24 (06.01.2020) to avoid confusion.

- integrated ptitSeb's latest GL4ES improvements: Better handling of games that detach and delete shaders right after linking the program. And some cleanup.

And, of course: many many thanks to kas1e for more testing and more moral support

Cheers,
Daniel

Update for MiniGL4GL4ES is now in the os4depot queue:

Version 3.4 (5.2.2020)

- Fix: fullscreen <-> window toggle initiated by GLUT is working now. This means that e.g. Foobillard works flawlessly now, MiniGL demo "warp" doesn't crash anymore, etc.

- note: in contrast to previous notes env-var-handling works. The following issue made it appear as if it didn't:

- added extra support for env var LIBGL_FPS 1 so that it also works with games which don't call mglSwitchDisplay but do a cgl_UpdateContext with two alternating front- and back-bitmaps instead (e.g. Q3 SDL2).

- GL4ES messages can be enable via setenv LIBGL_NOBANNER 0

- GL_VERSION downgrade to 1.3 fixated. Hollywood's GL_Galore uses GLFW internally which does a very strict GL_VERSION consistency check, too strict for MiniGL Better to play low here.

- included GL4ES fix by ptitSeb: fixed rendering when using glPolygonMode and GL_LINE on GL_POLYGON (diagonal line issue reported by IamSONIC).

As always: many thanks to Roman (kas1e) for testing and moral support
Oh, btw., a little sidenote to the nay-sayers: this MiniGL library doesn't use too many float calculations inside...

Cheers,
Daytona675x

Update for MiniGL4GL4ES is now in the os4depot queue:
Version 3.3 (3.2.2020)

- Fix: if you tried to overwrite the library if it had been in use then the system would crash / freeze.

- additional GL_EXTENSION entry GL_EXT_compiled_vertex_arrays. This extension is a typo! Usually it is GL_EXT_compiled_vertex_array without "s" but MiniGL's original extension string has that typo... So this has been added to satisfy programs which falsely rely on it (e.g. Q3 SDL2)...

- additional GL_EXTENSION entry GL_MGL_packed_pixels. Old MiniGL variant of GL_EXT_packed_pixels.

- GL_VERSION downgraded to 1.3 for now; workaround for Hollywood's GL_Galore which refuses to run if the version is different.

- Changed temporary WaitBOVP to equally temporary WaitTOF.

As always: many thanks to kas1e for testing and moral support

Cheerio,
Daytona675x

@Spectre660
Too bad, then you're out of luck for now unfortunately.
I have no Polaris to test it in the first place and so far you're the only one with such an issue :(
Maybe your problem will go away once I've implemented decent vsync support. Or maybe not, it was just a wild guess :P

@sinisrus
Thanks for reporting!
This is a GLGalore bug, I just reported it to Andreas. GLGalore fails if the GL_VERSION is not 1.3 :P
For now I changed MiniGL4GL4ES to report 1.3 too, until now it reported 3.2
Here was a quick download for you (will not stay there for tooo long - EDIT gone, check os4depot for an official update).

@Spectre660
Hm, only idea that pops to my mind is the shitty temporary WaitBOVP call inside. Replaced it by a WaitTOF in that test-lib above, maybe that makes a difference.

@samo79
No, this isn't the MiniGL Reloaded I was working on. This thing here I hacked together in the last 2,5 days (ab)using GL4ES, *really* quick and really dirty It's good enough for many game playing use cases for now, no more no less. Better than nothing, for Polaris owners, when it comes to old school MiniGL support.

@Raziel
Personally I'd only use it if I was a Polaris user for now

@Capehill

1) hm, yes, I can (if I include gl2.h before, of course), but who knows, maybe there is some side-effect with your concrete use-case somewhere. Please upload a project incl. your makefile for me to try.

2) our ogles2 doesn't support the GL_EXT_shadow_samplers extension as of yet. Therefore the rect-texture extension lacks the shadow-part too - which is why I didn't care about such defines as of yet

3) we are in ogles2, there is no "texture environment". Therefore there aren't defines for parameters which are required only for not-existing functions like GetTexEnvfv, GetTexEnviv, TexEnvi, TexEnvf, Texenviv, and TexEnvfv.

4) yes, thanks, fixed!

@all
Fog-issue: it was a bug inside ogles2.library, found and fixed it yesterday Has nothing to do with the struct itself.

A bug in the uniform shader variable handler resulted in same-named (and thus in the context of a GLSL GPU program logically identical) vertex- and fragment-uniforms to eventually be assigned different location numbers.
If the user later issued a glUniform(location_number,xyz) call then the lib would only find and set the vertex-shader's uniform and skip the writing to the fragment-shader's uniform because it would simply not find it (unless you used expclicit location specifiers in the GLSL code or were lucky)

OpenGL doesn't distinguish between such same-named but physically different uniform variables in the shaders of a GPU program - in stark contrast to Nova, where all that info is shader and not shader-program based. Consequently Nova's ShaderGetObjectInfo, which is used to query uniform variable information, works on shaders only.
Also, Nova only gives us a GLSL / GL compatible "location" info if it has been explicitely defined inside the shader, otherwise it doesn't generate one but only returns W3DN_NOLOCATION.

Because of all this ogles2.lib has to generate such location infos by itself at program link time, in a GL compatible way. Which means that in case of a same-named variable in both of a program's shaders the same uniform location has to be enforced -> which is where the flaw was

@kas1e
@thellier

When I wrote kas1e it was during holidays far away from any machine and without being tooo exact So if there's any confusion, let's clear it up:

Of course it's always about ONE (1) DBO. You only can bind 1 DBO just like you can only bind 1 VBO to a shader pipeline.
But this single DBO is partitioned into TWO memory sections, one for the vertex shader and one for the fragment shader.

If a uniform with the same name appears in both shaders then physically those are NOT the same and ogles2 has to detect that situation and issue 2 writes into the DBO: one in the area for the vertex shader and one into the area for the fragment shader. That's simply because ogles2 doesn't distinguish between the vertex- and the fragment-part of a shader program when it comes to glUniform.

That's actually the only special thing ogles2 has to do. And so far I didn't find a bug on my side here. So far I didn't see any reason why ogles2 should only update the vertex shader area and not both, which is what the symptoms look like.
But I'm still checking

Internally things get a bit more complicated because for performance reasons DBOs are mirrored and multibuffered similar to what I do for VBOs.

@kas1e
(leaning back, putting feet up) Wow, that's fantastic news - at least for us Once more: thanks for all that (re-)testing!

@kas1e
Regarding the FBO issue: I found that the respective FBO becomes "incomplete". However, the parameters seem to be correct, I still didn't find out what's causing this.

Regarding the skybox issue you just brought up:
from the screenshots it looks as if there were two different issues. Two of the Tuxkart screenshots look like the hash problem reappearing indeed. However, to me the other skyboxes seem to be correct regarding the geometry (the clouds' edges seem to match) but only the coloring seems to be wrong. But this can be coincidence as well.
I've put a test-lib on my ftp for you, please check out if that makes the problems disappear.

@kas1e

Tabor freezes with
test 900

R7 250 2 GB
RadeonHD 3.6
graphics.library 54.226
Warp3DNova.library 1.65
ogles2.library 2.10

@kas1e
Then I'll have to inspect it in depth to find the cause and whether it's related to ogles2 or Nova or whatever. Please prepare a nice package for me and upload that to my FTP server, as usual Also, if you have fresh trace-logs with the latest glsnoop, hand'em over please!

@kas1e
The crash is obviously due to a typical programming bug in Nova, a wrong usage of boost::shared_ptr. Basically it's a classic invalid function-call-attempt on a nullptr.
Which somewhat fits into the discussion we had about potential boost misapplication some weeks ago, which has to be fixed asap.

@thellier
No, that's not the way to go. The second parameter to VBOSetArray must be the index of an array of the respective VBO, namely a value between 0 and N-1, where N is the value you used when creating your VBO. Also, your 40 is not the VBOsize, it's your vertex-size, your VBO certainly contains more than 1 vertex
In your example N is 3, but you try to falsely set array-layouts for non-existing arrays 3 to 39.

Keep in mind that for this trick the real layout of your arrays is not of interest.
What's important is that you use W3DNEF_UINT8 (otherwise endian conversion would kick in) and the same size (otherwise the driver acts somewhat dumb and always selects complex-slow-copy, which is why you eventually have to add some extra bytes to your VBO (and I suppose an 8 byte divisible size won't hurt neither)) for all arrays of the VBO.
The idea simply is to split the VBO memory temporarily into N sequential raw-ubyte areas of the same size.

Let's asume your VBO should contain 4 of your vertices. Then it looks like this:

ArrayCount=3 (xyz, uvw, rgba)
VertexSize=40
VBOsize=4*VertexSize=160

But for the trick to work we must ensure that the VBOsize is divisible by our ArrayCount, therefore:

if(VBOsize % ArrayCount) VBOsize+=(ArrayCount-(VBOsize % ArrayCount)), so
VBOsize=162

So you will firstly create a VBO with 3 arrays and byte-size 162.

In reality your buffer will look like this:

However, to make the anti-endian-conv-trick you temporarily make it appear like this though:


which is
for(uint32 i=0;i<N;++i) VBOSetArray(vbo_handle,i,W3DNEF_UINT8,FALSE,1,1,i*(vbo_size/N),vbo_size/N);
or here
for(uint32 i=0;i<3;++i) VBOSetArray(vbo_handle,i,W3DNEF_UINT8,FALSE,1,1,i*54,54);

@kas1e
Regarding the blue/red color swap: it's a Nova bug, although, well, to be fair: it's more a question of definition who's responsable for what and what's to be expected from what.

Anyway, Nova ignores any eventual channel swizzle settings of a texture when it's bound to an FBO.
Unfortunately this channel-swizzling is the way how I implemented BGRA texture support: it's actually a texture of format W3DNPF_RGBA (which actually only means that it should have 4 color channels) and then I modify its default channel mapping.

I submitted a small bug report against Nova.
However, because Hans signaled that he won't fix anything anytime soon and because it's probably not really his fault this time, I just added a temporary workaround to ogles2:

whenever a texture is now used as FBO render target, I reset its swizzling so that it at least can be rendered as expected. This may have other sideeffects but for most usecases this should do.