Difference between revisions of "User talk:Mbc07"

From Dolphin Emulator Wiki
Jump to: navigation, search
m (Formatting guidelines for processor speed under testing)
(Formatting guidelines for processor speed under testing)
Line 70: Line 70:
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.
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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 05:42, 29 April 2017 (CEST)

Revision as of 04:43, 29 April 2017

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


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.


16:9 Aspect Ratio

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


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)