User talk:mbc07

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

---

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 MayImilae 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) - mbc07 (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... - mbc07 (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. - MayImilae (talk) 09:15, 1 March 2016 (CET)

I'm with mbc07 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? - MayImilae (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. - MayImilae (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>?" - mbc07 (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. - mbc07 (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 - mbc07 (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... - mbc07 (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)

Dolphin relies on two hard working threads and on IPC rate unlikely other applications, so even a small overclock could drastically improve Dolphin performance although it makes little to no difference in other scenarios. For reference, the overall speed improvement on "normal" use cases from the Ivy Bridge to Haswell jump was of about 10%, but on Dolphin that improvement were over 40%! We have some benchmarks on the forums and on AnandTech, I'll try to gather some real-world tests to better show what I'm talking about. - mbc07 (talk) 19:53, 1 May 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 - mbc07 (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)

So, it being "a lot of work" to change all the test entries isn't really a factor. Then I'm still trying to get an answer to my first question - Why are you editing my entries in the first place, since the manner in which I am making the entires is consistent with the Wiki guidelines? Flang (talk) 15:22, 1 May 2017 (CEST)

---

So, it being "a lot of work" to change all the test entries isn't really a factor.

Yes it is. All test entries across the wiki are currently consistent in the matter they omit the .0 thing, and we won't throw that consistency away. Updating the conventions to include the .0 means ALL test entries of ALL game pages (currently 3197 pages, and counting) must suddenly include it, and that's a lot of work just for a small nitpicking of yours.

Why are you editing my entries in the first place, since the manner in which I am making the entires is consistent with the Wiki guidelines?

It's simple, your test entries are being edited because they are not consistent with the current conventions, if you didn't get it yet . Also, you talk as if Kolano keeps lurking in a corner just waiting for your next edit but it just happens that Kolano reviewed your edits before someone else (like me or other active users), which would also purge your .0 thing you keep nitpicking. - mbc07 (talk) 19:53, 1 May 2017 (CEST)

---

Updating the conventions to include the .0 means ALL test entries of ALL game pages (currently 3197 pages, and counting) must suddenly include it, and that's a lot of work just for a small nitpicking of yours.

I already said previously that I would do all the work on every page myself to change any .0 test entries to all match each one another. The amount of work for you and everyone else would be zero, but this compromise was immediately declined.

And although you cite 3197 game pages that would need to be updated, only a small fraction of that total have any testing entries at all, and an even smaller fraction of that total have entries in which a tester was using a CPU with a speed of "x.0". The total number that would need editing would be no more than a couple hundred at most, with an edit time per entry of <1 minute. That's an hour or two of work, tops. So please be honest about how much work would really be involved.

Also, you talk as if Kolano keeps lurking in a corner just waiting for your next edit but it just happens that Kolano reviewed your edits before someone else (like me or other active users), which would also purge your .0 thing you keep nitpicking.

You appear to be mistaken - I made this test entry over 9 months ago. It was immediately edited by Kolano, then reverted by me. And that is how it remains now, still just as I left it. There were no active users in that entire period who believed it should be re-edited.

Just because we missed an edit doesn't mean everybody on that period believed it shouldn't be edited. Now that you brought it to our attention, it's likely going to have its .0 indicator purged - mbc07 (talk) 06:44, 2 May 2017 (CEST)

But I understand the message. Even though including the .0 suffix would be consistent with the Dolphin Wiki guidelines, as well as being consistent with how CPU speeds are written in other Wikis, both the general knowledge and emulation-focused variety, it is not how you want them to be written here.

I had hoped there could be a compromise (which would also be consistent with Dolphin wiki conventions, regarding disagreements), but it doesn't look like that will be the case. If I make test entries in the future, I will exclude the CPU speed, since based on the discussion here that would satisfy the current conventions and will be consistent with likely upcoming changes. Flang (talk) 22:37, 1 May 2017 (CEST)

Okay, there's some specific points I would like to talk on this one:

* Why should we be consistent with other wikis? Our test entries currently omits the .0 from the CPU speeds consistently on our entire wiki and that's all. There's no compromise nor we need to be consistent with how CPU speeds are handled on other wikis.

It's going to be how you want it to be, and there will be no compromise. I know that now. I gave several reasons why I believed it would be better to include .0 for CPU speeds near the beginning of this discussion (uniformity, visual coherency, consistency with the CPU manufacturers), but at the time I didn't have a good understanding of how this wiki operates. If/when you do update the guidelines, it may be helpful for other users to also update the section on disagreements to better reflect how they are handled here. Flang (talk) 16:50, 2 May 2017 (CEST)

"consistency with the CPU manufacturers" isn't true. Intel seems to normally show two decimal places, writing 4 as 4.00; but unclear they do that consistently. Kolano (talk) 20:08, 2 May 2017 (CEST)

My own preference would be to include both decimal places, so that the CPU designation matches Intel's exactly (I am interested to see pages where Intel deviates from that, if you would provide the links). Both Intel and AMD add a space between the speed and "GHz" at the end, which is also how I prefer to make my own test entries, again for the sake of neatness and coherency.

I initially thought keeping to a single decimal place with no space on the Dolphin wiki would be a compromise, as well as keeping with how CPU speeds are commonly displayed on most pages elsewhere on the Internet. But, no compromises here. Flang (talk) 21:18, 3 May 2017 (CEST)

I can be supportive of adding a non-breaking space to align with the stylistic guidance from BIPM, but such is likely to also be a pain to maintain. I'm still not onboard with adding excess decimal zeros. However, I still generally feel a single speed value is unlikely to capture actual performance characteristics well. There is simply too much scaling that occurs /w modern processors based on things like temperature/load. And we aren't going to get people to populate values appropriately to capture those sorts of details, or be able to back-populate them in pre-existing entries. I persist in a strong preference to simply purge the indicated speeds, which simplifies all this and likely has only minor impact on reported results (i.e. I still don't feel most overclocks effect things significantly enough to matter, even if a >10% improvement was seen).Kolano (talk) 22:12, 3 May 2017 (CEST)

That's not to say large improvements don't occur, I'm just unsure that such generally impacts the way things are detailed in reports. Few reports include FPS details, and similar to the Ghz reporting those that do don't / can't do so in a way that appropriately captures relevant details (i.e. is that an average FPS, the FPS at the moment the report was filed, the lowest seen or the highest, etc.). Kolano (talk) 22:18, 3 May 2017 (CEST)

* You keep referring to our own guidelines as if we're not consistent with it, even though we are. Perhaps we should rephrase that CPU speed section to better reflect how these speeds got handled during all those years since the way it's written currently leads you to that kind of "loose" interpretation?

I've never stated nor implied that your preferences are not consistent with the wiki guidelines, only that mine are consistent. Please do not misinterpret my statements. Flang (talk) 16:50, 2 May 2017 (CEST)

* About your future test entries, you should only stop putting CPU speed on your entries if/when this discussion get settled and the conventions get updated to reflect that. Even through there are intentions to simply purge the CPU speed from all test entries, nothing here has been officially approved. mbc07 (talk) 06:44, 2 May 2017 (CEST)

What are the current conventions regarding test entries where the CPU speed is not included? There are several such entries across the wiki. If the guidelines are such that we must either include the CPU speed or not make test entries at all, then I'll refrain from doing so. It would be a waste of time to go through the work of testing software on Dolphin if the data I provided would simply be deleted entirely. Flang (talk) 16:50, 2 May 2017 (CEST)

Currently the CPU speeds are included, so your test entries should have them. Excess specifications should be scrapped (e.g. 2.40 GHz => 2.4 GHz, 4.0 GHz => 4 GHz and so on). If you add new test entries not following this, your data won't be deleted, it'll simply be edited to fit those conventions (and that's what Kolano was doing with your recent test entries). Regarding the small number of testing entries which doesn't currently include the CPU speed, they're inconsistent and should be eventually edited to also include the speed, as that's our current conventions. - mbc07 (talk) 22:15, 2 May 2017 (CEST)

That statement is baffling to me. In the case that a user is running their CPU at a non-stock speed but did not include that information, you will edit their test entry by adding the stock speed of the CPU. The data presented will then be false, rather than incomplete. "Better to have bad information than less information" would certainly be a unique standard among wikis.

Today I have overclocked my own CPU. It would be sad to see my test entries changed to include false information, but that appears to be how determined you are not to give any ground. Flang (talk) 21:18, 3 May 2017 (CEST)

Again, why we'll never actually have consistent handling unless we generally purge the speed details. Kolano (talk) 22:12, 3 May 2017 (CEST)

Nickps

Could you please consider unblocking me? If you look at my contributions, you'll see I was trying to help. 2A02:1388:2189:5665:ACD9:E678:2ED6:E479 21:00, 31 July 2017 (CEST)

I've already unblocked you, sorry for accidentally catching your account in the backfire with the ongoing spam attack - mbc07 (talk) 21:03, 31 July 2017 (CEST)

Thank you. Nickps (talk) 21:01, 31 July 2017 (CEST)

"Although DSP LLE is a non-default setting, the issue is not fixed and we should keep track of it"

This is true. It's 100% better not to <s>XXX</s> it, my bad. Doesn't it affect the compatibility rating if it is in the Problems section? I think it (since it is a non-default setting) should alternatively be moved to Enhancements, Configuration or Emulation information. What do you think? Thanks! Kimishima (talk) 21:36, 26 July 2018 (CEST)

Well, Luigi's Mansion still have active problem entries besides the DSP LLE one, so, for now, its rating will remain 4 even if we move the DSP LLE entry somewhere else. I agree, however, that this specific problem shouldn't affect the compatibility rating. By our conventions, it can't go into Configuration since only non-default settings needed for most accurate emulation are listed here and it also can't go into Enhancements since DSP LLE isn't an enhancement nor a problem caused by an enhancement. Said that, I'm fine with you moving the entry to Emulation Information, although I would also wait for User:Kolano to chime in - mbc07 (talk) 05:32, 27 July 2018 (CEST)

I don't mind it being in Problems, I was just wondering. It's the first time I saw a non-default problem in there. I would wait for User:Kolano either. You two are much more experienced than me and both of you are doing great work! Thank you very much for contributing so many years to my favorite emulator of my favorite console (Gamecube not Wii of course XD) and thank you for letting me be a part of it. :-) Kimishima (talk) 11:09, 27 July 2018 (CEST)

I'd think it's a problem, so a Problems section is the place for it. It's first time to see non-default setting to actually be in Problems section that is as well met by your conventions. Lucario (talk) 23:43, 27 July 2018 (CEST)

Agree. What if we label non-default problems with "Non-Default: XYZ" to make it clear, especially for new users, that it won't affect people with default settings. I would then suggest (if we do that) to put it between 'default' and 'solved problems'. I'm wondering what you all say to it. By the way @Lucario: What is Super Smash Bros. Melee/sandbox? I think it looks interesting, but is it a modded version or something? I'm curious. Kimishima (talk) 02:47, 28 July 2018 (CEST)

Maybe give it with a little bit of rewrite to include mention of LLE being non-default? I think entry header looks fine. And, oh, Super Smash Bros. Melee/sandbox is just sandbox page demonstrating experimental templates and other cool changes, then maybe we'll have some new changes/features sprung out of it. Lucario (talk) 06:48, 28 July 2018 (CEST)

Absolutely! Some additional text warning the user would be good to include. Super Smash Bros. Melee/sandbox sounds awesome! Can't wait to see what happens to it over time! Great work! Kimishima (talk) 13:28, 28 July 2018 (CEST)

Chiming in a bit late here. We went through this whole discussion a while ago, when the "non-defaults" text/handling went into place. Per that former discussion, these non-defaults issues shouldn't be tracked, and numerous problems related to non-standard settings have already been purged from pages. Based on that/our current rules it should be purged out.

That being said, I have been concerned with handling it that way; and we already seem to make some somewhat arbitrary exceptions, such as listing some Direct3d related problems. I think the main concern with "non-default" settings is that there are a lot of them, many of which are likely to cause problems when inappropriately applied. We probably need to discuss how we want to handle these sorts of "exceptions". Perhaps the many problematic settings issue could be partially addressed with a more limited restriction, like only excluding "Graphics/Advanced" settings.

We also hoped to be able to more closely tie ratings with the existence of problems. If we want to open the scope of ptoblems tracked we should likely work out labeling to insure those problems won't impact ratings.

We should be cautious. both because we want to avoid needing to maintain and account for many issues with random settings, and to avoid encouraging setting non-default settings. The INI settings have greatly reduced the need to do so, and we want to encourage that. Kolano (talk) 08:05, 29 July 2018 (CEST)

Absolutly. I would suggest that a game tester doesn't need to test non-default issues we want to at least document (in an appropriate way) in the future. Suggestions for non-default issues we should track is the following. (Feel free to add or delete items to/from the following list. Just add [[User:X|X]] ([[User talk:X|talk]]) XX:XX, XX X XXXX (CEST) to your edit).

• DSP Emulation Engine
• Audio Backend
• CPU Emulation Engine
• Dual Core
• MMU
• FPRF
• Synchronize GPU thread
• Speed up Disc Transfer Rate

Kimishima (talk) 12:11, 29 July 2018 (CEST)