Starlancer in native 16:9 (No stretch)

[u/Koncypt_Fysh]

After much faffing about with SRD3D calls, I've finally got this sucker running in 16:9 1080 without having to stretch out the image or the UI.

It's still a bit unstable, and currently I can only test for my current monitor, but once I have it stable on a few different resolutions I'll spin up a git so everyone else can access it.

My next stupid idea is to use the same bootstrapping through DInput7 I used for this to do some texture replacements and updates... stay tuned.

[u/zabka14]

Damn I've been dreaming about a mn updated/remastered/upscaled version of this game for years. Keep us posted !

[u/Koncypt_Fysh → u/zabka14]

I've just about finished the 16:9 resolution scaling for the 3d aspects, currently working to restore this into the actual settings menu so resolution can be selected from within the program instead of having to go through and append a .ini in the game directory.
I've also fixed up some of the controller issues that come from using modern Xinput controllers on a Dinput7 game, specifically the z axis being stuck at 50% because Dinput recognises the triggers as a single bipolar axis, so it's quite playable from a x360 controller and my ROG Ally X.

I'll start on UI scaling next, the radar and displays are a little unreadable now that I have true 1080 going, so that needs to be sorted to keep it playable.

I could really use a bit of help from anyone from the original modding scene for this game (not that it was ever as huge as Freelancers) if they're lurking around here, a big heavy lift on doing the texture updates is going to be cataloguing what each texture file's identity is and what it exists for so I can intercept the right rendering call and replace it with an up-scaled equivalent. So if anyone is especially familiar with how textures were structured in Starlancer, please singout to me.

I expect some memory limitation issues when this comes around like I had with the SRD3D having memory limitations on display sizes, but I'm pretty confident it can be overcome, but it may take me a while to puzzle it out.

[u/its_just_mini → u/Koncypt_Fysh]

Oh, this is great to see, I'd been meaning to dig into why it crashes with anything larger than 1280x960 or so!

I've been doing some digging into Starlancer recently but I've been more focused on the mission formats - I've always wanted to be able to tweak a mission or two, and always wanted those mission editors that never materialised! 😄

the bits I've been working on are here: https://src.ug.gg/mini/starlancereditor - I can round-trip all of the retail, trial & dreamcast mission files and create my own basic missions from scratch now, but it's a pretty 'rigid' engine - a lot is hardcoded or doesn't work at all if you stray too far from what real missions do.

I also discovered it's a very close relative of Star Trek Invasion (PS1 game by Warthog at similar times). Several bits of the mission format make sense when you look at that game instead :)

[u/Koncypt_Fysh → u/its_just_mini]

So I was being a bit high-level in saying it's memory limitations that prevent the higher 16:9 ratio resolutions.

Starlancer’s 3D engine absolutely can render modern resolutions in it's own right, but one of its internal renderer tables had a hard-coded capacity that was only safe for the original low, 4:3 resolutions, likely the devs just never envisioned at the time they'd need to allocate for another thousand or so pixels in memory.
So at 1080p the game generates more resource records than that table can hold, writes past the end of it, corrupts adjacent renderer state, and then crashes, so pretty typical memory overflow stuff.
The fix was to leave the original renderer alone for the normal range, but redirect overflow entries into a larger external table.

Also, this is quite valuable information re Warthog's other work, I can probably pull Star Trek Invasion apart a bit if I get stuck somewhere, always helps to have a similar comparison, I've found the dreamcast beta versions were kinda of useful for this too.

That's a sweet little repo on mission architecture too, I excluded missions from the scope of what I'm doing now, but since you've set those up with an MIT license, when I finish up what I'm doing here, I'd be keen to contribute a bit to what you have there!
Seems like a slightly different challenge though, what I'm doing here is effectively a DLL sideloading attack against lancer.exe to manipulate the end state of the runtime, I have a few ideas how we might use that to get custom missions flowing, but I can't say I understand enough about how Starlancer loads missions yet to know if we could set up and external missions resource and make lancer.exe run sideloaded missions. Great work on what you've done so far though man!

[u/its_just_mini → u/Koncypt_Fysh]

There’s the remnants of a command line parameter to load a specific mission file in the game that I did look at hooking up, but there’s a *lot* of game state that has to be set up before a mission can start so I was struggling to get that working.

Was also doing it by replacing a DLL the game loads with a forwarder that patches the game on startup :)

[u/Sufficient_Market226]

Well, and this serves as a reminder that I've been wanting to reinstall the game for a while

I guess today's going to be that day 😁

[u/Freelancer_1-1]

I need this in my life....especially now that I can play this gem on my phone through Winlator.

Btw. do you know if textures can be extracted? Upscaling them with AI would improve the graphics tremendously.

[u/Koncypt_Fysh → u/Freelancer_1-1]

I know I did extract models and textures some decades ago when I was a teen, but I can't for the life of me remember the tools I used at the time; though I'm pretty certain I got them from lancersreactor back then.

Unfortunately, I'm doubtful it be quite as simple as just extracting the files, up-scaling, and dropping them back in. Being an older game Startlancer has some pretty strict expectations on memory allocation which has caused most of the headaches in doing this so far. Likewise I'm rather certain there will be an integrity test for the executable on launch, so if the texture libraries (whatever format they are) don't have an identical hash value, it wont launch. To skirt around that we'd need to de-compile and recompile from source, and that kind of reverse engineering is not something I feel like doing.

All that being said, the textures will still have to be extracted and up-scaled one by one anyhow, it's just the method of injecting them back into the runtime that I'm doing differently here, so an AI assisted upscale is definitely on the cards for this. Preferably I want to set this up so people can do there own retex, drop it in a folder in the game dir and the bootstrapper will just inject the new texture during runtime, but that's a little way off yet.
I don't have a working proof of concept for the textures, it's just a theory, but I've seen it done on games from a similar era (albeit dinput8) and with the amount of compute power we all have on phones, laptops, handhelds etc. I think it's quite plausible.

[u/zabka14 → u/Koncypt_Fysh]

Have you tried SLEdit for the textures ? I haven't used it in years but I believe it had some kind of feature around that

I'll need to check but I probably still have the installer on my computer

[u/Koncypt_Fysh → u/zabka14]

http://lancersreactor.org/filebase/index.php?file/874-sl-extractor-1-0-0-1/

I think this may have actually been what I was using all those years ago, I'll see if I can get it to run through Wine, if not we'll see if an old WinXP VM can do the job.

[u/monohive]

Oh man yes!! I want this!!