Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - foo

Pages: [1]
SFML projects / Swoosh 2 alpha release
« on: December 02, 2022, 11:35:33 pm »
Swoosh 2 is ready for use but not yet merged into master. Use branch feature/swoosh2 for the latest changes.

What is Swoosh?
See More:
(click to show/hide)

Swoosh 2 changes the way we render graphics. Traditionally, SFML sprites are drawn directly to the target surface or window. With Swoosh 2, we submit render events with data in them and let the user-defined renderer decide how to draw. It's convenient to think of render events for sfml drawables as "tags". By tagging the drawables, we can tell the renderer how we'd like to draw them.

Swoosh 2 comes with a simple composite renderer, SimpleRenderer, and a few event types to begin migrating from the previous version:
  • struct Immediate → used by swoosh internals to draw directly to the final output buffer
  • Clone(...) → a utility function that makes a copy of your sfml primitive before submitting. Useful for migration.
  • renderer.submit(sf::drawable*, sf::RenderStates) → overload to replace the previous draw calls will wrap sfml primitives into RenderSource events.
Swoosh 2 can let you define multiple renderers and switch between them on the fly. I think a video speaks for itself. In the following video, I switch between the simple renderer that comes with Swoosh and a deferred renderer for 3D lighting effects. The deferred render is available for your own use in the Example Project that comes with the fork.

Click the image to go to the YouTube video

Having multiple render options for SFML projects is powerful and brings a lot of utility.

One render option can be used to increase performance on embedded machines by discarding some events entirely, especially since SFML 2 is still very behind on modern graphics support on PC and mobile.

Another renderer can be used for debugging your application. Or you can get creative and make the renderer an in-game effect that changes how your player sees the world around them.

The most powerful aspect about Swoosh 2's new renderer pipeline is that you do not need to change what you submit to draw so all of your scene's code stays the same.

See the Example Project draw step source code to see this fact in action.

SFML projects / Megaman Battle Network (ongoing fangame)
« on: June 22, 2020, 10:00:57 pm »
Download The Game

Made with a fork of SFML 2.5 so I can use shaders on mobile hardware
Uses Swoosh, an SFML library, for scene management and screen transition effects.
Everything else has been coded from scratch
Builds on Mac, Linux, Windows, and includes android studio for Android (may not work atm)

video tutorial
The video in the link above shows you how to build the engine from source code and includes links to the source in the comments

The current demo uses the #development branch

Go directly to github

I needed better shaders for SFML to run on mobile. This adds ES 2.0 shader support. Every render texture comes with a
routine that allows you to define the default shader. If you don't set a default shader on mobile it will either be completely black or crash. On mobile, shaders need both fragment and vertex shader for its constructor.

Because mobile stores image data flipped by the Y axis, you must also use
 flipTexture(bool flip)
if you're doing post-processing.

Besides that it's normal SFML 2.5.1. If you're on desktop those new functions won't be available. Add these checks using the

sf::Texture loadingScreenSnapshot = ENGINE.GetRenderSurface().getTexture();

#ifdef __ANDROID__

Because the texels/s in mobile GPUs are restricted compared to desktop, making a copy of a render surface, applying post process effects, and displaying it on the same frame can choke. SFML sends a lot of stuff back and forth from GPU <-> CPU and this is costly. If SFML had a way to represent a proxy render surface by an OpenGL ID, it could skip passing the texture data over to CPU and apply shader post-effects all in the GPU before rendering to screen. This would make real-time post-processing effects possible on mobile.

I've been using this custom fork for my Open Net Battle engine. View references on using SFML for mobile >> here <<

Some videos of SFML on mobile:

SwooshLib for SFML also works with SFML 2.5.1 custom fork. Use swoosh to make professional looking games with cool shaders, screen transitions, app management, ease functions, and more.

Feature requests / Proposal to rename SFML
« on: January 04, 2019, 08:35:08 pm »
This proposal may sound unintuitive to programmers especially those with a long history with SFML. Let me address that I have an eye for markets, user ecosystems, and social engagement. It's in my interest to contribute to SFML in other ways than code namely image and growth.

The Issue
To put frankly,
"Simple Fast Multimedia Library" is a misnomer to developers and this is bad for SFML because users have misinterpreted expectations that lead to disappointment and abandonment altogether. Why does this matter? With the exposure Hospin's Minecraft, rise in modern C++ interest, Microsoft's VS video tutorial using SFML demonstration to name a few, we'll see an influx of new users wanting to try out SFML. With more active users in the community, we can gain more contribution, which means faster progress at lesser effort from the maintainers. Green thumbs for everybody.

