Toggle sidebar

Homebrew Release: PNGShot - Capture screenshots as PNGs.

  • Thread starter Thread starter JK_
  • Start date Start date
  • Views Views 8,163
  • Replies Replies 69
  • Likes Likes 18
Yep, it's all about convenience as BP doesn't sort into folders.

I'll try to build it with zero compression since storage is not an issue.
Post automatically merged:

Built it with zero compression and no slowdowns at 1020/1331! Even compression set to 1 takes time and slows the game down, but 0 has zero effect on gameplay :P
 
  • Like
Reactions: impeeza
Only issue with zero compression is that it needs more time to save file.

Overall I also recommended to switch to libspng, reduces time for level 4 to 2.5 seconds and for level 0 to 4 seconds at 1963 MHz CPU 2131 MHz RAM in the same situation from post before.

I think it should be configurable how high compression level user wants.
 
If we want real config, I'll try to get to it later today. It shouldn't be too difficult or time consuming to implement.

I've been trying to work on a game in GameMaker for shits and giggles the past month or so. That's where I've been. I'm still getting used to baby mode programming. Should be fun to do real big boy stuff again for a little bit.
 
  • Love
Reactions: impeeza
Hey everyone. I have some bad news. I was hoping to implement a basic JSON config by the end of today, but unfortunately, shortly (literally an hour) after I made that post I received some bad news and a family member passed away suddenly. I laid out the basic structure though. Hopefully over the weekend it will be done.

I was already juggling a lot too (GameMaker game, JKSV update, Avatool re-re-write, then PNGShot config). Thanks for understanding.

Edit:
bitmap-printer just saves raw image with no compression.
Click to expand...
This is also a disadvantage PNGShot has that you can't really work around. Bitmap-printer always knows how large the end screenshot will be. PNGShot can't. I have to make extra fs calls to ensure the file is the correct size and can be written to.
 
Last edited by JK_,
  • Love
  • Sad
Reactions: lightwo and impeeza
namename11 said:
So with 0 compression a config could exist for faster writes?
Click to expand...
As you can see in benchmark - that's actually wrong. :P

Because PNG doesn't have an option to store raw image, it needs to go through DEFLATE that needs to figure out now how to store data without compressing it so INFLATE can read it properly. And this actually takes more time than just compressing it. It's so inefficient that it cannot take advantage of whole CPU core power, that's why game doesn't slow down.
 
  • Like
Reactions: impeeza
masagrator said:
As you can see in benchmark - that's actually wrong. :P

Because PNG doesn't have an option to store raw image, it needs to go through DEFLATE that needs to figure out now how to store data without compressing it so INFLATE can read it properly. And this actually takes more time than just compressing it. It's so inefficient that it cannot take advantage of whole CPU core power, that's why game doesn't slow down.
Click to expand...
I meant faster uncompressed writes. Of course it will still be slower due to the huge file size. But maybe it can be optimized to be as fast as Bitmap-Printer since the final size is known at 0?

Or someone could just add sorting shots into folders to Bitmap-Printer, I guess :P
 
  • Like
Reactions: impeeza
If you want to further optimise fs, do note that it is faster to set the file size in chunks rather than on each write. When compression is used, each line written causes the file to be resized. So you could set the initial size to something large, for example the max uncompressed size, then do the writes as normal, then before closing the file update the file size with the actual.

Internally this saves many fs calls which causes the file to grow.

The 7s+ to write a uncompressed file is odd imo. I understand it being slower due it being bigger, but *that* much slower? How are uncompressed writes being done? Line by line? Or single shot write (create file with final size set, write file in one go, close). If it's the former, then well ofc it's going to be slow as hell. If it's the latter then I really don't know.
 
  • Like
Reactions: impeeza
Jayro said:
Does speed really matter when writing the file to SD?
Click to expand...
I don't understand why it wouldn't matter? Whether it's time spent compressing or time spent writing the file, it's still time spent on core3 that could be spent elsewhere (loading screens, sysmods). Faster is always better.
 
  • Like
Reactions: Jayro
Jayro said:
Does speed really matter when writing the file to SD?
Click to expand...
Yes, sometimes (a lot of times, actually :P) I want to take a screenshot 2 seconds after my first one and I can't as the first is still being saved.



Would be cool if it cached the first one to the 40MB of free memory to process/save later and just take the second shot I have but maybe that's asking for too much considering the available memory is way lower in new FW.
 
