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.
Friday, 23 September 2016
Wednesday, 14 September 2016
Updates
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.
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.
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.
Subscribe to:
Posts (Atom)