Banana Rogue has already 6 files that compile which can be seen as a minor success. It tells that once you get old C translated to C++ compiler it will be "fine" if we forget about memory management problems of C like raw arrays etc.
Function pointer stuff in daemon and daemons modules doesn't work, because the function signature has to match the pointer in C++ which is more strict about types. If I'm lucky it will be fixed by changing all 'void' functions to 'int' return value, even if they don't use it. Or check out if the functions actually are all void type.
The gui refactoring is almost ready. Most of the action happens in Window (previously WINDOW) struct of curses which I replaced with a class. Window is used inside io module through procedural function wrappers which makes it "easy-ish" to replace later with other type of implementation. Everything works in ascii level, the Window is simply a rectangle of ascii data. It's quite brilliant. The only connection to SDL2 will be Display which shows the window. Then also you need SDL2 in keyboard routines which are also simple in case of ascii codes. There will be some complications if you want to use modifier keys or any special keys like arrow keys, but it can't be too difficult to fix.
The rest of bigger problems are in save game routine, options module (which can be easy, I have skipped it) and linked list routines. The internal type for linked list data is surprisingly char* which is a mystery, because malloc itself is void type or typeless.
Sunday, 31 March 2019
Saturday, 23 March 2019
When otherwise
The strange 'when' keyword was just a macro for break;case pair which I think is cute. I may even keep that macro, but some macros may have to go. Oh, I'm talking about Banana Rogue, a derived game from Advanced Rogue. I've now gone through source files and mostly created missing header files. Somehow it was possible to compile the source without header files back in what year it was made, because they weren't missing from the source, otherwise there would have been #includes for them, right?
The year is also a mystery (well, guess I could google more about it...) because the source says it's 1985, but it can't be that early, right? Also, the xcrypt source code which is some kind of strange encrypting method for wizard's password is from 1994. I think 1990's is much better guess for this game, they just didn't put it into the source code, but kept some random year, maybe the year they started to work on this game.
Xcrypt can be removed, because it's used for networking (password) which is going to be removed also. The system they programmed this had some kind of built-in networking, this was I think before widespread use of internet as we know today.
What is quite surprising is how clean the source code actually is. There aren't too much parameters in functions and the game has only few datatypes. Probably the most dangerous one is the linked_list which is as mentioned before a linked list type and when you combine C's memory management to that it could be a source of bugs. It's maybe too big task to replace it with C++ version, but it's early to tell. Maybe the internal implementation can be changed.
I'm not too concerned about "destroying" the original source code, but at the same time it's silly to replace everything that looks "bad" from C++ perspective.
The year is also a mystery (well, guess I could google more about it...) because the source says it's 1985, but it can't be that early, right? Also, the xcrypt source code which is some kind of strange encrypting method for wizard's password is from 1994. I think 1990's is much better guess for this game, they just didn't put it into the source code, but kept some random year, maybe the year they started to work on this game.
Xcrypt can be removed, because it's used for networking (password) which is going to be removed also. The system they programmed this had some kind of built-in networking, this was I think before widespread use of internet as we know today.
What is quite surprising is how clean the source code actually is. There aren't too much parameters in functions and the game has only few datatypes. Probably the most dangerous one is the linked_list which is as mentioned before a linked list type and when you combine C's memory management to that it could be a source of bugs. It's maybe too big task to replace it with C++ version, but it's early to tell. Maybe the internal implementation can be changed.
I'm not too concerned about "destroying" the original source code, but at the same time it's silly to replace everything that looks "bad" from C++ perspective.
Sunday, 17 March 2019
Banana Rogue
The license of Advanced Rogue tells you can't use name Advanced if you derive from it so the project name could be Banana Rogue and in the story you work in a banana plantation, but want to escape hard working conditions in nearby deadly dungeon which sounds much better option.
I found rnd() function from main.cpp and it really looks like main could need some cleaning up. There is some kind of "network" code which is going to be removed. Also, there are signal handlers in case the program crashes which makes the player die from bug. I think it's better remove those also, because if the game crashes it's better to make it possible to load the game from possible existing save game.
This project really needs a gui module and there is already io.cpp which has things like msg for message output, but it could have everything gui related in it. I think the game doesn't have a "level" structure but it has at least four WINDOW arrays (which work as layers) which I think are from missing curses library. They are simply char arrays if I'm interpreting the code correctly.
I found another 'when' keyword switch-case which has the first keyword 'case' but the rest are 'when'. It's quite baffling, because I can't even find any mentions of 'when' being a keyword in C.
I found rnd() function from main.cpp and it really looks like main could need some cleaning up. There is some kind of "network" code which is going to be removed. Also, there are signal handlers in case the program crashes which makes the player die from bug. I think it's better remove those also, because if the game crashes it's better to make it possible to load the game from possible existing save game.
This project really needs a gui module and there is already io.cpp which has things like msg for message output, but it could have everything gui related in it. I think the game doesn't have a "level" structure but it has at least four WINDOW arrays (which work as layers) which I think are from missing curses library. They are simply char arrays if I'm interpreting the code correctly.
I found another 'when' keyword switch-case which has the first keyword 'case' but the rest are 'when'. It's quite baffling, because I can't even find any mentions of 'when' being a keyword in C.
Saturday, 16 March 2019
Confronting a vast cosmic mystery
It might be possible that the random Advanced Rogue source code that I downloaded from somewhere and started to work on could be obfuscated. One clue for this are the missing function declarations, but I've also seen a switch - case with two 'when' keywords. Or could it really be possible that it's written in some kind of special version of C?
Anyway, rather than trying to compile one file at a time (which is still not even possible) I've started to re-create header files for each file with functions it has. There are some functions that has to be replaced, but luckily more modern alternatives are possible without changing the call style. One of those is msg() which has a vararg style parameter list, but the syntax is different than it will be in the "modern" version and also I'm probably going to change the internal implementation to std::string, because it just looks like it's better that way.
The number of datatypes I've seen this far is reasonable, it's four: coord, object, thing and linked_list. The last one is a manual linked list as the name implies and it could be heterogeneous through void pointer magic, but I'm not sure yet. But it's using macros to allocate memory for objects. I'm not sure if it's useful to replace that with something safer, at least if it actually works.
Anyway, rather than trying to compile one file at a time (which is still not even possible) I've started to re-create header files for each file with functions it has. There are some functions that has to be replaced, but luckily more modern alternatives are possible without changing the call style. One of those is msg() which has a vararg style parameter list, but the syntax is different than it will be in the "modern" version and also I'm probably going to change the internal implementation to std::string, because it just looks like it's better that way.
The number of datatypes I've seen this far is reasonable, it's four: coord, object, thing and linked_list. The last one is a manual linked list as the name implies and it could be heterogeneous through void pointer magic, but I'm not sure yet. But it's using macros to allocate memory for objects. I'm not sure if it's useful to replace that with something safer, at least if it actually works.
Friday, 15 March 2019
Advanced Rogue
I was reading the source code of Nethack one day and noticed that I can also read source code better these days, mirroring my increased skills in programming. So I downloaded the source code of Advanced Rogue which I think was last updated in 1985. Rogue had quite a number of variants just like Angband later, but I've never played any of them.
The source code of ARogue seems to be quite small, but it's also old school C which means that weird way of writing function definitions and declarations. The plan is to rewrite the source code to C++ (not OOP, but keeping the procedural style) just for fun reasons and I've already on the way. Another "problem" I guess is curses which is an external library used in ARogue and it's not included, but can be replaced with SDL2 gui. It's possible that curses has also changed during all these years, so it's probably not going to work just like that. However I could even keep the old function names so in theory it's possible to replace SDL2 gui with curses, or whatever.
As a small mystery some functions are defined, but not declared in any of header files. Or in this case rogue.h which is I think one of the two header files the project has. Creating header files for functions defined in a .cpp file is another task in the list.
Other than that I think the majority of old C code should run in a modern C++ compiler, but we'll see it later. There are lots of pointer stuff in ARogue's source which can be a problem and also I'm going to replace memory management routines with C++ code.
The source code of ARogue seems to be quite small, but it's also old school C which means that weird way of writing function definitions and declarations. The plan is to rewrite the source code to C++ (not OOP, but keeping the procedural style) just for fun reasons and I've already on the way. Another "problem" I guess is curses which is an external library used in ARogue and it's not included, but can be replaced with SDL2 gui. It's possible that curses has also changed during all these years, so it's probably not going to work just like that. However I could even keep the old function names so in theory it's possible to replace SDL2 gui with curses, or whatever.
As a small mystery some functions are defined, but not declared in any of header files. Or in this case rogue.h which is I think one of the two header files the project has. Creating header files for functions defined in a .cpp file is another task in the list.
Other than that I think the majority of old C code should run in a modern C++ compiler, but we'll see it later. There are lots of pointer stuff in ARogue's source which can be a problem and also I'm going to replace memory management routines with C++ code.
Subscribe to:
Posts (Atom)