SkinPartType::PART_ENNEAD. This should also support SkinPartType::PART_TRIAD. We should probably build a list of Entities that need to be drawn this frame by examining each of them and determining which of them will actually be visible on the screen (or close to visible). Then the actual draw loop will run through those entities and draw them as necessary. However, I see this method as being very slow. We'll have to test this and see how it works. It may be easier to have the entities listed with an attached tile coordinate using an algorithim to determine roughly which tile they're on using the above tile coordinate finding approach. Then during rendering the drawing routine only needs to check in those coordinates for an entity and can determine rendering offsets that way. As the Map class itself is not responsible for actually performing Entity location calculations, entity tile locations can be updated whenever the map is notified of just such an update. At the same time, the map class purely keeps a list of the Entities but doesn't actually modify any of their locations so we may just have to do this on the fly and hope for the best.
This is a decision that can be made outside of this function.
textureFormat could be potentially uninitialized should nColors be anything other than '3' or '4' (24 bit and 32 bit color modes, respectively). The only other expected values would be '2' (16 bit color mode) or '1' (8 bit color mode). While in practice neither of these cases is likely to show up, it's extremely important that textureFormat is initialized to a good default value that will work for generally all modes or one that will at least not cause a crash. Currently only Veritcal type sliders are supported. Horizontal should be pretty straight forward.
There's a bit of odd behavior when the mouse is dragged passed the slide area. This should be fairly straight forward to fix using the mMouseX and mMouseY values although it requires that this Control respond to onMouseMove() events.
Implement processing of the various attributes of sheet.
The current method of processing allows for the user to define more than one 'img' or 'blend' node and the parser will blindly accept it. A sheet should have exactly one 'img' node and exactly one 'blend' node.
The current method of processing allows the user to define the 'img' and 'blend' nodes in whatever order they want and it goes ahead and calls functions whenever if finds a valid node. This should instead first check for the 'blend' node and, once that's been found, should then go and find the 'img' node.
1.7.1