It’s about to get dark
Lint Roller? I Barely Know Her

ellievsbear
wallacepolsom

@theartofmadeline

★
styofa doing anything
Today's Document

No title available
TVSTRANGERTHINGS
Keni
Claire Keane
Misplaced Lens Cap

PR's Tumblrdome
No title available
ojovivo

Andulka
tumblr dot com
h
2025 on Tumblr: Trends That Defined the Year
AnasAbdin
seen from United States
seen from Türkiye
seen from United States

seen from United Kingdom
seen from Türkiye
seen from United States

seen from Germany
seen from Malaysia
seen from United States
seen from United States

seen from Netherlands
seen from Croatia
seen from United States

seen from Finland
seen from United States
seen from United States
seen from United States

seen from Mexico

seen from Indonesia
seen from Malaysia
@ordernexusdev
It’s about to get dark
Did you write Mastering SFML Game Development? I bought the book, downloaded the code, but I have no idea how to put all those files in a project so I can run the example code. Doesn't say anywhere in the book how to do that, help?
Yes, I did. The shared code in each chapter can either simply be copied into the same directory as the chapter code itself, or be compiled as a separate library, provided it’s linked and included correctly. Since the “Mastering” title is more advanced, it leaves the exact implementation details up to the reader. That’s why the code is structured in such a way.
When you make a stress-test that’s ugly as sin...
Making a 2D RPG project look snazzy with bump, specular, and shadow mapping techniques for my next book. It will be out this January!
P.S. I know the tiles look a little bit “tiled”. Crazybump doesn’t handle tile-sheets too well, and ‘aint nobody got time to draw each map by hand.
Using particles to create fall!
Up all night.
When you have to abstract tightly coupled code...
My book, a.k.a. why I have gone AWOL
Good day/night, Tumblr. Oh my, aren’t you all different now? You were about THIS tall when I last saw you! You’re just growing all the time, ya’ little slugger!
For the better part of the last year, I’ve been completely off the face of this site for two reasons. One of them involves me moving to a different country, but let’s face it, nobody wants to hear about that. The other reason why I went missing for what seems like decades in internet time was me writing a book. Last November I was contacted by a representative of Packt publishing, who kindly offered me a chance to write a “by example” publication about the SFML library, called “SFML Game Development By Example”. The result is this:
https://www.packtpub.com/game-development/sfml-game-development-example
This is the primary reason why I haven’t been posting anything. Gladly, I’m able to say that the book is done now. Three games are built throughout the course of it, all varying in complexity. It covers in detail subjects like building an entity component system, a GUI system, sound and networking. By the end of the book, you are actually left with a functional 2D multiplayer RPG that can be used as a jumping off point for any game you want to build! It will most likely come out sometime in early-December, however it could be released in late-November as well. The good news is that it can be pre-ordered now as either an e-book or a paperback. The latter version includes the e-book as well.
Hopefully I will be able to maintain my presence here a little better now, and there should be some exciting things coming soon! If you have been intrigued by my book, check it out and consider buying it! Take care, Tumblr.
cool blog! I am looking into learning about game design. And am currently overhauling my blog.
Why thank you! Glad to know you're enjoying it.
Entity Component System part #1 (bitmask)
At the moment of writing this post, I haven't yet finished implementing sub-systems for components, even though everything else is more or less done. Since I'm still in the middle of developing it, I've decided to hold off with the other parts I wasn't yet fully sure about and start with what is already firmly in place and is the least likely to change. This is going to be a very quick update post about my method of choice for identifying and managing types of components quickly, as well as specifying requirements for sub-systems without mountains of if/else statements. The bitmask.
You might be wondering why it's beneficial to use something like that instead of a traditional way of checking with many conditionals. Well, for one, all of the information about what components an Entity has and what components a sub-system requires an Entity to have is stored in a single variable. Checking if an Entity should belong to a specific system is as easy as calling a compare method of the entity bitmask and passing in the systems requirement bitmask along with a mask for the bits we're interested in(later referred to as relevant bits). This is much more elegant, not to mention the fact that bitwise operations are cheap to perform. An ugly alternative would be making calls to some sort of method, provided by either the entity class itself or some kind of Entity/Component manager class, to check if it holds a specific type of component. Depending on the implementation and the data structure used, such method might need to iterate over tons of other components just to check if one of the desired type exists. For fairly small systems it might be an okay solution, but it does not scale well.
Before taking a look at the code, it's fair to mention that I've currently limited the number of possible components to 32. This method is expandable fairly easily though, so it shouldn't be a problem in case 32 max components don't cut it anymore. Let's take a look at the base component class first to get a better picture:
typedef unsigned char ComponentType; class BaseComponent{ public: BaseComponent(const ComponentType& lType) : Type(lType){} virtual ~BaseComponent() = 0; const ComponentType& GetType()const{ return this->Type; } protected: const ComponentType Type; };
Note that I haven't yet started working on actual components, so this may change. The basic idea will remain the same though. Each component type will have a specific ID (ex. Position is 0, Velocity is 1 etc.). Only 5 bits are needed to represent a value 0-31. The closest thing to that is an unsigned char, which has a whole byte to play with, so I've chosen it to represent the component ID. Should there ever be a need to expand the number of components, the same type can still be used to represent anything from 0 to 255 thanks to the unused 3 bits.
With that covered, here's the bitmask implementation:
#include <stdint.h> typedef int32_t BitmaskType; struct Bitmask{ Bitmask():bits(0){} Bitmask(BitmaskType bitmask):bits(bitmask){} BitmaskType GetBitmask() const{ return bits; } bool Compare(const Bitmask& Bitmask1, const BitmaskType& RelevantBits = 0) const{ return(RelevantBits ? ((Bitmask1.GetBitmask() & RelevantBits) == (this->bits & RelevantBits)) : (Bitmask1.GetBitmask() == this->bits)); } bool GetBit(const unsigned int& n) const{ return bits&(1 << n); } void TurnOnBit(const unsigned int& n){ bits |= 1 << n; } void TurnOnBits(const BitmaskType& bitmask){ bits |= bitmask; } void ClearBit(const unsigned int& n){ bits &= ~(1 << n); } void ToggleBit(const unsigned int& n){ bits ^= 1 << n; } void ZeroOut(){ bits = 0; } private: BitmaskType bits; };
It's fairly basic, so I won't elaborate much. Essentially, it just treats a certain variable as a set of bits. In this case, the number of bits is explicitly specified in its name int32_t, supplied amongst many others, thanks to the stdint.h header. Should there ever be a need to expand the number of components, all that's necessary is changing the typedef line to refer to a data type that has more memory. Everything else here is simple binary arithmetic. For more information, see this article:
http://www.cprogramming.com/tutorial/bitwise_operators.html
Not dead!
For the past few days I've been working on a complete re-write/re-design of the entity component system, since the previous implementation was such a joke. At some point in time I heard that programmers do most of their development away from the computer screen, hence the cursive bits. The image above just barely represents what it's supposed to, but it looks kind of cool, so I decided to throw it in here. I do plan on writing a series of posts very soon to break down the more efficient version of ECS, so stay tuned for that.
While I'm at it, I'll plug some books and other resources that I found useful lately, which are both fully and vaguely related to what I'm working on:
http://www.cppstdlib.com/
The C++ Standard Library by Nicolai M. Josuttis is a great book for referencing the standard library. Usually I refer to http://www.cplusplus.com but if it just so happens that you're isolated from your internet connection for whatever reason (which happened to me), this book is the next best thing to look at.
Effective C++ by Scott Meyers is another great book that talks about a lot of ways to optimize your code, avoiding bad design decisions etc.
Other random resources:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
http://www.cs.wustl.edu/~schmidt/PDF/stl4.pdf
http://www.sourcepole.ch/sources/programming/cpp/cppqref.html
Hey gamedevs!
What’s everyone working on right now? How are your current game or projects going?
Finally fixing up my messy first time implementation of an entity component system. More info on that is coming fairly soon. Also playing around with streaming SIMD instructions. Fairly exciting stuff, albeit difficult to properly show off here, but I’ll give it a shot later.
Nice! If you do end up posting it on your blog I would be interested in checking it out. Are you coding it in C++?
All of it is written in C++ so far. I’m seeing some assembly in the future, as well as LUA. Former is coming sooner than latter. I’m glad you’d be interested to read about it! Stay tuned :)
Hey gamedevs!
What's everyone working on right now? How are your current game or projects going?
Finally fixing up my messy first time implementation of an entity component system. More info on that is coming fairly soon. Also playing around with streaming SIMD instructions. Fairly exciting stuff, albeit difficult to properly show off here, but I'll give it a shot later.
50 FOLLOWERS!
It's been a while, but I finally have 50 followers!
I'd like to say thank you to all 49 of you that I know the names of and that 1 mystery anonymous person for following.
Spritesheet source: here
Like/reblog if you see yourself! :)
SFML tile flipping & rotation pt2.
At the end of the first part of "SFML tile flipping & rotation" we left off with this:
SFML tile manipulation:
By messing around with some funky calls to the SFML methods, one can gather some quite useful information. Case in point, the setScale() and setRotation() methods. These will be the main two methods we'll use for transforming our sprites. The rotation is obvious, but how is scaling sprites going to help us? Well, as it turns out, you can flip a sprite if you scale by negative values. Scaling by -1 in either axis flips the image along that axis. Neatto! In a very early post on this blog, I've drawn out a Lookup Table to figure out the different possible states of a sprite and the resulting states after manipulation:
For now just ignore the top table, that's irrelevant for this subject. There are 8 possible tile states, as I've crudely illustrated. Normal, Flipped Horizontally, Flipped Vertically, Rotated by 90 degrees, Rotated by 90 degrees and Flipped Horizontally, Rotated by 90 degrees and Flipped Vertically, Rotated by 180 degrees & Rotated by 270 degrees. The left side is the current state a tile is in, the top side is the manipulation being applied to it, which results in a new tile state. This is what the actual L.U.T. looks like in code:
The first dimension, again, is the current state, and the second dimension is the manipulation being applied. Before we can flip the sprite, we need some helper methods to give us the proper scale and rotation values for each of these states:
As I previously stated, negative scale values flip the sprite, and rotation is self explanatory.
How does all of this come together? Well, you will want to store the orientation enumeration variable with each tile somehow. During the render process, a call will have to be made to the sprite setScale() and setRotation() methods to pass in the appropriate data based on the current tile orientation. While flipping the structure, you will want to change the tile orientation as well by utilizing the orientation lookup table as such:
newOrient = Math::orientTable[repRef.orient][Math::Orientation::ROTATED_90];
where the first index is the current orientation and the second one is the manipulation. In this case, this was taken from the structure rotation method, so the manipulation is ROTATED_90. With the orientation also being changed, we should finally have the result we expected:
SFML tile flipping & rotation pt1.
A few posts ago I promised I'd explain the tile flipping and rotation. I've decided to split this in two parts for the sake of clarity and sparing a poor soul from coming across a monstrous wall of text on their dashboard.
Structural flipping and rotation:
Now this isn't the case for my project, but for the sake of argument let's assume we're dealing with a simple 2D array that we want to rotate and flip. The first index is the X coordinate and the second is the Y. Let's rotate this sucka:
void Rotate(bool CW){ // Allocate a new array here. for(int i = 0; i < height; ++i){ for(int j = 0; j < width; ++j){ if(CW){ return[i][j] = contents[width - j - 1][i]; } else { return[i][j] = contents[j][height - i - 1]; } } } // Delete the old array memory here. // Set the old array pointer to point to the new array. }
As you can see, it's fairly simple. The width of the array becomes the height and vice versa. This method takes a single boolean argument that signifies the desired rotation. I've desired to skip all the allocation and de-allocation stuff, since that's as easy as calling new and delete a few times. Let's take a look at the array flipping:
void FlipHorizontal(){ for(int i = 0; i < height; ++i){ index = 0; for(int j = width - 1; j >= 0; ++j){ return[index][i] = contents[j][i]; } ++index; } } void FlipVertical(){ for(int i = 0; i < width; ++i){ index = 0; for(int j = height - 1; j >= 0; ++j){ return[i][index] = contents[i][j]; } ++index; } }
The dimensions remain the same this time, so no re-allocation is needed. We have to count backwards on a selected axis and keep track of a separate index value for the return array.
At this point, the result should look something like this:
The array is obviously being rotated and flipped. For ground tiles that would be fine, but this particular selection requires adjusting the orientation of the tiles as well, to maintain coherency, which will be covered in part 2.
Basic textbox implemented.
Since this blog is mainly game development oriented, I've decided to shift my focus from the map editor for a while and implement something a little bit flashier on the game side, yet still fairly minimalistic for now. What kind of an R.P.G. doesn't have this style of a textbox?
It's still not perfect, like most things that just came into existence, however I did bang out the basic idea behind text wrapping and letter-by-letter printing. Something that could be improved is it not slicing words in half, as well as looking much better than this, but it's a start. The font used in the textbox: http://www.fontspace.com/style-7/half-bold-pixel-7
Now stop surfing Tumblr and get back to working on your project!