have you seen this?

The description of
https://github.com/phoboslab/wipeout-rewrite/issues/56 looks correct.
On Wazp3D Qemu is running

https://streamable.com/ws27so

@smarkusg

And the textures should be 16bit under QEMU with current drivers, as that’s all WB can display,
put perhaps its not working in 32bit, because its using 16bit textures.

Stuffing 2 pixels into one-pixel won’t work so well. Of course, it can be entireness thing as well,
graphics drivers have different BE/LE modes.

I’m not sure WPA converts BE/LE or just scales from 32bit to 16bit or the other way. How is it displayed on workbench.

@LiveForIt

AFAIK, WritePixelArray is a straight copy into a bitmap. No pixel format conversions whatsever.

When it comes to 16-bit modes, please check which mode you actually have. Older Radeon cards support big-endian 16-bit, whereas newer Radeon HD (Southern Islands) and Radeon RX cards don't. The Picasso96 driver API doesn't allow the driver to do any automatic conversion. So, your software had better check what screen-mode it's running on. We've had trouble in the past with software assuming that big-endian 16-bit modes are available.

This is also why Wipeout 2097 can't be used in full-screen mode with newer hardware...

Hans

@SinanSam460

crash/GR says "Trap type: Alignment exception":
54.60 (24.8.2023) Sam460 release
Machine model: 7 (Sam460ex)
Dump of context at 0xff9ef3e0
Trap type: Alignment exception
Machine State (raw): 0x2f030
Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Temporary stack trace:
#0: 0x7ef0e1f4
#1: 0x7ef34394
#2: 0x7ef1e630
#3: 0x7ef4c540
#4: 0x7ef51cb0
#5: in module Kickstart/newlib.library.kmod+0x2624 (0x1b2a564)
#6: in module Kickstart/newlib.library.kmod+0x3350 (0x1b2b290)
#7: in module Kickstart/newlib.library.kmod+0x3874 (0x1b2b7b4)
#8: 0x7ef0b284
#9: in module Kickstart/kernel+0x54f48 (0x1854f48)
#10: in module Kickstart/kernel+0x54fc0 (0x1854fc0)
#11: 0x0

Crashed process: wipEgame (0x59887e20)
0: 01b31758 5b5fca70 00000000 00000000 5b5fcaa0 00000000 00000040 0000001c
8: 00000000 5b7a754d 80000000 5b5fca70 00000794 5b60f42c 595f9f90 00000001
16: 00000000 00000000 5bc8f280 00000000 5b5fcdd8 7ef51a34 00000009 595f9f80
24: 00000000 595f9f70 00000000 00000000 022e0000 59870680 5b5fcc88 5b5fca70
CR: 24442824 XER: 00000008 CTR: 00000000 LR: 7ef0e1c4
ESR: 01800000
DEAR: 5b7a75b5
mcsrr0: 0x0
csrr0: 0x0

Disassembly of crash site:
7ef0e1e4: c99f0080 lfd f12,128(r31)
7ef0e1e8: fc0c0028 fsub f0,f12,f0
7ef0e1ec: fc000018 frsp f0,f0
7ef0e1f0: 813f0024 lwz r9,36(r31)
>7ef0e1f4: d0090068 stfs f0,104(r9)
7ef0e1f8: 393f0030 addi r9,r31,48
7ef0e1fc: 7d244b78 mr r4,r9
7ef0e200: 807f001c lwz r3,28(r31)
7ef0e204: 4bfffbe9 bl 0x7EF0DDEC
7ef0e208: 7c691b78 mr r9,r3

Kernel command line: debuglevel=4 SERIAL MUNGE

Registers pointing to code:
r0 : native kernel module Kickstart/newlib.library.kmod+0x00009818
r9 : wipEgame:hunk()+0x19e9d9 (section 22 @ 0x19FF6D)
r13: wipEgame:hunk()+0x68b8 (section 22 @ 0x7E4C)
r15: module wipEgame at 0x00000001 (section 0 @ 0xFFFFFFDC)
r21: [src/platform_sdl.c:344] wipEgame:main()+0x0 (section 1 @ 0x49A30)
r28: native kernel module Kickstart/ohci.usbhcd+0x00465b00
ip : [src/wipeout/object.c:59] wipEgame:objects_load()+0x308 (section 1 @ 0x61F0)
lr : [src/wipeout/object.c:59] wipEgame:objects_load()+0x2d8 (section 1 @ 0x61C0)
ctr: unknown (0x0)

