Well, although I have implemented what I stated, it sounds like Japa is not planning on merging it because he wants to take stonesense out of process, being a separate executable communicating via RPC. If he decides to go with in-process overlay what I've wirtten can certainly be adapted. If not, then hey, at least I know a lot more about OpenGL than I did before.
Since that sounds like a longer term project, my code in the current form can still be compiled against r5, and used with DF2012. Mifki, since you have development environments for all three platforms set-up, perhaps you could create some builds of what I have for people to try? (
https://github.com/KevinCathcart/stonesense/ branch OpenGL) I.E. a short term fork for those of us still playing DF2012 while Japa undertakes his stonesense restructuring. It sounds like there will not be a stonesense for DF2014 until that restructuring is complete, and I imagine it will take some time. Probably at least a few weeks, perhaps longer.
Also some technical details behind how my ssense overlay OpenGL mode works for mifki and others interested:
As for how ssense overlay works, it currently creates a new "renderer" subclass that encapsulates the existing renderer. It sets itself as enabler->renderer. (This pattern was copied from rendermax). It forwards most calls, but during the render call it first creates a texture from the bitmap image. I manually interpose the "draw" method of the underlying renderer (the code simply assumes it is some subclass of render_opergl and that only single inheritance is used). The interposed draw method first calls the that subclass's implementation of draw, and then draws a single textured quad itself.
It needs to leave the underlying renderer running so that the menus can be updated. The SDL 2d only version did block all update_tile calls for the overlay-ed area from reaching it. I left that out when OpenGL rendering is enabled, since I was not sure that such a block would not cause weirdness with TwbT.
The code I have at the moment does not work with nextgen at all, in large part because TwbT nextgen assumes that enabler->renderer is its own renderer. Otherwise I strongly suspect it would display correctly with the current code. I really don't want to put too much more work into my current codebase, since the restructuring would make it moot, but I remain committed to seeing that TwbT and ssense overlay are compatible. Why? Because I want to end up with a DF where I mostly play with a TwbT tileset, but can toggle over to an isometric view with one key for when I want to visualize some complex 3D structure.
I'm in no hurry to jump onto the DF2014 bandwagon, since right now none of the most obnoxious DF2012 bugs are yet fixed in DF2014, and it has plenty of new bugs itself.
mifki, one last thought. I'm you might not be aware that you can get get rid of the hardcoded vtable indexes (e.g. 13 or 14 for draw depending on platform) by letting DFHack calculate them for you like so: "vmethod_pointer_to_idx(&renderer_opengl::draw)". That works for any class, even those unknown to DFHack, like "render_opengl". That could help you cut down slightly on the amount of magic numbers in hook().
Author
Topic: Text Will Be Text - dfhack plugin (Read 773098 times)