So I just had my first hackathon a few days ago! It was centered around mobile apps, and, boy, did I have a hard time!
I didn’t even get to finish my app! After implementing a native function, I couldn’t manage to link the libraries I wanted to and ended up wasting 3/4 of all the time of the hackathon.
Such a waste.
Hooray!
I’ve just recently been able to compile and run a basic text-only libRocket + SDL2 program on my system! This means I should be able to begin work on libRocket and SDL very soon. Perhaps I’ll be able to start on the game, who knows?…
Currently, I’ve been planning more about the development of Haven. Just creating the basic GUI seems to be a pain, and I’m looking for a fully developed solution to the GUI.
The answer seems to be libRocket.
As a newbie, I like the idea of “write once, run everywhere,” and libRocket seems to do what I want it to do. My only concern is how flexible the GUI can be, but if all goes well with the integration with SDL2, I’ll be able to fulfill all of my GUI needs and be free to develop the actual functionality of the game.
Therefore, most of my time over the next few weeks will be spent trying to integrate libRocket with SDL2, and then beginning work on the basic game engine.
I am also considering whether I should switch to Python since libRocket makes use of Python as its scripting language, but seeing as I’ve already used Lua, it makes me wonder whether I should even think of using Python. I’ll look into it anyways.
This is a picture of a prototype of Haven’s GUI system in alpha. This was taken the night after I implemented Lua.
It’s been awhile since I’ve updated this site, but I’m back. Though I’m pretty sure no one reads this, here’s the deal: I’ve made it a goal to finish Haven’s development no matter what, and things have been going along smoothly. I’ve been slowly progressing thanks to the work of people on Stack Overflow, and I’ve managed to create a basic GUI that can do these things:
I’ve rewritten the basics of this GUI system about four times now, and it actually takes a lot of work to make sure it is built smoothly. Much of the work goes into organizing your code and class structure to make it extensible and able to be used with other parts of systems. However, more code is now ready to be implemented. Once I finish up writing additional GUI elements, I should be able to put together a title screen. After that, much of the work will be creating another prototype of the battle and cut-scene systems, which is bound to take awhile. But, however, fear not! much of the actual planning of the gameplay is done.
Haven is now the name of the game that is in development. It is currently meant to be a 2D tile-based turn-based strategy game, similar in genre to Fire Emblem or Advanced Wars. However, I plan to release the game on PC and perhaps mobile platforms, and allow people to develop their own missions for the game through scripting and perhaps bundling their own resources in mission packs. Multiplayer is possibly an option, but will most likely not be for the sake of simply finishing the game. It may be included later in an expansion update or something of the sort.
Haven will also have a campaign of around 20 to 30 missions. Each mission will put you in charge of a host of programs and perhaps viruses to progress through the story, as well as through some boss battles.
The basic story is as follows:
It is the middle of the 21st century, and the world is booming. The computer industry continues to surge forward, and Haven Software Solutions is on the cutting edge of technology for information security. You are Drake Pauler, a young software analyst for Haven, and are one of the first people to be given the revolutionary, data-integrated virtual reality system by the name of HavenOS. After receiving a strange message from an anonymous persona called Cipher, you discover a strange, almost impossible piece of technology that will change the face of the Earth forever: Isa. Can you uncover the mysteries surrounding Isa and Haven and bring hidden secrets to light?
More story and development details coming later. Not promising soon.
extern type variablename;
It turns out that extern is a very interesting command that is often not taught in many tutorials when trying to link multiple C++ files and headers together to create one final executable. As I have finally started building my SFML framework for a GUI, I’ve been meaning to separate all my code into logical files such as “init.cpp” or “entity.h” in order to make everything neater.
But what if I want to use variables from another file? How does this work?
This is where “extern” comes in handy.
In SFML, there is such a thing as sf::Texture. This is just an object to hold an image, such as “button.png.” However, say I want to call one of these from an “init.cpp” in my main function in another file. This means I would have to define this specific sf::Texture object in my main file.
Say the sf::Texture has a name “name”:
extern sf::Texture name;
And that’s all it takes! Isn’t that amazing! Boom!
This is very helpful whenever you want to do such a thing.
I’ve finally managed to get a basic wxWidgets 3.0.0 program to compile! After fiddling around with the settings, I’ve managed to configure the compiler on Code::Blocks right in order to get the building process to work. After lots of webpage hopping, I’ve finally got the information I needed.
So let’s get down to business.
Using wxWidgets with Code::Blocks
wxWidgets’ actual useful components are located in two places: in the “\lib\gcc_dll\mswu\wx” and “\lib\gcc_dll” folders. Within the “\mswu\wx” folder are important headers (such as setup.h) that must be compiled, and within the “gcc_dll” folder is .A and .DLL files. .A files are statically linked libraries; .DLL files are dynamically linked libraries. I used the dynamic/shared version of wxWidgets, so I needed to set up it this way:
wxWidgets is extremely newbie-unfriendly. I’ve spent perhaps 10 hours and I STILL can’t get a regular window to open.
The problem is with its distribution method and its setup. Let’s do some overviews:
wxWidgets is often compared to Qt, another GUI library, and unlike Qt, wxWidgets is cleared to be used in any type of program, commercial or open-source. Qt, owned by Nokia, will result in me having to pay money for a commerical license. Despite Qt’s wider range of platforms (including non-smartphones and so on), I chose wxWidgets for its less-restrictive licensing terms. This means that if I decide to ever sell Asylum or develop commercially with my GUI, wxWidgets will give me no problems.
But wxWidgets has major problems with its documentation.
Unlike SFML, wxWidgets is left unbuilt. What does this mean? This means that you will most likely have to go into the Command Console on Windows and manually compile your library.
What? Yes. This means that you’ll have to compile wxWidgets like your Hello World program.
WHY?! I’ve been frustrated by the amount of options and ways you can compile wxWidgets. Thankfully, this has introduced me to important programming concepts,but learning these this way is hell.
First of all, I had to compile wxWidgets. At the time of this article, I am currently compiling wxWidgets for the THIRD time in an attempt to make it work:
http://wiki.wxwidgets.org/WxWidgets_Build_Configurations
HOLY SMOKES! I’M A NEWBIE, DON’T KILL ME! But after hours of research, I found out that there are several options:
And after 30-40 minutes, BOOM! wxWidgets is built! But wait! There’s more! Now I can freak out over the compiler and linker! I can’t compile my code without compiling with the right “-whatever” parameters and the right link directories! GAH! Nothing’s working!
Unfortunately, my chief problem is that I’m compiling with a “64-bit incompatible compiler.” This is complete BS, as I am using the TDM-GCC mingw64 compiler! I am using a 64-bit version! This is just ridiculous. No help for the weary.
So this is going to be my first post.
I’ve been trying to work with wxWidgets, but it’s just so hard.
Anyways:
THIS IS FOR BEGINNING PROGRAMMERS!
This blog is going to be about my journey into programming, and, hopefully, game development. My first major goal is to create a game called Asylum, a 2D turn-based strategy with a control scheme similar to Fire Emblem, but done very different in its execution. For starters, the game will be focused around virtual combat with agents and viruses, and will be situated around the Asylum Virtual Solutions Co., an anti-malware software development company. Through the game, the main character, Drake, will encounter Isa, a very special character, and will attempt to uncover the mystery surrendering Isa’s existence.
Well, that’s nice. NOW I HAVE TO ACTUALLY LEARN HOW TO PROGRAM!
First of all, I’ve decided to begin learning C++ as my language of choice. I’ve scrambled in the past with HTML and Java, but C++ is a very powerful and relevant programming language. Hence, I will be learning C++, no matter how hard it may be.
However, once we get past “Hello World!” I need a Graphical User Interface (GUI). I need to create windows, draw pictures, gather user input, etc.
But there’s no in-built GUI into C++, unlike Java, which as Swing.
Thus begins the search for a GUI!
Now, in most programming languages, libraries are basically add-ons of code. Libraries are like books of existing code that you can use in your own personal code in order to add extra functionality. Let’s take the standard library that comes with C++: often times, in the Hello World console program, you’re going to want to write a sentence or phrase to the console screen. But there is no basic function in C++ that allows you to do so! However, C++ comes with a standard library that comes with a function like this. Within the C++ standard library, there is a file called “iostream.h” or so that you can include into your program at the very beginning. The code looks like this:
#include <iostream>
Within <iostream> is the code that allows users to output to the console screen: cout. Other libraries, such as SDL, can do much more complex things. OpenGL is also a very popular graphics library.
I’ve looked into two separate third-party libraries: SFML, and wxWidgets. SFML stands for Simple Fast Multimedia Library, and it can handle everything from graphics to sound to user input and so on. The only problem is that it cannot create “actual” windows. Yes, this means that I won’t be able to have menu bars and scroll bars and other conveniences like the such. While I can draw circles and set background colors, SFML lacks the ability to create windows and frames that mimic Windows, Mac, and so on. This is a problem; even Paint has a “File” menu.
While SFML’s lack of a “native-window” kit to build “real” windows with is a downside, it’s not that big of a deal. This is because SFML is not meant to be an all-encompassing library. Instead, I am using wxWidgets to help encapsulate SFML so that I can use both at the same time–wxWidgets will allow me to make regular windows while SFML can handle graphics, events, etc.
The only problem is that wxWidgets is basically impossible to configure and implement.
Glasslight Studios 