It's Not Simple!
From my internet scouting and discord monitoring, I've noticed users come to SFML for interesting reasons:
GUIs, cross platform system software, games. When they find out SFML doesn't have a specific features like default fonts, controller libs, and batch rendering out of the box they're surprised.

What I think has happened is that they are misinterpreting "Simple" in SFML as being a one-does-all experience. Not realizing that SFML is actually a lightweight collection of common application development modules and therefore will require work and code for advanced features. This demoralizes them and they may quit, running off into the arms of SDL2.

It's important to note that as any industry grows (software in this case), the barrier of entry must get smaller. This is because people expect things to come easy. If the implication is to be "simple", the new waves of coders expects their hand to be held. We can prevent this by not promising simplicity. We tell the coder (potential customer if you will), what they can expect from SFML that can be met every time.

It's Super Fast!
Change the name to "Super Fast Multimedia Library" because SFML is super fast for dev time, prototypes, graphics instantiation, and cross platform building. With this name change, we remove the implication that things are simple for new devs and now they cannot be disappointed resulting in a better and positive experience for them, retaining them as a happy user and contributing to the community.

This name change also keeps the well-known brand "SFML". Some copywrite (text) will need to be changed and in the end we keep the strong SFML lettering we recognize, keep the logo, and only change the long-form name. 

Sometimes something as effective as changing a slogan in business can have a huge effect on a product. This is no different.

In summary, change the name from "Simple Fast Multimedia Library" to "Super Fast Multimedia Library". Keep the brand name's iconic lettering "SFML" change only text on site and the docs over time. Form new user expectations that can be met with SFML as is, increase user experience, retain the user, more growth, more contributions, less work for maintainers.

Feature requests / [In progress] SFML ES 2 Discussion
« on: November 18, 2018, 10:10:02 pm »
Hello I've been in contact lately with binary 1248 and other members on the SFML committee regarding modern OGL support.


For my engine to run on mobile, as it relies on shader effects, I needed SFML to be upgraded sooner. I've forked binary's feature branch SFML and added
macro definitions for the new code. I've more or less standardized some ways SFML can handle the new shader requirements.

Problem is that sf::Sprite used to handle all the built ins like Texture Coordinates, Color, etc. This is no longer supported and we must provide that info. Luckily this is just one uniform property away. It would be cumbersome to force the user to bind the text coord properties for each sprite (S in SFML stands for SIMPLE). I suggest we add a function to a class higher up in the chain, like the sf::RenderWindows themselves as they are responsible for drawing in the end.

sf::RenderTexture surface;
sf::Shader shader; // load shader...
sf::RenderStates states;
states.shader = &shader;
surface.draw(sprite, states);

Open to better naming conventions

For falling back on a default shader, we could require binding a default shader to the RenderWindow and RenderSurface at initialization.

sf::Shader defaultShader; // load default vertex and frag shaders
sf::RenderTexture surface(defaultShader);

surface.draw(sprite, states);


sf::RenderWindow window(VideoMode(800, 600), "window", Style::Default, defaultShader);

Otherwise passing a shader in with each draw call is a must.

Finally, if backwards compatibility is a must which we can do we supply built in shaders and suggest the default variable name in the docs and also allow the user to change the property with the proposed signatures as demonstrated before:

// Not loading any shaders, using SFML provided default shaders
window.setTexCoordUniformName("vTexCoord");// but we change the name of our tex coords

SFML projects / Open source pokemon battle engine
« on: November 11, 2018, 08:57:54 am »

Watch most of the play through here!

Fork or download the source and release builds on github!


This demo began because a few SFML community members challenged the capabilities of Swoosh. Could it make segues as complicated as pokemon? Two flashes and then a unique effect happens before the battle shows up.

In less than a weekend, I had a demo working with the screen transitions just like pokemons. Then I realized ActionLists are an amazing building block for turn based games like pokemon.

Two weekends later I had polished the battle engine using primarily ActionLists that are now a part of Swoosh.

That is less than 5 days - I had a near perfect replica of the battle engine for the GBA pokemon games. The polish and speed that Swoosh brings is incredible. This demo is testament to that.

Updated 10/12/2020 to reflect latest 1.2.4 API

