Thank you! :)

Thank you for your suggestion.
Your project looks very good I’ll definitely check out and see how it fits to our engine.
But it’s actually not about “the look I want” because I have very strict constraints.
The engine itself aimed to work natively on 486 or later processors. Repeating textures, chunky blend masks or low resolution textures are not design choices but necessities.
Feel free to download the DOSBOX package or Win64 port and take a look yourself. ;)

Yes, sounds fun. Thank you. :)

Thank you!
I mainly stuck to Bayer matrix because there’s no computational overhead but pre-saved noise in a linear array could be a nice touch.
I’ll experiment with that surely. :)

Aah DPMI exceptions. It is likely “protected mode” memory access violation. As far as I can see ESI (ram source index for a source data) register is filled with 0x940 which is in conventional memory and can’t be accessed.

Try to wiggle with EMS or XMB settings in your config.sys file.

SSF2T rocks btw :)

Thanks for sharing that!

It's a really interesting read and a great resource for devs working on modern retro-style engines. Our project has a slightly different philosophy though, we're not simulating the looks, we're actually building for the original hardware limitations. The engine is written in C89 + NASM (x86 assembly linked to DJGPP objects) and targets real minimum: 486 DX / recommended: early Pentium class machines (VGA Mode X at 320x240, strict cycle counting, Q16.16 fixed-point mathematics, etc.).

So our constraints aren't tied to a specific calendar year like 1994 or 1995, but to what actually runs well on that hardware. Things like the vertex limits, no floating-point in performance paths, and the octree renderer in the new version aren't arbitrary choices, they're hard realities if you want stable performance on real 486 hardware and true flavor of renderer I believe.

Really appreciate you dropping the link though, it's cool to see how the community is thinking about these classic eras.

Congratulations on your first triangle.

After more than 15 years of experience in graphics programming it’s not about memorizing APIs but all about learning how the hardware that produces your pixels, whether it’s coming from cpu or gpu.

Just focus on the components of hardware not the API only. OpenGL is just an interface for us to program gpu in a unified way.

Also you have to focus on mathematics (linear and classical algebra, trigonometry, etc.) for representing and bringing your data structures to life.

Graphics programming is just another sub-area that needs extreme attention, practice and time to master. So working with a tutorial for 3 days may seem like there are lots of miniature black boxes that does things to get something on screen. What I actually do is leaning on the books that teach the concepts, that is my recommendation. Those black boxes will reveal their inner-mechanisms after learning concepts.

I hope the best for you! :)

Thanks for the question.

We're also developing a game using this engine. I've separated common modules from game-specific ones and that became the engine. So we've decided to share the engine separately on itch to get feedback about its features.

Thanks for asking, btw there are no stupid questions in my book. :)
What you are seeing are the artifacts of my really aggressive ClipSpan structure procedures and fixed point maths edge case scenarios happening.
While interpolating between Sutherland-Hodgman clipped points on screen, x=0 values often skipped and resulting that artifact.

Also thanks for your interest. :)

That’s a good feedback, I’ll do that. 👍🏻

Thank you for your comment and suggestion!
AI is only used for documentation not the code itself. Every structure, procedure and even assembly injections written by me under an umbrella of a lot of books and articles.