Big Endian PPC 32 bit ( client side - MORPHOS platform )

[Cowcat5150]

So far I managed to make the client side work for ppc 32 and that could help other ports. Still some issues.

First of all R_LoadLump (tr_bsp.c) crashes when called.

My "fix" is right at the beginning of the function:

lump->filelen = LittleLong(lump->filelen);
lump->fileofs = LittleLong(lump->fileofs);

Next stop/crash is R_LoadTerrain that calls R_UnpackTerraPatch:

UnpackTerraPatch calls ShaderForShaderNum with those parameters.

pUnpacked->shader = ShaderForShaderNum(LittleShort(pPacked->iShader), LittleShort(pPacked->iLightMap));

But ShaderForShaderNum already has endian applied for first parameter -> shaderNum = LittleLong( shaderNum ); .

A possible fix is a ShaderForShaderNum function without LittleLong code and change all functions in tr_bsp.c that calls it with the proper parameters with endian applied.

Note: Actually UnpackTerraPatch "should" call ShaderForShaderNum that way:

pUnpacked->shader = ShaderForShaderNum(LittleUnsignedShort(pPacked->iShader), LittleUnsignedShort(pPacked->iLightMap)); // fix ? Cowcat

Now the issue:

Static models (tents, vegetation, etc ) that aren't displayed on screen: Don't know if R_CopyStaticModel ( called by R_LoadStaticModelDefs ) does its job. Values seem to be correct while endianness is done. If you remove whatever value there it gets the same effect in a X86 binary.

2nd Note: It is weird that UnPackTerraPatch has endianness applied while R_SwapTerraPatch ( all in R_LoadTerrain ) already does it. I have changed UnPackTerraPatch to not do endian code there. Still no staticmodels on display.

[smallmodel]

Try by setting r_staticlod to 0, and also try by setting r_nocull to 0. Try with one those variables set to 0 or both.

Also try rendering bounding boxes for static models, r_showstaticbboxes set to 1 (lag warning):

[Cowcat5150]

Nice. Besides some little issue I posted for the commits, a fix is needed for UnpackTerraPack calling ShaderForShaderNum (as I mentioned ). Don't know if you're on it.

The "cheat" parameters don't show anything except showstaticbboxes that works.

[smallmodel]

The BSP terra patch is swapped accordingly before being processed: https://github.com/openmoh/openmohaa/blob/main/code/renderer/tr_terrain.c#L1423 The fix is in place here as almost suggested. It should be fine now, as iShader and iLightMap are swapped by R_SwapTerraPatch

[Cowcat5150]

I know but pPacket->iShader is swapped again in ShaderForShaderNum and crashes.

[Cowcat5150]

In tr_bsp.c/ParseMesh

ds->subdivisions needs endian conversion. If not, some maps crawl, render (more) badly and crash.

Adding this seems correct:

// pre-tesseleate
    ds->subdivisions = LittleFloat(ds->subdivisions);

The problems regarding staticmodels on big-endian, at least on my system, aren't only with them but other models too (non static). I see a lot of culling failures on maps other than "basic training".

A detail/clue: Found that in R_AddStaticModelSurfaces (tr_staticmodels.cpp) when r_showstaticlod is enabled, the second R_DrawDebugNumber shows an "empty square" instead of numbers.

[Cowcat5150]

Good to have new debug options:

infoworldtris shows this in "basic training":

sm: 0, tris: 2, models/static/corona_orange.tik, version: 5
sm: 2, tris: 2, models/static/corona_orange.tik, version: 5
sm: 4, tris: 2, models/static/corona_orange.tik, version: 5
sm: 7, tris: 46, models/static/tree_oak.tik, version: 5
sm: 8, tris: 46, models/static/tree_oak.tik, version: 5
sm: 11, tris: 242, models/static/vehicle_gmctruck.tik, version: 5
sm: 14, tris: 22, models/static/bush_regularbush.tik, version: 5
sm: 15, tris: 22, models/static/bush_regularbush.tik, version: 5
sm: 16, tris: 2, models/static/tree_oak.tik, version: 5
sm: 17, tris: 2, models/static/tree_oak.tik, version: 5
sm: 18, tris: 2, models/static/tree_oak.tik, version: 5
sm: 19, tris: 2, models/static/tree_oak.tik, version: 5
sm: 20, tris: 2, models/static/tree_oak.tik, version: 5

...... blablabla

sm: 155, tris: 2, models/static/corona_orange.tik, version: 5
sm: 157, tris: 2, models/static/corona_orange.tik, version: 5
sm: 159, tris: 2, models/static/corona_orange.tik, version: 5
sm: 161, tris: 2, models/static/corona_orange.tik, version: 5
sm: 163, tris: 2, models/static/corona_orange.tik, version: 5
sm: 165, tris: 2, models/static/corona_orange.tik, version: 5
total static model tris: 1062

Compared to an ouput linux version, a whole bunch of models aren't displayed or have wrong tris number ( see vehicle_gmctruck for example ).

[gbudny]

Hi

Is this issue also exists in OpenMoHAA on Linux PowerPC?

[Cowcat5150]

@gbudny No idea about Linux/PPC. I should wrote "Linux LittleEndian/64bit" version vs "Morphos BigEndian/32bit" output.

[gbudny]

@gbudny No idea about Linux/PPC. I should wrote "Linux LittleEndian/64bit" version vs "Morphos BigEndian/32bit" output.

Hi

Thank you for the answer.

I know that you talk about OpenMoHAA for Linux x86-64. I mentioned OpenMoHAA for Linux PowerPC because I wonder if this issue exists on all PowerPC systems like Linux, MorphOS, or AmigaOS.

[smallmodel]

@gbudny No idea about Linux/PPC. I should wrote "Linux LittleEndian/64bit" version vs "Morphos BigEndian/32bit" output.

Hi

Thank you for the answer.

I know that you talk about OpenMoHAA for Linux x86-64. I mentioned OpenMoHAA for Linux PowerPC because I wonder if this issue exists on all PowerPC systems like Linux, MorphOS, or AmigaOS.

The issue is related to the architecture being big-endian, some data may not be read as big-endian. Will research this.

[gbudny]

@gbudny No idea about Linux/PPC. I should wrote "Linux LittleEndian/64bit" version vs "Morphos BigEndian/32bit" output.

Hi Thank you for the answer. I know that you talk about OpenMoHAA for Linux x86-64. I mentioned OpenMoHAA for Linux PowerPC because I wonder if this issue exists on all PowerPC systems like Linux, MorphOS, or AmigaOS.

The issue is related to the architecture being big-endian, some data may not be read as big-endian. Will research this.

Hi

Thank you for the answer.

I hope you can find a solution.