isledecomp
Background / screen outside 2D overlay not cleared in building
i.e. gas station: (SDL3 GPU)
Not sure if this can be easily fixed (it would probably need awareness of when it is a building vs. vehicle), but it looks odd for sure. I realize this is incidental since the original game didn't have to worry about rendering outside the original resolution, but now that we can do that we should fix this.
Ideally interiors will have everything outside the 2D image boundaries set to sky color or black, and vehicles can stay the way they are.
@AJenbo what would be the cleanest way to solve this in your opinion? I know where in the code base we are in a vehicle vs. building, what would be the best approach to tell the renderer to not draw anything outside the 2D overlay? I'm not sure where the responsible code path is in miniwin
Yeah you will have to make the game aware and render something at a negative position. For DevilutionX what we did was extend the load screens, it's a bit of work but can look pretty decent.
Step one:
Usually what we do is cut out the 640x480 part and have it be transparent so that it only adds sides, you might want to bleed it a bit since this isn't always rendered 1:1
This is the place where we can override bitmaps if desired:
https://github.com/isledecomp/isle-portable/blob/master/LEGO1/omni/src/video/mxstillpresenter.cpp#L73
I'm not really sure how best to progress though. Replacing the data like the texture loader does seems easy enough, no idea about the rest going from there.
It is worth exploring how we can enable modding through loading our own, newly created .SI asset packs. This would definitely be the desirable long term solution because it allows us to modify / extend most data in the game, and not have to handcraft solutions for every aspect. Existing tooling (SiEdit) is already out there:
SiEdit still isn't capable of creating completely new .SI files yet, only modifying existing ones. If we can fill that gap I can see a path forward to make this work fairly elegantly. The game might need a little bit of extra logic to allow patching existing assets but that shouldn't be too hard.
The idea for this particular issue would be to have a WIDESCREEN.SI pack that can then substitute all the 2D backgrounds with widescreen ones. Information necessary (such as where to render it etc.) is all part of it (as seen in the screenshot)
I agree that something like that makes a lot of sens. I think where things get complicated is that afaik the game expects specific files to be in specific archives so you would still have to explicitly tell the code about the new files that it should look for overwrites or extensions. Or that all files should first be looked up in the custom .si files, and then I fail to see how it's anymore elegant then files in a folder?
The idea for this particular issue would be to have a WIDESCREEN.SI pack that can then substitute all the 2D backgrounds with widescreen ones. Information necessary (such as where to render it etc.) is all part of it (as seen in the screenshot)
Maybe it would make sens to make a portable.si that bundles all project specific files so code doesn't have to be modified each time a new data type is added (3dscreens.si, hdmusic.si etc.)?
I think where things get complicated is that afaik the game expects specific files to be in specific archives so you would still have to explicitly tell the code about the new files that it should look for overwrites or extensions.
There would definitely be some new logic necessary to replace existing assets, but for new assets (like the widescreen images, which like you mentioned can really be just the widescreen part and the middle part transparent) this should work fine.
Assets can be loaded at any time and then only be activated/ shown by attaching them to specific worlds, with certain conditions. The game already makes use of directives like that embedded in the SI files.
Having files in a folder really isn't a scalable solution if you look at modifying all sorts of assets over time. Unless you define a custom file format you lack all the metadata necessary for various functionality for image, audio, animation etc. Sharing a collection of files is also more cumbersome than just sharing a SI pack.
Maybe it would make sens to make a portable.si that bundles all project specific files so code doesn't have to be modified each time a new data type is added (3dscreens.si, hdmusic.si etc.)?
I'm envisioning that all you do is specify the SI packs you want to load, and it will just work without any code modifications (other than a single mechanism to hot-patch existing assets). I'm fairly sure that will be possible, but first we need to extend SIEdit to allow creation of new SI files, then I'll look into this
If someone wants to work on a stop gap solution using a separate loading mechanism that's fine with me, but long term I definitely see custom SI packs the way to go
Yeah I'm completely ignorant to what the meta data looks like, though having a file representation for it would probably also make it much more feasible to make new .si files. Sharing is a good point, but while working on modifications it can be nice to not have to constantly edit containers, a solution to that would also be a tool that can generate the .si file during build. It could also open the opportunity for using platform specific container formats in cases where they make more sens then .si, but that's a bit out of scope here.
I'm envisioning that all you do is specify the SI packs you want to load, and it will just work without any code modifications (other than a single mechanism to hot-patch existing assets). I'm fairly sure that will be possible
A hot patching system would be ideal.
but first we need to extend SIEdit to allow creation of new SI files, then I'll look into this
On DevilutionX we have the extra data files checked in to repo and on build we then use a cli tool to generate the data archive. This makes it very easy to update and inspect the patched assets. SIEdit sounds like a bit of a heavy weight for that task, maybe a lib and a cli could be spun of from it?
On DevilutionX we have the extra data files checked in to repo and on build we then use a cli tool to generate the data archive. This makes it very easy to update and inspect the patched assets. SIEdit sounds like a bit of a heavy weight for that task, maybe a lib and a cli could be spun of from it?
The lib already exists and SiEdit is just a UI on top based on it: https://github.com/isledecomp/SIEdit/tree/master/lib although that lib would probably need extensions to create a SI from scratch too.
I'm seeing SiEdit as the tool that modders can use to create their own (asset) mods. If we want to distribute an official isle-portable SI pack approaching it like you outlined makes sense.
LEGO Island did have a "source" file format that they used to generate the SI files, here is an example https://www.legoisland.org/wiki/Weaver It would be fun to build a new tool based on that format, since we already have it, but I guess it's not strictly required. Unfortunately the original tool seems to be lost in both source and executable formats.
@AJenbo do you think it's possible to create the widescreen image using the exact same 256 color palette as the original (same colors with same indices)? That would be required to be able to embed without any major code changes.
The final image would look like this. If we can make it so that it uses the same palette as the cropped out part I can move forward with this. I don't have any image tools that would allow that kind of editing.
Here is the source (cropped out middle part) bitmap
nice
On Wed, Aug 27, 2025 at 8:43 PM Anders Jenbo @.***> wrote:
AJenbo left a comment (isledecomp/isle-portable#583) https://github.com/isledecomp/isle-portable/issues/583#issuecomment-3231487093
Last part of the police station image.png (view on web) https://github.com/user-attachments/assets/76ab51a2-52c5-4ac3-bd32-b0240e63535c
PoliDoor-w.zip https://github.com/user-attachments/files/22016556/PoliDoor-w.zip
— Reply to this email directly, view it on GitHub https://github.com/isledecomp/isle-portable/issues/583#issuecomment-3231487093, or unsubscribe https://github.com/notifications/unsubscribe-auth/BVJTEEXCD3RJEY57IQVYHUL3PZUG5AVCNFSM6AAAAACBK4M2VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZRGQ4DOMBZGM . You are receiving this because you commented.Message ID: @.***>