Anonymous edits have been disabled on the wiki. If you want to contribute please login or create an account.

Talk:Final Fantasy XIII

About this board

Not editable


Performance is still crap after patch. Locking it to 30FPS W 1/2 Refresh stabalizes performance at least

8
BONKERS (talkcontribs)
Mirh (talkcontribs)

You don't need v-sync and frame limiter. Use only the first if you are really sensible to tearing.. otherwise just RTSS if you want to stabilize framerate.

Anyway... you don't have microstutter because frametime varies a bit. You feel it only when there are massive frame drops. And this could even affect just little fractions of time (overlay refreshes only every second by default, remember)

Since CPU, nor GPU seems to be stressed when game stutters (which is evident during fight) my first theory would be: hdd access lag (that's the most common and simple cause, imo).

Though if you could check the exact framerate timeline (in MSI afterburner nvm, for example) it would be interesting to survey every frame one by one

Anonymous (talkcontribs)

FWIW it doesn't seem to be disk access either - I moved XIII+-2 back and forth on a high speed SSD and a regular HD and it made 0 difference. That said in FFXIII I get a solid 60 with my newest rig (G1G 970, Xeon 1231v3), but that's overkill for this app. I can't get a solid 60 on FFXIII-2 - amazingly, it is miles worse than FFXIII (DOF+DAI issues and additional forced inefficient post-processing). FWIW from a lot of hours of messing around it seems to revolve around said framing pacing and limiter issues and what your base GPU speed is at what the broken frame limiter decides to stick at. This may explain why overclocked GPUs can actually result in lower framerates. Just a theory like everyone else though.

BONKERS (talkcontribs)

You don't seem to understand what frame times are about. If those frames aren't delivered at the correct rate. This is microstuttering. Frames aren't being pushed out as fast or as slow as needed (which is supposed to be a flat 16.6) Thus the image isn't smooth. You don't have to be having framerate drops to be getting microstuttering.

Look at the panning in my shot, as it stutters along.

Mirh (talkcontribs)

Where for "correct rate" I think Ā±25% could even be accepted: but the problem in your shot (which is no longer available btw) is that frametime is sampled only once for second. That hides completely every issue with single frames that may happen.

The game may actually be requesting a frame every 16.6ms... but if one drops.. (and we can't be sure due to aforementioned reasons) then you would have to wait 33.3 ms.. and that's a big difference.
Nothing like that 2ms differences you seem to be worried of (and that really, I can't understand how could be perceived by humans)

BONKERS (talkcontribs)

Frametime polling rate isn't 1 second. It's ~500ms. Setting it to 100ms instead doesn't make much of a difference.

The video is recorded without vsync,changing the polling period to 100ms instead even with vsync the times are super variable (+- 2ms via OSD) But the variation is less so than without Vsync and there is little to no stuttering INFACT, with 60Hz vsync forced from Nvidia Inspector, there is far less microstuttering, but frame drops during battle still occur.

But then, look at this

Just look at how crazy this is, polling period 100ms, capped to 60FPS externally every so many frames one takes ~33ms to be shot out and this is just standing still. http://i.minus.com/iA76Sv5ksWOUt.png

Now look at the same with a game like Killing Floor Capped to 60FPS externally, flat line with spikes because i'm playing in windowed mode, which results in stuttering http://i.minus.com/iIpwzyJruGU6m.png

http://www.vortez.net/articles_pages/frame_time_analysis,1.html http://www.anandtech.com/show/7195/amd-frame-pacing-explorer-cat138 http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools

Mirh (talkcontribs)
Mirh (talkcontribs)

my final fantasy won't open

1
Dragonfire (talkcontribs)

I have already tried to use the site's method, and I tried to search for help on other sites and nothing, I would like some help with this problem

Mirh (talkcontribs)

Game videos format has been "deciphered".
Now I see 2 possible ways to achieve blu-ray quality:

  • Convert PS3 videos to bink (quality degradation expected)
  • Hack the game to make it read PS3's H.264 and ATRAC codecs (libavcodec being the library of choice probably)
Garrett (talkcontribs)

Bink's compression level is highly configurable (1080p instead of 720p would also really help), so that shouldn't be a big problem. Bink 2 isn't available in the RAD Video Tools but the topics you linked to indicate that the game will also accept videos in Bink 1 format.

Mirh (talkcontribs)

Sure, but you are still compressing again an already lossy compressed video.
Doable, but not optimal

BONKERS (talkcontribs)

Hopefully they come up with some good workarounds.

I've yet to see any good encodes with bink ever. But hopefully that can change

Links for the soundtrack mods seem to be down.

2
BONKERS (talkcontribs)

Does anyone have backups of them they can mirror here?

I don't get a bunch of the keypoints in this page.

1
JohnTHedgehog (talkcontribs)

First of all, I don't know what use that has for the reader. It's not something to keep in mind when deciding to purchase the game, and it doesn't break anything if you already bought it, so I removed it.

And what does "software upscaler support" means? Is it the upscaler they used for the PS3 version? Again, why does it matter when almost no game on PC does that?

Macroblock-like hair artifacts mach 2

11
Anonymous (talkcontribs)

Just a heads up that this edit was just meant to make it so that the guide was linked directly in the fix instead of as a reference, not a revert. The fix template doesn't like direct links in the main header, so I basically took a trimmed version of my old explanation and give the long one below. BONKERS completely replaced it previously, as it was a bit too general by itself. Hopefully it's technically accurate (guide version is still below).

The eventual goal is to move some version of it back to essential improvements (unless Square fixes it by then...... yes, you can stop laughing now) after I digest what BONKERS has told me and the related information and turn that into something coherent. Long story short and incomplete it's a Fermi+ fix and doesn't appear on the XXXX line, and may be strictly a Fermi+ issue (4XX on).

P.S. originally the page was NVIDIA, so I changed those occurrences to be all caps. It seems inconsistent everywhere, especially on the articles here, but I think the correct spelling is Nvidia?

Garrett (talkcontribs)

The linking feature can be disabled by adding the link=false parameter to the template; I'm personally of the opinion that the link function should be removed entirely because of this sort of problem.

EDIT: Nvidia use all caps to emphasise the brand (many companies do this); writing it as Nvidia is fine (Wikipedia does this) since it's not an acronym or special casing (unlike GeForce). This wiki currently has no standard in this area.

Anonymous (talkcontribs)

Thanks. For some reason I could get it to work with the NVIDIA Inspector link but not the guide link - it would always turn all the text to "

{{1}}

" with the Guru3D forum guide link. I tried doing raw HTML and it worked that way (but later did a reorg of the page so I wouldn't have to), and it seems to be the Anchor template that it's wrapped in that's causing issues.

Also went the Wikipedia format for Nvidia, as that what incoming edits were using.

Garrett (talkcontribs)

If a link has an equals sign in it (as with the Guru3D forums) you'll have to specify the number for the template parameter (like {{Fixbox/fix|1=Some description}}) otherwise the equals sign in the link will be interpreted as a parameter.

The fixbox linking feature has been removed so that aspect isn't an issue now.

Anonymous (talkcontribs)

EDIT2: OK, I understand the other problem here.

Interesting. Yes, it does work with the 1=, but still bugs out without it. I'd say that was intended if the other link didn't work either.

It seems like the arguments are being passed correctly from the fix template, but the anchor template itself doesn't like it without the 1=? Take

{{Anchor|Follow [http://forums.guru3d.com/showpost.php?p=4936011&postcount=2444 this guide] under}}

Which gives: {{{1}}}

Now take:

{{Anchor|1=Follow [http://forums.guru3d.com/showpost.php?p=4936011&postcount=2444 this guide] under}}

Which gives: Follow this guide under
---

Currently all the anchor template is:

<span id="{{{2|{{{1}}}}}}">{{{1}}}</span>

It's literally including the entirety of the fixbox header as a span id for the anchor since we aren't passing a second argument to T:Anchor through T:Fixbox (I find this incredibly wasteful now that I think about it...). However, if there's a quotation mark in the anchor header (with or without 1=) it just puts an empty span tag there instead that I assume is put there by the wiki parser (I assume the intention was anchor fixbox headers, but having to anchor and reference it using the fixbox header text that useful?).

Quoation example:

{{Anchor|Quotation "killed" the span id}}

Which gives (note no span id): Quotation "killed" the span id

Which kills the span id in the full sentence, which made this response turn out weird before edits (again, no span id): Follow this guide under the section "GeDoSaTo Setup" to create a driver profile for Final Fantasy XIII and enable the "AntiAliasing Fix" to fix block like artifacts on character hair

Garrett (talkcontribs)

The equals sign and quotation mark behaviour are technical limitations of MediaWiki.

I've removed the anchor feature from this template since it is also a remnant of the unused fixbox linking capability.

BONKERS (talkcontribs)

Ah, I had to experiment a lot to get the text/links to be presentable at all. I was wondering why I couldn't fixbox with a text link. Sorry, had to try and work around that. The way MPM did it now, works very well I think. Better than what I could come up with I suppose.

Though I still think there should be a link to the video, I'm just nitpicking I guess. Especially since my post on Guru3D has the video linked twice!

Mirh (talkcontribs)

Considering you are already linking the solution in your Guru3D post..
why not "porting" the instructions here?

And if it's too much for a fluent reading, well... it may be time for a dedicated GeDoSaTo article then

BONKERS (talkcontribs)

It is quite a wall of text. The guide itself has a lot of links and what not too.

Dunno.

Anonymous (talkcontribs)

IMO it's high time for an article on GeDoSaTo in general considering its wide and flexible support now.

Anonymous (talkcontribs)

The reason this is here is because the Steam page advertises "A game controller using Xinput is recomended for this game" for the system requirements. Otherwise it wouldn't be an issue.

EDIT: Forgot to mention that it breaks links with XIII-2 article, which has the same thing.

Mirh (talkcontribs)

You have a point.

Though, the "solution" and the wording of the explanation in the issue fixed section is quite bad.

Especially the "basic=DirectInput" part (I mean, aside of the wrong simile, it's not like you find a driver on the street)

I know it may be long to explain, but that's why we have Glossary:Controller page (whatever what is written in this fix mean)

Anonymous (talkcontribs)

Point taken. TBH I'm not 100% sure how to put it into easy to understand layman terms - I'll try my best to explain it here, maybe this is too technical and not "issue-driven" enough, but I'll give it a shot. Typically there are 2 drivers for XInput controllers: a XInput driver and a HID driver.

For example, a wired Xbox 360 controller will having the following in Device Manager in Windows 8:

1) Human Interface Device->HID-compliant game controller: This handles Kernel level HID calls and associated APIs including RawInput (and the depreciated DirectInput which wraps around RawInput).

2) Xbox 360 Peripherals->Xbox 360 Controller for Windows: This handles XInput calls.

Each driver has its own options/preferences. With XInput controllers a HID driver isn't required, and even for those with one it can be disabled or even uninstalled and still have it functional for apps using XInput. This leads to the issue at hand where one driver or the other gets disabled, removed, or in rare cases never installed to begin with.

If someone did understand the above, the challenge is to put in layman terms, like "Make sure you have a HID driver for your controller installed and enabled".

Mirh (talkcontribs)

Whatever your source for these info was, it wouldn't be bad to have similar behaviors explained in the glossary:controller talk page

Anyway, what I wanted to say is that you don't usually just "install basic drivers" for controllers. You only have one (SCP driver and XBCD aside)

Garrett (talkcontribs)

The game is essentially working as intended. x360ce has no effect because it only targets those specific DLLs (it does not work with DirectInput or raw input methods). I have replaced the mentions with a note under system requirements.

Anonymous (talkcontribs)

I'm not sure what x360ce has to do with this, as I was talking about Windows driver issues (if you didn't understand my post that's fine). Also, was the removal of the controller recommendation from the table itself intentional? Just wondering. I'll try to roll with this and change XIII-2 as well.

EDIT: I was just wondering if you understood the issue (admittedly involved) as you keep attributing it to something else like x360ce and it's puzzling me, because as I mentioned above if it's recommending an XInput controller and doesn't use XInput it will use the wrong Windows drivers and thus not working as intended causing driver usage issues. It's OK if nobody gets it, I'm being verbose anyway.

Garrett (talkcontribs)

The Steam topic from the reference was regarding x360ce. Essentially, this is not a game-specific issue.

I removed the 360 controller recommendation from the system requirements since it led to this expectation. I'll redo it as a note instead.

Anonymous (talkcontribs)

Amusingly this is somewhat game-specific to FFXIII and FFXIII-2, and the source I referenced explains why (Knurek on NeoGAF), though you can test it yourself in a variety of ways including the utilities on PCGW: "The fact that FFXIII team wrote it's own XInput implementation, instead of using readily available xinput.dll, really shows just how much SEJapan doesn't get PC developing."

Knurek is saying that instead of using the XInput DLL or XInput's driver interface, SEJ rolled their own "XInput implementation" (in this case using DirectInput) according to the documented button layout for Xbox controllers without realizing they didn't actually implement XInput at all because:

1) DirectInput uses the controller's HID driver path (outside of hooks it's similar to RawInput's HID interface in XP+), while XInput runs on a separate driver path (the Xbox 360 controller drivers supplied by Microsoft don't implement vibration or the LT+RT buttons in the HID path, for example).

2) Various third party programs rely on XInput DLL hooks to provide alternative behavior.

You can still use XInput without the high level interface in xinputXX.dll, though nobody in their right mind does so because of #2 and the pointless added development time.

Then again, this appears to be flying past everyone's heads here (it's not complicated at all to me, but like I mentioned I have a decent amount of wingamedev knowledge which appears to be making it difficult to explain in a simplified manner), so I'll still leave it as is and just make a correction to your version.

Full screen is borderless fullscreen windowed?!?

6
Anonymous (talkcontribs)

An edit a couple months ago an edit changed the borderless fullscreen windowed from "Use Windowed Borderless Gaming. Start the game in windowed and add it to the program. Then use the program to adjust the window to your monitor resolution." to "On by default. Set to full-screen mode in launcher."

As far as I know, this still uses normal full screen mode in DirectX when full screen is selected in the launcher, or am I wrong? The standard fullscreen behavior still seems to apply when I run it. Also, if it is borderless fullscreen windowed mentioning "on by default" makes no sense as there's no 'normal' full screen option available in that case.

Mirh (talkcontribs)

I don't think we actually care if the game is running in "complete" (was exclusive the right word?) fullscreen or just borderless windowed (as long as the screen is 100% used by the game content it's fine imo)

Said this, I know nothing about this game.
I found this though

Anonymous (talkcontribs)

If that's the case, why bother mentioning borderless fullscreen windowed at all (TBH it is a dubious now with most articles just noting it as a hack with a reference to a common 3rd part tool)? However, there are obvious differences between traditional full screen and windowed full screen: rendering, vsync/tearing, performance, and multitasking behavior. Either way that seems like a discussion best taken to the general forums as it affects about 1,000 articles.

BTW the link is referring to Gedosato options (3rd party). Maybe the editor had a 3rd party tool running and did not realize it. I guess I'll eventually revert that section to the norm for articles as retesting confirms fullscreen is still traditional fullscreen and windowed mode still has borders. Thanks for the input!

Mirh (talkcontribs)

We mention borderless fullscreen windowed because clearly, that has the advantages of windowed mode (fast alt-tab) with the immersion of fullscreen mode.

I mean.. Especially in the past exclusive fullscreen could be awful in some implementations

and besides, it was the only fullscreen available
so that's why if a game supports it, it's not a news

Garrett (talkcontribs)

Exclusive fullscreen does not count as borderless.

An easy test for borderless is to open some windowed program (e.g. Calculator) while the game is running. A game running in borderless windowed mode will remain visible behind the windowed program whereas a game running in exclusive fullscreen will be minimised when the focus switches to the other program.

Some games don't have a dedicated borderless option, instead hiding the normal window border when the desktop resolution is selected in-game. A few games use borderless by default, and some don't have an exclusive mode (e.g. all WinRT games from the Windows Store).

RaTcHeT302 (talkcontribs)

I always thought it was a "faux borderless" mode, but at least I know the actual name nao.

Removal of Radeon Pro reference

5
BONKERS (talkcontribs)

The reasoning here is that GeDoSaTo natively supports enabling EQAA for Nvidia cards via it's FFXIII specific configuration file.

Any Post-Processing or Post-Processing Anti Aliasing forced on top from Radeon Pro will only apply post resolve, so if your TV/Mon is 1080p and are rendering the game at 4k, it will only be applied after it is resolved back to 1920x1080.

Adding PPAA on top of MSAA is generally not a great idea. Both SMAA and FXAA will effectively reverse anti alias a lot of what MSAA does. The only way it will work well and resolve without major issues is if you are downsampling in conjunction. Problem being here that SMAA/FXAA from within GeDoSaTo for FFXIII are not supported yet. So RadeonPro doesn't have much use.

GeDoSaTo supports Post-Processing that is basically the same as SweetFX natively, that will apply pre-resolve at rendering resolution and before the UI pass.

Anonymous (talkcontribs)

Thanks for the explanation, now I know not to overstack AA with RadeonPro. BTW "EQAA for Nvidia cards" had me really confused at first until I read the GeDoSaTo notes (CSAA for NVIDIA and EQAA for AMD). Just making a note of that for future readersĀ :).

BONKERS (talkcontribs)

EQAA and CSAA are both parties equivalents. Though with Maxwell IIRC CSAA was removed.

But a differeniation is a good idea so people don't get confused.

Timothy Lottes, creator of FXAA used to have a blog post on Combining MSAA with FXAA and the problems with it, but he deleted all of his old post.

Mirh (talkcontribs)
BONKERS (talkcontribs)

Any potential reference did not seemed to be captured.

I will continue looking.

There is mention in a lot of the FXAA 4.0 blog posts (Which is an unreleased version of FXAA) about using a Spatial only filter that helps FXAA work on top of MSAA without issues for example

There are no older topics