opentdu

You should download *_Win32.exe binaries (eg. opentdu_assetextractor_win32.exe) instead of the archive attached to the release (the archive is a snapshot of the source code; and is only useful if you want to compile the client or tools locally).

I have added Windows 32bit to the CI (as well as Linux and macOS binaries) (https://github.com/opentestdriveunlimited/opentdu/releases/tag/ci_release_26). I have also reworked asset deserialization in the client for x64 (I assumed their asset formats always had padding after the space they reserved for raw pointers; turns out they sometime don't...). This way both x86 and x64 should work out of the box.

.zc files are zlib compressed files (using zlib 1.2.3) without encryption or a fancy header. You can easily find the load routine by searching for references to "edFileDirectAccess::LoadzCompressFileInMem" (they left tons of assert/debug log for some reason). I haven't looked in details but from what I've seen this is as straightforward as initializing zlib and calling inflate on the compressed chunks you loaded into memory.

I am pretty sure that you can already show the online races offline (e.g. by using the project paradise launcher). However if your goal is to unlock the achievements then you won't be able to do it unless you play online (or you can edit your savegame to unlock those achievements...)

I haven't spent too much time reversing the player data format, but my understanding is that online and offline profiles use the same format and it should easily be possible to load online profiles offline

Re-implementing the network logic on the client side is planned however I don't plan to write a server emulator

There isn't (I am running Renderdoc on Linux (using Wine and DXVK)). On Windows you can use PIX (as long as you patch the executable to bypass D3DPERF_SetOptions)

Oh definitely not! I am planning to use something like HLSLcc (or re-use the DXVK shader translation logic if the code license allows it) to directly translate the shader bytecode (and not having to hand translate the +5k permutations the game uses ). HLSLcc (while pretty old and buggy at times) should be good enough to translate shaders from the SM2-era (if I can figure out wth the lexer crashes from time to time) and has some compatibility options to reduce friction between APIs. My main complain is the quality of the output The only challenge for shader modding would be to figure out what each shader is doing (I've only managed to to label each "shader group" based on Ghidra and RenderDoc outputs). @andrey zyb Yes, although it will require some minor changes to properly load assets (as TDU1's file formats are 32bit and require extra care when supporting 64bit)

I initially started with OpenGL 3.3 and ended up switching to Vulkan, as I was struggling to find a good library to translate dxso bytecode to GLSL. I might revisit this at some point if I need to save time. I am not planning to support 32bit at the moment (as this will complicate streaming/resource management and file parsing).

As long as your phone supports Vulkan, yes. It should also be possible to support Emscripten/WebAssembly to make the game playable from a web browser (not sure if there is an audience for that tho )

I've also finally setup a CI to automatically create binaries for Windows (will add Linux and macOS later). You can find those binaries on the release page: https://github.com/opentestdriveunlimited/opentdu/releases While there is no client available yet, you can use the asset extractor binary to extract the .ini files from your original TestDriveUnlimited executable and tweak the configuration of your game (this is the same files as the ones existing in TDU2). To use the extractor, copy the executable next to your TestDriveUnlimited.exe one and run it (./opentdu_assetExtractor -executable "./TestDriveUnlimited.exe"; using either Powershell or cmd.exe). The executable will extract .ini files (as well as DX9 shaders). You can then run TestDriveUnlimited and use specific command line switches to use the extracted .ini. For reference: -game "./GamePC.ini" -system "./SystemPC.ini" -audio "./Audio.ini" -devices "./DevicesPC.ini" -replay "./Replay.ini" -physics "./Physics.ini" e.g. ./TestDriveUnlimited.exe -w -game "./GamePC.ini"

I'd be more than happy to contribute to any kind of document/wiki! I've made some rather interesting findings during the decomp that could help other modders projects (eg. the PC executable supports zlib compressed banks and has a bunch of helpers to reverse endianness; the game looks for DLCs in the savegame folders (and will install anything present in the marketplace subfolder; as long as the .big, .map and .xml inside the archive are valid)). Rewriting everything from scratch sounds also pretty exciting, hope it will get somewhere

I'm planning to reverse/decompile the client logic. It won't be compatible with Platinum online unfortunately (as the mod uses a proxy dll to hook the game). If one of the mod author is willing to share the source of the client I'd more than happy to support it natively

You can already get "grass as tarmac" if you extract the configuration files from the original executable (using the asset_extractor tool from the repository) and place the .ini next to your original TestDriveUnlimited executable (the original executable will use any decrypted .ini placed in the working directory)

Hello everyone, I have started a rather ambitious project: a decompilation of TDU1! My current progress can be found on Github: https://github.com/opentestdriveunlimited/opentdu What does it mean? A decompilation project goal is to convert the assembly (machine code) of the shipped game into "readable" high level code (C++). Why? My main motivation is to provide a modern, cross-platform game client with quality of life improvement (e.g. remove framecapping for AI, remove WinAPI/D3D9 dependencies, fix existing security issues, etc.) as well as restoring cut content left in the game (e.g. pedestrians, boat tour, dirt system). Roadmap The goal is to get basic systems running first; then basic game modes (e.g. Sandbox or CarShowcase) and finally start working on FreeRide/implement the world streaming system/online/etc. Stretch goals would be to have native mod support (directly integrated in the game), TDU2 asset support, state of the art rendering pipeline (move from the D3D9-era pipeline and use a fancy BRDF; photorealistic atmosphere rendering; etc.). But this is far far away, as decompiling a game is already a long term project (and a hobby project; I am not working full time on this!) I will try to keep this thread alive with update/progress (so far I only have a blank window with a Vulkan context running; and I am actively moving and cleaning all my decompilation progress from Ghidra to my C++ project).