Friday, 23 September 2016

SDL2 in OSX with CodeLite

If you are searching for information about things in the title I'm sorry, you wont find anything helpful in this entry. It looks like no one ever set up a SDL2 project on OSX using CodeLite. This far I have managed to install CodeLite. Then there were missing "developer tools" which can be installed typing gcc in terminal. OSX will detect if gcc is missing and asks to install developers tools.

I have SDL2 installed, it's in the Library as something called "framework". For some reason I can compile a large project with number of SDL2/SDL.h references, but the linker fails which I guess means something, but what. OSX can't work things the simple way. As far as I can understand you can't show the compiler and linker where SDL2 files are, it has to be done with "framework". I just don't know how, there is no such information on the internet. Yes, call the internet, I'm asking for that information.

Although, even if I can't run the project I can prepare the source code for OSX simply by making sure it compiles. But I'm going to continue the painstaking research about SDL2 + CodeLite + OSX and if succeeding pass that to my cv when I'm applying to fucking NASA. They will immediately hire me, because it's harder than rocket science.

Wednesday, 14 September 2016


I think my PC survived the notorious Anniversary Update of Windows 10. In fact I updated it manually, because the older version started to have that annoying 50% cpu updater loop problem. I hope Microsoft would just fix that problem, because it seems to come back on regular basis. It's a bug that prevents the Windows updater from updating and it was introduced I think after Microsoft first released Windows 10.

Also updated Teemu from VS2010 to 2015. It was surprisingly easy, I just had to copy SDL2 stuff to VS directories. It's the way I have always setup SDL, just copy include and lib stuff to the compiler's directories.

VS2015 is not that bad. It's a little bit slower than 2010, but it has more modern C++ compiler and I think W4 warning level works nicely, although it doesn't seem to catch all similar code for warnings which is weird. At first it was annoying to adjust "space rules", because there are lot of them for no good reason. It should have been an optional feature for those who wants that kind of stuff, not something you have to turn off one rule at a time.

I'm again trying to proceed in Teemu and it's possible if I try to keep the current technical implementation and concentrate on the game design.

Friday, 2 September 2016

F# language experiences

For quite a time I was looking for a different programming language I could try, because working constantly with C++ can be strenuous. My initial plan was Ruby or even Python, but I found out that just installing them on unix system (OSX) was more than I could handle. I had also planned to update from Visual Studio 2010 to 2015 and noticed that VS2015 is pre-installed with F#. So it was easy to start hacking with it. (Note: you can keep 2010 along with 2015 which is nice, because all my projects are on 2010.)

F# is mainly a functional language and it has been nice to approach programming from another perspective. In functional paradigm you are supposed to input parameters to a function and get some kind of result. It could be thought as a procedure becoming an algorithm itself, rather than containing it. At least that's the way I'm understanding it.

In real life programs pure functional style is difficult to use, because you are not supposed to have variables, but only constants computed from other constants. Yes, it does sound crazy. For convenient reasons F# does have variables that can be created using mutable keyword. F# has also classes which is another good option to have.

The learning barrier to F# is surprisingly low, at least when you get started with the language. Sometimes the syntax is bit confusing (for someone with mainly C++ background), but it's possible to get it right when trying hard. Couple of things I noticed were tuples (which are used in Console-routines). When you use (x, y) notation it's a tuple, not two parameters as in C++. Also, for some reason you have to create a tuple using let a = (x, y) and pass 'a' to Console-functions for them to work, for whatever reason.

Another subtle thing is unit as a C-style void return value. The proper way to write void function returning void is let function() : unit = //some code and also remember to call it like this: function() with parentheses. Or even more strictly using do-keyword: do function().

The way F# source files are arranged is also a bit crazy. They are in a list where top most files are used by files lower in the list. You can't call a function unless it's declared above. I guess it's actually possible to write large programs using this style, but it seems to be quite primitive. All source files are always compiled for this reason which makes compile times slow even on small projects.

I'm not really that excited about functional programming. I guess it solves some problems as it forces the use of constants. It's like having C++ const as default and mutable only when you need variables. This is something you kind of start to use in C++ as well when you become a better programmer. I've noticed that most of my variables are const type and you start to become more const correct with experience. Even so, the way F# has mutable variables and classes shows that they are useful to have, rather than trying to follow a strict functional path.

