Messages

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 an easy activity management and transition effect library built on top of SFML. The lib also comes with a ton of already-made transitions, shaders, and utility functions for games.

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.

2

SFML projects / Re: SFML 2.5.1 with GL ES 2.0 shader support for mobile devices

« on: April 23, 2021, 09:22:12 pm »

I am interested in getting shaders to work on Android and iOS. Does this also work on iOS or only Android?

Hey jonc, it should work on both. All I did was change out the GL stuff for GLES 2.0 which 99% of mobile devices support.

I will be revisiting this project later this year to add more features for both mobile devices.

3

SFML projects / Re: <SWOOSH> Header-only mini library for activities and segues

« on: January 02, 2021, 07:45:56 pm »

I have been working on a NES Zelda 1 re-make for awhile now (lots of breaks since we had another child!).  And this is probably perfect for me!  Not sure when I’ll get to the point of using it since I focused on intro / player name entry first but I’ll try to implement in my proof of concept soon!

Congrats with the newborn! Yes, swoosh is capable of doing the camera panning effect (if each area is its own level/scene).

I've been meaning to put together a Zelda clone/example for swoosh for a while now to demonstrate some of the "best practices" when using the library- but 2020 was crazy!

Best wishes

4

SFML projects / Re: Raycasting engine / (future dungeon crawler)

« on: January 02, 2021, 07:43:53 pm »

I love ray tracers! This is awesome!

5

SFML projects / Re: <SWOOSH> Header-only mini library for activities and segues

« on: October 11, 2020, 06:33:55 am »

Major updates in v1.2.4 just released today
Some API changes are made to support better mobile and low-end GPU hardware support. See the readme.

Added new "Dream" transition effect to the supplied src/segue/ folder in the project. Add it to your project by adding

#include <Swoosh/Segues/Dream.h>

.

Plug-n-play baby! 

https://streamable.com/cw5pev

6

SFML projects / Re: <SWOOSH> Header-only mini library for activities and segues

« on: August 19, 2020, 01:26:10 am »

The poll was close at a neck-and-neck tie with RPG and RTS Action game and RPG finally won! See the final poll: here

I will be making a youtube mini series on writing a polished and flashy RPG game with SFML + Swoosh. I'll post whenever the video series is ready.

In the meantime, follow SwooshLib on twitter here for sooner updates and early sneak peaks!

7

SFML projects / Re: <SWOOSH> Header-only mini library for activities and segues

« on: July 29, 2020, 08:27:16 pm »

I am making a web series on youtube using SFML + Swoosh lib to make a game from scratch! Please help vote here for the game genre YOU would like to see recreated. 

8

SFML projects / Re: Megaman Battle Network (ongoing fangame)

« on: July 29, 2020, 08:25:29 pm »

Thank you for the kind words unlight 

9

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)


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

10

SFML projects / Re: SFML 2.5.1 with GL ES 2.0 shader support for mobile devices

« on: January 13, 2020, 06:30:32 pm »

Thank you.

Per making a fork:

No I have not because the design of this feature has been in limbo from the main devs for some time.

The biggest point being breakage of the existing SFML API.
How do they support custom shaders's named attributes and uniforms... or how should SFML behave with default shaders?
Should it have a built-in one or should users always supply a default shader in order to get their first SFML app running?

These kinds of questions never seem to get any resolve so I made the features myself.

11

SFML projects / SFML 2.5.1 with GL ES 2.0 shader support for mobile devices

« on: January 12, 2020, 06:17:02 pm »

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

setDefaultShader(sf::Shader*)

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

 __ANDROID__

pre-processor.

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

#ifdef __ANDROID__
    loadingScreenSnapshot.flip(true);
#endif

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.

12

SFML projects / Update v1.2

« on: March 17, 2019, 11:31:54 pm »

v1.2 is released

Includes new segues (over 25 segue effects), custom sf::View support per each activity, custom background color for each activity, and lots of other tweaks.

Most importantly, this update has separated the shader effects used in segues into their own header: Shaders.h

Now you can use the following shaders in your SFML projects and apply them directly to sprites. No need to write your own GLSL code!

1. FastGausianBlur --> blur effect you can raise intensity + grain depth
2. Checkerboard    --> remove parts of sprite block by block. Increase kernel size for a dissolve effect.
3. CircleMask          --> Cut off everything outside of the circle you can define the amount
4. RetroBlit             --> Remove colors layer by layer for a retro effect
5. CrossZoom         --> Makes your sprite glow and pop out of the screen
6. Morph                 --> Morph your sprite from one to the other
7. PageTurn            --> Make your sprite turn fold like it's turning a page
8. Pixelate              --> pixelate your sprite
9. RadialCCW         --> cut off sprite with a radial effect. useful for visuals like health.

13

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.

14

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.


progress

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

SFML_OPENGL_ES32

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...
shader.setTexCoordUniformName("vTexCoord");
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
shader.setTexCoordUniformName("vTexCoord");
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
window.draw(sprite);
 

15

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.