[TLDR]: I released a free C++ library and free GUI application (Studio, SFML based) for procedurally generating animated pixel-art spaceships, with a wide range of configurable parameters!

Hello everyone!

Some of you (perhaps 5 or 10 of you :D) may have seen me post about a game I'm working on - Rogues in Space. While working on it, I, a kind of pretty bad pixel artist, started developing a procedural spaceship generator, the purpose of which was to just generate a very basic ship that I could manually "clean up" and animate.

Aaand well, I just kept adding generators for more and more things - hulls, engines, wings, weapons... In the end I even added animations and spritesheets!

At some point, when it was clear that this (now) library and GUI application were getting larger than the video game itself, it made more sense to cut it off as its own project instead of having it permanently embedded in the game codebase.

So, after doing all the new work that I've never originally intended, I've now released SpectralShipGen and SpectralShipGen Studio as open-source projects!

SpectralShipGen is the C++17 generation library itself, while SpectralShipGen Studio is a standalone GUI application (SFML based) for visually playing around with the generator and exporting ship images and animation spritesheets without needing to integrate the library into anything.

On the technical side, ships are generated deterministically from seeds, and how they look (and from which components/color palettes and what intensity), can be controlled through structural profiles, faction profiles, mentioned color palettes and plenty of other generation settings. Majority of the aspects of an existing ship (so engines, details, accessories, weapons, etc.) can be rerolled individually instead of regenerating everything, keeping the general construction of the ship mostly the same, except for the specific parts that you wish to change.

Saving and loading the recipes for said construction is also supported, as well as adding the ships to favorites/bookmarks, and browsing them later.

All ships are also generated with Idle animation and with (currently experimental) left/right/up/down movement and firing animations.

I've tried to keep the different visual identities fairly broad rather than making them into simple predefined ships. So, the same structural style or faction can still produce quite different results based on the seed and configuration.

The library itself is independent, while the Studio application does rely on SFML (and the library, of course) for the graphical rendering, button interactions, and everything else GUI related.

Interestingly, an unexpected amount of work towards this release ended up being in the boring-but-important category - regression/performance/robustness testing, establishing CI, writing (everyone's favorite) documentation, thinking about how licensing works, etc., so that these two can actually function as an independent library and a standalone application.

I've attached several examples of generated animations that I thought were interesting to show what the output can be, although they only cover just a tiny amount of what can be generated.

In case anyone likes what they're seeing and is wondering about using the generated output - anything you generate with it is yours to use however you want, including commercially. There's no attribution requirement and the source code licenses don't apply to the generated images or spritesheets.

Lastly, I'd also like to mention a couple of important topics.

I definitely don't see this ever replacing actual pixel artists - someone who's at least decent with pixel art can likely make a much better spaceship by hand. Something like this is, I think, much more useful if you're on a very tight art budget, if you need/want a bunch of ships generated during runtime (as you don't really need to save the generated spritesheet to disk in order to use it), if you're at a game jam and just need urgent assets.. Or if you just wanna generate a few hundred ships to see what odd things appear, because that can also be pretty entertaining (I may or may not have spent too much time doing just that).

Something that I also want to be fully transparent about, because I do think it will definitely be asked - the development/code writing on this project has been AI-assisted. However, that is the extent of it. There is no generative AI image creation anywhere in SpectralShipGen, reference images are NOT used, and there aren't any premade spritesheets or images "hidden" behind the library being chopped up and re-combined.

The ships are generated by the C++ code itself through procedural geometry, pixel masks, components (hull, engines, details, weapons, etc.) placing rules, seeded random decisions, and so on.

The nice thing about doing it with deterministic seeding way is that the same seed and the same configuration always give the same ship.

The amount of AI assistance during development was also one of the reasons I personally felt more comfortable making the project open source instead of keeping it completely proprietary. That's also not supposed to be some statement about how AI-assisted software should be licensed or what anyone else should do with their own work (that's a completely separate discussion) - it just felt like the right choice for me and this particular project.

As mentioned, the generated output is deliberately unrestricted as well - if you generate a ship image or spritesheet with SpectralShipGen (or Studio), you can do whatever you want with it. Use it in a commercial video game, redistribute it, paint over it, use it as a placeholder - attribution isn't required.

Links:

Library: https://github.com/SpectralHorse/SpectralShipGen
Studio: https://github.com/SpectralHorse/SpectralShipGen-Studio
Studio Download (from GitHub): https://github.com/SpectralHorse/SpectralShipGen-Studio/releases/tag/v1.0.0

I'd be very interested to hear about your thoughts - both about the generator itself and if the different ships actually feel like they have enough variety while still looking like they are thematically and systematically similar.

And, of course, if you end up generating something ridiculous with it - I'd love to see it! :)

I finished chapter 1-12, but I changed a lot from the author's source code

first, there were quite a lot of bugs in the author's source code.

The provided source code is not organized in well-defined libs, there was no mention of build config files anywhere in the book. I divided the project into 3 main libs (utils, core, ECS)

I used Conan to manage external library dependencies, and I used CMake to build my project.

