Release Wipeout Rewrite


Farox

Certified Guru
Joined
Jan 8, 2009
Messages
2,413
Age
56
Location
Italy
Website
rbnet.it
Hello after Pyra i just released Wipeout Rewrite for Pandora.

shot03.png



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.
 
Last edited:
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);
 
@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
 
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.
 
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.
 
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.
 
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 ;)
 
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.
 
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 ;) )
 
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.)

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.
 
Last edited:
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...
 
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 :cool:
 
Back
Top