GithubHelp home page GithubHelp logo

wipeout-rewrite's Introduction

wipEout Rewrite

This is a re-implementation of the 1995 PSX game wipEout.

Play here: https://phoboslab.org/wipegame/

More info in my blog: https://phoboslab.org/log/2023/08/rewriting-wipeout

⚠️ Work in progress. Expect bugs.

Building

The Wipeout rewrite supports two different platform-backends: SDL2 and Sokol. The only difference in features is that the SDL2 backend supports game controllers (joysticks, gamepads) and uses OpenGL 2.x, while the Sokol backend does not support controllers and uses OpenGL 3.3. The Sokol backend is also only supported on macOS, Linux, Windows and Emscripten.

For Linux & Unix-likes a simple Makefile is a provided. Additionally, this project can be build with CMake for all platforms.

Consult the following sections for how to install the prerequisites for your platform:

Linux & Unix-like

Building on Linux should be as simple as installing CMake, GLEW, and the necessary platform libraries from your package manager. For brevity, this guide assumes that the necessary development tools (i.e. a C compiler, make) have already been installed. The SDL2 platform should only require the sdl2 library and headers, whilst the Sokol platform requires the library/headers for:

  • X11
  • Xi
  • Xcursor
  • ALSA

The following snippets list the specific package manager invocations for popluar *nix OSs:

Debian/Ubuntu

apt install cmake libglew-dev
# For SDL2
apt install libsdl2-dev
# For Sokol
apt install libx11-dev libxcursor-dev libxi-dev libasound2-dev

Fedora

dnf install cmake glew-devel
# For SDL2
dnf install SDL2-devel
# For Sokol
dnf install libx11-devel libxcursor-devel libxi-devel alsa-lib-devel

Arch Linux

pacman -S cmake glew
# For SDL2
pacman -S sdl2
# For Sokol
pacman install libx11 libxcursor libxi alsa-lib

OpenSUSE

zypper install cmake glew-devel
# For SDL2
zypper install SDL2-devel
# For Sokol
zypper install libx11-devel libxcursor-devel libxi-devel alsa-lib-devel

FreeBSD

pkg install cmake sdl2

OpenBSD

pkg_add cmake sdl2

Note that the Sokol platform is not supported on the BSDs, since the Sokol headers themselves do not support these Operating Systems.

With the packages installed, you can now setup and build:

# With make for SDL2 backend
make sdl

# With make for SDL2 with GLX backend (for legacy NVIDIA and perhaps others)
USE_GLX=true make sdl

# With make for Sokol backend
make sokol

# With cmake
cmake -S path/to/wipeout-rewrite -B path/to/build-dir
cmake --build path/to/build-dir

macOS

Currently only the SDL2 platform works. macOS is very picky about the GLSL shader version when compiling with Sokol and OpenGL3.3; it shouldn't be too difficult to get it working, but will probably require a bunch of #ifdefs for SDL and WASM. Pull-requests welcome!

It is recommended to use Homebrew to fetch the required software, other solutions (e.g. MacPorts) may work but have not been tested. Using homebrew, you can install the required software with the following:

brew install cmake
# For SDL2
brew install sdl2
# Nothing extra needed for Sokol

With the packages installed, you can now setup and build:

cmake -S path/to/wipeout-rewrite -B path/to/build-dir \
	-DCMAKE_PREFIX_PATH="$(brew --prefix sdl2)"
cmake --build path/to/build-dir

Windows

clang-cl

Building natively on Windows requires a more complicated setup. The source code relies on GCC extensions that are not supported by msvc, which requires the use of clang-cl. The simplest way to get a build environment with clang-cl is to download and install Visual Studio (2022 at the time of writing) with the "Desktop development with C++" option selected. Also make sure to select "Clang C++ compiler for Windows" in "Individual Components" if it hasn't been already.

The next step is to acquire development versions of SDL2 and GLEW. The easiest way is to install vcpkg and let Visual Studio's integration build and install it for you. Follow the vcpkg "Getting Started" guide and integrate it with Visual Studio.

Finally, open Visual Studio, select "Open a local folder", and navigate to the directory where you have cloned this repo. Visual Studio should automatically configure itself to build with CMake, and build the necessary libraries using vcpkg. Since this repository contains a CMakeSettings.json file, there should already be CMake configurations listed in the menubar dropdown. When adding a new configuration, make sure to use the clang_cl toolsets. Select the config you want from the list and build using F7, the build artifacts should be under path\to\wipeout-rewrite\build.

MSYS2