It would be interesting if anyone of you would find it helpful, and please feel free to give your remarks regarding on how I could improve it.

Chapter 13 and 14 are remaining, I don't know if I'll continue.

Plus, you can play the game I coded using this engine that the book helped me code.

https://github.com/CrunchyPeanutButterJar/sfml-proj

Thanks for your time!

title

I tend to assume that the latest version is better, but I've seen a few new projects recently that use SFML 2.6. And, since 2.6 was out for longer, more tutorials / Q&A exist for it than 3.0.

Is there a list of the tradeoffs between the versions that could explain why some people are using 2.6 still?

(and what's the benefit of 3.1 over 3.0? should 3.0 projects migrate to 3.1 just because they can?)

Hello everyone!

I've been working on the combat for my C++/SFML space shooter game, `Rogues in Space`, and I wanted to share a showcase of some of the guns and skills currently in the game.

Each gun and skill have their own upgrade pools, so their behavior and stats can change quite a bit through the run. The video mostly shows their base versions, with short explanations of each mechanic included in the footage.

The game is built in C++17 with SFML 2.6.x. A good amount of what you're seeing here, including the gameplay rendering and visual effects, is running through my SFML-based rendering/post-processing setup.

I'd love to hear what you think about how the combat is looking so far, and I'm also happy to talk about the SFML/implementation side of anything shown in the video :)

And also, most importantly - do you feel like you could have fun with some of these combinations? :D

Hi all,

As the title suggests, I am looking for a way to keep the main program (so my update() and render() functions) running, whilst the window is being resized.

I have already tried multi-threading, keeping the event loop on the main thread, and having another loop calling the update() and render() functions on another thread. This requires me to use the win32 API to intercept the window's WM_SIZE message during resize, and update my own window size variable.

This approach sort of works, allowing my window size variable to correctly update whilst the user is resizing the window. However I don't have a good way to pass this to the sf::RenderWindow.

If I don't set anything, the sf::RenderWindow doesn't update its internal window size to the current window size. If I call sf::RenderWindow::setSize()+setView(), it updates the internal window size, but also results in graphical artifacts where the region SFML draws to the screen isn't in sync with the actual window size, and previous frames bleed into the current frame.

Does anyone have a better solution to this? Any help would be greatly appreciated.

not solved

lol wut?

;-;

Hello everyone!

TL;DR: Pls give feedback :)

I would like to share with all of you a game that I've been working on for the past several months - `Rogues in Space`!

The development has been done using only SFML, so it should be relevant to this sub as well :)

You are a daring pirate rogue trying to fight back the swarms of enemies ranging from officers of `The Imperium` to your fellow rogues, while aiming to reach the stockpile of galactic wealth which would most definitelly secure your future!

Gameplay is focused on being a space shooter (inspired by `Warblade` - one of my favorite games growing up) with an array of various guns and skills that you use to battle the waves of enemies.

So far, the core playability is as a `Roguelike` - so once you die, that's it, there would be no metaprogression apart from your knowledge of enemy patterns, ideal skill/gun combinations, etc.

As you finish each stage, you can upgrade your guns and skills to improve their performance in combat - you will most likely very much need that for the harder levels :)

The game is currently in early development, however the majority of the core systems have been created, so I'm estimating that all the future development will go more or less smoothly.

I've attached a screen recording of starting a new game which features a basic level gameplay and the initial ship selection with details of each ship/gun/skill for each ship - I've just briefly shown the details in order to not have a 5 minute video, so if you're curious about the details you can pause the video to check it out - or you can ask in the comments and I'll post the details for easier reading :D

Gameplay starts at 37 seconds.

I would appreatiate any and all feedback, comments, suggestions and impressions - both good and bad are always helpful!

Thank you for reading,
SpectralHorse

Note 1: All the displayed ships, guns and skills are fully implemented, and if you're curious how the look in-game, let me know and I'll post those as well in the comments
Note 2: UI (and a couple of assets) is in a very "placeholder" style currently, although I do think that I'll keep the layout of everything, but with an actually "pretty" aesthetic, and not just blue-ish blocks :)

"Blue Fruit" is the working title for a project whose primary mission is to program an environment destruction system based on various objects and materials—also known as "procedural destruction."

As an added bonus, I also plan to incorporate other systems—such as realistic fluids, volumetric lighting, and additional procedural elements—to create a natural and realistic environment.

Wondering if it's possible on Mac to take inputs without giving permissions to my sfml project. I'd prefer not to have to (not a big deal, just kind of annoying). There are some reddit and other posts suggesting that it's possible to use window events rather than sf::Keyboard::isKeyPressed for inputs, which also supposedly would not require permissions iirc. The posts I saw were pretty old though so I'm not sure if this is changed in SFML 3.0. Thanks!

            if(state == LevelSelect)
        {
            if(sf::Mouse::isButtonPressed(sf::Mouse::Left))
            {
                sf::Vector2i mousePos = sf::Mouse::getPosition(window);


                if(lv1.getGlobalBounds().contains(mousePos.x, mousePos.y))
                {
                    state = Game;
                }
            }
        }

