SFML 2.5.0 Update (Or how I learned to hate RenderTextures)

 

 

On May 6th, the C++ Simple and Fast Media Library (or SFML for short) was updated to stable version 2.5.0, adding various updates including more optimial iOS support, bug fixes, added functionality for Text and Audio and various optimizations. For such a big release, it made sense to upgrade and get my Vigilante Game Framework updated, and why not update Gemstone Keeper while I’m at it?

Well it took nearly a month, but I did manage it in the end. Gemstone Keeper 1.0.5 has been uploaded to Steam, both for Windows and Linux!

As the title suggest, a lot of the work had to do with the updates to the sf::RenderTexture object. However, I don’t absolutely hate them, they are extremely useful for rendering a scene to an area of the screen, or to apply post-processing effects to. However the problem lied in how I was using them, and how the fixes done in the latest update effectively broke my engine’s rendering system.

The initial update showed promise, as my most recent game worked fine, but moving onto the framework’s examples and Gemstone Keeper showed that a lot of things weren’t rendering at all.

Vigilante Framework currently renders 3D models using Modern OpenGL, and while it was working fine with SFML 2.4.2, it rendered nothing with SFML 2.5.0. The solution was embarrassingly simple despite the amount of effort put into fixing it, including implementing my own version of SFML’s glCheck function and re-writing SFML’s own OpenGL example to run with modern OpenGL. When rendering the 3D scene, I modified some of the OpenGL states, which wouldn’t be an issue before but now those OpenGL states carry over into other contexts. The solution was to simply make sure that the GL states were reset BEFORE rendering the scene using a sprite object.

 ///Render 3D scene and apply to a sprite.
 RenderTarget.resetGLStates(); //Reset the GL states to the default for SFML
 Sprite->Draw(RenderTarget); //Render the sprite.

Gemstone Keeper however uses legacy OpenGL, and while I could have updated the VFrame source code but that could take more time to fix. Regardless, I was able to get it working by rearranging other objects that define sf::RenderTexture, including the bloom post processing effect and the help popup terminal.

Gemstone Keeper’s other graphics were another story. The approached I had been using up to this point was to render text objects onto a single rendertexture, and then store the generated texture to be used as a sprite, particle or tilemap. While this was okay for the time, but it is rather inefficient and bad for graphical memory.

I wanted to do a single-texture approach, where all the graphics are rendered onto a single texture, and a rectangle area is specified when creating renderable objects, for a while but I kept putting it off. SFML’s update, causing any newly created render textures to dereference generated textures, it was time to take this approach on. The best part is that most of the work was already done by myself with the additional code of Jukka Jylänki’s MaxRectBinPacker algorithm, all that needed doing was to change how I defined renderables from setting the texture to whatever the name of the genrated texture is to the name of one texture sheet, and to get the correct rectangle from a map/dictionary, searching by string ID.

CaptureCaptureCapture

Now this doesn’t mean the entire game’s visuals are rendered from one texture. Including the 3D gemstones, any assets that use a repeated texture grabs a subsection of the main texture as a copy, same applies to the VBackdrop as well. Getting the icon was a more painful looking process of converting the entire texture sheet to an sf::Image, so I can load in a subsection to a new sf::Texture object, and then convert the new texture object to an sf::Image in order to set it to be the application icon.

sf::IntRect iconArea = TextureData::p()->GetTextureRect(TextureData::p()->GetPortalTextureName(true));
 sf::Image image = VGlobal::p()->Content->LoadTexture("TextureSheet").copyToImage();
 sf::Texture tex;
 tex.loadFromImage(image, iconArea);
 VGlobal::p()->App->setIcon(iconArea.width, iconArea.height, tex.copyToImage().getPixelsPtr());

Like I said, not pretty.

So enjoy Gemstone Keeper, the number of you who own it. Now back to doing more stuff in C++…

Advertisements

New Years Resolutions

