User talk:Mbc07: Difference between revisions

From Dolphin Emulator Wiki
Jump to navigation Jump to search
 
(70 intermediate revisions by 13 users not shown)
Line 1: Line 1:
Want to say or ask something? Just click "Add topic" above, I'll get into it when possible. [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
{{lowercase title}}
----
== The spam page ==
It must have caught your eyes by you going to the [[Project:Community portal]] where I edited something there recently. I added more page types for talk page DPL so my discussion at [[MediaWiki talk:Common.css]] doesn't vanish but then I noticed the spam page. I'm impressed that it has survived so long. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 11:58, 29 January 2022 (CET)


== 21:9 ==
== Why did you remove the rating template from someone's testing result? ==
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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:58, 1 March 2016 (CET)
From your recent edit at <s>[[StarBlade]]</s> sorry, it was [[Rygar: The Battle of Argus]], I see you removed a four star {{tl|Rating}} and replaced it with "Playable", is there something wrong with the template? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 02:44, 4 February 2022 (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) - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 05:57, 1 March 2016 (CET)
: Excess Ratings templates on a page throw off the [[:Category:Rating]] that pages get assigned to. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:50, 4 February 2022 (CET)
::: Actually this isn't the case, as that template doesn't output the categories. At the same time I'm supportive of these updates. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:34, 4 February 2022 (CET)
:::: Two similar templates doing similar things can be confusing, if one's going this won't be the case. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 12:49, 5 February 2022 (CET)


