Wet, thanks

I spent the two-and-half months you can barely call a summer (the difference between a finnish summer and a finnish autumn is the temperature of the downpour and the shade of the gray clouds the sky is filled with) without sparing a thought to qmapper. Then, about a month ago I sighed and decided to fix the little blocker I had with my problem. I had given up in June because no matter how I tried to wrote around it, my document object tree model didn't work. Guess what caused it? A wee exclamation mark that made negative semantic sense where it was, but which C++'s useless static type checker let through. Read more of that particular adventure from the qt forum.

The last month or so I have been re-implmenting old memapper's functionality with Qt. And by old functionality I mean the propertyeditor window that let's the user change arbitrary properties of arbitrary objects, and making it possible to add & remove layers and map. Because I don't have a real plan of the GUI, I have kept the adding & removing as a guile API.

But now I have kind of run out of "easy" problems again, which means it's time to try to tackle OpenGL subsystems.

Currently the rendering widget draws a red rectangle. It's supposed to render the whole freaking drawing queue into the viewport. It's also supposed to support old memapper-like asset abstractions. It doesn't have to do efficient sorting by z-coordinate, because this engine is completely 2D and I'm 25% certain OpenGL would do that behind the scenes anyway.

The asset-abstraction is the part which makes this somewhat harder than it should be. The TextureAsset class should have its dimensions as read-only int properties ¹ , and it should contain the opengl texture handle in a way which it can both draw to screen with a simple .render(QOpenGLFunctions_4_3_Core *f) interface AND serialize back to a .png file. It'd be cool if the user could double-click on the texture asset to open it in an mspaint looklike, edit it, save it, and the edits would be immediately reflected in the main editor. This is not going to happen in the MVP though.

Texture assets can not be pure OpenGL textures due to the need to be able to render them. On top of the texture handle they need an immutable vertex store, and both fragment- and vertex shaders. Default vertex shader just dumps the texture at pixel coordinate (0,0), origin at the top-left corner. Default fragment shader picks the colours from the loaded OpenGL texture

Then there is the sprite-asset abstraction. They differ from the pure textures in a way that the keep a reference to a texture, have mutable X, Y and rotation props. On top of that, they have two references to glsl scripts, one for fragment shader and one for vertex shader. Default shaders work similarly to the texture asset's default shaders, but take the X,Y,rotation props into account when rendering.

Scripts asset should work similarly as they did in the old clojure version. I just have to figure if I'm able to extend the libguile's geiser server and emacs's client in the way I extended nrepl

You can tag an object compiled with propertylisp with a custom tag². When editing an object that has a member property of that tagged type, the editor's propertyEditor window creates a qcombobox which gets its options from flattening the domtree and filtering the objects implementing that tag.This tagging functionality should ease pairing sprites to textures or to shaders. It might be easiest to just use class names as tags. I dunno.

That's a small road map for this project. In near future I plan on blogging about the clj-propertylisp and outlining a sort of road map for it also. That particular language will probably stay a turing incomplete macro language that compiles lispy definitions to c++ class definitions with a custom runtime type system. It'll provide some escape hatches from C++'s moronic object system, though. The property-editor's dynamic behaviour relies on objects knowing their properties runtime, and being able to query and set property's value by a const char pointer. If I didn't have my custom-RTTI-hack I'd have to implement specialized propertyEditors for every kind of object I can put into the editor's DOM.

Anyway, this document should ease my descent into chaos OpenGL development by being a reference about WTF I'm trying to achieve

• Protip to myself: implement read-only-props to clj-propertylisp
• TODO: design & implement