InfinityEngine - Enhancer
theforgotten69
Member Posts: 9
Hi all!
I wanted to showcase my mod, called InfinityEngine-Enhancer. What is it though?
It's a modification that runs as soon as you launch the game that allow currently:
Other features will follow through, but the above features are already big enough to release:
However, by default, the mod won't do anything as there aren't any upscaled tiles available or in the game. Hence why I released its companion mod: BGEE Graphics Enhanced
I began with BGEE and you can follow the status through the README, but all games locations will be upscaled.
Installation:
I wanted to showcase my mod, called InfinityEngine-Enhancer. What is it though?
It's a modification that runs as soon as you launch the game that allow currently:
- Upscaling all tiles through PVRZ/TIS. We can for instance scale 4x what the current game offers and it does without any ARE/WED files modifications, making it compatible with virtually all mods barring concurrent TIS/PVRZ
- Some niceties regarding Tile rendering such as better filtering
Other features will follow through, but the above features are already big enough to release:
However, by default, the mod won't do anything as there aren't any upscaled tiles available or in the game. Hence why I released its companion mod: BGEE Graphics Enhanced
I began with BGEE and you can follow the status through the README, but all games locations will be upscaled.
Installation:
- Install EEex (and huge kudos to Bubb)
- Download the latest release from BGEE-Graphics-Enhanced
- Launch your game through `InfinityLoader.exe`
- Profit
[/list
Some images (you should definitely zoom 😛 ):




Album: https://imgur.com/a/cLPJywn
Post edited by theforgotten69 on
0
Comments
https://github.com/TheForgotten69/BGEE-Graphics-Enhanced/releases
Let me know for any performance/crash/issues
I'm not a modder, so I must ask: Is this compatible with BGGO?
And I think you'd be interested in drunk tiefling's shader stuff too.
For now I'm only touching vanilla files and it's more of a test phase, I'll need to contact the BGGO modder and check which area are affected
Yeah I saw it but some of them (fpdraw mainly) won't work as much, i have some shaders already that will - I'll share it down the line
Yup I've edited the main post to reflect this: The only thing left is just conflicts, I think BGGO is editing night maps mostly, I haven't touched them yet
As for the character models, no such trick haha, it requires first to patch the game engine but I haven't check the sprites quality yet, I fear they might be too low res to do something in their current state, we'll see
Best bet for now is just to install this mod before BGGO then, should be compatible but obviously no upscale for anything that BGGO touches.
Good find, that would still be quite an endeavor as there are lots and lots of sprite, and I suck at anything 3D related. Maybe someone will be motivated though
Only 100 maps left and then I'll do some touch ups and EET compatibility and move onto BG2!
If you could check the sprites at some point, as mentioned, that would be great too.
Same here, on a fresh install. It has nothing to do with your SotSC mod. The animated parts lines also happen in the Denoised Areas Mod, which I recommend you use until this one gets fully ironed out.
I haven't updated my github yet but please download all fles: https://www.nexusmods.com/baldursgate/mods/105. All maps are done and playable.
Order is main file -> patch -> seams shader which will help grealty with animates tiles (you won't see much lines but shiver will be light)
Enjoy
A follow-up to my post about the area tiles on Mac. Last year you wrote that HD sprites aren't a simple trick because the engine has to be patched first. On the Mac EE I found a way that needs no patch, and it now works in game.
How it works. The engine builds each creature on the CPU in an "FX surface" at 1:1 (palette, colour ranges, tints, walls, equipment layers), then draws a single quad. So instead of patching the renderer, every BAM frame stays at engine scale and carries three things:
- markers that the shaders can read;
- a "probe" rectangle exactly where the original sprite was, so the engine applies walls, transparency and selection to it at 1:1;
- the HD image, with the same palette indices.
VPDRAW shrinks the quad back onto the probe, and FPDRAW samples the HD image and masks it with the probe. Everything else goes through Beamdog's shader code, unchanged. Equipment works because all layers of one FX surface get the same frame geometry, computed from the engine's own CalculateFxRect rules. Dragons, wyverns and the Demogorgon are drawn with FXBltFrom (quad clipped to the viewport, frames sharing corners in the atlas), so they use a second layout that the fragment shader decodes per pixel.
Where it stands (BG2:EE 2.7.3, M1 Max):
- All 17 creature animation classes convert: the 10,284 BAMs the engine loads for creatures, listed by running every animation constructor (INI file included) in an emulator. Every frame passes a check by calculation.
- One in-game test with a creature of every class on the same screen: a red dragon (9 tiles), the Demogorgon, wyverns, equipped characters of every size class, layered monsters, animals. Everything is HD, in place, with walls dithering as usual (screenshots below).
- The HD art is only Scale4x for now. This was a pipeline test; real art (AI upscales or 3D re-renders) is the next step, and the runtime doesn't depend on it.
Every creature class on one screen:
The red dragon, drawn as 9 tiles:
The Demogorgon, wyverns and layered monsters:
Equipped characters (body, weapon, shield and helmet layers) and other creatures:
Why I'm posting it here.
1. It's the sprite counterpart of the FPSEAM shader: a DLL-free path. It should also work on Linux, and on Windows for players who can't or won't use a DLL (untested so far).
2. bg2hd's runtime is built on a patched version of your Enhancer. A shared target format could let the same HD sprites run everywhere: an HD BAM set (same names and cycles, k× frames, same palette indices) goes through one converter. Spec and tools (MIT): https://github.com/alejandrosml/silicon-coast-sprites
3. Two constraints worth knowing: "Always Dither" must stay on (with it off, walls erase texels instead of halving them), and the CPU cost grows with k², because the engine copies every layer into the FX surface each frame.
Would you be interested in comparing notes on the sprite side? Happy to test anything on Apple Silicon.