Legend of Saladir remake

[Krice]

Now I remember that the game did freeze sometimes and one possible place is fixed which is the fov routine. It was using a 102 x 102 raw array and also read the level map without checking the index. Now those two are fixed and I think there aren't that many raw arrays left. I could release the source code after fixing the portal problem (and save game), because it seems you can't enter anything at least in the overworld map. I'm just wondering what the original developer thinks about all the bad things I've done to his source code... Kind of scared to ask him about it.

 

[Krice]

Entering dungeons in overworld map was first checking if the dungeon is overworld and index was zero, but in this case the first index was 1 so it missed that check. Then I read the source code which I rarely do and figured out that the overworld dungeon locations are at fixed locations so that's how the entering works, it's checking the locations. However the overworld generation has big problems when it sometimes creates a lot of mountains and sometimes almost all water so you can't reach the dungeon locations. Now we also solved the mystery why the overworld map was saved as a file, the developer probably gave up and used a fixed overworld map and locations. Also the generation of lakes was commented out, because the base routine can create them, in some cases too much water even. The overworld generation isn't that smart, so I'm thinking about how to fix it. Obviously something like first creating the locations, then paths (invisible or visible) between them and then filling the rest of map with random terrain. I think random locations would be a better idea.

 

[Krice]

The overworld dungeon locations are now random, but still have to fix the height map generation. I'm thinking about creating a path routine to manipulate the height map itself, but I'm not sure how to get the proper values from the routine to the path creating routine. I don't really understand how the height map generation works, the only thing I know is that it has height values which are then turned into terrain types (water, grass, mountains etc.) Well if the values are static then it's just trying out to find them. Or maybe even try something funny like finding out the min and max values after the generation and then the middle value is most likely grass or ground level value.

 

[Krice]

If I put this to Github I wonder if there are some kind of rules for the directory structure. I always use a flat directory for source files in the root of the project. I don't put them in 'src' or whatever. Will Github break if source files are in the root... maybe I should move this project to Linux and use 'src', makefile and other funny stuff.

 

[Rean]

Github will not break. Organize them however you want.

 

[Krice]

Highscore list had a problem with monsterdef's missing copy constructor so I fixed it (in some cases you can't give constructors to structs, because C issues..) by assign operator in the Score constructor. However I forgot that the score data was saved and loaded from file so I spent almost two hours trying to figure out why isn't the score showing properly, because monsterdef data was empty. It was loaded from the file so it always had the old data.

Anyway, this project has 17 unfinished modules, could be worse.

 

[Krice]

Fixed couple of "notes", I have a style of commenting something weird or buggy with //note: so I can find them later. Went from 102 to 96 today, it's painfully slow to fix these. Then again, there is going to be a lot of them in the first release, fixing only those which are the most important. I'm hoping that the gameview refactoring is going to make some stuff easier, but it also has to work properly. Short explanation is that gameview has "shortcuts" or pointers to topmost game objects which are updated when that object is moving. That way you don't need to find items from a list to display etc. it's much faster and this game had a problem with speed for that reason.

 

[Krice]

I went back from trying to stuff everything in classes to moving action code to functions. In this project it works really well, because it was the original style. However I've changed it so that functions also take in the player's handle, so they are not using global 'player' object. In theory it makes easier to make those actions work for monsters as well. The plan is to divide action code to functions and object data to classes, but with extra internal code in classes, not just as "empty" structs as they were.

 

[Krice]

It's still funny to look at the source monitor data, because it's so bananas. The original source had 99 files and 35K lines of code and the current one has 187 files and only 25K loc. Somehow I removed 10K lines of code which I'm still wondering how that happened. Well there were some stuff that was manually programmed like random numer generator which I replaced with std::random, and I think there was code to encrypt the save data, but.. the difference is that quite a lot of code was moved from functions to member functions of classes, but it shouldn't remove lines of code that much?

 

[Krice]

Still stuck on inventory browsing routine that has 400 lines of C. Spent 20 minutes just looking at it and I think the only way to make some kind of sense is to create a class. Then you can break the code in small pieces without having to pass variables around.