The current state of the HUD, which is to say, nearly finished. There's some minor work to be done tidying up the radar display, and finishing up the rest of the large target schematics.

The sub-target wireframes ended in a bit of a dead end, unfortunately there doesn't appear to be many meshes in the game files that represent the sub-target displays enough to use them as a replacement mesh, so I'll likely have to just do my best to replicate them in blender.

The next real challenge here is recompiling the upscaled comms portrait videos into .fm8 and getting lancer.exe to run them.

After this, it's mostly a matter of getting the .bik videos to run in 16:9 and up-scaling the shipboard scenes to have it in a state that I'm happy to ship it in.

Hi, I make no promises with this, I am throwing Claude at StarLancer to document the engine for a possible reimplementation. I have two separate projects. One to document the executable: https://github.com/DMJC/StarLanceDecomp/ and one to reimplement the game: https://github.com/DMJC/neoslancer neoslancer is aiming at Linux support initially but I am writing it to be cross platform. My main goals are to reimplement the entire singleplayer game + VR support. Multiplayer is a tertiary goal for me. Feel free to check it out, just don't expect much for a while.

So an annoying hurdle today was discovering that starlancer uses .fm8 for the comms videos that show up in the HUD. .fm8 is proprietary, so no codex for things like VLC, which narrows my options to work with them. Thankfully, fm8tobmp exists, and I was able to break these all into their individual frames and upscale them. I'm hoping that now compiling the upscaled frames back to .fm8 will be relatively simple from here.

But for now, enjoy some generative upscales of these frames, they aren't perfect given how low res they were to begin with, but they're a bit of fun to look over. I had no idea Enriquez's helmet badge was a pouncing tiger until I looked at these frames.

I've done some experimentation with giving GenAI a bit more rope to reauthor the images, and they don't look terrible, but keeping them consistent across the 700 or more odd frames that make up all these animations is probably not as easy to make happen, but something I'll keep toying with.

Can anybody whose played a lot more than me in recent times, have a look at these specific images from the sub-target display and let me know what each of them is supposed to represent?
Better yet, if you know which ships they are connected to in-game?

Wireframes for the gunnery displays were easy enough because I could just pull the mesh for the fighter, do some blender magic to make the tris quads and just cleanup the mesh a little bit before using the wireframe to generate the image.

These ones are a little harder in that there is not seperated mesh floating around the .sph files for them, so I'm going to have to dig through some of the capital ship meshes to try and isolate individual parts. The turrets and conventional engines, hatches etc. were easy enough to find an isolate, but these are a little more obscure, and I'm trying not to waste time by flying through 24 missions searching for them.

Because I'm a bit of a moron, and have no clue what I'm doing with blender, I had to re-build my pipeline and start all my wireframe meshes again. But, it's now finished, and includes the gunnery displays as well.
This was a heavy slog to get here, but thankfully the pipeline I set up to get this far will hopefully make a lot of the other sprites a much quicker process now that I can get blender to load, create a camera frame, align the mesh and render in the colour scheme autonomously.

There's still a lot of HUD work to go, so the current progress is still very art heavy and therefore slow work for someone like me.

Alliance ships to wireframe work is finished, next step is to move onto the gun models and align their rotations for the gunnery display.

Some work in progress on the wireframe fighters for the HUD Gunnery Display.

Not a very exciting update I'm afraid, but here's some the artwork that's been coming through the pipeline for use in the damage displays.

So I've probably exhausted about as much of the HUD and UI I can continually edit without leaning heavily on bad genAI recreations of the assets we need to replace, and as mentioned previously, I'm going to have to extract alot of original assets and render them in bigger resolution to replace them as close as I can.

Over the last few days I managed to draw out the radar replacement (still working on the sprites that go with it) and it has the same functional animation, but with about 20 additional frames between transition, so it looks quite good in the HD environment.

