Template talk:Problems: Difference between revisions

From Dolphin Emulator Wiki
Jump to navigation Jump to search
Line 54: Line 54:
** [[Def Jam Vendetta]]
** [[Def Jam Vendetta]]
* Unlimited VPS
* Unlimited VPS
** [[Need for Speed Pro Street]]
** [[Need for Speed: ProStreet]]
** [[Excite Truck]]
** [[Excitebike]]
** other NFS titles
** other NFS titles



Revision as of 13:26, 21 December 2015

Other Shared Issues To Look At

Let's be careful not to go *too* merge happy with problems! For issues that only have two or three entries, I don't really see the need for it. Also, we need to be careful about association! The heat blur issues aren't really related, and I would be opposed to those. But the banding problems are related, since they use the same engine. Let's be careful! - MaJoR (talk) 10:02, 13 December 2015 (CET)

Naming Convention

I think I was in programming mode when I set this up initially without spaces in the titles. I'm guessing there is no good reason to handle them that way. Should these be revised to include spaces, and otherwise extend them, to make them them easier to identify? Kolano (talk) 22:14, 17 December 2015 (CET)

Noting Additional Data

Various shared problems have additional data tacked on to the end of statements (screenshots, particulars of the issue for that title). I think we may want to handle that differently so we can be aware of such content when these issues need to be cleaned up. Some strategies:

  • Just ignore it, always remember to postfix something like ".*?(?=== )" to the ends of search 'n replaces used to clean these up (i.e. followed by "== "). (My regex syntax may be off there). Though something a bit more complicated would be needed to account for shared problems following one another.
  • Add notes regarding the post-fixed content on each shared problems documentation page, and be careful cleaning shared problems with such text. We probably should have some standard documentation of it in any case.
  • Pull the content into the shared problem in some pay (i.e. provide additional parameters). Though this probably makes the clean-up steps equally hard as with the "ignore it bullet", so perhaps not a good solution.

Please chime in with opinions/other ides. Kolano (talk) 22:14, 17 December 2015 (CET)

Black Bars

As is apparently common with GameCube titles this game adds black bars around the edges of the screen to avoid gameplay being covered by television bezels. Figured we should probably have a common {{Problems}} template for such, but want to get some further details first. How it works seems to be a bit odd, at least for this title. Here I get black bars at startup (in 4:3 mode) and all the time if in fullscreen mode, but if in windowed mode /w Auto AR and Auto Adjust Window Size no side black bars are seen. In any case hoping someone can chime in regarding some of the details with titles and black bar edges. Kolano (talk) 05:54, 2 December 2015 (CET)

AFAIK enabling "Crop" option in Graphics settings should get rid of those black bars in recent revisions. Have you tried it? - Jhonn (talk) 16:32, 2 December 2015 (CET)
Noticed that last night, but didn't have a chance to try it. How "smart" is the cropping? Different titles left a variety of different sized gaps; some only on one pair of sides, some even allowing fine grained control over their coverage area. Kolano (talk) 22:57, 2 December 2015 (CET)
Perfectly smart! Described in a progress report here To poorly describe how phire put it when he told me about it, it uses the area that the game tells the hardware it will render to within the rendering space. It will eliminate all black bars, period! And it does it by zooming in, instead of the old squishing method (which can be achieved by using stretch to window). - MaJoR (talk) 12:27, 3 December 2015 (CET)
OK, question spew...
  • Any chance we'll still see "a full blog post ... coming later to explain all of the technical details."?
  • What's the feeling on how we should handle titles with black bar issues? Would a {{Problems}} template be appropriate for them (the review process for this seems pretty large though :-\ )?
  • "Crop" is defaulted to off, should we be recommended it be turned on for titles /w black bars (or perhaps in general)?
  • Do we know how crop works out on titles that allow redefining their AR? I'd need to reference back through the recently GC Widescreen test titles, but at least one provided individual adjustments for both the horizontal and vertical (and possibly also allowing an offset for an uncentered image).
Kolano (talk) 20:15, 3 December 2015 (CET)
I'm pretty sure all of the recent "black bar" problems are invalid. ALL games will have small black borders around them now with crop off, and this is by design. I think this black bar things that keep popping up are just people seeing the black and adding errant problems because they don't know how it works. Honestly, I wish phire had set crop to on by default to avoid that. :/ As for any issues with crop... there shouldn't be any. And crop works on games that redefine their Aspect Ratio. Much like how aspect ratios are handled now, crop uses what the game tells the console, so it is extremely reliable. The auto widescreen detection algorithm could have some problems, however, but they would be separate from crop. Also, if by black bars you mean something like what the Metroid Prime 2/3/Tri problem? That's very very different and unrelated to all of these!
As for the article... ask phire. He's been procrastinating it! Also, if you want any information at all on this, phire knows all about this, and he can fill you in.- MaJoR (talk) 04:48, 4 December 2015 (CET)