Zugg Software :: View topic

Posted: Wed Sep 03, 2003 6:22 pm

Today, while working on zMapper, I discovered some other small speed improvements that I can make to the mapper. These are not nearly as huge as the issue adding new rooms to big maps, but it should help a bit.

Unfortunately, I'm not able to do any programming Thurs-Sun this week, and there are a few other things I want to fix in zMapper. So, I'm delaying the zMapper release until next week and will then work on the bug fixes to zMUD for the week after that.

In addition to the updated map database code, I hope to improve the useability of zMapper a great deal and plan to also release a new tutorial on how to use zMapper to create D&D dungeon maps (I want to use it for the current campaign I'm playing Wink

)

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

::drool::

Posted: Fri Sep 12, 2003 12:59 am

Time for another update:

As usual, I'm not capable of a "quick" update. When I got into the guts of zMapper, there has been a lot of bugs that I want to fix. I really want to release a more stable and useable update this time around. As a test tutorial, I'm trying to create D&D maps from a paper module.

I've wasted a lot of time on stupid Windows "bugs". For example, zMapper uses the concept of "Paths" in Windows. But I've discovered that Windows has some rounding problems in how metafiles (the shapes in zMapper) use Paths. For example, if you draw a rectangle 2 different ways:

METHOD 1

Rectangle( hDC, X0, Y0, X1, Y1)

METHOD 2

StartPath( hDC)
Rectangle( hDC, X0, Y0, X1, Y1)
EndPath( hDC)
StrokePath( hDC)

did you know that you don't get the same rectangle on the screen? In metafiles, it seems that Windows first converts the points in the metafile to MM*.01 coordinates, THEN converts them to device coordinates. Doing two transformations separately instead of one complete transformation adds some rounding errors. This only seems to happen when generating paths.

Anyway, I finally ended up doing my own coordinate conversions within the metafile enumerate loop. It's a pain and a kludge, but I finally got the two methods to match. Of course, it actually still doesn't work for Rectangles...only for Polylines. So, internally I also have to convert Rectangles into Polylines.

The reason I'm concerned about this is that I want to be able to have rooms on the map with "thick" borders (like dungeon caves). If you've ever played with zMapper a lot and tried to change the pen width of a shape in the shape editor, you'll see that when you add that shape to a room and then stretch the room, the pen width of the horizontal and vertical lines will be different if the room is a rectangle instead of a square. This is because Windows treats the pen width as a logical coordinate value within the meta file and so it gets distorted along with the shape itself.

In order to generate a uniform pen width for a room that has been stretched, I have to compute the Path for the outline of the room, and then redraw the path after the shape has been displayed using the correct pen width. This overlays the original metafile shape with a new thick border. Of course, if the Path and the original shape don't match, then the thick path is overlayed in the wrong position, and it looks annoying.

Finally got it working though. You can now have thick walls on your rooms no matter how the shape is distorted, and can also have a "floor grid" drawn on the floor of the room. (Think about printing D&D maps and wanting the 5-foot squares for minatures).

I still want to spend some time improving the way doors work. I'd like to add a way to move doors so they are not always centered on the room edge. The database already supports this (you can tweak the door position in the Exit Properties), but I'd like a better drag/drop interface. I also want a way to add a door to the edge of a room more easily. When two rooms are touching, the normal link tool isn't very useful.

I'm out of town again this weekend, so the release isn't going to get done. Next week is also pretty busy but I hope to get some time to program. After Sept 21st, my schedule of other activities gets a whole lot better, so there is still a good chance of getting something before the end of the month.

Thanks for your patience!

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I'm just curious (and this is probably a big step in a direction you never were planning to take with the mapper) but rather than using the silly windows GDI have you thought about using direct draw instead? I haven't had a whole lot of experience with ddraw yet, but I've played with the examples on www.gamedev.net and it seems pretty straightforward and gets rid of the whole metafile issue. I guess it might have compatibility issues with olders windowses...but then so does mdac, so tellin' ppl to upgrade their direct draw at the same time as their mdac wouldn't be that big a deal?

Wizard Joined: 14 Oct 2000 Posts: 1368

quote:
Originally posted by Rainchild

I'm just curious (and this is probably a big step in a direction you never were planning to take with the mapper) but rather than using the silly windows GDI have you thought about using direct draw instead? I haven't had a whole lot of experience with ddraw yet, but I've played with the examples on www.gamedev.net and it seems pretty straightforward and gets rid of the whole metafile issue. I guess it might have compatibility issues with olders windowses...but then so does mdac, so tellin' ppl to upgrade their direct draw at the same time as their mdac wouldn't be that big a deal?

Direct Draw isn't supported anylonger. Direct3D should be used instead Smile

.

Posted: Sat Sep 13, 2003 8:54 pm

quote:
Originally posted by Rorso

Direct Draw isn't supported anylonger. Direct3D should be used instead .

direct3d for a 2d program..... while entirely possible, I'm not sure how much faith I'd put into microsoft on this one..... their direct-X releases (especially when it's a non-point release) are usually riddled with bugs, that would lead to a huge increase in tech support.... not to mention saying that zmud would require DirectX would be kinda a shocker and a pain for those whom might not have it (read: win95 users), though requireing them to download it wouldn't be a problem really, seeing that zmud requires MDAC as well, still though.

*shrug* I kinda don't see the overall point, unless it'd save zugg a LOT of work.

Posted: Tue Sep 16, 2003 12:22 am

Direct Draw would also prevent it from working on Windows NT, and I'd still like to support those users.

Also, Direct-X is very complicated and the amount of time it would take me to understand it and utilitize it would probably not be worth it. It took me a year to understand how to optimize ADO, for example. Also, Direct-X is still more tuned for 3D applications rather than 2D. Right now, the display drawing speed is not the bottleneck. The bottleneck is the database code and the code used to loop through the cache of data in memory.

Finally, I don't *want* to get rid of the Metafile issue. The entire point of the "Shape Editor" in zMapper is to utilize the Windows Metafile format and create an editor to that. I shouldn't need to invent my own "shape" data structure when Windows already has so many routines for dealing with MetaFiles. Also, using MetaFiles makes zMapper instantly compatible with any other drawing program that supports Copy/Paste, such as Corel Draw, Adobe, Macromedia, etc. Using metafiles was one of the best design decisions I have made in terms of modularity and design. The downside is that I need to deal with bugs in the Microsoft metafile stuff, and in differences across Windows platforms. But since I have to deal with those issues in general anyway no matter what I do, it's not a huge deal.

It was just interesting to uncover this specific issue regarding Paths within Metafiles and how some routines in Windows seem to exclude the lower-right edge, and some don't.