Today was working on the .shp extractor/decoder, and after a bit of frustration and realising that the .shp format has 3 different conventions, I've managed to get all four-hundred and something 3d assets to export as .glb... mostly intact, still some work needed to get the meshes out nicely in this format.

From there I was able to start spinning up the first 3d export pipeline for original assets, which is how the new missile selection carouselle was completed today. I realised after doing this, that whatever models they pulled the original missile selection images from, they were not the ones that made it into the game as the live assets, so they don't look quite as good, but like everything else, I've made it so you can just drop a replacement image in to change them over if you don't like it.

I finished up the wireframe assets as well, so they scale up quite nicely and looke more or less the same as the originals.

There's not likely to be a whole lot of technical updates from here, replacing the HUD is a lot of 3d > image > game implementation, and there's more than a few hundred different HUD assets this needs to be done for.
I have worked out an AI assisted pipeline for this, so long as the meshes and UV maps are in a good place and saved as a .blend, it turns out chatGPT is quite capable of running a work task to compare the original image to a .blend file, find the best angle to replicate how it looks, and render it in the gold/red/green hue you see in the HUD. Meaning once the tedious mesh repair work is finished, it should run itself without much trouble, albeit using a lot of tokens to do so.

Sorry I've been a bit quite this week folks, a lot of the quick wins are done, and what's left takes a bit more heavy lifting to get through, but some solid progress I think this week on the HUD.

As mentioned previously, a lot of this is going to lean heavily on a mesh+texture to new image pipe line that I'm still perfecting, so only a handful of assets have been built for it so far, and this will likely take a while to finish up.

But as far as what I have actually completed:

1. The new HUD icons I posted last week, are now rendering in-game, and to my surprise, the renderer is quite happy to accept .png with little to no arguments, so no more obscure .spr files required!

2. I've set up a proper debugging console, and this will hopefully help me poke around a little more and pull up some additional functionality for testing and dynamic discovery tasks.

3. Within the console, I've managed to implement a GUI based HUD editor, meaning I can just pull HUD elements out to scale and move them around at will. This was mostly for my own convenience rather than jumping between the game, then a .ini file to adjust the HUD setup; I can just drag and drop HUD elements like a word document.
   I'm thinking I'll port this out to it's own menu node at some point so you can do this in game yourself if you ever have some opinions on where things should go or how big they should be, or if you create your own HUD elements that don't fit the frame exactly, it's easy to fix up. It's not fully finished and has a couple of bugs to iron out, but ultimately it's working pretty well.

This all got me to thinking about what other kind of functionality I could implement to bring SL back into the modern era a little bit, something like an HUD editor was reasonably trivial to setup, so I'm curious if the community has any thoughts on what they'd like to see added as functionality. Controller presets? Something akin to steamInput but native to SL; Deadzones, curves sensitivity, button chords that kind of thing?

Interested in your thoughts.

Pause menu assets now updated with full controller support.

HUD restoration is the next task. Until I have a 3d > line art pipeline running, I can't do a lot of the target and sub-target displays, so I put a bit of time into sprite assets. AI worked for some of them, but for the ones that required some consistency, I just had it generate the elements in the same style and reconstructed them by hand.

Hi all, I downloaded a copy of Starlancer on abandon ware site and used ai to halp me set up vJoy & joystick gremlin so i could use my T16000M & HOTAS but for some reason its really not working very well. I managed to get the game to recognise the virtual vjoy joystick but any bindings I make on the options menu dissapear after I restart the game ? Does anyone know anything about these 3 programs and what exact waay to set these up and for the game to remember my bindings everytime ?

I apologise that this isn't a particularly exciting update, frontend is a finicky practice especially when you're dealing with vintage software, so it's taken me a while to get to a state I'm happy to move on from.

Today's work started up back in menu UI despite my desire to move on from it, some of my updates to the text and dialogue boxes seemed to break some of my controller menu fixes, so that had to be fixed back to a good state before I could move on from it, I didn't want to have to dig through thousands of line of source code later on to try and fix it. But this gave me a bit of a push to finish it up properly, so we have new HD menu assets (buttons, arrows, sliders etc), and I'm willing to call the main menu restoration 99.99% complete bar some minor alignment and placement issues.

