A very merry Christmas to all!
With the year winding down, I want to talk about one of my wishes for the next beta cycle. Some of them I've discussed already: Unicode support, this one being much shorter, etc. But I want to nix the software rendering engine, and I'll discuss what's involved there. What's involved may mean it's not a 513 thing after all, but a man can dream.
The software engine is of course way old, slow, and can't handle a number of things, so I want to get rid of it. There are two problems: First, you have the people with integrated Intel cards who can't seem to do shaders, and I still haven't figured out why—but I'm not going to let that stop me. The other problem is that software mode is still integrated into the map editor, and statpanels, grids, and right-click menus. The integration problem should be more surmountable.
First let's talk about statpanels and such. The problem there is that these are creating composite bitmap images from a set of icons. The routine that handles all that is, well, pretty old. It's gone through some revisions to handle pixel offsets on overlays, that sort of thing, but it really needs to be updated completely to be in line with what players would see on a map. This means what I need to do is create a way to run icons through the hardware renderer but with a specific offscreen rendering target in mind, and then read the results from that from the memory buffer. That's very doable and it should be something I can tackle during the 513 period, provided nothing else gets in the way. This would mean a lot of advances, particularly that filters would work in these situations too.
The real sticking point is the map editor. The map editor is very old and persnickety, and took a lot of coaxing to get working with different icon sizes as opposed to back when all icons were the same size. Currently, Dream Maker maintains its own Windows image lists for icons—that list also being used in the object tree—and uses the image list for the map editor and its controls as well. The map editor contains three controls where this is relevant: the instance list, the main view, and the world view.
Changing the instance list wouldn't be too difficult; it would be very similar to a hybrid between what I just discussed for menus/statpanels and the new icon list control in the updated icon editor. Consequently, the instance list should be very simple to work on since I now have the experience of the icon editor under my belt.
The world view is basically just another map control that shows a scaled-down version of everything in the world, so it's similar to the regular view except that it has to be drawn in pieces. I don't imagine the drawing-in-pieces part will ever change. But the regular view is the big problem.
What I need to do, basically, is alter all of the drawing code. Here's the way I think it breaks down:
1) Every single instance on the map needs to keep track of its visual bounds, based on its icon, transform, and obviously the impact of any overlays. (Visual contents might be an issue too, but what you can do with those at compile-time is way more limited so that shouldn't be a big deal.)
2) The map editor will need to keep track of the visual bounds for each tile based on the instances it contains (and their offsets).
3) I'll need a system similar to the "chunk" handling on the server for keeping track of which tiles go out of bounds within which portions of the map.
4) Using the chunk method above, I'd scan every tile that might appear within range of the area being drawn.
5) A routine similar to the client's GetMapIcons() will take the tiles in that area and sort them the same way they'd be done at runtime.
6) Finally, the drawing would be replaced by running those icons through the renderer—which allows for hardware or software—and adding the appropriate selection rectangles/diamonds.
In the case of the world view, the above has to be done in stages, and it's a friggin' nightmare. What will likely happen is that I'll render the map in pieces like I mentioned, but scaled down and saved in bitmaps that will just be applied in tiles the way it is now. The work I plan to do for statpanels/menus/etc. should pave the way for that too.
And that's the big challenge I face. It's all doable, just a little daunting right now.