Sunday, 21 October 2018

Visual Studio C++ code metrics issue

Before I say this I want to point out that I'm not ungrateful about the fact that Visual Studio has a free version (it was called Express, now it's Community or something else). VS is a great IDE, in fact I think it's the best IDE at the moment. Yet there are some features which are weird. One of them is the missing code metrics option for C++ (unmanaged/actual) language.

Not getting some kind of project summary in lines of code, number of files etc. is not the end of world for me, but it would be a nice feature. They have it for managed code (like C#) which makes one wonder what was the reason to drop it from C++. Is there some kind of technical problem we the users don't know? When I read questions about that the "support" of Microsoft is the usual outsourced cut-paste answer that makes no sense. I really wonder why they even bother answering, I guess they get paid to cut-paste.

VS has extensions that could do the trick, but it should be a built-in feature (it is for managed code!) in my opinion and trying to find free extensions for that particular task is a real hassle. The extension/plugin system of VS is quite annoying, because most of the plugins are listed in several categories which itself are somewhat confusing and there is no clear indication of the price.

VS does have a static analyzer for C++ which is like way more complex feature than code metrics, so it's not like it would be impossible to do. Then again the static analyzer and Visual C++ compiler are both a bit "random" at reporting issues. If you don't believe me check your code with GCC and be enlightened. (Remember to use the warning options you need.)

Code::Blocks, the other IDE I'm using quite a lot has another type of problem, namely being open source. It has a simple summary of the project (which for some reason tells that one of my files is missing (what file?)), but it's only a LOC counter. If you know anything about open source development then you know that asking for some feature is almost always useless. The open source developers are notorious for being stubborn to do things exactly the way they want. That being said I think Code::Blocks developers are surprisingly friendly, but any feature you want you just have to wait for, sometimes it takes years as we have seen in case of projects like Blender 3D (for example the legendary case of N-gon feature).

Sunday, 23 September 2018

Being simple

Finally solved the display map synchronization problem I had for a long time. The underlying problem was my inability to think the simplest possible solution. In programming almost always the simplest solution is also the best one, because it's going to reduce the number of places things can go wrong.

I solved this in Teemu where I was adding support for multiple items per tile. The solution was so simple it just came out from nowhere. It's sometimes difficult for a highly creative person like me to think in simple way, but it's something I'm trying to do when programming. I try to be a simple person and it's probably the most difficult thing to do for extremely intelligent people in my experience. Although even harder for me is how to get women. It seems to be impossible for me and sometimes it makes me sad.

I'm also going to import the "flight package" routine from Teemu. It adds flying items into a list and then throws them at the same time, rather than go through each creature and make them throw items one at a time. When items are flying at the same time they could even hit each other. For example you run into an archer who is about to shoot you, but you can throw a large item and intercept the flying arrow.

Friday, 20 July 2018

Modular style

So what I have discovered lately is a sort of modular programming style where classes and functions of same theme are placed in one source file. This doesn't sound like very interesting news, but at least in my experience it may solve some problems resulting from C++ "class per file" rule we have been told to follow.

The problem with "class per file" is the physical size and complexity of the project: the more files it has the more difficult it becomes to maintain. C++ doesn't help, because you have to remember to include headers and also keep track of headers that are no longer needed. With large, over 300+ files project it starts to become a hassle.

Modular style has also other benefits like keeping better track of similar types of classes/routines and possibly making them more generic with inheritance etc. If your classes are in a single file you may actually forget(!) something similar exists. It's easier to find stuff, too, when similar type of code is in one file.

In C++ the downside is naming, sometimes there are issues when some namespace has been opened. But it's quite simple to remedy it by not making your names too generic even it is possible with namespaces, or use nested namespaces when possible. With modules the amount of namespaces seem to drop as well, with logical solution to use namespace per module, possibly even using the same name as the filename to keep things tidy.

For me at least modular programming used to be split to classes in a way, because classes are kind of modules by themselves. But using larger thematic modules may actually prove to be very important in this project and in the way I'm able to maintain and develop it.

Wednesday, 30 May 2018

Object-oriented news

I have a plan to put related classes into one file. This idea came from The Prowler's Datatype module and when I was programming similar type of stuff in Brick Atelier. I noticed that it's somehow easier to manage code and even design inheritance when there are less source files. It's maybe something we were not told to do, but I'm doing it anyway.

It's not a big refactoring which is something I try to avoid these days. It's more like re-arranging code into bigger pieces. This works with small classes, but not so much with bigger classes where actually splitting the class is a better option as mentioned earlier with the Level class saga.

I also try to use more inheritance which sounds quite obvious with a C++ project, but it's something I guess many programmers try to avoid (for no good reason). If you have a class-based code it's almost better use inheritance, because then you are going to remove some similar, repeating code for sure.

With content I try to design level themes from basic terrain topology first and then moving into details. I have some new ideas and tools to create difficult level themes so let's try it and see what happens.

Thursday, 8 February 2018

Plans for 2018

The account problem with VS was fixed, but I've also made a project for new Code::Blocks with virtual folders trying to make some kind of sense to it. The Cornucopia system I made for Teemu is going to be in Kaduria too. I think it will work well in town generation which is a missing piece in dungeon generation algorithms.

Something happened to me during last year, I don't remember I mentioned it before, but I became more aware of problems in my source code and programming style. In a way I became a better programmer almost overnight. It was a strange thing to happen, because it came out from nowhere. Maybe brains sometimes work that way, they get information from a long period of time and then make a decision to step into a new level.

The plan is simple: detect and work on problem areas of this project. There aren't that many left I think and they are mostly fine tuning some system like dungeon generation, in which I'm going to follow my experiences in Teemu and use more or less individual level theme generation for the basic structure of a level theme and then add more generic routines which create objects etc.

Wednesday, 30 August 2017

Switching to Code::Blocks

Visual Studio started to have strange problems with the Microsoft account which made me rage quit and switch to Code::Blocks and gcc. I've made final compiles for Teemu and Brick Atelier with gcc and it was easy to set up Kaduria for it.

Code::Blocks is let's say less good than Visual Studio, but it's not that bad actually. All I had to fix were some missing c headers, because VC is "silently" including them. And fix some missing forward declarations. Then I built the project using some useful warnings and also -Wall. At the end of the day it's quite clean, couple of floating point comparisons left to fix. I did suppress 'write-strings' warning, because it's warning about things like printf("Hello"); not being const. I can get the reason behind it, but it's still one of those impossible warnings you don't need, because there are going to be billions of them.

The debugger of gcc is quite useless, but luckily I almost never need it. Most of the bugs I'm making can be found with static checking and warnings of "dumb" things you can easily write when tired etc.

Code::Blocks is surprisingly stable for open source program which is great, because without it there would be even less options to replace Visual Studio. One thing I didn't yet solve is how to get rid of the console window in SDL2. -mwindows doesn't seem to work.

Monday, 28 August 2017

New gameview design plan

Since I had no luck with FOV I've moved on to next feature which is not in fact terrain effect when moving but the new gameview. Funny thing is that I've had this constantly scrolling "Ultima" style gameview since the beginning of this project, but I'm going to change it anyway. The reason for Ultima view were tiles of course, because in ancient times you couldn't create a large view area with tiles, it had to be small. But it's no longer a problem.

The current view is 17x17 tiles, but since I'm keeping a full hd resolution as "minimum" then there is room for larger view. One possibility could be 30x20 tiles. It's still quite small, but allows push scrolling for the view and it's not too large, because more tiles means slower gameloop. When I was making a sketch of 30x20 tiles to see how it looks it's quite mindblowing to realize that Nethack's gameview is 80x20 something (the level area). It's so wide, but it's harder to get, because often the font is taller than its width. I guess you could say Nethack predicted wide angle screens long before they existed.

Push scrolling is used in many roguelikes so it's not that strange. ADOM has it and also tile versions of roguelikes, including Nethack. It's also quite "easy" to change the gameview to push scroll and I have done it in Teemu so at least it's not going to be a big problem like FOV. But as always we'll see that later. Also the screen size is going to change and it means lots of changes in placing gui components, windows and other stuff like that. However since I'm developing this one feature at a time it's not going to blow up everything at once.