Search This Blog

Wednesday, January 15, 2020

Installing SDL 1.2.15

If you want to write programs using SDL you'll need to download it.  In this post I'll show you how to obtain and install the development libraries for SDL 1.2.15 for Visual Studio 2019.  (Note that version 1.2.15 of SDL is superseded by version 2.  I'll write a separate post for that version!)

Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D.

First we need to find and download the SDL library from their website.


On that page you'll find several different options - Source Code, Runtime, and Development.  You're looking for the Development one for "Win32 Visual C++".  (Note that I'm not linking directly to that download archive since the location or version may change.)

Once you've downloaded the package, extract it to a sensible location.  I like to have all my development work in one location.  In my case, I put everything into "C:\Dev" in appropriate folders.  In this screenshot you can see SDL-1.2.15 along with other libraries I've installed.  (The "Projects" folder is where I point Visual Studio towards to store all my projects.)


Go into the project properties and we'll begin to tell Visual Studio how to find SDL so that we can use it.
Use the wrench on the project head

Select Configuration Properties.  Ensure that Platform is set to x64 since we're using the 64-bit libraries.  Then select C++ Directories and set the Include and Library Directories to the location of the SDL include and lib folders that we extracted earlier.

In my case,

  • C:\Dev\SDL-1.2.15\include
  • C:\Dev\SDL-1.2.15\lib\x64

 If you select either "Include Directories" or "Library Directories" there will be a corresponding drop down context to the right.  From there you can "Edit" and use the ellipsis (...) to open a dialog that you use to locate the correct folder.

Include and Library Directories
Find and select the SDL include directory
Find and select the SDL lib directory

We now need to set the library dependencies.  Find Linker / Input in the properties and set Additional Dependencies to include SDL.lib.  Do not remove anything from the line; just add SDL.lib.

Set Additional Dependencies
Make sure you confirm all the updates and return back to the editor.  SDL 1.2.15 is now complete.

Once we have the project properties all set up we're ready to create a simple "Hello World" using SDL.  It may seem a waste of time to do (yet another) Hello World test, but when you're including external libraries it is really best that you make sure the tool chain won't break into pieces when you use them.  Hello World will make sure that you have a usable working environment.

We'll do that in the next post.  As always, please let me know how I can improve this post.

HelloWorld.cpp

In my last post I showed how I do basic project configuration.  It's time to do the standard "Hello World" and make sure things work.

Recall that in that post we created an empty "HelloWorld" project.

Empty HelloWorld Project
In the view above, you see what I call a "filter view".  This does not actually represent our files on disk but, rather, the types of files you have (source, headers, etc).  If we started adding source and header files now these would be dropped in among the various other files that Visual Studio uses to manage the entire solution.  That wouldn't be ideal at all for large projects so I want to set up folders that will contain my source and include files.  To do this I switch from the default filter view to the files view.  If you click that icon that looks like a stack of papers you'll switch to file view.

Stack of papers
Notice that the file view is empty.  We need to create two folders.  We might need more, but these two will allow us to start simple.  Right click the project "HelloWorld" and Add a New Folder named "src".  Repeat this for "include".


If you look in Windows Explorer and find your project, you'll see the new folders.  Inside each we will place any needed source or header files.  Neat and tidy.


Right click the "src" folder and Add a New Item.  Select C++ and click Add.  I kept the default "Source.cpp" filename since this is just a simple Hello World test.  Also note that the source file location is set to our "src" folder.


In our new C++ file we can enter the ubiquitous Hello World code!

 #include <iostream> 
int main(int argc, char* argv[]) 
{
std::cout << "Hello world!" << std::endl;
return 0;
}

(Blogger doesn't have a codeblock tool so that looks pretty ugly.)

Hit F5 (to run with debugging) or Cntl-F5 (to run without debugging).

The program will compile and link.  Output will be in the proper output directory.  All intermediate files will be in the Intermediate Directory.  Neat and clean.

If you get goofy errors, be sure to check that your platform settings are appropriate.  My empty projects seem to always start with the x86 platform by default.  Every so often I'll get an error (usually during linking) and realize that I forgot to set the platform.  This sort of thing would be rather loud if we were linking an x64 program against x86 libraries


Below you'll see that compile and link was successful and that we can run HelloWorld.exe successfully.



This is just a simple Hello World but I hope this is helpful to anyone just getting their feet wet with Visual Studio.  As always, I welcome constructive criticism.  It helps me learn and get better at this stuff.

Basic Project Configuration in Visual Studio 2019

As you might recall from a blog post a year or two ago, I like to ensure my projects in Visual Studio are set up in what I consider suitable and sensible ways.  I learned this from Yan Chernikov, a game programmer with EA, who runs a very well produced YouTube programming channel.

In this post I'm going to walk through the basic project configuration settings I set for all my projects.

First, you'll need to have a blank project created.

Create a new project

Create an empty C++ project

Name the project

A brave new world

Now, select the project name and click the "wrench" to get the project properties.


Under the General section of the Configuration Properties, set the following values:

  • Output Directory: $(SolutionDir)bin\$(Platform)\$(Configuration)\
  • Intermediate Directory: $(SolutionDir)bin\intermediates\$(Platform)\$(Configuration)\

Set directories
Hit Apply and then OK.  That's it!  Of course there are plenty of other things that we can configure, but these basic steps will ensure that any project we create will be stored and filed sensibly for any Configuration or Platform.

In future blog posts I'll cover how to set up SDL and other external libraries and even write some simple "Hello World" test programs.  Exciting, I know.  Stay tuned.

Upgrading VS2019

A couple of days after installing Visual Studio 2019, I was met with a pop up that indicated an available update was ready to install.


I clicked on that pop-up and was presented with the summary of what was being done.


I clicked on the Update button and watched as the patch was downloaded, extracted and then applied.  VS2019 was running in the background and, as noted in the summary, it closed automatically at some point.  No fuss or need for me to intervene.

Once the update was finished, Visual Studio reopened on its own.  Easy.

The upgrade was quick and painless.

Moving to Visual Studio 2019

I made the leap and downloaded Visual Studio 2019.  Installation was painless which is what I come to expect from Windows software installers these days.  I'll be making new posts related to VS2019 but posts about the older versions will remain for anyone who might need them.

Usual disclaimer: I am not a professional programmer.  What I do with my IDE is, in all likelyhood, not something big programming shops would do.  I try my best to incorporate good workflow but please don't flame me if I'm doing things against the grain.

I suppose that it's worth mentioning as well that my code is not "clean" and not C++14 (or even C++11).  I do dumb things and ask dumb questions.  But I've been happy with the results of many test programs, proofs of concepts, and so-called "tech demos" that I've written over the years.

One of the dumb things that I did was uninstalling VS2017 and VS2013 from my system.  I knew that a VS project could be converted automatically for use in newer versions of Visual Studio.  What I hadn't consider is that if there was a problem with the conversion process.

Luckily most of the affected projects were of the simple "Hello World" type.  A program to test function pointers, another to test some OpenGL stuff and one for SDL.  I had many of what I call my "WTF" programs where I was trying to sort out one thing or another.  Basically these were all throwaways and I did just that.

My biggest worry was having the project files for my game get destroyed.  This "game" is hardly finished and nowhere near the point that I can even claim it to be a game at all.  But I worked months on that thing, pouring over pages of notes for SDL while I attempted to get a dwarf to move sensibly in a grid-based game world.

It was safe and I breathed a sigh of relief.  My next posts will cover the most basic of basics in Visual Studio 2019 - updating it and getting Hello World working.

Friday, August 31, 2018

In-App Purchases

At one point, games on mobile devices were fun.  Addictive even.  Today, they are still addictive - depending on the game.  But my patience with the overuse of in-app purchases (IAP) has worn away.  If a game wishes to inundate me with ads and pleas for cash then I delete them.  Even if it's a game that I once loved to play.  I've no time for the nonsense anymore.

I absolutely support a developer's right to ask for payment for their work.  Free apps that have an IAP for purchasing the "full version" or to remove banner ads are alright by me.  But if your game is downright impossible to play without "boosts" and those "boosts" are also available as "permanent boosts" and you flood me under with downright pushy ads then go away.

And if selling my virtual farm goods to virtual vendors in the game subjects me to an ad that I'm required to watch for me to claim the coins I worked (virtually) to earn then I'm deleting your game.

Look, I'm an indie game developer.  I love to write games and I've got a long list of game ideas and works-in-progress.  I develop my games in Unity, Roblox, or just roll my own games using SDL and C++.  I understand that making games is work and that we enjoy getting some sort of payment for that work.  For me, I really like hearing from people who play my games and say, "That was a fun game!"  I appreciate the folks who send me a dollar here and a few more dollars there.  But I absolutely refuse to subject my players to pay walls or pay-2-win or cash grabbing tricks designed to suck money out of them.

Enough is enough!  Make games.  Make fun games.  Ask people to pay for them and even offer some incentive boosts for purchase.  But don't take your audience for granted.

You'll lose the confidence of the gamers you're trying to keep playing your games.

Sunday, March 18, 2018

The Programmer's Dilemma

It's been a long while since I did any coding in the Linux kernel.  I was never a contributor to the kernel.  I never pushed any patches.  I did, however, enjoy the simple changes I made to the code that I ran on my sandbox server.  This was way back around the 0.99 days.  These journeys into the Linux kernel were brought on mostly for "academic exercise" while brute-forcing through my operating systems class in college many years ago.  I was successful at building that kernel.  It loaded with the simple boot loader that I wrote in assembly language and C.  I put a notch on my keyboard and checked off two items on my nerdy bucket list.  I never got more involved in kernel programming beyond these initial steps.

As you might know from previous posts, I am not a professional programmer any longer.  That was many many years ago.  When I switched from programming to systems administration I found that, over the years, my programming skills began to fade.  At one point I was rather good at C and was growing more functionally competent with C++.  Occasionally I would sit back and wish that I had stayed with programming.

When I started getting back into programming I found that, although going back to basics wasn't entirely necessary, I needed a refresher in how certain things worked.  Pointers had become rusty and function references were now as foreign to me as the surface of Mars.  I took to task going over each and every page of the C++ Reference which served as an excellent catch up tool.

I then jumped head first into the waters of game engine design.  And drowned almost immediately.

I had forgotten Rule 1 of learning programming.  Stay in the shallows until you learn to swim.

As much as I wanted to write my pet project game engine I realized that I absolutely had to start smaller.  The years away from formal programming had taken their toll and I was no longer able to "think like a programmer".