Um, maybe I’m crazy or something, but when I loaded RA on the Wii, I went to settings->Onscreen Display all I see are the following:
OSD Message Font OSD Message Size OSD Message X position OSD Message Y position
But no option to disable it, so I don’t know -_-
Maybe I’m overlooking something? Nothing in Onscreen display or OSD settings, it’s not there.
Edit: Also, I hope at one point the mGBA core can load 32 MB ROMs instead of crashing 
Sometimes loading a game (Nestopia) causes the screen to squish into the top half and the audio becomes slow and distorted. Exiting to the Homebrew channel results in the Hombrew Channel being orange instead of blue. Corrupt memory. 
Same, but it happened on the older version too, most commonly with the SNES core.
As far as I know this issue was fixed since 0.9.9 using component cables. If you use scart RGB like me (or composite, or s-video) the problem is still present! http://libretro.com/forums/showthread.php?t=3889
One of the persistent bugs so far is that RetroArch doesn’t save the appropriate .cfg. Whenever I simply open up RetroArch with no cores loaded and I try to change the defaults settings like video height/width manually to save it in the general retroarch.cfg, the app simply saves it into whatever other core it decides to save it.
Doesn’t that kind of defeat the purpose of having per-core configurations?
Unibios option for neogeo games isn’t in the good core ! Option is on FBA Arcade Core, not on FBA Neogeo.
Version 1.2.2
I just reverted back to 1.2.2 due to the nightly’s not working, and found a potentially (?) new bug:
If “crop overscan” is disabled, it causes graphic corruption and usually a crash when loading the quick menu, or reloading/quitting the program.
Why would you testing it on dolphin be relevant at all? The nightly thread has had multiple posts by multiple people saying the nightlies are broken on real hardware, that’s all that matters.
That’s really the only reason I went back to 1.2.2, is because the latest nightly is broken and I didn’t feel like trying to find what the latest working one is.
I should have some time tonight though, so I’ll try to track down the last working build and see if I can reproduce the bug.
Also, just a question from those in the know: What is the “VI Interface Width” option for? It defaults to 640, and I can increase it by increments of 2. Does this ever need to be configured?
I do want to help actually, and I’m a competent programmer. I’ve contributed to several open-source projects in the past. But I don’t have the time to do much else besides do bug reports unless someone wants to give me a rundown of what file does what.
My only point is that you coming into threads saying “this works for me” is equally unhelpful. Subtle differences in configuration, devices using the same platform, etc. make all the difference. For instance, the menu scrolling issue and netplay not working on my galaxy note but working on your devices doesn’t automatically mean that I’m full of it and there are no issues. Case in point here, several people are telling you the nightlies are broken on real hardware and you’re saying it works on an emulator? Pfft. You must have a huge ego.
They are accepting donations now: http://www.libretro.com/index.php/about-donations/
Donate a few quid for devs to buy a second hand Wii and it will make all the difference.
I did some bisecting, and it ended up being a big waste of time. I should have compiled master first, because it compiles and runs fine 
If anyone wants a rundown of what I checked:
master … compiles and loads fine (tried this last) … 65670e0 builds but doesn’t load (black screen) c2f044d doesn’t build (then works) 1d911ac doesn’t build (then works) 1225fce doesn’t build (include “video_common.h” into menu_display.h for GRFloat typedef for the previous 2 builds, then builds and works) 2a100d7 is okay b90c782 is okay
I also checked my original bug report of video corruption when “Crop Overscan” is disabled, and it’s still present. The effect looks like if you had a damaged lcd screen, with just a messy line pattern on the bottom 50% of the screen.
I’m a programmer by trade… but it’s all web development. I’ve taken a look at the Retroarch source and just end up getting kind of confused. I’ll keep at it, since there’s definitely a few things that I’d like to try to see implemented someday.
As far as I can tell, it built and ran fine. I used Wiiload, and wasn’t deleting configs in between builds, so maybe I should have been doing that. I’ll do a bit more checking tonight, to make sure that the builds that didn’t load (they just stuck at a black screen, or exiting after a few seconds like the current nightly) were actually failing in the same way as the nightly.
I also did a bit more playing around with the “Crop Overscan” disabled, and it’s definitely causing the video corruption issue I had encountered before and thought had been fixed. Turns out I just left the option enabled. When disabled, you get a bit of video corruption, and then loading another file gets much worse (I’ve only tested a 240p-ish resolution) and the corruption even carries back to the hombrew channel and system menu causing weird slowdown and a strange orange tint.
Also, on the latest build with snes9x-next, things are running really slowly when there are transparencies on the screen. My specific example in the floating continent in Final Fantasy 3, there are some transparent clouds in the background. On this scene, it’s running at about half speed, but hit a battle or go into the menu and things go back to normal. This wasn’t happening in the 1.2.2 stable. I could try to track down the change that caused this if that would be helpful.
I thought the orange thing was a problem with 240p, specifically, rather than crop overscan…?
I’ll test a little bit more tonight, but from what I experienced, it was very easy to reproduce when crop overscan was disabled, but I wasn’t able to reproduce when crop overscan was enabled.
There was a thread where someone posted about how ekeeke (genplusgx) thought that it would be related to some sort of video corruption, rather than the 240p mode specifically. Perhaps the crop overscan feature does not behave properly on the Wii? Perhaps the video buffer is sized as if cropping were enabled, and with cropping disabled it is writing too much data into the buffer, or overflowing into the 2nd buffer (and then from the 2nd into…??).
Could be. I would like to see that option removed entirely and let the cores handle the cropping on their own (Nestopia already does this). Is it doing it with all cores for you or just some of them?
I’ve only tested with snes9x-gx so far, but I’ll test out a couple more tonight.
Edit: I’ve tested some other cores, and you’re right that it seems to be snes9x-next only, or in some way related to it. Gameboy was fine, as was Nestopia and FastNES, GenplusGX and Mednafen PCE Fast. On SNES9X, it depended which game I loaded, whether or not the video would corrupt (or crash Retroarch). I had a hunch that it had to do with higher resolutions, so I loaded Seiken Densetsu 3, and it crashes Retroarch on the Title screen (but is able to display the squaresoft logo). Final Fantasy 3 and Dragon Quest 6 also would corrupt the video to some extent, but didn’t always crash. Sometimes it would crash when loading a new game, or changing cores after seeing some corrupted video.
I should also mention that disabled crop overscan did what it was supposed to on the NES cores. I could see lots of extra junk on the left and right of the screen when it was disabled.
Also, I tested this with the 1.2.2 build, because I don’t have any other cores available to compile with. I figure if they’re working on that version, it’s likely they’re working fine on the nightly as well.
And finally, this is interesting:
More Edit: I messed around with the source last night, adding a bunch of resolutions back in, and testing out the idea of changing resolutions on the fly, since some titles do this (Seiken Densetsu 3). For the most part, it seemed to be working, though the switch is noticeable, since 256 width seems to scale differently from 512. The code also doesn’t care about a lot of cases, like resolutions from portables, so it’ll likely never be of any use.
While testing this, I was able to corrupt the video even with “crop overscan” enabled (and likely using the 256x224 resolution), so it’s likely that crop overscan isn’t the problem, or again that something is trying to write more data to a buffer than it can handle, which is easier to reproduce with a smaller buffer. I later made some other changes, and was able to change the resolution as much as I wanted without corruption, but it’s likely that the code I commented out is required in order to display things properly
[QUOTE=thatcadguy;30476]I do want to help actually, and I’m a competent programmer. I’ve contributed to several open-source projects in the past. But I don’t have the time to do much else besides do bug reports unless someone wants to give me a rundown of what file does what.
My only point is that you coming into threads saying “this works for me” is equally unhelpful. Subtle differences in configuration, devices using the same platform, etc. make all the difference. For instance, the menu scrolling issue and netplay not working on my galaxy note but working on your devices doesn’t automatically mean that I’m full of it and there are no issues. Case in point here, several people are telling you the nightlies are broken on real hardware and you’re saying it works on an emulator? Pfft. You must have a huge ego.[/QUOTE]
You should try a new nightly then for Android, I dunno what this issue is with the menu scrolling you are referring to but if it was the issue where scrolling would turn things black on some random Mali GPUs, then yes, we have fixed that now.
[QUOTE=thatcadguy;30489]Reporting bugs here and on GitHub isn’t helping? Again, huge ego. You are literally what pushes people away from open-source projects, good job.
@Charco: money better spent donated to the respective emulator projects that aren’t buggy on every single platform.[/QUOTE]
Don’t abuse our mod like this. He has put valuable time and work into this project that he can’t ever get back, and the last thing that should happen here is for him to be degraded and insulted by some guy who has not even lifted so much as a finger for this project yet.
No, just reporting bugs is NOT ENOUGH. Too bad if you don’t like hearing that but it’s the truth. I don’t care what your talents are BTW. Don’t insult our mod team and don’t insult our efforts or dedication either (‘respective emulator projects that aren’t buggy on every single platform’. Let this be your first and only warning, you are NOT going to insult us like this and think it is OK and you can get away with it. Treat us with due respect and we will treat you with due respect in kind.