Building with MSYS2 is sightly easier but still involves a bit of configuration. Download and install MSYS2 using the installer, and enter a MSYS2 environment using the start menu. For this guide we're using the UCRT environment, but the others work just as well.

Install the following packages using pacman:

pacman -S mingw-w64-ucrt-x86_64-{toolchain,cmake,SDL2,glew}

With the packages installed, you can now setup and build:

# With make for SDL2 backend
make sdl

# With make for Sokol backend
make sokol

# With cmake
cmake -S path/to/wipeout-rewrite -B path/to/build-dir
cmake --build path/to/build-dir

Emscripten

Download and install the Emscripten SDK, so that emcc and emcmake is in your path. Linux users may find it easier to install using their distro's package manager if it is available. Note that only the Sokol platform will work for WebAssembly builds.

With the SDK installed, you can now setup and build:

# With make (combined full and minimal builds)
make wasm

# With cmame (full or minimal builds specified via -DMINIMAL_BUNDLE={OFF|ON})
emcmake cmake -S path/to/wipeout-rewrite -B path/to/build-dir -DPLATFORM=SOKOL
cmake --build path/to/build-dir

Build Flags for cmake

The following is a table for project specific build flags using CMake:

Flag Description Options Default
PLATFORM The platform to build for. SDL2, SOKOL SDL2
RENDERER Graphics renderer. GL for OpenGL 3, GLES2 for OpenGL ES 2, SOFTWARE for a pure software renderer. GL
USE_GLVND Link against the OpenGL Vendor Neutral Dispatch libraries. ON, OFF ON, falling back to OFF if the libraries aren't found or an OpenGL renderer isn't used.
MINIMAL_BUNDLE Do not include the music/intro video when building for the web. ON, OFF OFF
PATH_ASSETS Set a static path where the game assets are loaded from. Any valid filesystem path. Unset
PATH_USERDATA Set a static path where user data (e.g. game saves) are stored. Any valid filesystem path. Unset
DEV_BUILD Sets the assets/userdata path to the source directory. Useful when testing any changes. ON, OFF OFF

Running

This repository does not contain the assets (textures, 3d models etc.) required to run the game. This code mostly assumes to have the PSX NTSC data, but some menu models from the PC version are required as well. Both of these can be easily found on archive.org and similar sites. The music (optional) needs to be provided in QOA format. The intro video as MPEG1.

The directory structure is assumed to be as follows

./wipegame # the executable
./wipeout/textures/
./wipeout/music/track01.qoa
./wipeout/music/track02.qoa
...

Note that the blog post announcing this project may or may not provide a link to a ZIP containing all files needed. Who knows!

Optionally, if you want to use a game controller that may not be supported by SDL directly, you can place the gamecontrollerdb.txt in the root directory of this project (along the compiled wipegame). Note that if you want to use the analog sticks of your gamecontroller in the game you have to configure it in the Options menu; the analog sticks are not bound by default.

Ideas for improvements

PRs Welcome.

Not yet implemented

Some things from the original game are not yet implemented in this rewrite. This includes

  • screen shake effect
  • game-end animations, formerly Spline.cpp (the end messages are just shown over the attract mode cameras)
  • reverb for sfx and music when there's more than 4 track faces (tunnels and such)
  • some more? grep the source for TODO and FIXME

Gameplay, Visuals

  • less punishing physics for ship vs. ship collisions
  • less punishing physics for sideways ship vs. track collisions (i.e. wall grinding like in newer wipEouts)
  • somehow resolve the issue of inevitably running into an enemy that you just shot
  • add additional external view that behaves more like in modern racing games
  • dynamic lighting on ships
  • the scene geometry could use some touch-ups to make an infinite draw distance option less awkward
  • increase FOV when going over a boost
  • better menu models for game exit and video options
  • gamepad analog input feels like balancing an egg
  • fix collision issues on junctions (also present in the original)

Technical

  • implement frustum culling for scene geometry, the track and ships. Currently everything within the fadeout radius is drawn.
  • put all static geometry into a GPU-side buffer. Currently all triangles are constructed at draw time. Uploading geometry is complicated a bit by the fact that some scene animations and the ship's exhaust need to update geometry for each frame.
  • the menu system is... not great. It's better than the 5000 lines of spaghetti that it was before, but the different layouts need a lot of ifs
  • the save data is just dumping the whole struct on disk. A textual format would be preferable.
  • since this whole thing is relying on some custom assembled assets anyway, maybe all SFX should be in QOA format too (like the music). Or switch everything to Vorbis.
  • a lot of functions assume that there's just one player. This needs to be fixed for a potential splitscreen mode.

