Reply to Re: 0.3 release time
If you don't have an account, just leave the password field blank.
Speaking of bugs, I had another look at this one. The relevant lines are in game_engine.cpp in game_load_screen(), and are as follows:
In terms of data:
- mapdat_num refers to the screen number in map.dat that is to be loaded
- g_dmod.map is the struct that holds Dink.dat (the screen index etc)
- cur_ed_screen is the map.dat screen data in memory that you end up seeing after a redraw
The most pertinent of what's in there is ts_loc_mem[769], which is an array of the same data type as cur_ed_screen, i.e. it holds map screens in RAM. It seems to only be used for the test suite and is never modified anywhere else, meaning that for normal use, the "else if" executes instead since all values in ts_loc_mem are empty. In FB2 and other d-mods with large amounts of screens where the author decided to use MapNuke, there's the eventual problem where DinkEdit makes more than 768 screens, as MapNuke doesn't actually remove anything, and only zeroes the reference in Dink.dat. In the case of FB2, it has 804 screens in its MAP.DAT.
For screens above 768, my assumption is it's going outside the bounds of ts_loc_mem and seeing if memory values above that are NULL, of which many wouldn't be, and then causes a segfault when it tries to memcpy 31280 bytes of something else it shouldn't into cur_ed_screen, hence why, as Scratcher says, it crashes even if MAP.DAT isn't there. What flummoxed me initially was that it was occasionally loading screens above 768, probably due to comparing to an address out of bounds that just happened to be zero and thus loading normally. The next release will have this rectified, probably by getting rid of the if/else if.
int game_load_screen(int mapdat_num) {
if (g_dmod.map.ts_loc_mem[mapdat_num] != NULL) {
memcpy(&cur_ed_screen, g_dmod.map.ts_loc_mem[mapdat_num], sizeof(struct editor_screen));
else if (load_screen_to(g_dmod.map.map_dat.c_str(), mapdat_num, &cur_ed_screen) < 0)
In terms of data:
- mapdat_num refers to the screen number in map.dat that is to be loaded
- g_dmod.map is the struct that holds Dink.dat (the screen index etc)
- cur_ed_screen is the map.dat screen data in memory that you end up seeing after a redraw
The most pertinent of what's in there is ts_loc_mem[769], which is an array of the same data type as cur_ed_screen, i.e. it holds map screens in RAM. It seems to only be used for the test suite and is never modified anywhere else, meaning that for normal use, the "else if" executes instead since all values in ts_loc_mem are empty. In FB2 and other d-mods with large amounts of screens where the author decided to use MapNuke, there's the eventual problem where DinkEdit makes more than 768 screens, as MapNuke doesn't actually remove anything, and only zeroes the reference in Dink.dat. In the case of FB2, it has 804 screens in its MAP.DAT.
For screens above 768, my assumption is it's going outside the bounds of ts_loc_mem and seeing if memory values above that are NULL, of which many wouldn't be, and then causes a segfault when it tries to memcpy 31280 bytes of something else it shouldn't into cur_ed_screen, hence why, as Scratcher says, it crashes even if MAP.DAT isn't there. What flummoxed me initially was that it was occasionally loading screens above 768, probably due to comparing to an address out of bounds that just happened to be zero and thus loading normally. The next release will have this rectified, probably by getting rid of the if/else if.
