Topics

1

SFML projects / A-Maze Batz

« on: September 04, 2018, 08:44:20 pm »

A small casual game entry for the Game Maker's Toolkit Game Jam 2018.



Source code (Windows/Linux/Mac): GitHub
Precompiled (Windows): itch.io

You're helping Batz on his way through dark and deep caverns on the look for the one thing that really matters: Batsie. This must be true bat love in some way, although Batsie seems to leave our hero from time to time and he'll have to find her once again.

There's no real end: Once the last level has been beaten, the game will simply restart from the first one. You can even create your own levels and challenge your friends to find Batsie as fast as possible.

You can't really lose the game. There are no lives, there's no timer. Some kind of time attack mode was planned, but I was lacking time so far. In its current form, consider this a prototype and proof of concept.

Controls

The game controls are pretty straight forward:

• Cursor Keys and W/A/S/D: Steer Batz through the dark caves.
• Space: Use Batz's sonar to identify caverns, tunnels, and openings. Batsie will also answer your call, if she can hear you.

Compiling the Game from Source

If you're not running Windows, but still want to try the game (or you don't trust Windows executables  from strangers), you can download the full source code for the game  from GitHub and build it yourself. You'll need a working environment to compile and link C/C++ programs for this, including CMake and SFML.

This project originated in a game jam weekend in a total of less than 24 hours. This code isn't clean and it's clearly not built around best practices and optimization only. If you're curious, have a look, but always keep this in mind.

Modding and Level Editing

The game's levels are stored in a very simple and easy to edit way. Open the sub directory `assets/levels`, where you'll find one PNG image per level.

You can edit existing levels or create new ones, simply creating a new file following the existing numbering pattern. If the last level is `level5.png`, save your own level as `level6.png` to extend the game. There's no need to recompile or rebuild the game in order to test new levels.

There are a few tiny things to keep in mind here:

Your PNG file has to be saved as an 24-bit or 32-bit color PNG image. 8-bit PNGs are not supported.
Fully black parts (RGB: 0/0/0) are considered solid. You don't have to fill shapes. Even 1 pixel thin lines should count, although sonar pings might pass through thin diagonal lines.
Make sure that tunnels and choke points are at least 10-12 pixels wide.
Green pixels (RGB: 0/255/0) are potential starting positions. If there's more than one position available, the actual starting position will be picked at random.
Red pixels (RGB: 255/0/0) are potential goal positions, i.e. where Batsie may be found.
Blue pixels (RGB: 0/0/255) create random water drops that will be visible.

2

SFML development / sf::Font: Abstraction and Bitmap Fonts

« on: April 09, 2017, 01:40:20 pm »

With sf::Text and sf::Font SFML offers a clean and easy way to load True Type fonts and show some text on screen.

However, when you want to create some old school like pixel art game using bitmap fonts, you're quite lost.

Using True Type in such situations often looks out of place, even if you're trying to use a bitmap style font. Things never line up perfectly.

If you'd like to use a real bitmap font from a texture, you'll have to implement it yourself (or reuse some existing code).

SFML 3 gives us the opportunity to do something I've been trying to do for a long time: Splitting sf::Font to have a base class you can derive from. Since this changes the API and breaks existing code, it wouldn't have been that great to introduce it during 2.x.

Here's the basic idea:

• Rather than using sf::Font you pick either sf::TrueTypeFont, sf::BitmapFont, or any derived class you create on your own. The rename of the old sf::Font is important to avoid confusion and provide an easier to understand naming scheme.
  
• Therefore sf::Font is the new name of the abstract base class (similar to sf::Drawable).
  
• The behavior of sf::TrueTypeFont is 100% identical to the classic sf::Font.
  
• sf::BitmapFont utilizes image files rather than font files together with a simple mapping.

How would you use sf::BitmapFont?

The basic concept is identical to the True Type counterpart, with the minor exception of having to provide a mapping so SFML knows where to find the actual glyphs. This implementation doesn't require any special texture markers. The following interface is subject to change; feel free to suggest changes and improvements.

void sf::BitmapFont::loadFromFile(const sf::String &filename, const sf::String &mapping = "...", const sf::Size glyphSize = {0, 0}, const sf::Size glyphSpacing = {0, 0});
 

Parameters:

• filename: I'll leave this one for you to figure out. This can be any image format supported by sf::Texture.
  
• mapping: This is a string representing the characters the way they're aligned in the image. Columns aren't separated; rows are separated by line breaks.
  
  Note that this also allows you to map special glyphs or icons (like button images) to Unicode characters. You're also not forced to map every possible codepoint. Invalid ones would be skipped or replaced by the first one.
  
  The default value could look like this:
  

" !\"#$%&'()*+,-./01234567890:;<=>\n"
"?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^\n"
// ...

• glyphSize: This is the size of individual characters. The default value forces SFML to derive the dimensions based on the image size and character mapping.
  
• glyphSpacing: This is simply the distance between glyphs in the image (if any). Many premade or generated bitmap font textures come with no spacing or one line between rows and columns. This allows you to load these as well.
  