License

There is none. This code may or may not be based on the source code of the PC (ATI-Rage) version that was leaked in 2022. If it were, it would probably violate copyright law, but it may also fall under fair use ¯\_(ツ)_/¯

Working with this source code is probably fine, considering that this game was originally released 28 years ago (in 1995), that the current copyright holders historically didn't care about any wipEout related files or code being available on the net and that the game is currently not purchasable in any shape or form.

In any case, you may NOT use this source code in a commercial release. A commercial release includes hosting it on a website that shows any forms of advertising.

PS.: Hey Sony! If you're reading this, I would love to work on a proper, officially sanctioned remaster. Please get in touch <3

wipeout-rewrite's People

Contributors

andypiper avatar beworld2018 avatar bjnfne avatar ekirchman avatar eltociear avatar enigma9o7 avatar johnflan avatar juanantlopez avatar lukp17 avatar phoboslab avatar spykyvenator avatar the-king-of-toasters avatar tjrileywisc avatar vanfanel avatar wgmyers avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wipeout-rewrite's Issues

Option to disable joystick support or clear their buttons

I can only guess that I have an issue where there's a joystick being detected by the game preventing me from exiting 1st person view and veering left slightly at all times. Not sure how to fix this besides getting a gamepad to perhaps read real values from (I do not have one currently plugged in).

float unrepresentable in integer range

Minimal version, 40 seconds into the game, just trying it out. Chromium console shown:

wipeout-minimal.wasm:0x143b1 Uncaught RuntimeError: float unrepresentable in integer range
    at wipeout-minimal.wasm:0x143b1
    at wipeout-minimal.wasm:0x28ae
    at wipeout-minimal.wasm:0x17ec6
    at wipeout-minimal.wasm:0x55c01
    at wipeout-minimal.wasm:0x62329
    at wipeout-minimal.wasm:0x711bd
    at Module.dynCall_idi (wipeout-minimal.js:6789:39)
    at tick (wipeout-minimal.js:5133:13)

All settings were kind of random in the main menu, so it's possible that I cannot reproduce it. I was pressing x continuously and z multiple times. Hopefully, the screenshot helps a bit more to identify the location:

image

Assembly:

    local.set $var97
    local.get $var97
    f64.convert_i32_s
    local.set $var366
    local.get $var370
    local.get $var366
    f64.mul
    local.set $var373
    local.get $var282
    i32.load
    local.set $var98
    local.get $var98
    i32.const 2
    i32.div_s
    i32.const -1
    i32.and
    local.set $var231
    local.get $var231
    f64.convert_i32_s
    local.set $var368
    local.get $var373
    local.get $var368
    f64.sub
    local.set $var375
    local.get $var375
    i32.trunc_f64_s ; This is the problematic point at 0x143b1
    local.set $var228
    local.get $var267
    local.get $var228
    i32.store
    local.get $var267
    i32.const 4
    i32.add
    local.set $var299
    local.get $var278
    i32.const 4
    i32.add
    local.set $var316
    local.get $var316
    f32.load
    local.set $var328
    local.get $var328
    f32.neg
    local.set $var348
    local.get $var348
    f64.promote_f32
    local.set $var361
    local.get $var361
    f64.const 1
    f64.add
    local.set $var356

Can't build current GIT version on GNU/Linux

hi there @phoboslab

Until now, I was following development easily by building often on GNU/Linux, but recently compilation has broken:


src/wipeout/image.c:20:10: fatal error: stb_image_write.h: No such file or directory
   20 | #include <stb_image_write.h>
      |          ^~~~~~~~~~~~~~~~~~~

I have been building like this until now with no problems:
C_FLAGS="-march=native -mtune=native -fomit-frame-pointer" GL_VERSION=GLES2 make sdl -j4

Any ideas on what has happened?

Request: Anti-Aliasing

This port runs great already, so why not add some QoL features. On Windows using my Cmake fork I've been running the game at 4k 144Hz with 8x SSAA + 8x Transparency AA on my 4080, and I'm still getting thousands of FPS. Unfortunately injecting AA this way isnt as easy on Linux/Mac, so it would be nice to have the option built into the game.

Mac build complaining about undeclared function

Very well may be something odd about my particular system (MacOS Ventura 13.5) but I kept getting this until I disabled that error:

src/render_gl.c:578:2: error: call to undeclared function 'glFramebufferTexture'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
        glFramebufferTexture(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, backbuffer_texture, 0);

