First hackathon

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!

• Java + JNI is a pain to implement
• Web development seems all over the place with a million frameworks
• Java + JNI + C/C++ is REALLY not fun

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.

Notes for using TDM-GCC-64

• Use the “-m32” as a compiler and linker flags to compile on 32-bit PCs.

The problem with wxWidgets – pt. 2

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

• Done on Microsoft Windows 7 Professional
• Done with C++
• Done with the TDM64 bundle, GCC 4.8.1 compiler, found here. This compiler is a branch off of the regular MinGW compiler, similar to Cygwin and the third-party alternative to Windows compilers.
• Done with Code::Blocks version 13.12
• Created a specific project file, not just a .CPP file

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:

1. In Code::Blocks, the compiler settings are located under “Settings–Compiler…” However, just for your individual wxWidgets project, you’re going to want to go to “Project–Build options…”. Here, navigate to the third tab, labeled “Search Directories.” Three sub-tabs are present–navigate to “Compiler” and “Linker.”
2. Within “Compiler,” click the “Add” button, and add the “\mswu\wx” file path to the list. Because I store Code::Blocks and wxWidgets on a flash drive, mine is “G:\progr\wxWidgets-3.0.0\lib\gcc_dll_SUB\mswu\wx”.
3. For the “Linker” tab, include the “lib\gcc_dll” folder path. It is recommended, however, to change the name of the “gcc_dll” folder, as whenever you try to compile wxWidgets to get different version, the compiler will automatically create a folder called “gcc_dll” and input whatever files it creates in there. This is bad if your old library files are still in that folder. Thus, change the name. I changed mine to “gcc_dllSUB”.
4. Now, on the regular Code::Blocks window, go to “Settings–Compiler…” Navigate to the “Toolchain executables” tab. Make sure that your compiler is using the correct files to compile with. For me, I am using “x86_64-w64-mingw32-gcc.exe” as my C compiler and linker for both dynamic and static libraries. I am using “x86_64-w64-mingw32-g++.exe” for my C++ compiler. It is very important that you use g++ as your C++ compiler–I had a lot of errors because I was trying to compile my C++ program with a C compiler.
5. Go back to the main menu, and go to “Project–Build options…” Here, go to “Linker settings” and click the “Add” button under “Link libraries.” Make sure you select the .DLL files (if dynamically linking) under your personalized “gcc_dllWHATEVER” folder, especially “wxbase30u_gcc_custom.dll.” It will not normally show up–you’ll have to tune your file selector to filter “All files (*)” in order to see your DLLs.
6. Your projects should all compile!

The problem with wxWidgets – pt. 1

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:

1. wxWidgets can be built to work with Unicode or ANSI. Given Unicode is better for internationalization and language translations, I compiled with UNICODE=1.
2. wxWidgets can be built for a Debug or Release version. Given that I have no idea that I am doing and don’t know what debugging exactly is (at least the way they’re describing it), I chose to build wxWidgets as BUILD=release.
3. wxWidgets can be built as a static or dynamic library. Basically, do I want to bundle wxWidgets into my executable file and inflate my final file size, or do I want to include the code on the side so that I can link it up to my executable program when it needs it? Since the tutorial says to build wxWidgets as a “SHARED” file (dynamic), I chose to build wxWidgets as SHARED=1.
4. wxWidgets can be built into one file, or as a monolithic file. Doesn’t sound good–wxWidgets people often say that wxWidgets already bundles enough useless libraries into its all-encompassing #include “wx.h” file, so I decided to build without it monolithic. No idea what it mean, though.

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.

Getting past “Hello World” and into GUIs

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.