Strange portal rendering glitch (since maybe 4.8)

[emile_b]

I know this is closed but for interest this is cause by some alignment issue between HWLinePortal and line_t

This is the fix for 32bit machines for me:
https://github.com/emileb/gzdoom/blob/1 ... tal.h#L161

I can't see what exactly is causing it as the code looks like it should work fine. Thought I would mention it in case there is something fragile in the code and this appears later even on 64bit machines.

[Rachael]

If that's the case it could be a compiler error. If one simple line is enough to fix this, I will add it, but with the caveat that this does not change GZDoom's official status for supporting 32-bit. If anyone wants to do a 32-bit fork and this helps them, though - I have no issue with that.

EDIT: This already seems to be in GZDoom's master branch?

[emile_b]

Lol oh yeah sorry, it was something I found ages ago, didn't realise it was in upstream. Maybe it needs to be removed?! On ARM it seems to cause exactly the same error as shown in the picture and only affects 32bit code. But maybe not related, sorry for the false alarm!

Edit: yeah seems to I have snuck in with the gles2 updates last year

[Graf Zahl]

It's an alignment issue. Some recent change added an internal virtual method table pointer to this struct and with 32 bit alignment rules causes the part that mimics line_t to not align to 8 bytes anymore - but then fails with aligning the DVector2, creating an alignment gap, which is critical.

[Graf Zahl]

I rewrote that part to use safe language constructs instead. If this broke once it may do so again in the future on a different system so better let's steer clear of such unsafe type punning exploits.

[emile_b]

Ah just seen, good fix