:: Looks like this is going to be easy.
:: Also, when included on the testing template, the stars become very tiny to the point it's barely readable and out of place in general, as the results column is intended to have text only. Furthermore, it has been years since we last used that template on game pages (it was superseded by {{tl|Ratings}}) and the only reason {{tl|Rating}} hasn't been deleted yet is because you're including it in one of your sandboxes, otherwise it would have been already gone. [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 05:23, 4 February 2022 (CET)
{| class="wikitable"
|
== Enhancements ==
=== 16:9 Aspect Ratio ===
Green texts are modifiable aspect ratio value. Check [[Other Codes#Aspect Ratio|here]] for other aspect ratio values.
==== NTSC-U ====
040037A0 3C608000
040037A4 C38337AC
040037A8 4805ACBC
040037AC <span style="color:#0c0;">3FE38E39</span>
0405E460 4BFA5340


==== PAL (English) ====
:::Alright, you've got a point. I think the templates used in my sandboxes can go too, the rating number can be fed into the main template but I will most likely abandon that column anyway. I'll copy/paste codes used to create stars for future use... [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 06:36, 4 February 2022 (CET)
8C05F4BC 7C7E1B78
040037A0 3C608000
040037A4 C38337AC
040037A8 4805BD1C
040037AC <span style="color:#0c0;">3FE38E39</span>
0405F4C0 4BFA42E0
00000000 40000000


...
== Ultrawide AR Codes ==
|}
I saw this edit reverting another user's 32:9 codes for the F-Zero GX[https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX&oldid=181115] and wanted to know where I could advocate for the Wiki pages themselves having more codes on them. Your comment for the edit, "(Although widescreen codes are an allowed code type per the wiki conventions, we currently accept only 4:3 => 16:9 or vice-versa)" indicated that this was a standard, but I couldn't find that on the [[Project:Wiki_Conventions#Enhancements]] that you linked. It only says Wider Aspect Ratios, not specifically 16:9. So, where can I learn more, or advocate for a change here? The rule seems to exist - but I don't see where it was decided. Thank you! --[[User:BlinksTale|BlinksTale]] ([[User talk:BlinksTale|talk]]) 19:39, 23 March 2022 (CET)


:: 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? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 09:28, 30 April 2016 (CEST)
: The discussion goes waaay back and at some point were scattered over a few different talk pages (usually from wiki users questioning why an edit adding a  widescreen code got reverted) so it might be a bit hard to find them all nowadays. From a quick search, I could find only the initial discussion back from 2015 under [[Project talk:Wiki Conventions]] and '''a lot''' has changed since then (especially the page pollution that big codes caused at the time). I recognize that the usage of bigger displays (aka wider than 16:9) is more widespread nowadays than it was 7 years ago, but I'm personally still a bit wary of allowing other aspect ratio codes directly on the wiki. Anyway, feel free to create a new discussion topic about this under [[Project talk:Wiki Conventions]] (or [[Project:General Discussions]] perhaps) and let's see how it goes, we can adjust the conventions depending of the general outcome... - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 08:22, 24 March 2022 (CET)
::: 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... - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk: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).[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 06:33, 1 March 2016 (CET)
== NSMBW BT issues ==
Hello mbc07, you recently removed the BT issue workarounds I added on the NSMBW page.
Wouldn't it be helpful to at least some people if the info stayed there?
I was able to confirm that both of these workarounds work with the Wii Bluetooth Module. [[User:Lettendo|Lettendo]] ([[User talk:Lettendo|talk]]) 11:04, 19 March 2024 (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. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:15, 1 March 2016 (CET)
: It is known that a timing issue exists on New Super Mario Bros when using Bluetooth Passthrough, it was initially reported [https://forums.dolphin-emu.org/Thread-new-super-mario-bros-bt-passthrough-only-works-in-windowed-mode way back in 2019], however, as I said in the revert summary, the cause was never identified and several "workarounds" that either don't work or that only work under specific circumstances were proposed in that forum thread.  


: 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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 13:47, 4 March 2016 (CET)
: Now, back to the wiki edit, it mentioned disabling V-Sync as a workaround but that has already been mentioned to '''not''' fix the issue (and Dolphin default settings already have V-Sync disabled by default anyway), it also mentioned enabling and setting CPU Clock Override to 30%, which is unverified to actually fix the issue and, due to the extremely hacky nature of the option and the amount of support burden it has caused in the past (mainly due to seemingly unrelated issues that starts happening by users who don't know what they're doing starts messing with non-default emulated CPU clocks -- in case the CPU clock override automatically disabling itself when closing the emulator or the warning text that accompanies that option wasn't clear enough), is something that definitely isn't going to be advised in the wiki unless you have an '''''extremely''''' good reason to.


:: 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? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 13:52, 4 March 2016 (CET)
: In short, if you want to mention the timing issue exists and perhaps point people to that forum thread so they can further discuss possible solutions or perhaps point to an [https://bugs.dolphin-emu.org/projects/emulator/issues?set_filter=1&tracker_id=1 issue report] (unsure if one already exists for this problem), fine, go ahead, but I, particularly, am not willing to let workarounds that are known to not work (remember, just because it worked for you, doesn't mean it works for everyone having the same issue), or that relies on "dangerous" settings like Emulated CPU Clock Override be mentioned directly on the wiki. - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 00:31, 20 March 2024 (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. [[User:Lucario|Lucario]] ([[User talk: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. - [[User:MaJoR|MaJoR]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk: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? [[User:Lucario|Lucario]] ([[User talk: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>?" - [[User:Jhonn|Jhonn]] ([[User talk: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 [https://forums.dolphin-emu.org/Thread-gc-ar-codes-for-16-9-21-9-60hz a master thread] just for them. - [[User:Jhonn|Jhonn]] ([[User talk: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/95544/7th-Generation-Intel-Core-i7-Processors) 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.

Latest revision as of 01:31, 20 March 2024

The spam page

It must have caught your eyes by you going to the Project:Community portal where I edited something there recently. I added more page types for talk page DPL so my discussion at MediaWiki talk:Common.css doesn't vanish but then I noticed the spam page. I'm impressed that it has survived so long. Lucario (talk) 11:58, 29 January 2022 (CET)

Why did you remove the rating template from someone's testing result?

From your recent edit at StarBlade sorry, it was Rygar: The Battle of Argus, I see you removed a four star {{Rating}} and replaced it with "Playable", is there something wrong with the template? Lucario (talk) 02:44, 4 February 2022 (CET)

Excess Ratings templates on a page throw off the Category:Rating that pages get assigned to. Kolano (talk) 04:50, 4 February 2022 (CET)
Actually this isn't the case, as that template doesn't output the categories. At the same time I'm supportive of these updates. Kolano (talk) 08:34, 4 February 2022 (CET)
Two similar templates doing similar things can be confusing, if one's going this won't be the case. Lucario (talk) 12:49, 5 February 2022 (CET)
Also, when included on the testing template, the stars become very tiny to the point it's barely readable and out of place in general, as the results column is intended to have text only. Furthermore, it has been years since we last used that template on game pages (it was superseded by {{Ratings}}) and the only reason {{Rating}} hasn't been deleted yet is because you're including it in one of your sandboxes, otherwise it would have been already gone. mbc07 (talk) 05:23, 4 February 2022 (CET)
Alright, you've got a point. I think the templates used in my sandboxes can go too, the rating number can be fed into the main template but I will most likely abandon that column anyway. I'll copy/paste codes used to create stars for future use... Lucario (talk) 06:36, 4 February 2022 (CET)

Ultrawide AR Codes

I saw this edit reverting another user's 32:9 codes for the F-Zero GX[1] and wanted to know where I could advocate for the Wiki pages themselves having more codes on them. Your comment for the edit, "(Although widescreen codes are an allowed code type per the wiki conventions, we currently accept only 4:3 => 16:9 or vice-versa)" indicated that this was a standard, but I couldn't find that on the Project:Wiki_Conventions#Enhancements that you linked. It only says Wider Aspect Ratios, not specifically 16:9. So, where can I learn more, or advocate for a change here? The rule seems to exist - but I don't see where it was decided. Thank you! --BlinksTale (talk) 19:39, 23 March 2022 (CET)

The discussion goes waaay back and at some point were scattered over a few different talk pages (usually from wiki users questioning why an edit adding a widescreen code got reverted) so it might be a bit hard to find them all nowadays. From a quick search, I could find only the initial discussion back from 2015 under Project talk:Wiki Conventions and a lot has changed since then (especially the page pollution that big codes caused at the time). I recognize that the usage of bigger displays (aka wider than 16:9) is more widespread nowadays than it was 7 years ago, but I'm personally still a bit wary of allowing other aspect ratio codes directly on the wiki. Anyway, feel free to create a new discussion topic about this under Project talk:Wiki Conventions (or Project:General Discussions perhaps) and let's see how it goes, we can adjust the conventions depending of the general outcome... - mbc07 (talk) 08:22, 24 March 2022 (CET)

NSMBW BT issues

Hello mbc07, you recently removed the BT issue workarounds I added on the NSMBW page. Wouldn't it be helpful to at least some people if the info stayed there? I was able to confirm that both of these workarounds work with the Wii Bluetooth Module. Lettendo (talk) 11:04, 19 March 2024 (CET)

It is known that a timing issue exists on New Super Mario Bros when using Bluetooth Passthrough, it was initially reported way back in 2019, however, as I said in the revert summary, the cause was never identified and several "workarounds" that either don't work or that only work under specific circumstances were proposed in that forum thread.
Now, back to the wiki edit, it mentioned disabling V-Sync as a workaround but that has already been mentioned to not fix the issue (and Dolphin default settings already have V-Sync disabled by default anyway), it also mentioned enabling and setting CPU Clock Override to 30%, which is unverified to actually fix the issue and, due to the extremely hacky nature of the option and the amount of support burden it has caused in the past (mainly due to seemingly unrelated issues that starts happening by users who don't know what they're doing starts messing with non-default emulated CPU clocks -- in case the CPU clock override automatically disabling itself when closing the emulator or the warning text that accompanies that option wasn't clear enough), is something that definitely isn't going to be advised in the wiki unless you have an extremely good reason to.
In short, if you want to mention the timing issue exists and perhaps point people to that forum thread so they can further discuss possible solutions or perhaps point to an issue report (unsure if one already exists for this problem), fine, go ahead, but I, particularly, am not willing to let workarounds that are known to not work (remember, just because it worked for you, doesn't mean it works for everyone having the same issue), or that relies on "dangerous" settings like Emulated CPU Clock Override be mentioned directly on the wiki. - mbc07 (talk) 00:31, 20 March 2024 (CET)