Implement maps about dgengine HOT 10 CLOSED

The automap functions are contained within the address range 0x401DA4-0x40311A and their signatures have been documented in http://sanctuary.github.io/notes/#fileData/automap.h, where the addresses refers to the 1.09b release of Diablo.exe (note that the addresses of the 1.09 and 1.09b are identical, so both versions work).

The automap_init_types function initializes the mapping between tile IDs and automap type by parsing the *.AMP file (e.g. Levels/L1Data/L1.AMP) , where the types include:

• HorzArch
• VertArch
• HorzDoor
• VertDoor
• HorzGrate
• VertGrate
• Square
• Stairs

No specific CEL file is used to draw these automap types. Instead pixels are drawn manually to the screen in a specified colour (that corresponds to an index into the active palette); see for instance automap_draw_type which draws the specified automap type at a given screen coordinate.

Keep in mind that the parameters screen_x and screen_y are not X- and Y-coordinates on the screen, but must first be translated. For more info, see https://github.com/sanctuary/notes/blob/master/name_desc.md

x = screen_x - 64
y = screen_y - 160

To render pixels on screen, several different functions from engine.cpp are used. One such function is engine_set_pixel(int screen_x, int screen_y, uint8_t pixel) which sets the given screen coordinate to the specified pixel value (index into the active palette).

I know this is not enough information to implement the automap rendering, however it's hopefully helpful to get started.

from dgengine.

The drawing of automaps is now well documented, after @squidcc's work on diasurgical/devilution#299

from dgengine.

I don't know if I'd say "well" documented - I made up my own flag names (didn't know the ones mentioned above existed) and the caves handling part is a bit vague; I think it's done that way because cave tiles can have walls on two opposite sides but that's a guess. Drawing the walls using different colours helps figure things out if anyone is curious.

from dgengine.

Drawing the walls using different colours helps figure things out if anyone is curious.

That's a good idea. Thanks for the tip.

from dgengine.

Thanks. The automap code was one of the first things I looked at in devilution. My approach will be a bit different (I might skip the SOL files and use something else that works for other resources, like flare's), but I'll try to have the same final result.

I'm thinking to have a texture with the automap tiles and just draw them by indexing each tile to an automap tile. This way you could have different automaps by just changing a texture. I can't use the SOL for this because there's some logic in the code for wall edges, so I'll have to create a new mapping file similar to the SOL file.

from dgengine.

Something to keep in mind is that the map can be scaled, so if you were using textures the lines/dots would also get scaled and look very different to the original.

from dgengine.

i.e. zoom in/out on the automap.

from dgengine.

Yes, I know. It's not a requirement I intend to do. Zoom, yes, but if it doesn't look 100% like the original, that's OK.

from dgengine.

In this last commit I added my implementation. You can still simulate zoom. I added 2 levels of zoom to show that it can be done as it takes some work to do each zoom for all level types (dungeons, caves,..).

As it is right now I would say it's good. The caves and nest levels are the ones I didn't do as in the original. Some pillar id mappings may be missing when loading levels with textures indexes not in the current commit's levels.

from dgengine.

The automap looks great! Also with the zoom.

from dgengine.