Are there any downsides or points not yet covered?

• Sure! One popular example would be proportional fonts (i.e. no fixed width). Should SFML support these? If so, how?
• We could make the abstraction generic enough so it becomes possible to also implement something like sf::VectorFont later on. Opinions?

Anything else to keep in mind?
Unfortunately there's no standard or most common image format for bitmap fonts, so there's no "TTF" to implement here.

3

Feature requests / Provide sf::to_string() overloads for SFML types?

« on: August 26, 2014, 09:44:48 pm »

Just some random thoughts whether something like that would be feasible to have in the default codebase - analog to C++11's std::to_string().

I'm using such overloads for debugging purposes with events right now and I think it might be quite trivial to implement, but still really nice to have out-of-the-box, without providing any overhead to other functionality.

The actual value returned would either just be some generic string identifying an object (like "sf::RenderWindow"), but there could also be some more information or even actual content (like "sf::Vector<float>(4.31f, 24.21f)", "sf::Event::MouseMoved(524, 132)", or "sf::Color(255, 127, 127, 255)").

4

SFML projects / Black Knight Blockade (Minigame)

« on: December 16, 2012, 09:57:39 pm »

So, finally something finished to show off.

I've initially created this for Ludum Dare 25. The topic has been "You are the Villain".



You are the feared Black Knight. You are in charge of a small passage in the dark wood and you decide who's allowed to pass: no one!

Unfortunately there are quite a few pesky peasants out trying to cross the bridge to do some of their daily bidding, something you shall not endorse.

Keep the peasants from crossing, but watch your rage, as you might get angry enough causing your head to explode in anger. You don't want your head explode, do you?

Every killed peasant will lower your anger, while every escaped peasant will raise your rage. If your rage exceeds your rage meter, you're going to explode and the game is lost. Use your attack key to restart the game.

Keyboard Controls:

Walk left: Cursor left, A
Walk right: Cursor right, D
Walk up: Cursor up, W
Walk down: Cursor down, S
Sword thrust: Space, Return

If you want, feel free to download the source code (GPL v3) and toy around with it. It should compile out of the box for Windows as well as Unix and similar systems. If you're able to compile SFML, you should be able to compile and run the game as well.

Update - 28.12.2012
- Water now slows down minions.
- It is now possible to hold down the attack key rather than smashing it.
- Some further tweaks.

Update - 01.01.2013
- Added a simple icon (for Windows binary).
- Some minor tweaks.
- Replaced the binary download with a release version (last release has been debug).

[Github Repository (primary)] [Google Code Repository][Windows Binary (updated)] [Source Code Snapshot][Ludum Dare 25 Entry Page]

5

Feature requests / Support for dialog popups (MessageBoxes)

« on: February 14, 2012, 02:19:11 pm »

This is something brought up here already and I really think this is something that should be included, given the fact it's rather hard to do it in a cross platform way by hand (if you don't want to resort on writing your own GUI render code or use third party libs for this). After all it's something that can be very useful for any multimedia application or game (even if it's just to tell the user that something went wrong).

Essentially, I'd like to see some simple interface that works similar to Windows API's MessageBox().

The signature would be something like this (parameters could be bitmasks or some object, too):

Code: [Select]

sf::DialogResult sf::Window::ShowDialog(const sf::String &text, sf::String &caption, const sf::DialogIcon icon = IconNone, const sf::DialogButtons buttons = ButtonsOk) const;

Code: [Select]

sf::DialogResult sf::Window::ShowDialog(const sf::String &text, sf::String &caption, const unsigned int flags = 0) const;

Code: [Select]

sf::DialogResult sf::Window::ShowDialog(const sf::String &text, sf::String &caption, const sf::DialogStyle &style = sf::DialogStyle()) const;
It's a member function, so the window can act as its parent, but some static version with an optional window parameter might be interesting, too.

I could as well think of dialogs with more elaborate dialog choices (compareable to those found in Windows Vista, Windows 7 or (I think) Unity), but at least the basics would be very neat.

Right now I use defines to redirect my error messages to console or MessageBox(), but some ready to be used function or class (might be overkill) would definitely be better.

I could provide a barebone implementation ready to be used for Windows, but unfortunately I'm far too unexperienced in X Windows, etc., to do the same for the other platforms.

6

Feature requests / Direct access to window focus

« on: December 30, 2011, 12:16:10 pm »

This is something I noticed lately. There doesn't seem to be any direct way to determine if some window is the active window or not (i.e. if it's focused) yet. This is partially exposed through SFML's event handling, but I really think this should be added as sf::Window members:

Code: [Select]

bool sf::Window::HasFocus(void);
void sf::Window::GetFocus(void);
While above might suggest something different, I agree, windows shouldn't bring themself on top on their own at an time, but that's actually something that should be handled by the OS anyway. I.e. under Windows the second call listed above should trigger the task bar entry of the window to be highlighted and/or flashing. In a similar way on Ubuntu the icon would shake (if I'm not mistaken), etc. without stealing focus of the active window (unless you just started the program).