On-demand way of saving the last few seconds of gameplay as a gif.

[DanielSnd]

I'm not sure if this is possible with the features already existing in the engine. I wanted to do something like in the game Towerfall where when a match is over it replays the last few seconds of the gameplay on the screen and let's the player quickly and easily save it as a gif right then and there.

I believe it could be implemented with a circular buffer keeping a copy of the last X frames rendered, but I'm not sure if there is currently a performant way to keep those that wouldn't super impact performance. So it would only actually have to impact performance when the player does decide to save the gif, and it would go through those frames in whatever format they are and turn them into actual images.

I imagine what is needed in this case is a performant way to retrieve and store the result of a rendered frame the way it was rendered, without having to constantly be "creating images" to store it which was the first way I thought of implementing it but I believe would impact performance.

Is there already a way of doing this using some feature of the engine?
Or would this require a proposal of a new feature?

[AThousandShips]

This would require a very significant buffer to be kept, it doesn't just impact performance when saving, it would impact it every single frame, they are already images, that's not possible otherwise, unless you mean some form of replay storing data like positions

What's worse is that you would need to extract each frame from the graphics card, which isn't cheap, you can't just get the rendered image like that it needs to be downloaded from the GPU, this is slow, so doing this every frame will significantly hurt performance, plus the cost of scaling the image down, assuming you don't want it at the original resolution, in that case the memory for the saved data will be quite significant, unless you want to spend more processing power on compressing it (five seconds of 10 fps images, at 1024x768, with 24 bits of depth, takes 118 kB, or there about, note that you would have to use the native resolution and colour depth of your settings unless you want to do conversion)

This, however, is really the area for a plugin, not something the vast majority of games would be interested in, and can't be something to put into the engine

There could be ways to do this by copying the frames inside the GPU itself, but that's very complicated and I wouldn't know how to do it, and it'd take quite a lot of resources on the GPU, this would avoid the performance problems of downloading the frames, but it'd involve a lot of complicated GPU related code and I don't know if this is possible with the rendering pipeline, at least without adding code to the rendering pipeline

[DanielSnd]

This, however, is really the area for a plugin, not something the vast majority of games would be interested in, and can't be something to put into the engine

I see, that makes sense.

There could be ways to do this by copying the frames inside the GPU itself, but that's very complicated and I wouldn't know how to do it, and it'd take quite a lot of resources on the GPU, this would avoid the performance problems of downloading the frames, but it'd involve a lot of complicated GPU related code and I don't know if this is possible with the rendering pipeline, at least without adding code to the rendering pipeline

That also does make sense... If we could keep it in the GPU I can see how that would be better in keeping performance from being affected. I know we can access the current screen texture on shaders using the hint_screen_texture, so I wonder if there is a way to copying it in the GPU and keeping it in a circular array. I also saw the BackBufferCopy node which maybe does something similar to what I want it to do? Will look more into it.

For a gif I only need about 16 frames per second, and it would be a quick replay of 3 to 5 seconds. (48 to 80 frames that I'd be keeping). If it can be done with a plugin without the need for any new engine features that'd be great, I think the BackBufferCopy might hold part of the solution, will investigate it more.

[theraot]

Every captured frame would have an impact on performance, and chances are that impact is too much for mobile or web. I don't know if encoding the gif this can be done efficiently and with small enough footprint to be in core.

But, if you need this for your game, and it is a desktop only feature... You might get away with getting the frames from a viewport (at the frames it makes sense to match the frame rate you want and keeping only the amount you need), and passing them to another executable to convert to gif.

Yes, that won't be good enough to add to Godot, but it might be good enough to deploy the feature on your game.

Do not underestimate desktop computers.

[AThousandShips]

While desktops should have no problem doing this there's performance aspects to consider as getting data from the GPU requires synchronization that's not free

I'd say this is too specific to put in core even without the performance concerns, however adding support for saving gif files is a thing to discuss, I'd suggest opening a dedicated proposal for that

[Calinou]

Even on desktop platforms, you'll need #7886 to achieve this without stuttering, as get_image() on a Viewport imposes a pipeline stall.

Regarding saving GIFs from Godot, GIF is a pretty outdated format by today's standards. Not only it has a limited color palette, its compression is also inefficient. Therefore, I wouldn't encourage further usage of it. Modern browsers all support APNG and animated WebP (which can be either lossless or lossy) 🙂

That said, you should probably be sharing videos if lossless quality isn't strictly required. Godot can record those, albeit not during gameplay.

[DanielSnd]

Even on desktop platforms, you'll need #7886 to achieve this without stuttering, as get_image() on a Viewport imposes a pipeline stall.
That definitely looks like something I'd need for it :o

Regarding saving GIFs from Godot, GIF is a pretty outdated format by today's standards. Not only it has a limited color palette, its compression is also inefficient. Therefore, I wouldn't encourage further usage of it. Modern browsers all support APNG and animated WebP (which can be either lossless or lossy) 🙂
It's still widely known and used, I get that other file types are better and more modern, but they're not nearly as widely adopted. If I want to send an animated image that auto-plays on a discord channel I can't send an APNG or a WebP, only a gif. Steam Description doesn't even accept uploading of WebP or APNG as a Custom Image upload, only JPG,PNG and GIF. Same for Itch.io. So despite the better formats existing, I feel that if I want to have the best chance of my players actually using animated image replays from my game (and hopefully promoting it by doing so), I should give them the export as a .gif

Having said that I don't feel that Godot needs a way of exporting gifs on its core, I'm sure I could get it working in a GDExtension or a custom module.

That said, you should probably be sharing videos if lossless quality isn't strictly required. Godot can record those, albeit not during gameplay.

The (game) feature is an instant replay of the last few seconds of the match, and I can't preview when the last few seconds of the match will be.

I do feel that it should be possible to do this. Towerfall did it 11 years ago using XNA/FNA. And I know there's similar solutions available for unity using C# (This one seems to do it using Render Textures, which I believe the Godot equivalent would be Viewport Textures, so I'll be looking into those to see if they can be used for it).

Yes, that won't be good enough to add to Godot, but it might be good enough to deploy the feature on your game.
Do not underestimate desktop computers.

I would like to have this in my game, but if it's not possible I can live without it. I'll try with the solutions proposed and see if it performs well enough. If there are already options available to achieve it (and there seems to be different ways) then there's clearly no need for any new features on godot core to support it :) no problem.

My game will only be targetting desktop and consoles, so it will hopefully be fine ^^

Thanks everyone!