i placed 2 buttons on same place in 2 different states and it clicked 2 times , is there any way to make it click ones

SOLVED - see comment below.

Hey there,

I dont like cmake and dont want to use it in my sfml project and want to just stay with a makefile.

my Makefile:

CXXFLAGS = \
    -std=c++26 \
    -O3

LDFLAGS = \
    -lsfml-window -lsfml-graphics -lsfml-system

gelame: src/main.cpp
    g++ $(CXXFLAGS) $(LDFLAGS) src/main.cpp -o $@

... and i get those errors:

c++ -std=c++26 -O3 -lsfml-window -lsfml-graphics -lsfml-system src/main.cpp -o gelame
/usr/bin/ld: /tmp/ccvoNzmy.o: in function `main.cold':
main.cpp:(.text.unlikely+0x191): undefined reference to `sf::RenderWindow::~RenderWindow()'
/usr/bin/ld: /tmp/ccvoNzmy.o: in function `main':
main.cpp:(.text.startup+0xa25): undefined reference to `sf::String::String(char const*, std::locale const&)'
/usr/bin/ld: main.cpp:(.text.startup+0xa41): undefined reference to `sf::VideoMode::VideoMode(unsigned int, unsigned int, unsigned int)'
/usr/bin/ld: main.cpp:(.text.startup+0xa66): undefined reference to `sf::RenderWindow::RenderWindow(sf::VideoMode, sf::String const&, unsigned int, sf::ContextSettings const&)'
/usr/bin/ld: main.cpp:(.text.startup+0xa84): undefined reference to `sf::WindowBase::isOpen() const'
/usr/bin/ld: main.cpp:(.text.startup+0xaa2): undefined reference to `sf::WindowBase::pollEvent(sf::Event&)'
/usr/bin/ld: main.cpp:(.text.startup+0xaae): undefined reference to `sf::Window::display()'
/usr/bin/ld: main.cpp:(.text.startup+0xabc): undefined reference to `sf::Window::close()'
/usr/bin/ld: main.cpp:(.text.startup+0xac6): undefined reference to `sf::RenderWindow::~RenderWindow()'
collect2: error: ld returned 1 exit status
make: *** [Makefile:22: gelame] Error 1

the c++ code in main.cpp:

#include <SFML/Graphics.hpp>

int main(int argc, char **argv) {
    sf::RenderWindow window(sf::VideoMode(800, 600), "Hello World");
    while(window.isOpen()) {
      sf::Event event;
      while(window.pollEvent(event)) {
        if(event.type == sf::Event::Closed) {
          window.close();
        }
      }
      window.display();
    }
  }
  return 0;
}

What is wrong with the makefile? help is appreciated.i

Hello everyone,

I hope you're all doing well!

is::Engine 4.0.3 is now available!

The engine can now simulate most of SFML's features with SDL 2. Other improvements have also been made to the engine!

For more information, please visit the engine's GitHub page.

Here are a few examples of games created with the engine: I Can Transform, GravytX The Gravytoid, Super Mario Bros.

Your feedback is welcome.

Have a great day!

I wish you all a wonderful summer vacation!

I'm using SFML in Visual Studio and running into an IntelliSense issue: when I hover over an SFML function (e.g. bullet.setPosition(...)), the Quick Info tooltip only shows the function signature (void sf::Transformable::setPosition(const sf::Vector2f &position)) plus "+1 overload" and a "Search Documentation" link — but no actual description text.

I confirmed the SFML header (Transformable.hpp) does contain a proper Doxygen comment directly above the function, using the \brief tag in the classic banner style:

cpp

////////////////////////////////////////////////////////////
/// \brief Set the position of the object
///
/// ...
////////////////////////////////////////////////////////////
void setPosition(const Vector2f& position);

What I've already tried:

• Set the Doc Comment style to "Doxygen" (via Ctrl+Q → search "Doxygen")
• Added brief to Tools > Options > Text Editor > C/C++ > IntelliSense > Quick Info > "Doxygen tags to display on Quick Info tooltips" (it wasn't in the default list)
• Fully restarted Visual Studio after changing settings
• Deleted the .vs cache folder and rebuilt the project

Setup:

• Visual Studio [your version, e.g. 2022 17.x — check via Help > About]
• SFML installed via [vcpkg / manual download / NuGet — fill in]
• Windows [your version]

Any idea what could be causing this, or how to get the actual \brief description to show up in the tooltip? I actually have no Idea where to search and google is also not helping.

I find it fascinating that nothing on the screen exist as a vertex model it's only deterministic calculations per pixel position.

My local llm seams to eat shader math for dinner and know everything about Ray Marching and SDF objects, something I've just heard about tree days ago.

This is version 24 and has taken ~24 hours so far from the initial shader convertion since I'm supergreen in Glsl: https://www.shadertoy.com/view/wsjBD3

I need that version for windows and the official website to download it from is down.

I thought it was just me but apparently it's been down for almost two weeks now.

No wibe code this, although it been converted to sfml via a llm.