Skip to content

Software renderer implementation - #429

Draft
iProgramMC wants to merge 173 commits into
ButterscotchRunner:mainfrom
iProgramMC:sw-renderer
Draft

iProgramMC wants to merge 173 commits into
ButterscotchRunner:mainfrom
iProgramMC:sw-renderer

Conversation

@iProgramMC

Copy link
Copy Markdown
Contributor

Continuation of #128

Still a draft because I'm not completely happy with the implementation. However, UNDERTALE mostly works, and I've even been able to play through some of DELTARUNE as well, including the final boss fight of Chapter 3.

(Note: The "stars" attack of the Knight in Deltarune Ch.3 is only possible because I don't implement masking properly. It's actually not playable in Butterscotch at all because a graphics function isn't implemented)

iProgramMC and others added 30 commits May 17, 2026 20:41
Fix software only builds after recent makefile change
This allows the software renderer to work correctly on big-endian
systems like PowerPC Macs.

Note that the framebuffer will be byteswapped from little-endian mode.
This fixes Muffet's teapot in her right hand rotating around the wrong point.
iProgramMC and others added 26 commits September 16, 2026 15:46
This allows for dithering in 16 and 8 bit mode too.
These are completely unnecessary (srcCalcSrcAlpha always returned alpha)
And I don't see myself implementing any other blend modes anytime soon.
…ng of frame

Otherwise code might use a stale pointer
…s a placeholder

In Deltarune Ch3, drawSpritePos seems to be consistently used to draw Tenna.
Luckily, for him specifically, we don't need to do too much.

Later, somebody would do actual UV mapped rendering. I won't do it here.
@Un1q32
Un1q32 force-pushed the sw-renderer branch 2 times, most recently from 16c6584 to d495b1d Compare September 21, 2026 23:32
@Un1q32

Un1q32 commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator

IMO this is good enough to merge right away, even if not all features are implemented. I believe undertale is perfect, and deltarune only has a few minor issues.

@Un1q32

Un1q32 commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator

Merging now means that new vtable functions could be ported to the software renderer as they're designed in PRs for example, instead of after the fact. iProgram tends to go on long hiatuses in between working on this, and merging means changes to the renderer don't accumulate tech dept as much, since the person writing the pr is responsible for making their change work on the software renderer, rather than iProgram or one of the maintainers later on after it's merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants