User talk:Mbc07

From Dolphin Emulator Wiki
Revision as of 18:33, 30 April 2017 by Kolano (talk | contribs) (Formatting guidelines for processor speed under testing)
Jump to: navigation, search

Want to say or ask something? Just click "Add topic" above, I'll get into it when possible. Jhonn (talk)


21:9

I presume you'll want to revert the recent update to 007: Nightfire‎ (i.e. 21:9 AR Code). I don't mind following that convention, but if we do we need to document it under Project:Wiki_Conventions. We currently don't document acceptable ARs. Kolano (talk) 04:58, 1 March 2016 (CET)

I tried to dig the talk page where we discussed this but I couldn't find it. As far as I remember we were close to getting a consensus to add only 16:9 codes I think, because we started having a lot of weird AR codes popping out, taking a lot of space in the (at that time) patches section (48:10 or similar in Super Mario Sunshine? Don't remember now). Theoretically an existing (and decrypted) 16:9 code can be turned in any other AR by just adjusting the values so in future I would like to investigate the possibility of doing something allowing the user to get different ARs without cluttering the page with various codes that looks almost like duplicates (except for the value bytes, of course). I'm not sure either but MaJoR seems to prefer sticking to 4:3 and 16:9 only too. Anyway we need to get this sorted out soon (I'll wait reverting the 007 code until we conclude this) - Jhonn (talk) 05:57, 1 March 2016 (CET)
Looks like this is going to be easy.

Enhancements

16:9 Aspect Ratio

Green texts are modifiable aspect ratio value. Check here for other aspect ratio values.

NTSC-U

040037A0 3C608000
040037A4 C38337AC
040037A8 4805ACBC
040037AC 3FE38E39
0405E460 4BFA5340

PAL (English)

8C05F4BC 7C7E1B78
040037A0 3C608000
040037A4 C38337AC
040037A8 4805BD1C
040037AC 3FE38E39
0405F4C0 4BFA42E0
00000000 40000000

...

