An old trick still useful today Added another planned optimization to the Sandbox example. Using dirty rectangles, I can avoid redrawing the height, diffuse and normal background where nothing has moved. I worried that the frame-rate would feel uneven because it increases the difference between worst and average case, but at these speeds, a one fourth's frame's jitter is lost to tearing against the screen's 144Hz refresh rate anyway.

Results Reached 453 frames per second instead of 295 for 800x600 pixels. With 185 FPS for 1920x1080 pixels, I'm pushing the limits of my 144Hz gaming monitor and the extra fast DisplayPort cable.

Might sound like overkill but getting people to use CPU rendering again requires some sick performance to be convincing, because the GPU's only advantage is performance. More optimization can be done by computing deferred light using a smaller buffer one block at a time.

Recently read about how important it is for open source projects to let their users find them in order to get more contributors, and I do need help with making the project grow with all the big plans I have. Then I made a search for my old engine and only found one post mentioning it, which was about how such a good product could be completely unheard of for ten years. My skills in promoting my projects can probably improve, so I've spent the last week building a new flashy website with a short top domain, so that visitors have more than just the github page to bookmark. Read about search engine optimization but failed to get it indexed by any search engine in the end. Designed some banners that people can use when linking to the website, which will hopefully keep it from being completely invisible when people explicitly search for my full name. https://dawoodoz.com/dfpsr.html

Decided to

Floating-point operations in 3D geometry transformations aren't bit-exact between different computers rendering the sprites, but version history tools are very picky about serialized rounding errors. The sprite generation tool will now look at existing sprites and tolerate a certain deviation before deciding to overwrite existing files, so that rounding errors will no longer cause random sprites to be overwritten and bloat the version history. A fuzzy text comparison function parses all numbers to check the numerical differences.

Wrote an import function for the Stanford PLY format today. Used it to load and render the mage model I sculpted and vertex painted in Blender yesterday. The Stanford PLY format stores color together with positions and is commonly used for 3D scans, so I found it usable for generating isometric sprites.

I tried designing a model in Blender using surface sub-division and high-resolution vertex colors. What should've taken around 500 kilobytes using a compressed model format ended up taking 15 megabytes when exported to a standard model format as raw polygons.

A combination of adaptive quad-tree detail tessellation and compressed vertex data instead of textures would allow sharing large assets in a less entangled data structure. Each new tessellation step loaded from a compressed model file can let the position and color be stored relative to the average of neighbors. A 3D model for each detail level will be generated as a side-effect from this algorithm.

The next step for isometric rendering would be to create the foundation of an extreme detail design tool. This would allow previewing the final result while drawing height maps or transforming raw vertices directly.

First import a standard model format using only the vertex data. Then create an algorithm for reducing the triangle count for the shadow casting shape. The tool could do the entire sprite rendering step as a preview, but exporting to a model file and separate rendering script would allow automating the process if the settings change while making a game.

A simpler triangle rasterizer optimized for small triangles and progressive detail previews based on performance can make the isometric sprite generation fast enough to be used in real-time.

Runs in borderless maximized fullscreen on Windows 7. Should in theory work on all versions since Windows 2000.

Now it only needs a window wrapper module for Macintosh before it supports the three major desktop systems. Last time I used a Macintosh was in the 1990s.