The obvious thing to do with F# is of course to create a roguelike and that's what I have already started to program. It feels like I have to proceed with caution to find more functional ways to implement stuff and I'm sure it's a good way to learn something new.

Tuesday, 5 July 2016

Messages and events

The small event system that I had started is now removed. It was kind of funny thing, because I didn't realize that when you have an event system it has to cover everything in the game. Otherwise you have two "flows" of program happening at the same time, resulting to random outcome.

The event message type was not removed, because changing that would have been hard. In fact it works just fine, because "event" type messages simply use another type of id in specific situations. These are things like opening a door. With events you can make the door opening abstract, detached from who is actually opening the door, so later it's possible to make other creatures than the player open the door without changing anything in the door opening routine.

I've been combing the source code for messages, because some of them are not working as expected. When messages are ok then it's easier to concentrate on rest of the unfinished stuff. It's mostly gameplay content (story) and some level themes which need more complex stuff. I really want to release the new version even without the new RPG system, as soon as it starts to look like a playable game.

The current version of Teemu has 98 source files so it has been growing since last release. The quality of source code has also increased a lot I think. One of the reasons I'm releasing the source code is that I want to show in practice why C++ (OOP) is such a good option in programming (compared to C). It's hard to convince anyone just by telling that C++ is better, this way it's obvious.

Sunday, 26 June 2016

Level class inheritance

The Level class in Teemu is probably the last class that doesn't use inheritance (from those that needs it), but it's about to change. I've already started to break it apart. Level class shares almost every feature between different level themes, but the obvious difference is the generation process.

I was thinking before that generation part wasn't "good enough" reason for inheritance, but I think I was wrong. If nothing else it's easier to maintain source code one theme at a time compared to huge combined Level class. But it's possible to start think about more advanced inheritance schemes with intermediate classes between the base class and actual themes. Longer inheritance chains are better, because they emphasize the benefits of inheritance, but as always you have to be careful not to create wrong kind of inheritance.

This is an important change, because Kaduria has also one large Level class and even from this brief experience I can tell inheriting is much better than one class. It took me a long time to realize this, but things sometimes are set a certain way and can stay that way, because it feels like a big task to change it.

Friday, 17 June 2016

Cleaning up Teemu

It's surprising that I'm now a better programmer than I was couple of years ago, because I was really great then. When I'm looking at the source code of Teemu I can now see some issues clearly. The main problem is the way classes have functions (and functionality) that belongs to somewhere else. This is often easy to fix and I've been doing some of that already.

Sometimes functions could use another class using two or more classes to modularize classes to do only what they are supposed to do. But in some cases it's probably not that bad, especially in smaller projects like Teemu. Some classes could be broken into smaller ones, but it's not worth the trouble, because often some functionality is used in limited number of places. I've learned to avoid refactoring when weighing the benefits of better source code vs. time spent to fix some minor issue. Everything can be fixed later.

It's also useful to arrange files into small logical groups in the IDE using virtual folders (or filters as Visual Studio is calling them). This is more important in large projects, but it also keeps files in control in small-ish projects like Teemu.

Tuesday, 14 June 2016

Teemu news for 2016

After changing Teemu from SDL1.2 to 2.0 I've kind of abandoned it. The main reason is Kaduria, but somehow I also managed to mess up the source code of Teemu too much so now it's in state of minor chaos.

The problem areas in Teemu are message system and Level class. For some reason those two are difficult to get right for me. It's possible to copy some code from Kaduria's message system, but it's much bigger than Teemu's system and not that easy to use. I think it is also a bit different so it's not even possible to use it without changing messages calls.

The least I can do is go through Teemu's source code again and check out the problem areas, then try to figure out what to do with them. In game design I was first planning to change Teemu to become more a sandbox game without "story", but now I'm not so sure about it. I kind of like the adventure game style where you need to find key items to solve other things.

I would hate to leave Teemu in the current release state, because the new stuff I've made (and planning to do) is quite cool.