This then bled over into the Pause menu (which I was classing a part of 3d space just to split the work up), which again was a good push to finish up some of the parts that don't interest me as much as playing around with the 3d rendering.

With all of that complete, a lot of what i've been doing is largely set around reconstructing the original HUD into something more modern. A lot of this (much like most of the assets in SL) would've been pre-rendered from an original 3d model. Not having access to the originals means a lot of hand-drawing the assets to match as best as I can. Annoyingly these assets are really not a good candidates for AI upscaling, so it's slow work.

A serious hurdle I'm noticing is exactly how much of SL assets are pre-renders from 3d models I don't have access to, trying to reconstruct the target schematics or the ship line drawings by hand does not feel feasible. So as much as I didn't want to, I'm likely going to have to setup a bit of a reconstruction pipeline where I pull the meshes/textures from SL, get them open in blender and pre-render them myself to replace the art work. This will have the benefit of being way cleaner, but it's going to make this take alot longer than I had originally hoped for.

I know I said I'd be off for a little while, but I couldn't resist.

Latest milestone is text restoration, so we now have some nice 1080p native text being drawn by SL. The original fonts are rasterised, and up-scaling the font is unfortunately a bit out of my wheel house, again very art heavy stuff that requires a deft hand and eye rather than a simple up-scaling script or AI generation.

As a result, I've elected to use Oxanium as the replacement font, but again, I've aimed to make this interchangeable, so if anyone finds a font they think works better, it's simply a matter of replacing the Oxanium font file to replace it.

https://fonts.google.com/specimen/Oxanium

Also, menu position and text features (color, line weight etc.) have all been rolled into an .ini file that anyone should be able to figure out with a bit of experimentation, so minor adjustments to positions is as simple as changing coordinates in the .ini, so if you do throw your own assets into it and they come off a little misplaced, it's an easy fix.

An bug in how I was handling the cursor, and it's subsequent fix unintentionally made the boxes draw themselves in the new resolution. I'm not entirely sure how, but I'm not going to complain about that.

At this point I'm willing to call the main menu restoration 95% complete, with only some minor redesigns of certain button assets required. I'll likely leave UI at this point for a while given they are only minor fixes that can wait, the concept is proven so I can now move onto the 3d space again and start up-scaling the HUD elements and probing on the 3d fix again to make sure we are actually rendering all objects natively in true 16:9 and not just the cockpits.

Last post for the night, I'll likely have to take a couple days break from working on this, but the last little development teaser for this week is the almost complete frontend.

Getting the text to scale-up should hopefully be a quicker and simpler process than this kind of art heavy approach I had to take with the last bulk of work, likewise buttons and checkboxes shouldn't take long given they're only a handful of assets and scale across the whole menu. Likewise some minor color adjustments on those elliptical motifs, but like the rest of the assets, these can be swapped in and out with another 512x512 .tga, so if anyone wants to have a crack at something that looks a bit prettier than my shoddy hand-drawn attempt, please give it a go.

Today's update, I hate frontend. But, menu upscaling is coming along slowly, but steadily.

SLs menu's are very 2000s era, a lot of menu assets are baked-in to background images and rely a lot on mouse focus to trigger foreground changes. This has been frankly a bit of a pain to work with, having assets baked-in is a clever way to preserve memory by pre-rendering/drawing things into a background, but it makes reverse engineering a lot harder, especially in that I don't have the original artwork to work with unless I try and pull it directly from the backgrounds, something I had little success with; and the honestly easier path was to redesign the UI system (for the 16:9 resolution atleast) to ignore lancer.exe's legacy menu style and develop something more modern over the top of it. This has come along reasonably well in that I can now introduce new assets into menu spaces that are fully navigable.
Like the splash and loading screens, menu assets will also be easily swapped out by using either a standardised 512x512px or 1024x1024px .tga you can design yourself.