Stack trace:
(0x5b5fca70) [src/wipeout/object.c:59] wipEgame:objects_load()+0x308 (section 1 @ 0x61F0)
(0x5b5fcc50) [src/wipeout/object.c:59] wipEgame:objects_load()+0x2d8 (section 1 @ 0x61C0)
(0x5b5fcca0) [src/wipeout/game.c:530] wipEgame:game_init()+0x10c (section 1 @ 0x1662C)
(0x5b5fccd0) wipEgame:system_init()+0x4c (section 1 @ 0x4453C)
(0x5b5fccf0) [src/platform_sdl.c:411] wipEgame:main()+0x27c (section 1 @ 0x49CAC)
(0x5b5fcd40) native kernel module Kickstart/newlib.library.kmod+0x00002624
(0x5b5fcd90) native kernel module Kickstart/newlib.library.kmod+0x00003350
(0x5b5fcf40) native kernel module Kickstart/newlib.library.kmod+0x00003874
(0x5b5fcf70) wipEgame:_start()+0x1e0 (section 1 @ 0x3280)
(0x5b5fcfc0) native kernel module Kickstart/kernel+0x00054f48
(0x5b5fcfd0) native kernel module Kickstart/kernel+0x00054fc0

Disassembly of crash site:
7ef0e1e4: c99f0080 lfd f12,128(r31)
7ef0e1e8: fc0c0028 fsub f0,f12,f0
7ef0e1ec: fc000018 frsp f0,f0
7ef0e1f0: 813f0024 lwz r9,36(r31)
>7ef0e1f4: d0090068 stfs f0,104(r9)
7ef0e1f8: 393f0030 addi r9,r31,48
7ef0e1fc: 7d244b78 mr r4,r9
7ef0e200: 807f001c lwz r3,28(r31)
7ef0e204: 4bfffbe9 bl 0x7EF0DDEC
7ef0e208: 7c691b78 mr r9,r3
Stack pointer (0x5b5fca70) is inside bounds
Redzone is OK (4)

...

@jabirulo

"Trap type: Alignment exception"

Means that instruction stfs needs aligned memory.