Not sure if this is the right move (been a long time since I touched anything C related), but I get successful compile with this:
C_FLAGS ?= -std=gnu99 -Wall -Wno-unused-variable -Wno-implicit-function-declaration

Happy to see it run after that though! Super cool project.

[Question] does some one here cares about tuxkart?

tuxkart is the ancestor of supertuxkart.
https://www.youtube.com/watch?v=ZsGXZ-V95r8

It dates back to 2007. And it amazingly still compiles. The only problem is, that it uses OSS for the sound.

I'm hopping that someone contributing here would care enough to fix it. the problem is inside the sound library of plib. I think the best solution would be to convert the sound library of plib into a wrapper for openal.

Black screen on Raspberry Pi 4

Hi there again @phoboslab

I have tried to build this on the Pi4, using latest stable MESA and latest SDL2 git code version.
It builds fine, however I get a black screen upon game start (not even the intro is shown).

The Pi4 supports GLES up to 3.1 and full OpenGL up to 2.1 (appart from Vulkan)

I suspect the game is trying to initialize a full OpenGL 3.x environment, am I right?

I can see you initialize the OpenGL renderer here:

platform_gl = SDL_GL_CreateContext(window);

...But I don't see where do you try to pass an OpenGL profile or major/minor version.

In any case, would it be possible to have GLES 3.1 or even GLES 2.1 support?

Make keys selectable

First off, amazing project!

One thing I noticed is that break is hard-coded to the key 'z', accelerate is 'x'. Makes sense on an english keyboard because the letters are right next to each other.
On a german keyboard though 'z' and 'y' are switched, so next to 'x' is 'y' (that's because the letter z is much more common in German than y, so it was moved to a more accessible position). So playing a game with 'x' and 'z' as controls is awkward...

Could you therefore make the keys selectable somehow?

For reference, here's the german keyboard layout:
https://upload.wikimedia.org/wikipedia/commons/thumb/b/b0/German-T2-Keyboard-Prototype-May-2012.jpg/880px-German-T2-Keyboard-Prototype-May-2012.jpg

Linux PowerPC: Endian issues

Hello,

Thanks a lot for wipEout Rewrite! :-)

I was able to compile it on ubuntu MATE 16.04.7 PowerPC today. It starts but it has wrong colors and the sound isn't correct. I think it is an endian issue because Linux PowerPC runs on big endian machines.
I tested it on Void PPC as well but unfortunately it has the same issues on it.
Is it possible to fix these issues?

Screenshot:

wipEout_Rewrite_Linux_PowerPC

Thanks,
Christian

SDL target fail to render graphics on Debian

Hi there, and thanks for the port (seriously, those ports are godsends nowadays)

Sadly I'm having a hard time trying to run them on my Debian boxes. I'm testing at two setups at home:

  • A Sandy Bridge i5 (HD3000 IGP) laptop running Debian Bullseye (yeah, I know... I should upgrade Someday™): on that one the SDL target renders a black screen and nothing else (but I can heard the game sounds, and game reacts to keypresses). On that one the sokol target works fine (aside of the obvious lack of gamepad support).

  • A even older Core 2 Duo laptop with a MUCH older Radeon X1400 GPU, but this one runs Bookworm: instead of a black screen, on this one the SDL target renders a screen full of static garbage (but again, the rest of the game seems to work). The sokol target does NOT run on this one due to "GLX: failed to create GL context" (most likely because it wants OpenGL 3? This lowly 17 year old R500 can only do 2.0), and dies there.

On both machines I get no errors logged when running the game with the SDL-target binaries, just the normal texture load messages.

Flatpak

Flatpak would be great for easy installation on Steam Deck.

Here is a working Manifest org.phoboslab.wipeout.yml

---
app-id: org.phoboslab.wipeout
runtime: org.freedesktop.Platform
runtime-version: '21.08'
sdk: org.freedesktop.Sdk
command: /app/wipegame

cleanup:
  - /lib/pkgconfig
  - /lib/debug
  - '*.la'
  - '*.a'

modules:
  - shared-modules/glew/glew.json
  - shared-modules/glu/glu-9.json
  - name: wipeout-data
    buildsystem: simple
    build-commands:
      - unzip -n wipeout-data-v01.zip
    sources:
      - type: file
        url: https://phoboslab.org/files/wipeout-data-v01.zip
        sha1: 16f9f188d171d2b1f891766a1e4ac2df7e70973e
    post-install:
      - mv wipeout $FLATPAK_DEST/wipeout

  - name: wipeout-rewrite
    buildsystem: simple
    build-commands:
      - L_FLAGS="$(pkg-config --libs glew glu) -lm" make sdl
    sources:
      - type: git
        url: https://github.com/phoboslab/wipeout-rewrite.git
    post-install:
      - install -D -m 755 -t $FLATPAK_DEST wipegame