Yep, they're for AC lol. The second sentence in there is when we want to create "Other Codes" guide page (or how we want to name it) that will list many different AR values and list other codes like frame rate codes other than 60. Any feedback? Lucario (talk) 09:28, 30 April 2016 (CEST)
It's somewhat how I thought, but there are some flaws. The first (and probably the most important) is how are we going to keep track of the values? They won't be the same for every game, and on this mockup I see you're linking to another page where it seems we would store a list of values? If that's the case, in long term it's going to get bigger and messy... - Jhonn (talk) 08:24, 1 May 2016 (CEST)
We may have to list the correct value for each aspect ratio corresponding to the original modifiable value users find on the game page (in green text). As the page becoming cluttered over time, we probably shouldn't care. It's unified and better than seeing other users trying to clutter in each game page. But we may have to worry about modifiable value that is unique to a game though... ¯\_(ツ)_/¯ If that page comes into realization I'll try add a friendly rule saying that users should keep non-existent aspect ratio to themselves. Lucario (talk) 09:21, 2 May 2016 (CEST)
I'm a bit unclear regarding the need for 4:3 codes. I don't think too many will be trying to downgrade 16:9 games to 4:3. We should allow for some subset of more common AR's though. Clearly, 16:9, and 16:10 is also fairly common. Apparently 21:9 is fairly common as well (though I hate that it's naming is such marketing cruft, since it's really 21 1/3:9 and should be expressed as 7:3 if it were exact).Kolano (talk) 06:33, 1 March 2016 (CET)
I feel very strongly that *only* codes that increase 4:3 to 16:9 (the most common use case) should be allowed. Things can get extremely messy otherwise, and the more pick and choose we try to be, the harder it will be to defend against "if you accept this, why not accept this too?". By just firmly saying 4:3 to 16:9 only, that at least gives us something to say in those arguments that makes reasonable sense. I guess I'd be ok with a 16:9 to 4:3 code if it is a game that doesn't have 4:3 mode, but that seems super rare. - MaJoR (talk) 09:15, 1 March 2016 (CET)
I'm with Jhonn on finding a way to tell other users that they can modify the value in a given AR code to get a different AR. I'd like to say I don't support 4:3 code, but have realized I should because it will provide the code in the first address before the value for AR for the other users to use with their arbitrary AR value. I'm not sure how to provide AR code for the games that already support both 16:9 and 4:3. I may be in for 21:9 for this reason. Lucario (talk) 13:47, 4 March 2016 (CET)
Is there a consistent way to do this? Could we perhaps make a guide? Like, only list 16:9 codes (for the games that need it) and link to a guide that gives instructions for other ratios? - MaJoR (talk) 13:52, 4 March 2016 (CET)
Pretty much what I have in my mind. :) But I think it will be not much of help for the games that already support both 4:3 and 16:9 because we don't allow code for 21:9. Maybe in the end we just have to let other editors include 21:9. Then the guide will be useless either way. Lucario (talk) 14:32, 4 March 2016 (CET)
A guide is the perfect way around this. All we have to do is list 16:9 codes on the page, and link to the guide that instructs users to go to 4:3 or 21:9 or any other weird ratios they want! I don't see why anyone would have a problem with that solution. :D ...Assuming there is in fact a pattern or something we can teach in a guide, of course. - MaJoR (talk) 14:36, 4 March 2016 (CET)
Yes, it will have use for the 4:3 only games and then it will eventually teach users how to modify the code to 21:9 for these games. The games that support 16:9 will miss out 21:9 because there's no way to provide the game's unique code if we don't allow 21:9. Lucario (talk) 14:46, 4 March 2016 (CET)
Would you be fine with 21:9 if it's for games that already have 16:9 support? Lucario (talk) 09:28, 30 April 2016 (CEST)
With our current design, no, it would take too much space. However, if we could find a way to show those 21:9 codes without cluttering the page (I had some ideas a while ago but didn't try to get them on the wiki yet -- maybe soon, too busy ATM), I would probably be in favour given that 21:9 TV/Monitors seems to be getting popular nowadays. Anyway, if that ever happens in future, I would also want a very strict set of rules/reasons backing that to prevent future complaints like "if 21:9 AR is allowed, why not 48:10 or 5:4 or <insert any other weird AR here>?" - Jhonn (talk) 08:24, 1 May 2016 (CEST)

Why can't we have different aspect ratio codes on wiki pages?

On some of your edits that removed AR codes that allowed for 21:9 aspect ratios, you made it sound like those codes were not allowed. However, the wiki conventions state that adding AR codes for aspect ratios is allowed (https://wiki.dolphin-emu.org/index.php?title=Project:Wiki_Conventions). I would like to restore those codes, but wanted to make sure that there isn't a rule about it somewhere. I agree with you that the codes can clutter up pages, so instead of putting them on the page, are there any aspect ratio codes lists we could link people too? I know people can post them on game threads, but they can be impossible to find on threads with almost 100 pages, so I really think it would be helpful for people to be able to find aspect ratio codes right from the wiki page.

Currently we are only accepting 4:3 => 16:9 AR/Gecko codes or vice versa. We haven't explicitly stated that on the Wiki Conventions (yet) because we're still discussing some approaches to get other aspect ratio codes to the wiki (but with the whole release process of Dolphin 5.0 those discussions stalled). So, in other words, any aspect ratio code that's not 16:9 or 4:3 will get purged if added, at least for now. Meanwhile, until we finish with this mess, you can post them on the forums, there's a master thread just for them. - Jhonn (talk) 07:16, 15 July 2016 (CEST)

Formatting guidelines for processor speed under testing

This is a very small issue but it's been bugging me for a while. I use an i7 6700K processor at 4.0GHz speed when testing Dolphin. That is also the format I use for my testing entries - "Intel Core i7-6700K @ 4.0GHz".

As I understand the wiki guidelines for testing entries, we are supposed to write the processor so that it "Aligns with names used in Intel's Product Listing". On the Intel product listing page (https://ark.intel.com/products/family/88392/6th-Generation-Intel-Core-i7-Processors#@Desktop) the '.0' after the '4' is included.

Any time I have made a new test entry, another user - https://wiki.dolphin-emu.org/index.php?title=User:Kolano - has been editing it to remove the .0 at the end. I asked them to explain their reasoning for doing this but they did not respond.

I am aware this can be seen as nitpicking, but I would prefer that user not edit my test entries in this way, unless they are correcting a specific error, which I don't think is the case here. It feels like my contributions are being policed by a micromanaging user and the OCD in me is having a hard time with it.

Am I mistaken on how the processor names should be written? It makes sense to me to include the .0 at the end because '4GHz' could be misinterpreted, as if a tester accidentally abbreviated the entry.

My presumption is that general preference would be to omit needless excess specifications. 4 is 4.0 is 4.00 is 4.0000. Kolano (talk) 05:42, 29 April 2017 (CEST)

Generally our preference would be that the speeds weren't even indicated, as they aren't really relevant (and frequently aren't reported on correctly anyway). Kolano (talk) 05:44, 29 April 2017 (CEST)

I also think we should omit needless excess specifications, and we always did that anyway. And since we're talking about the speeds, I'm supportive of dropping them from all testing entries at "stock" conditions, including the speed only in the case the user overclocked their CPU. Cleaning up the wiki however would need a looot of work, especially considering base speed vs Turbo Boost speed - Jhonn (talk) 06:06, 29 April 2017 (CEST)
I'm a bit dubious that any overclocking is likely to effect things from a support/compatibility perspective enough for us to worry about. The clean-up would be fairly simple if speed indicators were just purged. Kolano (talk) 08:11, 29 April 2017 (CEST)
Although we overall don't focus on performance on the wiki, from my understanding the main purpose of the testing section is providing an insight of how well a game run on a given system configuration and a specific Dolphin version. In that regard, even a minimal overclocking of the CPU will directly affect the results and thus I strongly think the overclocked speed should be included in the test entry on those cases. Otherwise, for CPUs running at stock speed, dropping the GHz indicator is harmless since they're reflecting the performance all users of that CPU should get at stock settings... - Jhonn (talk) 09:31, 30 April 2017 (CEST)
I'm not convinced of that. Outside of very rare cases, there shouldn't be more than ~10% CPU speed improvement through overclocking (usually less than that), which seems unlikely to be truly significant to observed Dolphin performance. In general folks posting their overclocked speeds are just chest-thumping. Kolano (talk) 18:32, 30 April 2017 (CEST)
@Kolano If the guidelines were changed so that speed would not be included anymore, then certainly I would follow that. But at this time they instruct us to include the speed of the CPU ("Indicate CPU speed with a "@ #GHz" postfix listing the stock or overclocked frequency").
Yeah, that's unintentional. It wasn't covered that way because we really wanted speeds. More that that folks kept specifying them and, if so, we wanted it to be done consistently. Kolano (talk) 18:32, 30 April 2017 (CEST)
Regarding the formatting of the CPU speed - Though it is a minor detail, it's important to me that my own testing entries include the .0 appended at the end, It looks neater, more uniform with the CPU speeds of other testers, and it is officially how both Intel and AMD classify their products. Is that acceptable to you, until the guidelines are changed? Flang (talk) 08:18, 29 April 2017 (CEST)
That's a -1 from me. Even if we update the guidelines to "enforce" that, there's already thousands of test entries following the current guidelines and as such they would need to be cleaned up. TL;DR a lot of work just to accommodate a very small nitpicking - Jhonn (talk) 09:31, 30 April 2017 (CEST)
Whose nitpicking are you referring to? The manner in which I am entering my test info is consistent with the guidelines as currently written, correct? As I understand it, the editing of my entries has been to match Kolano's personal preference, not to make them consistent with the Wiki guidelines.
If the concern is the amount of work needed to clean up all the test entries to match each other, I would happily do all the work myself, beginning immediately. Flang (talk) 11:40, 30 April 2017 (CEST)
Yours. All similar ".0" entries on the wiki have been purged. There is no interest in adding zeros all over the place to make other entries consistent with yours (please don't), or having your entries be inconsistently handled. At the same time clean-up should be easy to handle, if we were to just purge the speeds, which I'd still prefer we do as it would reduce the frequent maintenance they force. Kolano (talk) 18:32, 30 April 2017 (CEST)