Would you like to get all the newest Gaming News from
QJ.NET in your email each day?
Want to learn more about the team who brings you the QJ news?
Read about them now!
This is a discussion on Mootjeuh/PCT's Screenshot Plugin within the PSP Development Forum forums, part of the PSP Development, Hacks, and Homebrew category; Originally Posted by mootjeuh get working on pausing the XMB Why? Just why? This limits the plugin to the XMB ...
ok so I took a few snapshots. only of stuff available in the xmb since I can't play games with the plugin on.
same as before with the links.
this is the xmb. it's a good snapshot since there's nothing much going on
I tried taking a screenshot of a picture but I forgot L goes back one picture. so this happened
Save data Utility
playing a sound file with the visualizations on. It can out pretty messed up.
mhfu has that video icon so it was playing while I took the screenshot
Last edited by elite999; 03-11-2010 at 10:35 AM.
I need to thank elite999 for editing the url for the pictures.
Only 6 more posts until you can post them yourself :)
Definitely looks like screen tearing, a simple wait until vsync would suffice I should think, when/if mootjeuh uploads the source I'll take a look and see what we can work out.
I'm not sure what screen tearing means, but if by waiting for vsync you mean pausing the screen until the picture gets saved the it'll just be a jpg version of fusa screenshot. I was liking that mootjeuh's plugin saved the picture in the background without pauses. I'm sure thats why we get 'tearing', it would be nice if there's no pauses. unless the pause is only a split second.
5 more to go!!!
There would be a very minor pause, but in theory only 1/60th of a second, so you shouldn't even notice it.
I'm just about to dart off to work but I'll explain VSync when I get back later and how it removes screen tearing as the wiki article can be a bit complicated if you don't understand all the terms.
Going to try and explain this in layman terms so hopefully understandable if you've not done any programming!
For graphics as a general rule you have 2 blocks of memory which contain graphics, the primary buffer and the secondary buffer.
When the off screen buffer has been written to, the buffers are 'swapped' (flipped) so that the off screen buffer is now on screen, and the previously on screen buffer is now ready to be written to.Code:Primary buffer: *on screen* Secondary buffer: *drawing buffer*
flipped:Code:Primary buffer <- on screen Secondary buffer
flipped again:Code:Primary buffer Secondary buffer <- on screen
When VSync is enabled the buffers only get flipped when the monitor is ready to refresh (based on the refresh rate), and only if the buffer is completed. If the buffer isn't complete yet then the system will have to wait for the next VSync before it will flip the buffers. For this reason VSync will slow down graphics and also limit the framerate to the monitor refresh rate, on the other hand there is no tearing.Code:Primary buffer <- on screen Secondary buffer
When VSync is disabled the buffers get flipped as soon as the monitor is ready to refresh, even if we are only half way through filling the buffer. Imagine we have a grid of squares, 4x4, the buffer is in theory 16 long. If we previously filled this buffer with all red squares we would have this:
Now we're drawing blue, but unfortunately our system is a tad slow and has only managed to get through 7 changes, we now get this:Code:Draw 1: RRRR RRRR RRRR RRRR
Code:Draw 2: BBBB BBBR RRRR RRRRIn comparison with VSync we'd getCode:Draw 3: RRRR RRRR RRRR RRRR
Code:Draw 1: RRRR RRRR RRRR RRRRCode:Draw 2: RRRR RRRR RRRR RRRRThese examples ignore double buffering but gives you a basic understanding of what VSync is and why it is important. Consoles use VSync to avoid tearing, PC games give more control and a lot have VSync disabled by default so we can squeeze the most speed out of games as possible, Crysis being one of those games that's nigh on impossible to play with VSync maxed out, so most people with high end cards would be willing to put up with tearing to get the best graphics possible rather than lower graphics and have no tearing.Code:Draw 3: RRRR RRRR RRRR RRRR
[epeen]For the record my system is powerful enough to max Crysis at 1080p and have VSync[/epeen] ^_^
I learned alot today. So I guess we do have a case of screen tearing.
You're welcome SupaStuff. :)
Auraomega, some homebrew have VSync implemented. Mostly in emulators. The slow down is noticeable though, since the GPU isn't up to the standards. Correct me if I am wrong.
2. http://slicer.gibbocool.com/ stay updated on all my projects
3. it'll be 5 years in june, that's nearly 1/4 of my life on this planet that i've visited these forums, what a ride it has been
Slicer pretty much nailed it; the graphics in emulators is generally not that difficult to do for the PSP's GPU, but it's the time taken to convert the (in Slicer's example) N64 graphics calls into PSP graphics calls. Where the N64 may only have had to make 1 call for a certain function, the emulator will have to read that call, convert it into a related call on the PSP, and call those groups of functions (as it may be more than 1 to do the equivalent), couple this with the fact there is a lot of graphics being rendered and what may have been 50 calls on the N64 turns into 50 reads, conversions, and maybe 350 calls; this is what ultimately slows down emulators.
As Slicer said though, the PSX emulator is powerful because it's based around a similar architecture, which means there's more 1-2-1 calls; also Sony having been the creator of both systems have full documentation, have large teams of professional developers whose job would be to create this, and the fact they're going to get more money if it's successful (which it was) gives them a much better starting chance than the homebrew devs who attempted a PSX emulator in the past.
...but yes, VSync wouldn't help issues because as I said, if it misses a VSync 'call' by even a single clock you have to wait just under 1/60th of a second before you can draw again, 1/60th of a second might sound very small, but it could reduce the framerate drastically if your GPU literally just misses the switch every time. I believe this is why developers are using triple buffering more often as when you've filled in the second buffer but waiting for VSync, you can then proceed to fill the 3rd buffer which may be half complete by the switch, leaving you with only half the buffer left to fill and thus the screen will be out quicker; unfortunately this method has the downside of requiring more memory and giving a noticeable input latency, all these trade-offs, it's just about finding the right balance I guess!
Finally! It's the weekend and I've done some working on the code and now, it takes a BMP screenshot, there is no tearing, and the size of the plugin is 12 KB. But the only two downsides are that there is no user-defined combo, and it takes 5-6 seconds to take the screenshot.