show_bmp and player_map
For those interested, I'm reporting on a small test I did with show_bmp.
While talking to Magicman some time ago, we thought it should be possible to put the marker in an arbitrary position by changing player_map before calling show_bmp. Things are slightly more complicated, and then quite a bit more.
Firstly, the marker is set depending on the last non-indoor map screen that was loaded. This means that it will work, as long as you don't make any map screens "indoor", and call load_screen before show_bmp. You will want to call load_screen again after resetting the player map, or you have the wrong sprites loaded. Also, this really does reload all your sprites, so they will be in the positions as if you just entered the screen again. That may or may not be a problem. You may worry that all sorts of scripts are being called, but this doesn't seem to be the case; that happens at the draw_screen call (which you therefore may want to do when returning to the screen where Dink really is).
However, there is a much bigger problem. When trying load_screen while player_map is pointing to a nonexistent screen, the engine can crash. So to make this work, all map screens that may be (ab)used this way must exist. This is easily solved, of course, but it isn't nice at all. It also hugely inflates the size of the dmod (unless your map is using almost all map screens anyway), because map screens are stored in an extremely wasteful way.
Because of this, I'm not sure if I'll be using the feature in my dmod. But I might, just because it's cool.
While talking to Magicman some time ago, we thought it should be possible to put the marker in an arbitrary position by changing player_map before calling show_bmp. Things are slightly more complicated, and then quite a bit more.
Firstly, the marker is set depending on the last non-indoor map screen that was loaded. This means that it will work, as long as you don't make any map screens "indoor", and call load_screen before show_bmp. You will want to call load_screen again after resetting the player map, or you have the wrong sprites loaded. Also, this really does reload all your sprites, so they will be in the positions as if you just entered the screen again. That may or may not be a problem. You may worry that all sorts of scripts are being called, but this doesn't seem to be the case; that happens at the draw_screen call (which you therefore may want to do when returning to the screen where Dink really is).
However, there is a much bigger problem. When trying load_screen while player_map is pointing to a nonexistent screen, the engine can crash. So to make this work, all map screens that may be (ab)used this way must exist. This is easily solved, of course, but it isn't nice at all. It also hugely inflates the size of the dmod (unless your map is using almost all map screens anyway), because map screens are stored in an extremely wasteful way.
Because of this, I'm not sure if I'll be using the feature in my dmod. But I might, just because it's cool.
>It also hugely inflates the size of the dmod
>because map screens are stored in an extremely wasteful way.
I was under the impression that creating a screen sets a flag in Dink.dat and fills the corresponding screen in map.dat with stuff in the tile area. This greatly expands map.dat, but bz2 compression provided by DFarc should make this negligible overall because it features run-length encoding. Is it more complex than that?
>because map screens are stored in an extremely wasteful way.
I was under the impression that creating a screen sets a flag in Dink.dat and fills the corresponding screen in map.dat with stuff in the tile area. This greatly expands map.dat, but bz2 compression provided by DFarc should make this negligible overall because it features run-length encoding. Is it more complex than that?
Is it more complex than that?
No, it's exactly that. But not just that the map is large; it's mostly junk, too.
What I mean is that every tile uses 8 data bytes, plus 72 junk. Every map screen adds 8509 junk bytes. That's a total of 15421 junk bytes on 31280 bytes for a map screen. And that's assuming you are in fact using all 99 sprites, because they take their space, whether you use them or not. If you're just filling the map for being able to use show_bmp, you're not using it at all, which really means all 31280 bytes are junk. For a small dmod, say 50 screens, that means you are adding 31280 * (768-50) = 22 MB to map.dat.
But you are correct, that this is almost entirely compressed away, so it shouldn't matter much for downloads. And 22 MB is nothing with today's hard disk sizes. But it still feels very wasteful.
No, it's exactly that. But not just that the map is large; it's mostly junk, too.
What I mean is that every tile uses 8 data bytes, plus 72 junk. Every map screen adds 8509 junk bytes. That's a total of 15421 junk bytes on 31280 bytes for a map screen. And that's assuming you are in fact using all 99 sprites, because they take their space, whether you use them or not. If you're just filling the map for being able to use show_bmp, you're not using it at all, which really means all 31280 bytes are junk. For a small dmod, say 50 screens, that means you are adding 31280 * (768-50) = 22 MB to map.dat.
But you are correct, that this is almost entirely compressed away, so it shouldn't matter much for downloads. And 22 MB is nothing with today's hard disk sizes. But it still feels very wasteful.
Man, I had been wondering why map.dat was so big! That's nuts.