finish-args:
  - --device=dri
  - --share=ipc
  - --share=network
  - --socket=x11
  - --socket=pulseaudio
  - --filesystem=home

Needs Flathub git sub-module for shared-modules

[submodule "shared-modules"]
	path = shared-modules
	url = https://github.com/flathub/shared-modules.git
flatpak-builder --user --install inst-dir org.phoboslab.wipeout.yml

if flatpak-builder fails downloading glu with certificate errors, apply this patch in shared-modules

diff --git a/glu/glu-9.json b/glu/glu-9.json
index c054749..e0aba90 100644
--- a/glu/glu-9.json
+++ b/glu/glu-9.json
@@ -5,6 +5,9 @@
     {
       "type": "archive",
       "url": "https://archive.mesa3d.org/glu/glu-9.0.2.tar.xz",
+      "mirror-urls": [
+          "ftp://ftp.freedesktop.org/pub/mesa/glu/glu-9.0.2.tar.xz"
+      ],
       "sha256": "6e7280ff585c6a1d9dfcdf2fca489251634b3377bfc33c29e4002466a38d02d4"
     }
   ],

Allow configuring the path of game assets

Somewhat related to #47

The game currently assumes all assets are stored under the same directory the executable is launched from, e.g. wipeout/<asset-path>. The make file should define an ASSETS variable, that could be overridden to, e.g. /usr/share/wipeout. This would improve the packaging of this game.

It should be a relatively trivial patch to implement, changing all hard-coded paths to reference some flag defined with, e.g. -DASSETS=$(ASSETS).

WebXR Support

If someone wanted to add WebXR support - would that be a good addition? I'm guessing you don't use a Quest 2 or have any plans to get a Quest 3 but this being all self contained in Wasm and running in a VR web browser would be so neat.

Will the game totally break if the camera is turned around to have free-look?

1 lap races

In the full download every race only lasts one lap in both championship and single race,
in the small download however the races are 3 laps?

I'm not sure whether this is on purpose or not, if so feel free to delete this 👉👈
love the game btw!
keep up the amazing work!

Any plans of UWP version of WipEouT?

Hi, Phoboslab. Nice project.

I am big fanboy of Nokia Lumia winphones :) So I have 1 little big question: Did you have any plans of UWP version of WipEouT? Or, maybe, some plans to use Uno or Xamarin Forms "frameworks" for real cross-platform support?... =)

Cheers up,
M.E.

Update: ohh, I not noticed that you not using C# and VS... so... sorry!

Query: mem_temp_alloc 8 bytes alignment of size

Hi, when looking at the the bump allocator i was assuming the following would modify size to be the next multiple of 8 but looks like it is not.

	size = ((size >> 3) + 7) << 3; // allign to 8 bytes

size = ((size >> 3) + 7) << 3; // allign to 8 bytes

Here is what i see when i add some logs

size: 16  --> becomes: 72
size: 4224  --> becomes: 4280

When user request 16 bytes, do we need to reserve 72 bytes in the temp? We could just reserve 16 bytes right?

[macOS] Could not open texture file

Attempted to run on macOS with

> brew install sdl2 glew
> make sdl
> open wipegame

Got this error:

> /Users/u/Documents/wipeout-rewrite/wipegame ; exit;
atlas texture     1
inserted atlas texture (  2x  2) at (  0,  0)
load cmp wipeout/textures/drfonts.cmp
Abort at "src/utils.c" line 23: Could not open file for reading: wipeout/textures/drfonts.cmp
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

Does run as expected by instead running the executable as documented in the README with

> ./wipegame

Use Xmake to build on Windows

I make a simple xmake.lua file to build on windows with mingw.

set_project("wipeout-rewrite")
set_languages("c11")

set_allowedplats("linux", "macosx", "mingw", "wasm")

if is_host("windows") then
    set_config("plat", "mingw")
end

option("platform")
    set_default("sdl")
    set_showmenu(true)
    set_description("Graphics platform to handle input/output")
    set_values("sdl", "sokol")
option_end()

option("opengl")
    set_default(false)
    set_showmenu(true)
    set_description("Graphics rendering backend")
option_end()

add_rules("mode.debug", "mode.release")

if is_config("platform", "sdl") then
    add_requires("libsdl")
elseif is_config("platform", "sokol") then
    if is_plat("linux") then
        add_requires("libx11", "libxi", "libxcursor")
    end
