rxi

Thanks!

The tools are all written in C and use microui[1] for the UI. The games are typically written in LÖVE with the exception of SCANLINE which uses Nim

[1] https://github.com/rxi/microui

I can't say exactly when, but I was writing it in itself before I made the initial commit on the public repo, so at least 6 months ago. Every change I made since then (in addition to the plugins I wrote) would have been written in lite itself.

You're equating the final stage of this approach to the entire approach. The point of this technique is that you get the benefits you typically would from dirty rectangles without the burden of the bookkeeping you would traditionally have. Using this technique your application "redraws" everything as if it's drawing it fresh each frame and the renderer cache takes care of determining what's actually changed.

Typically with dirty rectangles you would have to manage this state in the application code, for example, determining that line X was edited then updating the region for that line, or determining that view Y moved and updating a dirty rectangle based upon it's previous and current positions.

As the editor is written mostly in Lua, with C taking care of the lower level parts, plugins can typically customise anything limited to what is exposed by Lua and the C API. Beyond adding custom commands, plugins can also do things like patch straight in the DocView's line-drawing function to draw additional content:

https://user-images.githubusercontent.com/3920290/80743752-7...

Or create their own custom "views":

https://user-images.githubusercontent.com/3920290/81343656-4...

The treeview at the left of the screen is implemented as a normal plugin, and like any other plugin can be removed from lite by simply deleteing the `treeview.lua` file.

Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can call `renderer.show_debug(true)` to show these redraw regions: https://youtu.be/KtL9f6bksDQ?t=50

I wrote a short article detailing the technique here: https://rxi.github.io/200402.html

There shouldn't be any reason it wouldn't work on those platforms, the `build.config.py` script would just have to be modified to add those targets.

That test.c file looks familiar!