(R9 is 5B7A754D in HEX, 1534752077 in decimal.
as number ends with 7, and 7 can't be divided by 4 or 8.)

Typical 16 bytes alignment on AlltiVec, doubles are 64bit / 8 bytes.

AllocVecTags() has option for alignment, just remember to free it with FreeVec.

If your replacing malloc() with AllocVecTags you also need to remember to replace free() with FreeVec()

It is odd that happen to end up with nonaligned memory,
I assume at least 2bytes alignment be normal,
perhaps a length is read wrong, if high byte, low byte is swapped, you get a bad length. As result you can get a bad offset.

@LiveForIt

thx, still think is some endianess issue with textures/colors/..., 'cos audio was garbled and changing:

SDL_OpenAudioDevice(...
#ifdef __amigaos4__
.format = AUDIO_F32SYS,
#else
.format = AUDIO_F32,
#endif
...

now audio works fine (or just I'm lucky)

@LiveForIt
Quote:That's enough on all other Power(PC) CPUs supported by AmigaOS, for some even 2 byte alignment is enough for float/double, but not on 405 CPU cores with an "external" FPU (Sam440/460): float/double accesses must never cross a cache line boundary.
If it does you get an alignment exception, i.e. for double you need to use 8 byte alignment.

Quote:malloc() results (with newlib, no idea about clib2) should have at least 4 byte alignment.
If you need more alignment it's easier to replace malloc() with memalign() than using IExec->AllocVecTags()/FreeVec() instead: No need to replace free() as well.

@Hans
Quote:It has to do format conversation since it has a source (PIX_FMT srcPixelFormat argument) and a destination (the one used in the dst RastPort) pixel format, which may be different.

@joerg

There is 3 different versions of WPA, P96, CGX and graphic.Library.

from benchmark, it looked where similar scores, this why think perhaps it’s not doing byte swap, should be more deviation, between the different input / output format.

I think I need to do visual confirmation, or wite a validator.

One more thing, is WPA does not return success / failure, perhaps it possible to add without breaking software.

@LiveForIt
Quote:In AmigaOS 3.x and maybe MorphOS, but not in AmigaOS 4.x.
The AmigaOS 4.x cybergraphics.library always was just a wrapper calling P96, or graphics.library, functions, and Picasso96API.library doesn't exist anymore either, the only exception are the p96PIP_#?() functions.
All other Picasso96API.library functions are just simple wrappers calling the corresponding graphics.library functions now.

@joerg
Exactly, in os4 they all wrappers and that why they recommend to use graphics.library functions directly, and forget direct usage of cgx and p96. All in all usage of wrappers will be slower always.

P96 versions still can be used (for historical reassons) but were merged into graphics.library since some years and marked as abandoned

@all

@all

I tried to add some fixes from

https://github.com/phoboslab/wipeout-rewrite/issues/56

My current version looks like this

@Sinan
Quote:
Why some and not all ?:)

Anyway, sorry to sounds naive, but, wasn't you able just build BeWorld's version ? If i got it right, the colors on morphos version are ok (so endian issues are dealt with).

Or, version from PPC Linux, which also seems to be ok seeing the answers in the thread from Chrisian

@kas1e

I Downloaded BeWorld github (fix branch) and recompiled, and it just hangs when loading .PRM files ¿:-/

So I'm (like Sinan) applying step by step such patches and see where it hangs.

<thinking_loud>
Maybe MoprhOS GL library doesn't use GLES2 (as ours, and dunnot if there are "big" diffs between GL and GLES2 or "things" are applied differently on our 3Dgfx system VS mos 3Dgfx system) and some things do work with BeWorld's fixes and others don't.)
</thinking_loud>

EDIT1: and now such brach (fix) doesn't exists ¿:-/
his ain branch doesn't have render_gl_legacy,c

@SinanSam460

Great no more LSD-ish colors!!!!
Keep the good work mate!

@jabirulo
Maybe then LinuxPPC port worth to recompile ?

As for GL vs GLES2 differences : you do compile with GL4ES ? If yes, then it's "GL 2.x". If you do use OGLES2 directly, without GL, then there can be differences, but if it GL4ES , then it's the same "GL".

I also read some have issues with alignments crashes, they were solved already ?

And, seeing the picture from Sinan, it looks like textures just didn't loads up ?

@all

Maybe this will be useful to someone.

Before my compilation I downloaded a git:
BeWorld2018 ->fix
mrneo240 ->master
phoboslab ->master


According to the instructions from here : https://github.com/phoboslab/wipeout-rewrite/issues/56

Most of the patches from "BeWorld2018 ->fix" were added to "phoboslab ->master"

so my head branch remained - "mrneo240 ->master"="wip-dev"
added all patches that were missing from "phoboslab ->master" and added "BeWorld2018-morph.patch"

everything is sorted on a branch and dated 3.09.2023
In addition, in each folder there is a "patch" folder where all patches are located

in the "wip-dev" directory is what I did and there is also a directory for patches which have been added.
It runs on Linux x86_86 and on AOS Qemu 16bit.

As I wrote, it is fairly clear - if someone wants to use it, I have put up a file



https://we.tl/t-kjRPB1ubFy

I dont really publish my sources for WipeOut.
So i publish it because, i dont understand why that doesnt working for you

So I mixed 2 fork:

https://github.com/phoboslab/wipeout-rewrite
and
GL_LEGACY:
https://github.com/mrneo240/wipeout-rewrite

I just upload my fork for WipeOut here:

https://github.com/BeWorld2018/wipeout-rewrite/tree/master

Try that, and hope that working for you.

@beworld and @all

Thanks Beworld.

Some progress, more textures are loaded.

But no still no fonts, no sky

@Sinan
This is GL4ES build , right ?

Just to be sure, check if you have no errors in console about failing shaders, and, also, try to delete .psa dir just in case in the root (it contains precompiled shaders, so maybe old ones used).