Release Wipeout Rewrite

Farox · Oct 31, 2023

Hello after Pyra i just released Wipeout Rewrite for Pandora.

The game is a re-implementation of the 1995 PSX game wipEout. This re-implementation is done using SDL2, GL and GLEW libs.

More info in the author blog: https://phoboslab.org/log/2023/08/rewriting-wipeout
Where you can find also the game datas needed to run the game, as i didn't included to avoid legal problems.
Note that the author blog may or may not provide in the future a link to a ZIP file containing all files needed.
Once you have the game datas, uncompress it into appdata/wipeout_remaster/wipeout directory.

Pandora port is based on a different codebase, a fork for MorphOS that added GL-Legacy a more compatible code with old machines.

Pandora port run with the help of GL4ES library of ptitSeb.
Controls are adapted for my taste, but you can change it on the options menu.

Enjoy and let me know how it run on your Pandora.
With version 0.1.0.2 on a CC Pandora the game runs fine @600Mhz, so no need to overclock anymore.

M-HT · Nov 1, 2023

Farox said:
Anyway the game is a bit slow on our beloved Pandora, as i wasn't able to obtain a stable compilation using compiler optimizations over -O1
(i could have a working game with -O2 if i omit Cortex-a8 and Neon to the makefile...).

Try fixing alignment in function mem_temp_alloc in file mem.c.
Change this:

C:

void *mem_temp_alloc(uint32_t size) {
    size = ((size >> 3) + 7) << 3; // allign to 8 bytes

to this:

C:

void *mem_temp_alloc(uint32_t size) {
    size = ((size + 7) >> 3) << 3; // allign to 8 bytes

And if you didn't already, then apply alignment in function mem_bump (in file mem.c).
Change this:

C:

void *mem_bump(uint32_t size) {
    error_if(bump_len + temp_len + size >= MEM_HUNK_BYTES, "Failed to allocate %d bytes in hunk mem", size);

to this:

C:

void *mem_bump(uint32_t size) {
    size = ((size + 3) >> 2) << 2; // allign to 4 bytes
    error_if(bump_len + temp_len + size >= MEM_HUNK_BYTES, "Failed to allocate %d bytes in hunk mem", size);

Farox · Nov 1, 2023

@M-HT Thanks the second was already applied.
But adding the first one i have a running game only with -O2 ....with -O3 (or -Ofast) i have a bus error:

LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Sep 19 2022 09:23:07
LIBGL: Using GLES 1.1 backend
LIBGL: loaded: libGLES_CM.so
LIBGL: loaded: libEGL.so
LIBGL: Using GLES 1.1 backend
LIBGL: Extension GL_OES_framebuffer_object detected and used
LIBGL: Extension GL_OES_point_sprite detected and used
LIBGL: Extension GL_OES_point_size_array detected
LIBGL: Extension GL_OES_texture_cube_map detected and used
LIBGL: Extension GL_OES_blend_subtract detected and used
LIBGL: Extension GL_OES_blend_func_separate detected and used
LIBGL: Extension GL_OES_blend_equation_separate detected and used
LIBGL: Extension GL_OES_texture_mirrored_repeat detected and used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_depth24 detected and used
LIBGL: Extension GL_OES_rgb8_rgba8 detected and used
LIBGL: Extension GL_EXT_multi_draw_arrays detected
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_draw_texture detected and used
LIBGL: Max texture size: 2048
LIBGL: Texture Units: 4/4 (hardware: 4), Max lights: 8, Max planes: 6
LIBGL: Max Color Attachments: 1 / Draw buffers: 1
LIBGL: Hardware vendor is Imagination Technologies
LIBGL: EGLImage to Texture2D supported
LIBGL: EGLImage to RenderBuffer supported
LIBGL: Targeting OpenGL 1.5
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: FBO workaround for using binded texture enabled
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: glX Will try to recycle EGL Surface
LIBGL: Current folder is:/media/toshi32/code/wipeout-rewrite-legacy
best_index=4
Failed to load gamecontrollerdb.txt
LIBGL: Enable LIBGL_VSYNC=1 if you want to use vsync.
load save data success
load cmp wipeout/textures/drfonts.cmp
load: wipeout/textures/speedo.tim
load: wipeout/textures/target2.tim
load cmp wipeout/common/wicons.cmp
load cmp wipeout/common/allsh.cmp
load: wipeout/common/allsh.prm
load cmp wipeout/common/alcol.cmp
load: wipeout/common/alcol.prm
load: wipeout/textures/shad1.tim
load: wipeout/textures/shad2.tim
load: wipeout/textures/shad3.tim
load: wipeout/textures/shad4.tim
load cmp wipeout/common/rescu.cmp
load: wipeout/common/rescu.prm
load cmp wipeout/common/effects.cmp
load: wipeout/textures/target2.tim
load cmp wipeout/common/mine.cmp
load: wipeout/common/rock.prm
load: wipeout/common/mine.prm
load: wipeout/common/miss.prm
load: wipeout/common/shld.prm
load: wipeout/common/shld.prm
load: wipeout/common/ebolt.prm
open music track 0
Bus error

Well better than -O1 with this...Thanks

Farox · Nov 1, 2023

Ok i found what is causing BusError...is the intro video (or the source code that is loading it).

Using GDB i compiled with -O3 and the other options and found :

Code:

Thread 1 "wipegame" received signal SIGBUS, Bus error.
0x00036254 in plm_audio_decode_frame (self=self@entry=0x2b07cc <hunk+2466700>) at src/wipeout/../libs/pl_mpeg.h:4033
4033                                self->U[i] += self->D[d_index++] * self->V[ch][v_index++];

Also i found that removing the intro video the game runs fine with max optimizations.

TeDaDeS · Nov 1, 2023

I vaguely remember @ptitSeb was using GL batching to optimize draw calls, might something like that be applicable here to?

M-HT · Nov 2, 2023

Farox said:
Ok i found what is causing BusError...is the intro video (or the source code that is loading it).

Using GDB i compiled with -O3 and the other options and found :

Code:

Thread 1 "wipegame" received signal SIGBUS, Bus error. 0x00036254 in plm_audio_decode_frame (self=self@entry=0x2b07cc <hunk+2466700>) at src/wipeout/../libs/pl_mpeg.h:4033 4033 self->U[i] += self->D[d_index++] * self->V[ch][v_index++];

Also i found that removing the intro video the game runs fine with max optimizations.

I don't see anything suspicious here. It might be a compiler bug.
You can add #pragma GCC optimize ("O2") to intro.c, somewhere before #include "../libs/pl_mpeg.h". This way, the intro.c should be compiled with -O2 (the project can be compiled with -O3) and you can keep the intro video.

Farox · Nov 2, 2023

Wow great thank you!
Its working good....i'll update the pnd soon.

netcat · Nov 2, 2023

It's an ... outright re-wipe!

TeDaDeS · Nov 2, 2023

Farox said:
Wow great thank you!
Its working good....i'll update the pnd soon.

Any feeling on how much it differs?

I vaguely remember a presentation that explained optimizations used from compilers can be in the margin of error and some larger gains are attributed to the correct alignment of memory in cache.

atari_afternoon · Nov 3, 2023

It works great for me (CC, 750 MHZ, swap). I even have the files on the swap.
Thanks, Farox!
So far I have not encountered any noticeable problems or slowness. But I did not have a PS1 back in the day to compare the speeds - I did not know Wipeout until the PSP era, which was some 10 years later.
May report later after the first championships if anything should turn up

Farox · Nov 3, 2023

Updated the PND with the latest recompile with -Ofast. The game now runs fine (BIG Thanks @M-HT ) at stock 600Mhz and without Swapfile (but having one didn't hurt).

I also have experimented (thanks to @PowerGod that supplyed me his updated script that add those functionality) a version that automatically donwload game datas, unzip it ,and install from the Blog of author of the Rewrite....but i'm not sure is is the good thing.
Let me know your opinion about it.

atari_afternoon · Nov 3, 2023

IMHO, download linking is not really necessary. Another reason would be, would any link still be valid in five years, or ten? The game (and our Pandoras) will still be running after another 15 years

)

PowerGod · Nov 3, 2023

atari_afternoon said:
would any link still be valid in five years, or ten? The game (and our Pandoras) will still be running after another 15 years )

The automatic download is just an optional/easier/faster way to be ready to play, so it doesn't exclude the possibility of the manual installation of the files. (At least if it's made like the one of ZGloom.)
If the actual URL becomes invalid, you'll just go with the manual way.
(Anyway the URL is just a string value in the starting bash, it's not compiled of something.)

Farox said:
install from the Blog of author of the Rewrite....but i'm not sure is is the good thing.

Maybe just add a message to make aware people that the download could be against the law of the interested country, and the responsibility is all in their hands if they press the button.

Farox · Nov 3, 2023

PowerGod said:
The automatic download is just an optional/easier/faster way to be ready to play, so it doesn't exclude the possibility of the manual installation of the files. (At least if it's made like the one of ZGloom.)
If the actual URL becomes invalid, you'll just go with the manual way.

Yes exactly i've adapted your script to work with this download.
But i think for now i will not pubblish...

PowerGod · Nov 3, 2023

On my Rebirth with default speed I noted some little frame drop, nothing that makes the game unplayable, but playing at 1 Ghz is way better for me.

Thanks for the port

Release Wipeout Rewrite

Farox

Certified Guru

M-HT

Very Active Member

Farox

Certified Guru

Farox

Certified Guru

TeDaDeS

Forum Addict!

M-HT

Very Active Member

Farox

Certified Guru

netcat

Hardcore Member

TeDaDeS

Forum Addict!

atari_afternoon

Very Active Member

Farox

Certified Guru

atari_afternoon

Very Active Member

PowerGod

Forum Addict!

Farox

Certified Guru

PowerGod

Forum Addict!

Similar threads