Also, I don't think I said anything in that post that actually indicated that I was talking rubbish. I simply said that it might help reduce input lag -
It clearly mentions that here. In what way was what I was saying not making any sense then? I didn't state anything out of the ordinary other than what this article just stated here. I didn't make up any grandiose claims or anything like that either.Quote:
In other words, with triple buffering we get the same high actual performance and similar decreased input lag of a vsync disabled setup while achieving the visual quality and smoothness of leaving vsync enabled.
I said this:
which is exactly what the article stated. Word for word. So the only thing that could be misconstrued as saying that I don't know what I'm talking about would be for me to say that DOUBLE BUFFERING in GENERAL would just plain suck. I didn't mean it like that at all. If that was how it sounded like, then it's a misconception.Quote:
According to this article by Anandtech, there are almost no downsides to triple buffering compared to double buffering. If anything, it will help reduce input lag (according to the article).
It also ends that section with a caveat that on recent GPUs this might not even be a problem, like is stated here:Quote:
I've read that article. But you might want to consider what TweakGuides.com has to say about Triple buffering - that it actually increases control lag. Simple theory behind this is - more time is required between user input and the time it takes to fill 2 backbuffers and swap.
And this is exactly the reason why ive made it a selectable option.
TweakGuides.com - Gamer's Graphics & Display Settings Guide
In any case, I can measure clear improvements when using triple buffering on PS3. Your mileage may vary, and input lag might manifest itself on systems with a different input device (as in - the monitor/TV). But I think it's pretty crazy personally to leave it 'off' by default just because of the tiny potential that it 'might' introduce control lag.Quote:
However it appears that most recent graphics cards and most new games will not experience major problems by enabling Triple Buffering. Given the fact that it can help to both remove tearing while also preventing the significant FPS drop encountered when VSync is enabled, it is at least worth trying for yourself to see the results on your system.
I have nothing against including it as a toggleable option - in fact, I want to introduce an option like that myself for SNES9x PS3 and so on, but I recommend it should be turned on by default, and when in the odd chance that it might introduce control lag, it could be easily turned off.
If you've read the NeoGAF forums - back when the CFW first broke and the first CFW 3.55 versions of FBA were trickling in, they were all bitching and moaning about input lag and the overall slow speed. They were complaining about nearly all the emus in this regard. So it isn't like this feature is going to magically introduce those issues, and it isn't like I would help establish that or anything - they're pre-existing issues some are having.
1080p (1920x1080) - 4:3 (Scaled) - Triple buffering enabled
You can run the curved CRT shader (or the CRT shader which I personally prefer) at 1440x1080 at fullspeed using 16:9 though. This isn't possible with triple buffering turned off. Triple buffering really makes a huge difference in terms of shader performance and also the performance of various games - screen transitions in Street Fighter III (all three of them) are far smoother and there's less audio breakup. Same with Vortex / Star Fox 2 in SNES9x PS3. Double buffering definitely blocked on video - the only concern now is whether it aggravates control lag.
FBANext PS3 - r423 - Custom build v2 (FW 1.92/FW 3.15/FW 3.41/CFW 3.55)
Multiupload - fbanext-ps3-r423-custom-v2.zip (20.41 MB)
Uploadbud.com - fbanext-ps3-r423-custom-v2.zip
Included is a diff patch intended for Lantus - so these changes can be carried over into mainline FBA.Quote:
CHANGES SINCE last custom r423:
* New input code
* HD shaders - as with SNES9x PS3, 4xSoft-HD looks the best
I think it's generally expected of users to update their ROM sets in one way or another whenever there is a core update of FBA.
In this case - it would entail you just updating your romset. Simple as that.
I changed this line in src/burn/misc/pre90s/d_tecmo.cpp:
back to the way it was before:Code:
data = (data << 8) | (data >> 8);
and voila - colors are restored - no more green tint.Code:
data = swapWord((data << 8) | (data >> 8));
Another 'improvement' that isn't really noticeable to the user is that I now use CELL_SDK_VERSION (which is defined in an SDK header file) instead of some specific defined preprocessor switch (PS3_SDK_1_92) - so you no longer have to comment and uncomment those 1.92 lines in the Makefile to compile with either 1.92 or 3.41 SDK - it will basically autodetect which SDK you're compiling with.
I also updated the HD shaders (which are not really 'HD' shaders in a sense - what they do is - they do 2x scaling and then just apply the shader algorithm) - the resolution of the texture is now hardcoded to 768x448 instead of doing something like (0.499/IN.texture_size.x) / (0.499/IN.texture_size.y) - I arrived at these values for the resolution by basically multiplying 368 x 224 by 2 (368 x 224 is the resolution CPS1/CPS2/CPS3 games used). Most games on FBA have a native resolution of either 320 x 224 or 368 x 224 - this 2x scale seems to cover both bases equally well.
A heads-up to Lantus - there are some more games with palette/color issues - I think some of them got mentioned on the Issues Google Code project page -
1 - Prehistoric Isle in 1930
2 - Detana Twinbee - Konami TMNT2 hardware - weird corrupted graphics at one point and the enemies don't move and stay fixed to a certain position - so the game for all intents and purposes is broken. Probably endian issues in the Konami TMNT driver.