Good evening everyone! It’s no doubt that 2017 has been a hell of a year following what happened in 2016, but we fought through and we are still here fighting! This year has also been huge in terms of game development for me. I managed to finish SEVEN games this year, six from game jams such as #RemakeJam, PROCJam, Jamchester and Three Ludum Dares!

https://img.itch.zone/aW1hZ2UvMTYzMjc3Lzc1MjE2Ni5naWY=/315x250%23c/L0i8g2.gif  https://img.itch.zone/aW1hZ2UvMjAxMDM1LzkzOTE3OC5naWY=/315x250%23c/q5QpUK.gif

The seventh game was the nearly two year project Gemstone Keeper, which made an initial release on March 31st earlier this year and has since had numerous updates, although grouped together as four updates. The most recent of which was 1.0.4 that was announced on 21st of December. The game is currently on part of the Steam Winter Sale, and is currently 50% off!

Gemstone Keeper also had a second smaller release as it was ported to Linux, the build being available on Steam in June. I documented the progress to port the game in three blog posts (part 1, part 2 and part 3), and got a small amount of coverage from dedicated linux gaming websites as a result.

There was also an accomplishment in travel as well, 2017 was the year I went to both GDC in San Francisco and Develop in Brighton for the first time! Both events were great opportunities to meet up and socialise with fellow game developers and listen to talks from great minds such as Ken Perlin, John and Brenda Romero, Jordan Mechnar and Tim Sweeny.

As for 2018, I want to set some goals. As with many New Years Resolutions, chances are they will be forgotten and unaccomplished, but considering I managed to lose weight this year, I might pull through with a bit of committment.

First one is that I want to take part in at least one game jam a month, meaning I’d be finishing 12 games next year. I like the challenge and creativity from game jams, but this year I feel like six isn’t enough. At least spacing out the game jams to one a month will give me time to find a weekend or so to get my head down and finish something.

Second one is to get a game on console. It’s not like I haven’t bothered trying before (I’ve reached out to Nintendo about developing Gemstone Keeper for the Switch to no avail), but it would be nice to expand my work beyond desktop PCs and web development. Porting my own game to Linux should show how when I put my mind to it, building a game to another platform by hand is possible, and it would be great to show I can do that on one of the three main systems.

Thanks for reading and have a happy new year everyone!

Managing Content and the Joys of Smart Pointers

Hello everyone, I figured I’d write a post about something I’ve been working on for the last week or so, partly as a bit of advice for some budding programmer wanting to write a bit more low level games programming stuff, but also to try and explain why it has been several weeks since I last posted about a small prototype I’ve been working on, and why I have been posting less stuff on Twitter than usual.

To put it basically, a lot of C++ work, mostly involving Gemstone Keeper. I decided to go back to it one more time after a lot of bugs and feedback came in. By the time I’ve posted this, Gemstone Keeper has been updated to version 1.0.3, which includes bug fixes, UI updates and two new enemy types.

j7fcaz6

 

While most of this wasn’t planned (most of this would have happened much earlier if I was notified on Steam within days of it being reported), but it had been on mind for a particular reason.

To put it simply, I have been updating my C++ game framework, the Vigilante Game Framework. This is the framework that I had built up alongside the game it was made for, Gemstone Keeper, before open-sourcing it in the hopes that it could be improved for more projects. I noticed a problem with the content management system, and as such I had spent the last two weeks researching and implementing a new way that would make it more optimal while keeping it stable. Because of this, Gemstone Keeper will soon be updated with this improvement among other bug fixes, and any future games using the VFramework will feature this too.

dytc50n


Here is the original code for loading and setting an sf::Texture in my content system, according to the repository for Gemstone Keeper this was initally written around Feburary 2016, and aside from one change in April this remained how it was:

bool VContent::LoadTexture(const sf::String& name, sf::Texture &texture)
{
   if (FindTexture(name))
   {
      texture = textureDir[name];
      return true;
   }
   else
   {
      if (texture.loadFromFile(name))
      {
         VLog("%s loaded", name.toAnsiString().c_str());
         textureDir.insert(textureDir.begin(), std::pair<sf::String, sf::Texture>(name, texture));
         return true;
      }
   }

   VLog("Error loading texture: %s", name.toAnsiString().c_str());
   return false;
}