namename11 said:
Yes, sometimes (a lot of times, actually :P) I want to take a screenshot 2 seconds after my first one and I can't as the first is still being saved.



Would be cool if it cached the first one to the 40MB of free memory to process/save later and just take the second shot I have but maybe that's asking for too much considering the available memory is way lower in new FW.
Click to expand...
Can't you use an unused portion of RAM as a write buffer? That way the ram can flush to SD at whatever speed.
 
  • Like
Reactions: namename11
namename11 said:
Would be cool if it cached the first one to the 40MB of free memory to process/save later and just take the second shot I have but maybe that's asking for too much considering the available memory is way lower in new FW.
Click to expand...
That's a major problem too. Like, I could do it all in RAM and the write the contents in one go. Given I'd know the size of the compressed buffer at file creation, that alone would cut out all of the resize calls. But, then you run into the RAM issues. I'm pretty tired right now, but the whole process would likely use roughly 7MB minimum if my tired math is correct.
 
  • Like
Reactions: namename11 and impeeza
@namename11 @AllOver write speed is not an issue here. Read my post again...

- PNG DOESN'T SUPPORT WRITING RAW DATA.

Just changing library from libpng to faster libspng allows cutting write speed of uncompressed png by almost half while taking the same approach (compressed one still is faster).
If you want real raw data, you have bitmap-printer.
Post automatically merged:

Jayro said:
Can't you use an unused portion of RAM as a write buffer? That way the ram can flush to SD at whatever speed.
Click to expand...
Screenshot buffer alone would be 2.5MB. That's pretty big number for a sysmodule in post 21.0.0 space. 7 MB is even more than what Tesla overlays take.
 
Last edited by masagrator,
masagrator said:
@namename11 @AllOver write speed is not an issue here. Read my post again...

- PNG DOESN'T SUPPORT WRITING RAW DATA.

Just changing library from libpng to faster libspng allows cutting write speed of uncompressed png by almost half while taking the same approach (compressed one still is faster).
If you want real raw data, you have bitmap-printer.
Post automatically merged:


Screenshot buffer alone would be 2.5MB. That's pretty big number for a sysmodule in post 21.0.0 space. 7 MB is even more than what Tesla overlays take.
Click to expand...
How can you say write speed is not an issue? Do you know how shit fs is? Each write causes a resize. That's 720 resizes. If you set the file size to the max final size, then again at the end before closing the file, that reduces it to 2 resizes. Benchmark and you will see.
Post automatically merged:

Just to add, this 720 resizes is assuming that the buffer is big enough to store a compressed line. Otherwise it is more. Write a test that does 1024 writes of a 32k buffer, first test where you write the file as normal, and the other where you set the file size to 64mb and then shrink it at the end to 32mb. The latter will out perform the former.
 
Last edited by AllOver,
  • Like
Reactions: impeeza
Ok, my bad. Tested this on modified version of PNGShot with libspng and compression level 0. When reserving space upfront, it takes 6x less time to save.

Tested this on XCX with upfront 3MB.

Without reserved space - 4.26 s
With reserved space - 0.77s
 
Last edited by masagrator,
  • Like
Reactions: impeeza
Yep, that and multi threading is how maximize throughput. Not that I would bother with threading in this case personally as it's not worth the complexity and memory used, but in general native fs with reserving space upfront or in large chunks along with multi threading is the fastest you can go. Many homebrew do neither of this sadly.
Post automatically merged:

Oh I forgot this is all on core3, so threading wouldn't help at all.
 
  • Like
Reactions: impeeza
I thought the set size function only allowed you to make files larger for some reason? Guess I was wrong.

I actually found this out rewriting JKSV. If you know the end size of a file, creating the file with the size needed is a lot faster when writing than resizing and writing.
 
  • Like
Reactions: impeeza

Site & Scene News

Go to forum More news

Popular threads in this forum

Dusk for switch (TLoZ Twilight Princess port)

Ticobro - AIO Tico Management App

Homebrew  New Homebrew "Foil Server"?

Homebrew  Full List of N64 Recompilation Switch ports

Gaming  What are the oldest games available on Switch?

ROM Hack Tutorial GBA Emulator  FR/LG LayeredFS Ruby/Sapphire/Emerald Save Fix (ROM Replacement) — v1 (WIP)

Hacking  WiFi chip failing and can't boot. is it possible to enable Airplane Mode by editing system save files directly?

Hacking Emulation  Switch Prod Keys downloading from sites okay?