After problems with gdb not catching simple crashes of a program I went back to Visual Studio. Microsoft had already released 2017 version (I had 2015). I like the installer of 2017, you can select only those parts you need, from programming languages to technology pieces. With regular C++ I also installed Linux tools, because it made me giggle. I don't know what they are, but I guess there were some talk about Windows trying to emulate the linux style command line workflow. It would be cool if it was possible to build projects just like in linux, but I doubt it.
The double account issue was also fixed, I went to msdn forums to ask about it and there is a special console for Visual Studio where you can reset the account. Seems like that another account went away, it could have been some kind of glitch and no one in reality was able to create an actual account to download my source code. Which is a fear I have, because VS has all that connectivity to clouds and team systems. I have obviously turned those features off.
Teemu's level system is more or less ready, but I realized there is no need to store object handles to level's map, because they are not owned by it. I could just make one "global" map and use it, that way a big amount of data would be removed from save game and memory. That map already exists in form of gameview class which has dynamic stuff like fov and lighting. Other than that the "map tile as object" broke some things from level generation. For example shallow water is no longer created. I hope it's fixed by itself when I go back to map that has only raw data and no objects.
Sunday, 10 September 2017
Monday, 14 August 2017
Line-of-sight problem description
The line-of-sight problem or LOSP can be compared to Nth Prime Number problem with difference that prime numbers are easier, yet I think no solution has been found to Nth problem for 2300 years. Like Nth the LOSP is seemingly easy, but still impossible to solve. In theory line-of-sight always works in infinite precision, but in 2D map of a roguelike it's not infinite, but an approximation that can "flip" the location of line to "wrong" tile depending on floating point calculations in that particular processor.
This image shows the problem in action. The red line is line-of-sight in infinite theoretic space and the blue line is an approximation in 2D map (green is wall). The black tile is often called an artifact of the result where line drawing stops before it reaches the required wall tile. In finite space the line simply stops in walls before that one artifact location.
There are number of ways to fix this problem, but none of them actually can do anything about the finite precision conversion. One of the solutions is find those artifacts and fix them using a simple routine to check their location in context to origin point of the FOV calculation. The issue with fixes are that they make the FOV routine often about two times slower, or even more. So is it a problem in modern computers? I think it is. If you want to keep the speed of game loop at least somewhere in 20-50ms (using one core) then you need a fast FOV routine.
FOV becomes critical in situation where other than player character have it, similar to more advanced path finding routines. It's possible to make the game very slow very easily with slow routines. That's why finding a solution to this problem could be nice.
There are number of ways to fix this problem, but none of them actually can do anything about the finite precision conversion. One of the solutions is find those artifacts and fix them using a simple routine to check their location in context to origin point of the FOV calculation. The issue with fixes are that they make the FOV routine often about two times slower, or even more. So is it a problem in modern computers? I think it is. If you want to keep the speed of game loop at least somewhere in 20-50ms (using one core) then you need a fast FOV routine.
FOV becomes critical in situation where other than player character have it, similar to more advanced path finding routines. It's possible to make the game very slow very easily with slow routines. That's why finding a solution to this problem could be nice.
Saturday, 15 July 2017
New plans for Teemu
Well, same old actually, because I'm refactoring Level class hierarchy with the same idea I had for Kaduria. It's such a great way to handle the biggest class structure roguelikes will probably always have which is the random level generation and other stuff happening in levels.
This time it's easier, because classes in Teemu are way smaller than they are in Kaduria. Another new idea for Teemu is that terrain tiles become containers of objects. Yet I think there will be lists to handle things like monster movement, but those will be a copy of the map container's objects (pointers of course, not real copies).
I hope this new system will also push the release date of 1.3 closer. It's annoying situation, because I know there is not that much to do, unless I want to make Teemu more complex which should be the plan anyways. I'm one of those developers who want roguelikes to be complex and not simple commercial action games everyone is making for mobile game market. I'm laughing at Biskup's attempts to simplify ADOM's UI. I want to make them more complex, because it's fun. It's the reason why we are creating these games.
This time it's easier, because classes in Teemu are way smaller than they are in Kaduria. Another new idea for Teemu is that terrain tiles become containers of objects. Yet I think there will be lists to handle things like monster movement, but those will be a copy of the map container's objects (pointers of course, not real copies).
I hope this new system will also push the release date of 1.3 closer. It's annoying situation, because I know there is not that much to do, unless I want to make Teemu more complex which should be the plan anyways. I'm one of those developers who want roguelikes to be complex and not simple commercial action games everyone is making for mobile game market. I'm laughing at Biskup's attempts to simplify ADOM's UI. I want to make them more complex, because it's fun. It's the reason why we are creating these games.
Friday, 16 June 2017
C# Pihlaja engine
Started to write an engine in C# for a roguelike game. The engine was named 'Pihlaja' (it's a plant). So the way I approached it was a blank Form1 with a picture box control. It's a simple area that you can display a bitmap image. This bitmap image is then filled with ascii tiles which also are bitmaps. It's quite easy, because you can print font data on image as pixels and use that as faster way to draw ascii fonts. It seems to be quite fast even without any hardware acceleration (I guess it doesn't have it?).
There were some problems as always. First one was that I copy-pasted the Load method of Form1 which you don't want to do, because C# doesn't know it's there! You have to double-click the header of Form1 to generate a method. Even stranger if there is a manual Load method the new one is named Load_1, so it adds _1 in the name and that's the only working version. You can't rename it Load, in fact you can't remove the code that's generated by Visual Studio or the Form1 breaks! There is some kind of internal version of that code and whatever VS generates should not be deleted or renamed, or copy-pasted to another project.
The second issue was that when you get font metrics you can only get the height of the font in pixels even with monospace fonts. And it contains a lot of empty pixels around the font, but you can adjust the pixel rectangle size manually for that bitmap version. The font's 0,0 position is also quite far away from the edge, but you can print the font in negative location, in this case -1, -2 was the right location. I determined the font width from height, but it was width=height-9 so you can remove a lot of pixels from that. The font must be installed on computer I guess (dynamic resource), but I think you can also use font family (generic monospace).
Third problem is that AutoSize of Form1 doesn't work properly and this seems to be a common problem. It means you can't resize the form (or window) to match the size of the content (picture box in this case). There is randomly some kind of margin at the bottom and right sides of the window. Could try to give the picture box some top and left margins to see if it behaves better.
There were some problems as always. First one was that I copy-pasted the Load method of Form1 which you don't want to do, because C# doesn't know it's there! You have to double-click the header of Form1 to generate a method. Even stranger if there is a manual Load method the new one is named Load_1, so it adds _1 in the name and that's the only working version. You can't rename it Load, in fact you can't remove the code that's generated by Visual Studio or the Form1 breaks! There is some kind of internal version of that code and whatever VS generates should not be deleted or renamed, or copy-pasted to another project.
The second issue was that when you get font metrics you can only get the height of the font in pixels even with monospace fonts. And it contains a lot of empty pixels around the font, but you can adjust the pixel rectangle size manually for that bitmap version. The font's 0,0 position is also quite far away from the edge, but you can print the font in negative location, in this case -1, -2 was the right location. I determined the font width from height, but it was width=height-9 so you can remove a lot of pixels from that. The font must be installed on computer I guess (dynamic resource), but I think you can also use font family (generic monospace).
Third problem is that AutoSize of Form1 doesn't work properly and this seems to be a common problem. It means you can't resize the form (or window) to match the size of the content (picture box in this case). There is randomly some kind of margin at the bottom and right sides of the window. Could try to give the picture box some top and left margins to see if it behaves better.
Thursday, 15 June 2017
C# language experiences
I've programmed something with C#, a loader for .wst tiles to test how easy it could be. To be honest it was kind of easy. C# has a large library of stuff which makes trivial things let's say somewhat easier than in C++. C# in Windows at least is closely tied to Windows APIs (or whatever they are called these days) and programs with GUI has that part in them. I'm not too happy about working with Windows form designer etc. but that's life for you.
As a language C# is quite close to C++, but the main difference is automatic value/reference system similar to Visual Basic. Another easy to spot difference is that you write code directly to classes, there are no header files or declarations of classes. Namespaces are an essential part of programming as they should be. Other than that the syntax is very close to C++ which makes it a lot easier to approach than let's say Visual Basic.
After writing the loader I've started to think about trying to write a simple roguelike engine for C#. It's sad that I can't think of any other game types, but maybe roguelikes are the only games I want to play? In my opinion C# doesn't make everything that much easier, because the hardest part of a program is always the content and actions of the program. But it could make some GUI stuff easier to implement.
As a language C# is quite close to C++, but the main difference is automatic value/reference system similar to Visual Basic. Another easy to spot difference is that you write code directly to classes, there are no header files or declarations of classes. Namespaces are an essential part of programming as they should be. Other than that the syntax is very close to C++ which makes it a lot easier to approach than let's say Visual Basic.
After writing the loader I've started to think about trying to write a simple roguelike engine for C#. It's sad that I can't think of any other game types, but maybe roguelikes are the only games I want to play? In my opinion C# doesn't make everything that much easier, because the hardest part of a program is always the content and actions of the program. But it could make some GUI stuff easier to implement.
Sunday, 4 June 2017
Font ligatures and Space Mono
Ligatures connect two letters to one unicode character to represent something "better". This is a new feature in programming which I feel is useless twiddling. Recently I tried a monospace font 'Space Mono' which actually is a great font for programming. But for some comical reasons it has a ligature with f and i letters, forming a 'fi'. It's not even that it has any "programming" ligatures, it seems to have just that one.
Visual Studio supports ligatures, but that's the problem, you can't turn it off. It's almost as if the designer of that font knew it and included 'fi' ligature as a joke. Strangely (or is it supposed to do that?) VS still takes fi as separate letters in data (compiling), but when displaying it breaks monospacing. You thought fonts were the last thing that humanity could possibly not fuck up, but they sure did it with ligatures.
I don't know if you can somehow turn ligatures off in VS, but that's not the point. It's just plain harassing using that 'fi' ligature in a monospace (programming) font. Even it was possible to turn it off the brief moment of joy finding a good font has passed. Let's get back to Consolas or something else and hope they don't ruin it as well.
Visual Studio supports ligatures, but that's the problem, you can't turn it off. It's almost as if the designer of that font knew it and included 'fi' ligature as a joke. Strangely (or is it supposed to do that?) VS still takes fi as separate letters in data (compiling), but when displaying it breaks monospacing. You thought fonts were the last thing that humanity could possibly not fuck up, but they sure did it with ligatures.
I don't know if you can somehow turn ligatures off in VS, but that's not the point. It's just plain harassing using that 'fi' ligature in a monospace (programming) font. Even it was possible to turn it off the brief moment of joy finding a good font has passed. Let's get back to Consolas or something else and hope they don't ruin it as well.
Friday, 14 April 2017
Namespacing 1.3
Notations for enums are in process to be turned to namespaces. I think about 1/3 of them is reprogrammed, but in most cases it's easy. When you remove special notation from the beginning it may sometimes create a name clash, especially when you open the namespace. But namespaces are better solution for other reasons like for functions tied to namespaces. It's also easy to find namespace instances from the entire source code.
This is probably not a healthy way to develop the game itself, but with this I'm planning for bigger changes to content and also to the RPG system. The key to success is keeping things simple for this one. I know very well what happens if you plan something major in context of roguelikes. Even now with actual RPG system the development has moved on to harder difficulty level from a simple 7DRL that Teemu was before.
This is probably not a healthy way to develop the game itself, but with this I'm planning for bigger changes to content and also to the RPG system. The key to success is keeping things simple for this one. I know very well what happens if you plan something major in context of roguelikes. Even now with actual RPG system the development has moved on to harder difficulty level from a simple 7DRL that Teemu was before.
Subscribe to:
Posts (Atom)