The approach should be fairly straightforward:

  • If a texture exists, set it to the texture object and return true.
  • If it doesn’t exist, load it using the texture object. Return true if load is successful.
  • If it cannot load, return false.

However there is one problem, setting the texture object doesn’t set the reference, despite passing the object in as a reference (hence the &). Instead it creates a copy, with a new texture ID and references.

Performance wise, this doesn’t have much of an issue, however memory wise there could be a concern with creating several sprites with the intention of using the same texture, but it isn’t. The intent of a content manager is to load, unload and store a single instance of an asset, with any objects merely referencing that content. I investigated a number of approaches (and spoke with eXpl0it3r of the SFML team) to find the right one.

The approach I finally went with required the following changes:

  • The load function should return the object itself as a non-pointer reference, not a bool. This is to ensure that if the loading or finding process goes wrong, the program should let you know and fail. The reason for a non-pointer is to ensure you wouldn’t return a NULL object. Returning a reference makes sure not to return a newly created copy.
  • If it cannot be loaded, an exception should be thrown. Exception handling is an ideal alternative to responding to function returning false, because it’ll make a function closing on failure much easier.
  • The texture should be stored as a unique pointer.

The reason for a unique pointer, instead of a regular or “raw” pointer, is to ensure that the object only has one true owner, and that once it’s dereferenced (either by closing the game or unloading it) it’ll be properly destroyed and unable to be used by other objects, all with little to no difference in performance. While a unique pointer cannot have more than one reference, the raw pointer can still be obtained and used, just make sure that once the content is unloaded there aren’t any active objects still referencing it.

This is what the texture loading function looks like now (from the Github Repository):

sf::Texture& VContent::LoadTexture(const sf::String& name)
{
   auto found = textureDir.find(name);
   if (found == textureDir.end())
   {
      std::unique_ptr<sf::Texture> texture = std::unique_ptr<sf::Texture>(new sf::Texture());
      if (texture->loadFromFile(name))
      {
         VBase::VLog("%s loaded", name.toAnsiString().c_str());
         textureDir[name] = std::move(texture);
      }
      else
      {
 #ifndef __linux__
         throw std::exception(("Error loading texture: " + name.toAnsiString()).c_str());
 #else
         throw ("Error loading texture: " + name.toAnsiString());
 #endif
      }
   }

   return *textureDir[name];
}

To use the functions in this format, I had to change a lot of objects around the game. Textures, Images, Fonts and SoundBuffers all changed to use raw pointers, and the returned values from the functions are converted to functions as well.

texture = &VGlobal::p()->Content->LoadTexture(filename);
sprite.setTexture(*texture);

This ensured that the object being set is has the same reference as the object being returned, no more copying data, no more instantiating new objects to handle the copy.

I’ve also turned a lot of other objects into unique pointers, particularly the objects in VGlobal, which is intended to only have one instance of. It’s ideal since these ones are all destroyed at the end, and in a scenario where an object could be replaced with another one, the unique pointer can destroy the old one in order to replace the new one.

Other small changes I’ve made to update the framework includes all objects that load textures now having an optional area rectangle. This was mainly put in if multiple sprites use the same texture, but different atlases. Best example would be in the LoadGraphic and setSize functions of VSprite, where the default parameter will ensure the whole texture is used, else the animation system will restrict the render area of the sprite to that rectangle. While sf::Texture does have the ability to load a rectangle area of a texture to an object, I feel like this only adds a separate texture, instead of the one loaded and taken from VContent. At some point I’d like to use this more for Gemstone Keeper and other games, as I see reducing the texture count and having more render calls using the same texture would have additional benefits, no matter how small.

Hopefully more changes like these will benefit games I make with this framework, I’d also like to use more smart pointers, maybe shared pointers for my general objects, but for the time being, I’ve got a project to get back to.

Gemstone Keeper – Quest to Linux Part 3 – Gemstone Keeper

