I’m working on my own little HoMM3-library (written in haskell). I’m looking at your code for documentation, especially the CDefHandler.h/CDefHandler.cpp and also here: wiki.enleth.com/homm:homm3-def-animations
But I’m kind of stuck here. I’ve managed to parse all the way up until where the actual data begins, so i have what you call a
struct SSpriteDef
but here i run into trouble. If someone could please explain what happends in the switch-block on line 200 that would be of great help
In short, there are 4 types of def file compression, each case of that switch corresponds to one of them. We just fill there ret, an SDL_Surface, with pixels obtained from FDef. FDef is just the loaded def file, ret->pixels has pixels ordered line by line, starting from left top corner. I could explain more if you were more specific about your problems.
I don’t know what can be more explanatory than these for (do do…wile) loops with well-defined number of iterations and no gotos or breaks inside.
Therefore it’s probably not useful. We could remove it but I believe VCMI needs a lot of more important refactorings.
ftcp represents the number of the next pixel we need to write to the resultant surface. We should start with 0 and then, using memcpy, fill all pixels. Pixels are numbered according to SDL_Surface ordering (as described in my post above). I think ret->pixels must be initialized with zeros to make “ftcp jumps” (e.g. ftcp += RightMargin;) working correctly.
I think there is such .def… but I don’t remember its name. You can always make a loop over all .defs, load them, write an if for negativeness of margin and put there a breakpoint…