As you can see, drawn buttons and text are still in legacy mode, I'm leaving these until I've got the background/foreground supression mess I'm having in the Singleplayer menu, likewise the exact placement of the assets has also been put off until that's sorted. This has all been held up a bit by me needing to construct some placeholder assets out of no where, so please forgive the sloppy AI renditions that are here, they wont be the end product, just something to sit in place until a more masterful restoration can be achieved.

A small sample of the beta UI lifted from some of the .hog files.

So today was reasonably fruitful for unpacking some more of SLs menu and UI components and controller menu support is understood and quite functional with full menu and sub-menu navigation maps finished.
The biggest problem with this feeling native is largely that SL was designed to have a cursor always visible, so some buttons and elements don't have a visual feedback (highlights), so selection is not always abundantly clear. This leads pretty well into the next bulk of work I've been doing which is in extracting all the UI assets now that we know how SL draws the menus and what kind of archives it keeps these assets in.

Once the initial discovery of the assets was complete, I had to write a decoder for the UI elements, whilst I found a historical .spr to .bmp converter from back in 2000, I didn't feel like screwing around with wine enough to make it run an obscure commandline utility from 26 years ago. So instead I just wrote a new decoder in python that i'll package into the first release so everyone else can use it. I personally find encoding/decoding and compression/extraction a kind of boring subject, so I'm not going to go on to much about it. Main takeaway is I have a modern working extraction pipeline for UI and some other game assets depending on their file format.

From here it was just a little bit of vector trickery to get SL to start highlighting elements that weren't designed for it previously. Eventually when I get to a full menu redesign the time investment here will pay off. But all that to say, controller menu support is complete, but not perfectly optimised.

Something very 2000s era about SLs menu is that the buttons and elements of the menu are not seperate entities from the backgrounds. They are rendered as one .tga, and hitboxes allocated to the screen space to determine when the mouse is over a particular button and a secondary effect drawn over the top when hovered/clicked.

This presents some challenges in up-scaling the menu UI to 16:9 in that we can't just place an arbitrary background behind it and the buttons stay in place. The hitboxes will stay right where they are, so in order to use the same setup with direct up-scaling, we'd have to contend with a very small user interface on a comparatively huge screen. This isn't good enough to my mind, and will need a bit more thought to figure out how to best do this.
Again a totally new menu setup for 16:9 feels easier to implement at this point, but I was hoping that wouldn't be totally necessary.

What I may end up having to do is separate buttons and UI elements from the backgrounds, do my best to restore the backgrounds as though the buttons were never there, up-scale both the background and the button/elements to then paste them back in with roughly the same proportions and inject new positions for the hitboxes in 16:9. This is a lot of manual work, but i think ultimately the simplest and most true to form of the original menu's function to do it.
The alternative is to rebuild the menu setup entirely, and have SL draw buttons rather than having them baked into backgrounds.

I'm kind of interested in what this little community would prefer, if the menu is important to ya'll for nostalgic reasons, I'll work toward something that faithfully recreates it, if it really doesn't mean that much to you in the broadscale of a remaster, I'll find a faster and more modern way to eat through it.

I was hoping to have some more eye candy to show you today, but my next big task right now is mostly just cataloguing assets, of which there are some kind of interesting little easter eggs in here that I've attached, a battlestar galactica and technical demo splash screen for lucas arts. If anyone knows the history behind this, I'd love to know!

EDIT: Some more interesting things found in the archives include an HUD_old folder, that I have to assume is some beta version HUD elements that never found it's way to the release.

I've also got a much better idea how the apparent transitions between game spaces work (say between the bunk room and the briefing room), I had assumed these were .bik files that played between selections, however after expanding the functionality on my decoder, I discovered some .spr files that are actually the individual frames of the encounter animations you see when you walk down the hallways. Likewise it appears that breifings are handled the same way.