Finally, after beginning soon after the game’s Windows release on Steam, and well over a month after I initially wrote my first post about this topic, I’m finally done with porting Gemstone Keeper to Linux (for the most part) and ready to write about what I’ve learned from porting it over. Since both the Framework and Level Generator have been ported, getting the whole game to compile and run wasn’t as confusing as the last two, but that didn’t stop it being tedious.

Continue reading

Gemstone Keeper on Steam Right Now

https://i1.wp.com/i.imgur.com/EprkPSq.gif

Check out the Steam Store, and you’ll see that Gemstone Keeper has a page where you can add to your wishlist, purchase the game and write a review for it. I greatly appreciate seeing people buying the game and giving it a good review, it really means a lot after realising that this game has been in development for nearly two years (May 2015 – April 2017). Reviews in particular are important because I’d like to collect a list of issues and make fixes, and hopefully add a bit more to the game over the course of a year. Gemstone Keeper will also be shown at Insomnia 60 at the Birmingham NEC and maybe a few more events if people find an interest.

In particular I want to thank Vincent Rubinetti for his contributions for the game. While he was the person I had in mind to do the soundtrack from the point I listened to his music in INK, I was a bit nervous about approaching him with the demo I had. However after a few emails back and forth, we made an agreement and we were underway for producing a great accompanyment to the game’s visual art style and atmosphere.

https://i1.wp.com/i.imgur.com/ajrVcHB.gif  https://i1.wp.com/i.imgur.com/24gcQz8.gif

In addition, I’d like to apologise for leaving this two days late; I couldn’t plan ahead because I spent the last few days sending out emails and twitter DMs in the hopes to get the game looked at by people; I fixed bugs and adding some last minute features such as damage numbers appearing whenever you hit something with your bullets and being able to type the seed you want to use in Score Mode.

On the launch day, I was at Rezzed, where I did talk to a few people about my game, but mainly walked around and tried out a selection of great titles. By the time 6pm rolled around, I hung out at an after party and chatted to a few developers.

Then the day after was my birthday, so I figured I would post on social media, but spend most of the time away from the game and more with friends and family to celebrate and relax.

https://i1.wp.com/i.imgur.com/prEWNzt.gif https://i1.wp.com/i.imgur.com/Fi4QFr6.gif https://i2.wp.com/i.imgur.com/DTZmFdO.gif

As for my future plans, aside from this game’s maintenance, I’m hoping to return to smaller games for a while. In particular I want to try a few more game jams and experiment a bit more, I have a few ideas I want to try out, and now I have a little less pressure on me to work a bit on them.

Final Stretch: Gemstone Keeper’s Release

Back in May, I made a simple demo for a University Thesis, now it’s less than two weeks away from being released onto Steam. This is such an exciting occassion for me, but also a nerve wracking one. If all goes to plan, Gemstone Keeper will be available on Steam on March 31st at 6pm GMT.

For the time being I will be working hard on polishing the game and getting the word out, I appreciate any help from that. There have been several updates from when the game was shown at LAGC, especially thanks to the feedback I got of the game from both GEEK Play Expo and GDC. Game has been balanced (repeatedly), boss battles have been redone and several bugs have been fixed.

I’d also like to give my thanks to Gemstone Keeper’s composer for the soundtrack, Vincent Rubinetti. He is probably best known for producing the music to the game INK, the colourful yet minimal platformer by Zack Bell. We’ve been in regular discussions both online and at GDC about the game’s music, and you can hear one of the tracks from the game’s brand new trailer above, I think it’s some brilliant work.

I’d like to thank everyone who has shown support for Gemstone Keeper over the last year or more, this game has been a huge milestone to conquer and I hope all those who try it will have a great experience.

It’s just amazing to think of how it all started…

A Greenlit Developer’s view on Steam Direct

