Monthly Archives: April 2012

Building for Windows!

Download the Windows Version!

It took me a while to get there, but I’ve finally gotten a Windows build of the Weirdo in a Weird Land bootstrap project!

My first attempt at building one involved grabbing Visual Studio 10 Express but it really wasn’t meant to be used from the command line… at least not easily…

The successful strategy was to use the Minimalist GNU for Windows toolchain.  This lead to some heartache which began with linker issues… but working with the SDL FAQ, I got things mostly working.  Of all the problems, the most surprising to me was the fact that including libraries in gcc is significant.  Specifically… the following did not work:

$(CC) -o $(BUILDDIR)/$(EXETARGET) $(BUILDDIR)/main.o \
    $(BUILDDIR)/Level.o $(BUILDDIR)/SDLAppMain.o \
    -L$(SDLDIR)/lib -L$(SDLIMAGEDIR)/lib/$(ARCH) \
    -lSDLmain -lSDL -lSDL_image -lmingw32 -mwindows

but THIS did!

$(CC) -o $(BUILDDIR)/$(EXETARGET) $(BUILDDIR)/main.o \
    $(BUILDDIR)/Level.o $(BUILDDIR)/SDLAppMain.o \
    -L$(SDLDIR)/lib -L$(SDLIMAGEDIR)/lib/$(ARCH) \
    -lmingw32 -lSDLmain -lSDL -lSDL_image -mwindows

The significant part here is the -lmingw32 being first.  Without that, I got the following linker issue…

Undefined reference to 'WinMain@16'

Which is discussed in the FAQ… but the answer did not point out that the ordering of the libraries was significant!

Now i just need to create a proper Makefile that will switch easily between the two architectures…. then it’s time to actually write the game!

UPDATE: The original zip that I uploaded seemed to be missing a few necessary files… specifically two DLLs: libgcc_s_dw2-1.dll and libstdc++-6.dll both of which are now part of the distribution.

Weirdo in a Weird Land

Weirdo in a Weird Land is the working title for the slowly progressing game.

It took a while to actually get the application bundle squared away.

Click Image to Download v0.0.1!

One of the more irritating parts of creating the bundle was referencing the image resources.  Mac Applications are supposed to keep their data in a Contents/Resources but using the provided SDLMain, your application’s working directory is the PARENT of the resource bundle… so you’d have to make the assumption that the end user didn’t rename the application bundle on you and build your path including what you think your resource bundle is named.

I modified the SDLMain a little bit, putting the working directory at the top level of the Application Bundle.  This allows me to reference my image files as: Contents/Resources/Images/ which is still a little ugly, but probably more reliable.  The “correct” thing to do would be to have SDLMain expose a method which allows me to retrieve the path of individual resources.  That’s probably a much later change though.

My most recent efforts are to get a Windows build going.  I’d like to do the up front work to make this game cross platform.  This way, I can release builds for both Mac and PC/Win32 relatively easily in the future.  My first attempt at creating a Win32 build was using Visual Studio 2010 Express, but I ran into a lot of strange linking issues.  The compilation process was tough too.  cl.exe command line compiler had radically different invocations than gcc… so it’s unlikely that I’d be able to reuse the same Makefile. There has to be an easier way to build a windows app than this…

The SDL Tutorial suggests using mingw32 which is a minimalist windows toolchain built on top of all GNU tools.  This means that I *SHOULD* be able to reuse my Makefile and if it’s part of the tutorial… I shouldn’t run into weird issues.  We’ll see how that pans out.  Hopefully by Thursday I’ll have a slightly expanded build that runs on both Windows and OSX!

SDL side scroller takes shape

 In my previous post on SDL, I talked a little bit about layering bitmaps to create a simple side scroller.

Here, I’ve actually gotten bitmap layering to work.  I’ve used the rough bitmaps that I drew for the last blog post and built some code around it.   I haven’t gotten to the point where I can built a distributable binary yet, but I’m hoping that it won’t be too tough.  I’m hoping to NOT have to involve xcode… but all literature I’ve found on building apple distributables seem to center around that tool.

Here’s a screenshot of the resulting app.  Doesn’t look very different from my mockup… but that’s probably a good thing.

The way this ended up being implemented was through a Level class.  The Level class has an array of Layers and a current position (x axis).  Each layer has a coefficient that describes its motion relative to the Level’s x position. Foreground objects have a coefficient of > 1 and objects further in the background have coefficients less than one.

Each Layer has an array of LayerObjects. Each LayerObject which includes a bitmap and a coordinate. They’re arranged in the Array in increasing order of x.

I captured the SDLK_LEFT and SDLK_RIGHT key events.  When SDLK_RIGHT is pushed, I’d increment the level’s x position until the key was released.  Similarly for the SDLK_LEFT button except the position is decremented.





Chaining Demultiplexers

Before, I controlled 6 LEDs with 3 pins.  This fit very neatly onto a single 3-8 Demultiplexer.  For me to achieve my goals of world domination, I need to be able to chain them.

What exactly do I mean by chaining?  Well, by themselves, a 3-8 demultiplexer can control 8 things with 3 control pins.  It follows, that to control 16 things, we need 2 demultiplexers and 6 control pins.  Well, by chaining, you can control 16 things with just 4 pins!  Well, how does this work?

Well, you take the regular 3 control pins and connect them to BOTH multiplexer input pins. The 4th “input” pin actually just switches between which demultiplexer we’re using.  So it connects to the “G1″ of the second and one of the G2s on the first.

I couldn’t really do this before because I lacked the space on my previous little breadboard.  In case you hadn’t noticed… I’ve upgraded!