Well manually reading vmethods from vtables instead of just using inheritance. Including custom assembly to call said methods instead of just calling them (like rest of dfhack does it). I though that it's because of different calling conventions used in gcc and msvc.
Ok, so...
In the first version (what was the main branch until recently) I was saving address of certain vmethods, and replacing them in the original renderer vtable with my functions - that was the easiest way because I needed only to hook 2 vmethods. Then, on OS X and Linux I can just call the original vmethods as normal functions because on these systems "this" pointer is just passed as the first function argument. However on Windows the calling convention for vmethods is different from normal function calls, so assembler code was required.
In the current version I use different approach. I made my renderer inherit from renderer_opengl, and I added several dummy vmethods to it. Then I copy entire vtable from the original renderer to my object except for vmethods I want to override, and set original addresses of overriden methods instead of those dummy vmethods. Finally I copy all data fields from the original renderer to my object and set my object as the renderer. Old renderer is not needed anymore. This allows me to call original vmethods without any tricks and doesn't require copying screen* fields between old and new renderers each time like you do in rendermax, and I got rid of assembler code (to make you happy:) ).
There's nothing wrong in doing this, dfhack is doing more terrible compiler-specific things with vmethods, including things I don't understand (as I'm not a C++ developer) like virtual_identity::get_vmethod_ptr and functions it calls.
Author
Topic: Text Will Be Text - dfhack plugin (Read 801043 times)