There had to be a way to manage cool screen transitions as easy as possible in C++ without too much difficulty.

There wasn't until now Swoosh, the mini library that immediately adds 100x polish to your game.

Fork the project at https://github.com/TheMaverickProgrammer/Swoosh.

LICENSED under The zlib/libpng License.

Swoosh is easy to integrate and makes your game look pro. Just checkout the super simple game example that ships with it.

See the full video https://streamable.com/qb023.

The example project comes with 20+ header-only custom segue effects you can copy and paste directly into your project and it'll just work.

Using segues is as easy as calling push or pop and providing the intent. The intent is a specialized nested class designed to be human readable. Just see for yourself:

ActivityController controller;


// User selects settings
using types::segue;

Popping is the same way.


And if you're making a legend of zelda clone and the player teleports out of a series of deep dungeons back to overworld... there's a function for that too

bool found = controller.rewind<segue<SlideIn>::to<LOZOverworld>>();

if(!found) {
    // Perhaps we're already in overworld. Certain teleport items cannot be used!

Take a peak at the full source code for the demo project:
Source Code

Swoosh comes with other useful utilities specifically but not limited to games.

  • function bool doesCollide(a, b)
  • function double angleTo(subject, target)
  • function vector2 direction(target, dest)
  • function void setOrigin(sprite, fx, fy)

See the rest here:

May this be as useful to you as it is meant to be!

Java / SFML for android Gradle Build Fails
« on: October 12, 2018, 11:12:12 pm »
I'm using NDK r18, SFML 2.5, Android API 24, Clang on MacOSX. STL=c++_shared.

And I made sure the STL value was the same across cmake and the generated makefiles.

I followed both the SFML official guide and a template found here on the forums. Both end with the same error. I'll show the command line example from the official guide only:

Here is the output

Error: undefined reference to 'sf::String::String(char const*, std::__ndk1::locale const&)'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefined reference to 'std::__node_alloc::_M_deallocate(void*, unsigned int)'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefined reference to 'std::locale::~locale()'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefined reference to 'std::__node_alloc::_M_deallocate(void*, unsigned int)'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefined reference to 'std::locale::~locale()'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function std::basic_streambuf<char, std::char_traits<char> >::~basic_streambuf(): error: undefined reference to 'std::locale::~locale()'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function std::basic_streambuf<char, std::char_traits<char> >::~basic_streambuf(): error: undefined reference to 'std::locale::~locale()'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function std::priv::_Rb_tree<int, std::less<int>, std::pair<int const, sf::Vector2<int> >, std::priv::_Select1st<std::pair<int const, sf::Vector2<int> > >, std::priv::_MapTraitsT<std::pair<int const, sf::Vector2<int> > >, std::allocator<std::pair<int const, sf::Vector2<int> > > >::_M_erase(std::priv::_Rb_tree_node_base*): error: undefined reference to 'std::__node_alloc::_M_deallocate(void*, unsigned int)'
  /Users/maverick/Library/Android/ndk/sources/third_party/sfml/lib/armeabi-v7a/libsfml-main.a(MainAndroid.cpp.o):MainAndroid.cpp:function std::priv::_Rb_tree<int, std::less<int>, std::pair<int const, sf::Vector2<int> >, std::priv::_Select1st<std::pair<int const, sf::Vector2<int> > >, std::priv::_MapTraitsT<std::pair<int const, sf::Vector2<int> > >, std::allocator<std::pair<int const, sf::Vector2<int> > > >::_M_erase(std::priv::_Rb_tree_node_base*): error: undefined reference to 'std::__node_alloc::_M_deallocate(void*, unsigned int)'
  clang++: error: linker command failed with exit code 1 (use -v to see invocation)
  make: *** [/Users/maverick/Code/Forks/SFML/examples/android/app/build/intermediates/ndkBuild/debug/obj/local/armeabi-v7a/libsfml-example.so] Error 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Here is the makefile

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := sfml-example

LOCAL_SRC_FILES := main.cpp




$(call import-add-path,/Users/maverick/Library/Android/ndk/sources)
$(call import-module,third_party/sfml)

Someone on IRC said it might be link order so I've tried every possible combination. And I know it has to be a specific order: dependent libraries first so graphics then window then audio/network then system. As you can see I have that too.

I tried static and it installed but crashed on startup. Reading the official android C++ docs, they mention static is not suggested and use shared instead.

Help me get this to build and run right on android.

Pages: [1]