end

if has_config("opengl") then
    add_requires("glew")
end

target("wipeout")
    set_kind("binary")
    add_files("src/wipeout/*.c",
              "src/utils.c",
              "src/types.c",
              "src/system.c",
              "src/mem.c",
              "src/input.c")

    if is_plat("windows", "mingw") then
        add_defines("_USE_MATH_DEFINES")
    elseif is_plat("linux") then
        add_syslinks("pthread")
    elseif is_plat("macosx") then
        add_frameworks("Foundation")
        if is_config("platform", "sokol") then
            add_frameworks("Cocoa", "QuartzCore", "AudioToolbox")
        end
    end

    if has_config("opengl") then
        add_defines("RENDERER_GL")
        add_files("src/render_gl.c")
        add_packages("glew")
    else
        add_defines("RENDERER_SOFTWARE")
        add_files("src/render_software.c")
    end

    if is_config("platform", "sdl") then
        add_files("src/platform_sdl.c")
        add_packages("libsdl")
    elseif is_config("platform", "sokol") then
        add_files("src/platform_sokol.c")
        add_defines("RENDERER_GL")
        if is_plat("linux") then
            add_packages("libx11", "libxi", "libxcursor")
        elseif is_plat("mingw") then
            add_syslinks("gdi32", "ole32")
        end
    end

Try

xmake f -c -y --mingw=path/to/mingw
xmake

I don't have other systems (linux/macos) to test it on, so hopefully someone can improve it.

the music can't be played in an external player

i'm sure the qoa format is fine for games in general... but this also means that the very fine music of this game can't be played in your favorite music player along with the rest of your music....

Cannot move craft with Joystick

It seems after your work re: controller bindings, the ability to move the ships with the controller was removed. This is with the SDL2 platform, of course.

Edit: bisected to b2e3ae8.

add option for collisions to behave in a similar way to wipeout 2097

awesome work! Compiled on Fedora and ran without any issues. The first Wipeout game is very unforgiving. As soon as any contact is made with the side of the track or other vehicles everything stops very abruptly. This was improved a lot in Wipeout 2097 and the later versions, the way they allow the player to skim the side of the track without coming to a standstill really improved the game.

It would be nice to have a feature that toggles the way the collisions behave so that it can either be as in the original or a bit more forgiving, as they were in the later games.