On Friday, Valve posted on the Steam Blog that Steam Greenlight will finally be replaced by a new system for game developers to submit their games to the digital distribution platform. The new system will be called Steam Direct, where a developer can fill in a set of digital paperwork (such as company, tax and bank information) and pay a fee for each game they submit, with a small verification process to ensure that games will be able to run properly through the platform. With this news bringing heated discussions among game developers and journalists, I figured I’d put all my opinions down on one post to give my side.

While I have Steam Greenlight to thank for giving Gemstone Keeper the chance to be on Steam, I feel that Steam Greenlight has a lot of issues and is an easily cheatable system. It can make a game developer’s efforts a bit demoralising when they work hard on a game, pay the fee and spend time to create a good description and video to be placed on the page, when among the other hard working developers who put as much effort, you are also competing with people who either flip pre-made assets onto the store and could easily rack up votes by offering free Steam keys. Doing things the right way, as I talked to students about at a Staffordshire University conference months earlier, might take a few days if you are lucky, but more likely take weeks, months or (in a few cases) years to get greenlit, if you are greenlit at all.

The idea of having a fee per game, instead of a fee per account, is not new. It’s been suggested even why back when the idea of replacing Greenlight was first mentioned by Valve back in 2013, and I’m one of the group who agreed with the idea. This means that I was initially glad to see Steam finally announcing Steam Direct with this fee approach. It’s also worth mentioning that Steam has said that all games which have been greenlit, but have yet to be released, will not be affected by the transition and that it is possible to get a refund of the Greenlight submission fee if you do not have any Greenlit titles.

That being said, there are some concerns, namely with the vague and limited description of the approval process. While it’s all good to ensure that games released will actually contain an executable required to run the game, the question of quality arises. I’ve heard some ideas that a full vetting process would mean some really creative games would get rejected, which I do find valid since the appearance of a game is subjective, but I’d disagree on the fact that having a game that is quirky or unusual in appearance would still get through as long as it can run smoothly with a good framerate on average hardware and would be difficult to crash or bug out. It’s a concern to bring up, since part of the reason why Steam emassed such a large amount of poor quality games is because they allowed poorly made games to get through.

The other main concern is the size of the fee, to quote the blog post from Alden Knoll:

We talked to several developers and studios about an appropriate fee, and they gave us a range of responses from as low as $100 to as high as $5,000. There are pros and cons at either end of the spectrum, so we’d like to gather more feedback before settling on a number.

While a lot of developers are either worried or accepting of the maximum fee, citing either eliminating low income developers and developers from third world countries, I’m gonna be sounding like the optimist and say I doubt Steam would ever set the fee at $5000, unless they fully accept the risk of alienating a large amount of aspiring developers and reverse the progress of allowing indie development to be more accessible to bigger platforms. However it is because of reasons given like the fact that Valve and Steam are a business, submitting games has its own costs and there is a risk on Valve to allowing several games, especially if it’s unlikely they’ll make any money on the platform, that I do not see $100 being the fee they’ll decide on. Based on the several discussions I’ve read and the majority of developers preferring a lower fee, my best guess is that whatever fee Steam decides, it will not exceed $1000, maybe not even $750 if it would deter anyone who wants to use Steam as a way to make money with little effort.

Some have even suggested that the fee will bring a rise to smaller marketplaces for indie developers, as even Itch.io even joked about. I like seeing more variety, and I’m happy to see platforms like itch.io, GOG, GameJolt Marketplace and the HumbleStore growing their own communities, it would still take a few big named publishers to move to these platforms to topple Steam over.

Finally, I want to give my view to a point made by Jonathan Blow, who made a series of tweets criticising game journalists who write about Steam Direct being a reason for Indie Developers to panick, and not considering views who are on-the-fence or approve of Steam Direct. I don’t entirely agree with his viewpoint, in particular I don’t think it’s correct to think Kotaku/Polygon’s potentially biased reporting on the Steam Direct based on actual sources and “fake news” to be the same. However, considering that it’s only been a weekend and not every bit of infomation on Steam Direct has been finalised, I don’t think it’s good to treat every bit of detail in the Steam Direct announcement as negative, considering this is one of the first positive steps Valve has made in a while regarding Steam in a while.