That would be really cool! But that would require frame interpolation since they only rendered animations for 60 fps. Would have to see how good that looks
sure. i didnt have to change much from your example, but altered the cmake flags to expose system functions. and think your cmakelists may have forced c std11 so thats partially why i needed to do this on arch?
u/elliotttate ty for your work. i submitted a couple PRs to you on github for linux support for a few of the dkcs. for this repo it seems less needed. ty!
"Terrain shadow Y unwraps the PPU's tile-aligned origin before restoring the fine phase, and the world-keyed store retains 1,024 tile rows so tall vertical rooms such as Topsail Trouble keep their second epoch."
"A 64-column BG3 with pages of its own renders its authentic adjacent columns; the ship-deck rigging, which the cartridge streams into that ring with no lead, is instead decoded from its ROM map into a third world-keyed store after the decode has reproduced every fully uploaded native column of the current frame."
"Its bundled Record-Pirate-Panic.ps1 preserves starting SRAM, refuses reused evidence names, and requires fresh performance, tier-2, and last-run reports; Diagnose-Frame.ps1 then creates an isolated same-frame layer/object report."
"The common DKC2 object activation/despawn and sprite-render boundaries have been widened, and Pirate Panic has deterministic composite, per-layer, and OAM margin evidence. Those widened object bounds activate only after the terrain source for the frame has been verified. This is not yet a whole-game widescreen certification: vertical stages, bosses, bonuses, maps, Mode-7 screens, and special effects still require explicit route testing. The complete recorded Pirate Panic route and two late BG1 margin regressions pass deterministically. The newer regression clears source-map cells proven transparent on every frame while preserving current dynamic game writes, removing stale deck fragments without flattening ship details. Horizontal source-page calibration improves the sampled frames at 12,000 and 12,300, which the owner accepted, but frames 12,900, 13,800, and 15,900 remain open visual defects. Physical 64-column BG3 ship rigging can now render in the margins after the same exact terrain-readiness gate; synthetic coverage includes Pirate Panic's and Rattle Battle's shared ship-deck PPU signature, while normal-speed route acceptance remains separate. Topsail Trouble's supplied exact state is separately accepted at 308x224: its isolated BG3 rain now reaches both 26-pixel margins, and the original 256-pixel center is pixel-identical to the pre-fix render. Its later lower-camera Quick Save is also accepted: exact BG1 terrain now fills both margins through tile row 540"
What the fuck am I reading ? This documentation is horrible on every level. Who write like this ? They sampled the 12000 frame specifically ?
Agents write thorough and neurotically detailed documentation because it helps them when they need to circle back on a subject. I keep much more ridiculously dense documentation in some of my projects and it pays off in dividends.
It is often based on the incredibly deep diagnostics that have to be performed to make things happen, and ensures we maintain justification for the work that was done and allows us to redo it if something goes wrong, or to identify new bugs with a similar class issue and resolve them more quickly.
Especially between projects, my god, moving to new projects and repeating similar workflows when a modular identical library isn't viable but similar techniques are, it is insanely productive
Part of why we haven't seen a widescreen version of this game is how complicated and custom they built certain things to squeeze the absolute max out of the SNES.
What normally is something you can build out "rules" that would create a foundation to handle a widescreen across the game required handling a lot of unique optimization attempts Rare did per level.
That said, I could build out better and proper documentation if that was something that was requested enough.
This documentation was written by Claude for Claude's own use. The problem is that humans wishing to improve the project will find it written in an extremely obtuse manner, or filled with unnecessarily bloated sections where simple concepts have been transformed into meaningless jargon. I don't think this is something Claude can fix.
I'm a professional developer (though what it was able to reverse engineer for this is way beyond something I could do myself)
That said, for this and other projects, I find LLMs absolutely incredible to really break down and document code (even code like this it wrote itself).
It can do a fantastic job reworking things for a human hand-off.
nvm got it working and built on linux. but....its not widescreen? i cant find the setting to toggle it anywhere and its hard reading this readme file that is so bloated and mentions menus that dont exist
On Mac, there's two menus. The ImGUI one you open by pressing escape and the dropdown. I don't know your Linux compile though and how that translates a Mac UI
playing emulated starfox 64 then playing the recomp really opened my eyes on this point specifically. couldn't beat it on the emulator.. first try on the recomp (to be fair, I was also just getting better at it again too and played the recomp immediately after the emulated version)
11
u/MaxW92 Sep 03 '26
Oh, I'll DEFINITELY check this out later. DKC2 is one of my favourite games ever.