For nostalgia add a PS1 mode?

  • Force the resolution to 320x240 (or whatever it was on PS1) and maybe apply a post processing filter to make it look like a CRT based TV
  • Divide vertex positions by W so you get non-perspective correct texture mapping like PS1 (or maybe give this is WGSL you can just set @interpolate(linear) on the inter-stage texture coordinates in the shaders
  • Turn off the z-buffer as there was none on PS1

Linking against modern (non-GLX) OpenGL in GNU/Linux

Hi there @phoboslab

Awesome work you did here! Enjoying this immensely on my GNU/Linux systems.
Other than that, this links against the old/legacy OpenGL GLX implementation here:

L_FLAGS := $(L_FLAGS) -lGLEW -lGL

On Wayland and KMS/DRM systems, I have to replace -lGL with -lOpenGL, which links properly against modern OpenGL (which is MESA + GLVND, thus abstracting the windwing system as it should be).

So, what about replacing -lGL with -lOpenGL? GLX is a thing of the past anyway.

cmake on linux produces an executable named wipeout

which conflicts with the assets directory name, also wipeout.
It would be enough to compile an executable named Wipeout if this is the way you want to go.

Plus the makefile still produces an executable named wipegame

a menu image

The project should have an image for use in launch menus.

menu, "CONTINUE QUALIFYING OR QUIT" logic is reversed

Start championship race, finish outside the top 3. A menu appears
CONTINUE QUALIFYING OR QUIT
select qualifying and you go to the main menu, select quit and race restarts.

I've had a bit of a look at the code and can't see anything obviously wrong with it, but I'm not much of a c programmer I'm afraid.

Figure out which OpenGL version(s) to use

Related to #15, #16, #17 and #18 - we're currently in a mess of different OpenGL version and support libraries. My understanding of this is quite limited, so I'm not sure how to go forward.

Currently we use OpenGL 2.x (I believe) with SDL, WebGL1 (aka GLES2) on WASM and OpenGL 3.3 on Sokol. Additionally, the sokol_app version currently in the tree is quite outdated. The current sokol_app only supports OpenGL 3.3 and WebGL2 (aka GLES3).

The renderer for wipEout only needs OpenGL 2.x, but using that is causing a bunch of problems on different platforms. WebGL1 also forces us to use a 16bit depth buffer which is not optimal. So I guess we should bring this all to a sane, up-to-date level that hopefully runs on all modern hardware.

So:

  1. what are the current best practices for gl support libraries on each platform? Can we get rid of this dance with extensions that's using glext.h on MacOS vs. glew.h on Linux?
  2. what are the OpenGL versions we really need to support? From my understanding OpenGL 3.3 and WebGL2 (aka. GLES3) are good targets!?
  3. as pointed out in #16, SDL currently doesn't specify the OpenGL version at all - how do we fix this?

I'd like to find a solution that runs on all platforms ((Sokol|SDL)*(Win|Mac|Linux) and Sokol+WASM) and requires minimal #ifdefs.

Building with MSYS2: make.exe doesn't exist

I built a wipeout.exe following the MSYS2 instructions. The only issue I had was that the make command failed because make.exe didn't exist. I had to use mingw32-make.exe instead, as suggested at https://stackoverflow.com/a/63482278/1754517. Suggest the README.md is updated. Happy to PR this, though for such a small change it hardly seems worth it! For background I installed msys2-x86_64-20230718.exe in a bare Windows 10 environment.

Docker image

for easier deployement, you can use docker:

  • Add these files at the root of this project:
    Dockerfile:
# wipeout wasm in docker
FROM debian:bullseye

LABEL Greg Lebreton <[email protected]

ENV ROOT_WWW_PATH /var/www/html

RUN apt-get update && apt-get install -y \
    git \
    make \
    libx11-dev \
    libxcursor-dev \
    libxi-dev \
    libasound2-dev \
	ca-certificates \
	unzip \
	sed \
	p7zip-full \
    emscripten \
	coffeescript \
	xz-utils \
	nginx \
	wget \
	--no-install-recommends \
	&& rm -rf /var/lib/apt/lists/*

# sinon le build failed
RUN emcc --version

# clone repo git
RUN cd / \
    && git clone https://github.com/phoboslab/wipeout-rewrite.git \
    && cd wipeout-rewrite

# wipeout datas
RUN cd /tmp \
    && wget https://phoboslab.org/files/wipeout-data-v01.zip \
    && unzip wipeout-data-v01.zip -d wipeout \
    && cp -r wipeout/* /wipeout-rewrite

# build
RUN cd wipeout-rewrite \
    && make wasm

# mise en place des fichiers
RUN cp /wipeout-rewrite/build/wasm/* /var/www/html \
    && cp /wipeout-rewrite/src/wasm-index.html /var/www/html/index.html \
    && cp -r /wipeout-rewrite/wipeout /var/www/html


WORKDIR ${ROOT_WWW_PATH}

EXPOSE 80

COPY entrypoint.sh /

CMD [ "sh", "/entrypoint.sh"]

And the entrypoint.sh:

nginx -g "daemon off;"
  • Build image and launch the container:
docker build -t wipeout:1.0 .
docker run --name wipeout -p 80:80 wipeout:1.0

Fix readme

"In any case, you may NOT use this source code in a commercial release. A commercial release includes hosting it on a website that shows any forms of advertising."

Add a license so people can use this commercially.

Audio issues followed by complete loss of audio

First off, I'd like to thank you for creating this! Wipeout was one of my favorite games when I was a kid.

After trying (and failing) a few championship races, at the beginning of one of the races it played every sound effect in order at a higher pitch (Something like "Mines shockwave rockets 3 2 1 Go") and then it played some INCREDIBLY loud glitchy noises before going silent aside from the sound effects. Then, after another lap, the audio went completely silent and the message "Exception thrown, see javascript console" popped up.

I'm not sure how to reproduce this, but here's the js console's output just in case it contains some useful information. I'm using Microsoft Edge version 115.0.1901.200 on Windows 11

wasm build failed

Hi there, try to dockerise to building of the web version but it crashes because of the file race.o
Here are the logs (simple make wasm form Linux Debian 11:

greg@lenovo:~/workspace/wipeout-rewrite:(master)$ make wasm                                        
mkdir -p build/wasm                                                                                      
emcc build/obj/wasm/src/wipeout/race.o build/obj/wasm/src/wipeout/camera.o build/obj/wasm/src/wipeout/object.o build/obj/wasm/src/wipeout/droid.o build/obj/wasm/src/wipeout/ui.o build/obj/wasm/src/wipeout/hud.o build/obj/wasm/src/wipeout/image.o build/obj/wasm/src/wipeout/game.o build/obj/wasm/src/wipeout/menu.o build/obj/wasm/src/wipeout/main_menu.o build/obj/wasm/src/wipeout/ingame_menus.o build/obj/wasm/src/wipeout/title.o build/obj/wasm/src/wipeout/intro.o build/obj/wasm/src/wipeout/scene.o build/obj/wasm/src/wipeout/ship.o build/obj/wasm/src/wipeout/ship_ai.o build/obj/wasm/src/wipeout/ship_player.o build/obj/wasm/src/wipeout/track.o build/obj/wasm/src/wipeout/weapon.o build/obj/wasm/src/wipeout/particle.o build/obj/wasm/src/wipeout/sfx.o build/obj/wasm/src/utils.o build/obj/wasm/src/types.o build/obj/wasm/src/system.o build/obj/wasm/src/mem.o build/obj/wasm/src/input.o build/obj/wasm/src/render_gl.o build/obj/wasm/src/platform_sokol.o -o build/wasm/wipeout.js -lGLEW -lGL \
        -s ALLOW_MEMORY_GROWTH=1 \
        -s ENVIRONMENT=web \
        --preload-file wipeout
cache:INFO: generating system library: wasm/libc.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libc.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: wasm/libcompiler_rt.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libcompiler_rt.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: wasm/libc++-noexcept.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libc++-noexcept.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: wasm/libc++abi-noexcept.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libc++abi-noexcept.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: wasm/libdlmalloc.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libdlmalloc.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: wasm/libc_rt_wasm.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libc_rt_wasm.a" for subsequent builds)
cache:INFO:  - ok
cache:INFO: generating system library: wasm/libsockets.a... (this will be cached in "/home/greg/.emscripten_cache/wasm/libsockets.a" for subsequent builds)
cache:INFO:  - ok
wasm-ld: error: unknown file type: build/obj/wasm/src/wipeout/race.o
emcc: error: '/usr/bin/wasm-ld -o build/wasm/wipeout.wasm build/obj/wasm/src/wipeout/race.o -L/usr/share/emscripten/system/local/lib build/obj/wasm/src/wipeout/camera.o -L/usr/share/emscripten/system/lib build/obj/wasm/src/wipeout/object.o -L/home/greg/.emscripten_cache/wasm build/obj/wasm/src/wipeout/droid.o build/obj/wasm/src/wipeout/ui.o build/obj/wasm/src/wipeout/hud.o build/obj/wasm/src/wipeout/image.o build/obj/wasm/src/wipeout/game.o build/obj/wasm/src/wipeout/menu.o build/obj/wasm/src/wipeout/main_menu.o build/obj/wasm/src/wipeout/ingame_menus.o build/obj/wasm/src/wipeout/title.o build/obj/wasm/src/wipeout/intro.o build/obj/wasm/src/wipeout/scene.o build/obj/wasm/src/wipeout/ship.o build/obj/wasm/src/wipeout/ship_ai.o build/obj/wasm/src/wipeout/ship_player.o build/obj/wasm/src/wipeout/track.o build/obj/wasm/src/wipeout/weapon.o build/obj/wasm/src/wipeout/particle.o build/obj/wasm/src/wipeout/sfx.o build/obj/wasm/src/utils.o build/obj/wasm/src/types.o build/obj/wasm/src/system.o build/obj/wasm/src/mem.o build/obj/wasm/src/input.o build/obj/wasm/src/render_gl.o build/obj/wasm/src/platform_sokol.o /home/greg/.emscripten_cache/wasm/libc.a /home/greg/.emscripten_cache/wasm/libcompiler_rt.a /home/greg/.emscripten_cache/wasm/libc++-noexcept.a /home/greg/.emscripten_cache/wasm/libc++abi-noexcept.a /home/greg/.emscripten_cache/wasm/libdlmalloc.a /home/greg/.emscripten_cache/wasm/libc_rt_wasm.a /home/greg/.emscripten_cache/wasm/libsockets.a -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --allow-undefined --strip-debug --export-table --export main --export emscripten_stack_get_end --export emscripten_stack_get_free --export emscripten_stack_init --export stackSave --export stackRestore --export stackAlloc --export __wasm_call_ctors --export fflush --export __errno_location --export malloc --export free -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=2147483648 --global-base=1024' failed (1)
make: *** [Makefile:148 : wasm_full] Erreur 1

Great project by the way!
Is it possible to make the MEMORY_HUNK higher for upscaled textures loading for example ? ;)

xdg compliance in linux

it would be nice to follow the linux user folders standard.

the xdg standard
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

In short:

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

here, you only care about config

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.