feat(extra-natives-five): new natives for screenshots

[spacevx]

Goal of this PR

Implement new screenshot natives that allow resources to capture the game screen, with options to include or exclude the HUD layer.

How is this PR achieving the goal

By exposing new natives to all ScRT

Screenshot natives:

• TAKE_SCREENSHOT_ASYNC
• TAKE_SCREENSHOT_HUD_ASYNC
• IS_SCREENSHOT_READY
• GET_SCREENSHOT_ENCODED

This PR applies to the following area(s)

FiveM

Successfully tested on

Game builds: 3258

Platforms: Windows

You can test it yourself by using this resource
screenshot-test.zip

/screen for screenshot without HUD overlay
/screenhud for screenshot with HUD overlay

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

[mickeygeecom]

Would be super-duper dope, if we also had an native that could capture NUI / DUI elements as well - on top of HUD elements.

[spacevx]

Would be super-duper dope, if we also had an native that could capture NUI / DUI elements as well - on top of HUD elements.

Yeah already thought to this, if it's okay with @prikolium-cfx i can check for this

[prikolium-cfx]

Would be super-duper dope, if we also had an native that could capture NUI / DUI elements as well - on top of HUD elements.

Could you tell me the reason for that? For me it sounds more like privacy issue

[Mathu-lmn]

Would be super-duper dope, if we also had an native that could capture NUI / DUI elements as well - on top of HUD elements.

Could you tell me the reason for that? For me it sounds more like privacy issue

How is it a privacy issue ? I believe since the server itself controls what is displayed on the HUD, it's not really a private ? Or maybe I'm missing your point

[prikolium-cfx]

Would be super-duper dope, if we also had an native that could capture NUI / DUI elements as well - on top of HUD elements.

Could you tell me the reason for that? For me it sounds more like privacy issue

How is it a privacy issue ? I believe since the server itself controls what is displayed on the HUD, it's not really a private ? Or maybe I'm missing your point

I want to hear the reasoning first.

[ook3D]

Would it not be limited to just the fivem process? i dont see how its a privacy issue as long as its scoped to just the current process

[mickeygeecom]

Would be super-duper dope, if we also had an native that could capture NUI / DUI elements as well - on top of HUD elements.

Could you tell me the reason for that? For me it sounds more like privacy issue

How is it a privacy issue ? I believe since the server itself controls what is displayed on the HUD, it's not really a private ? Or maybe I'm missing your point

I want to hear the reasoning first.

My use-case is; we already have tools for screenshotting the client, but without NUI/DUI.
It could be useful to better understand what the player is actually doing.
Cause lets be real - all servers rely heavily on NUI now-a-days and disable the GTA hud features, so you only get some of the actual player's "UI".

Would especially be great for (automation of) bug reporting, players requesting help from staff or cheater investigations.
If a cheater (or legitimate player) triggers something that shows NUI (received item or gets a simple notification) - we are totally blind to this.

Comes down to missing pieces of the puzzle, as a 'regular' client screenshot only shows half of the story.
It all comes to to the purpose of confirming behavior for me.

[itschip]

Veryyy nice!

Would also be great with support for 'webp', related to file size. jpeg alone results in much bigger buffers than a webp. Not sure if there is anything built-in now.

One option could be to use https://github.com/libvips/libvips for converting it to webp and apply some compression, based on user input.

[prikolium-cfx]

Veryyy nice!

Would also be great with support for 'webp', related to file size. jpeg alone results in much bigger buffers than a webp. Not sure if there is anything built-in now.

One option could be to use https://github.com/libvips/libvips for converting it to webp and apply some compression, based on user input.

This library is using LGPL license which is not "good". The only acceptable options are MIT (and similar), BSD 2/3 Clause and Apache 2.0

[spacevx]

New natives to be able to record:

• GetVideoRecordingPath
• IsVideoRecordingReady
• StartVideoRecording
• StartVideoRecordingHud
• StopVideoRecording

My approach may be wrong, if there is a better way to do it, please don't hesitate.
Currently using the Media Foundation API to record. Recordings are locked to 30 FPS, with 4 quality available through the natives.

All recordings are saved to <CitizenFX>/recordings/

Note: GetVideoRecordingPath only returns the filename (e.g. recording_20260412_191822.mp4), not the full path. The name might need to be changed

[Gogsi]

Due to script sandboxing, I don't think a script can then read the recorded video file (for example to send it to the server or upload). Honestly I'm not sure what the best approach here is, given the large size of video files 🤔

[Ehbw]

Right now the game-view capture works really well for the use case of recording the game (and I have #3763 to resolve issues and improve the performance of capturing). Along with providing a large range of ways to handle and process that data. I don't believe these natives for video recording makes sense in the way you have proposed it.

It may be more logical to introduce natives to stop game-view from capturing native HUD elements when toggled.

[spacevx]

Due to script sandboxing, I don't think a script can then read the recorded video file (for example to send it to the server or upload). Honestly I'm not sure what the best approach here is, given the large size of video files 🤔

Completely forgot about sandboxing ......
We could expose them through nui but like Ehbw said, game view should be better for this use case ^^

[spacevx]

Right now the game-view capture works really well for the use case of recording the game (and I have #3763 to resolve issues and improve the performance of capturing). Along with providing a large range of ways to handle and process that data. I don't believe these natives for video recording makes sense in the way you have proposed it.

It may be more logical to introduce natives to stop game-view from capturing native HUD elements when toggled.

Never saw your PR, indeed game-view capture seems a better way for the use case of recording

Will revert my commit tomorrow, thanks for the feedback

[spacevx]

Hello, just reverted the commit for recording natives.

[PappaNiels]

Hi. As a graphics programmer, I thought I would drop my thoughts as well. Even though it could work, I am very worried seeing the mapping and processing to a jpeg on the render thread. The map call is quite expensive and you are processing megabytes of data, leading to hangs when presenting a frame. Would the mapping and processing be a good idea to be done on a worker thread?

And for the processing of other formats, and as an alternative for what chip mentioned, I recommend stb_image_write, as it processes every relevant image format. https://github.com/nothings/stb/tree/master

[spacevx]

Hi. As a graphics programmer, I thought I would drop my thoughts as well. Even though it could work, I am very worried seeing the mapping and processing to a jpeg on the render thread. The map call is quite expensive and you are processing megabytes of data, leading to hangs when presenting a frame. Would the mapping and processing be a good idea to be done on a worker thread?

And for the processing of other formats, and as an alternative for what chip mentioned, I recommend stb_image_write, as it processes every relevant image format. https://github.com/nothings/stb/tree/master

Hi. Thanks for the review, really appreciate it, honestly I hadn't considered that at all when writing the PR so thanks a lot for pointing it out.

I'll rework it properly and come back with a better approach for this
And I'll definitely look into stb_image_write for the format processing, big thanks :)

[spacevx]

Just made a update

I moved the encoding to a worker thread and included Map() (as suggested by @PappaNiels), once the device context isn't needed anymore and the worker takes over from there

We are also using stb_image_write, from natives we can choose between JPEG and PNG

 local handle = TakeScreenshotAsync(0, 85)
-- JPEG

  CreateThread(function()                                                                                                                                                                                                                            
      while not IsScreenshotReady(handle) do
          Wait(0)                                                                                                                                                                                                                                    
      end                                                         

      local encoded = GetScreenshotEncoded(handle)
      -- Send it through NUI or somewhere else
  end)

Tried with different resolutions (1920x1080, 2k & 4k and it's working fine)