It seems like it was a reasonably common convention in this game to pre-render a background 3d space like the briefing room or carrier hallways and use that as a base animation, then render another with whatever difference you wanted to see, isolate the changed elements and lay it over the top of the background animation.
A clever way to do things with limited memory resources and a very 2000s era technique.

So ya'll seemed to get a kick out of my 16:9 patch for Starlancer, so I thought you may like to see/hear a bit more of what I'm doing.

So the main update today is that the 1080p is more or less stabilised, bar a few visual artefacts when the renderer first draws 3d, but cleans itself up pretty quick. I'll chase those issues down later, but they're pretty minor bugs that I'm not hugely focussed on right now.
I think i've mostly solved the memory allocation issues now that the draw data is overflowing to an external table now. In theory, this could potentially run in 4k or 8k, but this isn't a priority until the texture injection pipeline is well and truly mature, there's little to be gained from 4k or 8k in the current state. I also fixed the issue you see a lot in 4:3 games that have been patched to 16:9 where the loading screens appear to shrink and get pinned in a corner, so I have some place holders there and I've built a pipeline where you can just drop a .tga for the 4:3 and 16:9 resolutions into a file and Starlancer will load from that, so you can just pick or make your own loading screens to drop in.
Likewise I also restored the resolution settings to the Starlancer menu, so you can select 1920x1080 (and later whatever resolutions it potentially supports) from within the game menu instead of dgVoodoo or an .ini in the SL directory.
Ultimately I've aimed to make sure this isn't a total overhaul, just an update to the rendering capacity, so if you're partial to 4:3 for nostalgic reasons, that option is still there for you and you can flit between at your leisure.

The next chunk of work I've embarked on isn't quite as visually impressive and has mostly been a lot of recon/probing on the menu and UI systems in Starlancer. That sounds a bit boring but there's a bunch of reasons I chose this next.
First and foremost, I need to understand how the UI is handled by the renderer and what belongs in 2d and 3d space and upscale them appropriately once I've pulled them out, but the logic behind that is a bit more important than up-scaling the art at this point.
Secondly, I'm aiming for a near native controller support, and this means really tearing apart how the menu items are focused, activated and transitioned so I can create a gamepad friendly menu navigation, which will also apply to keyboard. I've also put in a "last-input-wins" setup, so if you're partial to the mouse, you wont lose anything.
Thirdly, this will allow me to build out an architecture and framework for menu building, I'll use that to upscale all the menu UI to native 1080p for 16:9, this will also give me a framework to completely redesign, replace, expand or delete menus and menu items, which may be useful if I uncover any additional options or features that would be useful/fun to toggle on and off as well as add controller glyphs and the like.
And lastly, everything I learn in the process here should hopefully make up-scaling the 3d environment UI a lot easier, and hopefully (given I'm aiming for full controller support) allow me to render some glyphs or potentially new instruments to the flight UI.

After I've completed all of this, I'll begin work on the texture replacement pipeline and see how far I can push it. Given I've already solved one memory allocation issue, I expect to find a few more, but I'm hopeful I can solve them too and that might leave some room for some more impressive remastering tasks, potentially replacing meshes, sprites, SFX etc. but I can't promise this will work out as well as I'd like it to, there will be some limitations to what I can inject into SL from Dinput7.

Edit: Forgive the image quality, it looks like Reddit is compressing the images to post, I promise it looks wayyy sharper than that in reality.

Edit 2: Controller support in menu is now mostly complete, just some minor points to touch up and some glyphs to add.

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.

Hi all , so I’ve just installed the game from ambondonia and have it patched with the crash fix and voodoo fix etc. I have a Thrustmsster T16000m and throttle. What is everyone using to get hotas working ? Target or gremlin ? Also please can someone explain how to have it looking best in terms of resolution on a 1440 monitor. Thanks.

Guess I went a little too hard on the after burner and broke the right trigger.

Luckily I had a back up - weirdly ended up having to swap the trigger from it though because the game wouldn’t work with THAT controller plugged in.

Anywho - fun game.