Homebrew New VBA GX fork (2.3.0)
- Thread starter libertyernie
- Start date
- Views 182,568
- Replies 406
- Likes 25
Adding UStealth support is no big deal.I would certainly love to see support for uStealth in this fork!
You just gotta downloda a certain lib.a file, replace it in the compiler and that's it.
You just build the app with that library added and it will have UStealth support.
I understand how to make it support UStealth. I just think it would be convenient to already have it compiled with UStealth support rather than having to take the time to do it myself.
Hahah yeah I know.I understand how to make it support UStealth. I just think it would be convenient to already have it compiled with UStealth support rather than having to take the time to do it myself.
But these apps are still taken as Wii Homebrew, not wii U homebrew.
UStealth is exclusive to Wii U, which might be why many developers still don't compile these emulators with such library.
Edit:
Here's the updated Borders pack of mine.
Although, there is still ONE border I can't get to load...
Kirby's Dream Land is the only game that does not load the custom border for it.
I already matched the ROM header/internal name with the name of the PNG image and it still doesn't load.
Can you post a link? I don't remember a patch for this, but if it doesn't break anything I might as well add it.
Hmm... I wonder if I can fix that for 4:3 without changing 16:9.
Hey long time no see!
Here you have the link to the VBAGX 2.3.0 fork with libwupc:
http://www.mediafire.com/fix94#cnwd2mo2ovbpi
It should have a .patch file or the SVN.
Just out of curiosity, did you have the chance to check why the Coloured Rom hacks show garbled tiles with FCEUGX?
Not demanding or anything, I'm just curious to know what the issue might be for those ones.
Okay so I installed a previous version (2.2.8) and for some reason this version goes straight to the calibration screen on start up. With the version I got from here I get no calibration screen even after deleting my save game data from the folder.
Would really love to be able to play Wario Ware Twisted with the performance enhancements this version offers. Any support or advice would be much appreciated.
Would really love to be able to play Wario Ware Twisted with the performance enhancements this version offers. Any support or advice would be much appreciated.
Any chance of updating the other GX emulators with your mod? FCEUGX has old 2.2.0 source, 2.2.2 is out since more than a year.
Any chance of updating the other GX emulators with your mod? FCEUGX has old 2.2.0 source, 2.2.2 is out since more than a year.
I second this!
Especially trap filter or soft filters would be nice in NES emus
- Joined
- Aug 7, 2008
- Messages
- 2,463
- Trophies
- 2
- Location
- Melbourne
- Website
- vaguerant.tumblr.com
- XP
- 3,300
- Country
There seems to be a problem with the custom border system when games are being loaded from USB. I have all my ROMs on a USB HDD, but run VBA GX from an SD card. Any time a custom border is expected to be loaded (i.e. games without SGB support or when Emulation is set to a non-SGB mode) the emulator instead shows an empty white border. If I load my ROMs from SD instead, the problem goes away.
EDIT: This problem can be alleviated by placing /vbagx/borders on the USB drive instead, but I feel like it makes more sense to load borders from the same device VBA GX is running from. However, if loading borders from the ROM device is the intended behavior, then disregard.
Out of interest, what viWidth is this fork using? It seems to change based on whether the Wii itself is set to 4:3 or widescreen, but in theory it should be 704 at all times to maintain square pixels (with TV set at 4:3). This does run into overscan problems on many TV sets, though--the games themselves aren't such a problem since the original platforms' screens aren't wide enough to lose anything, but the VBA GX menu itself could be a problem at such a high width.
I'd say the best options would be one of either a) letting the user set the viWidth or b) setting the viWidth to 704 when a game is running but sticking to something lower in the menu.
EDIT: This problem can be alleviated by placing /vbagx/borders on the USB drive instead, but I feel like it makes more sense to load borders from the same device VBA GX is running from. However, if loading borders from the ROM device is the intended behavior, then disregard.
Out of interest, what viWidth is this fork using? It seems to change based on whether the Wii itself is set to 4:3 or widescreen, but in theory it should be 704 at all times to maintain square pixels (with TV set at 4:3). This does run into overscan problems on many TV sets, though--the games themselves aren't such a problem since the original platforms' screens aren't wide enough to lose anything, but the VBA GX menu itself could be a problem at such a high width.
I'd say the best options would be one of either a) letting the user set the viWidth or b) setting the viWidth to 704 when a game is running but sticking to something lower in the menu.
- Joined
- Aug 7, 2008
- Messages
- 2,463
- Trophies
- 2
- Location
- Melbourne
- Website
- vaguerant.tumblr.com
- XP
- 3,300
- Country
Ah, thanks SuperrSonic. If this and the below could be fixed I'd say this would be back on top as far as Game Boy emulators on Wii go.
Has anyone else noticed a sound issue with GB/GBC games in this fork? Over the course of about 2 and a half minutes, the sound gradually falls further and further behind the video (good place to test is somewhere like a game menu that beeps when you navigate it; try Pokemon Pinball for example). After a while, there's a jump in the sound as it "catches up" with the video and the sound is responsive again. I don't remember this in the mainline VBA GX, but it's a while since I've used it as I've been running GB/C games in RetroArch's Gambatte core, which doesn't seem to share this problem.
EDIT:
But that's getting ahead of ourselves, so let's go from the start. If we assume 4:3, 640*480 framebuffer and 640 viWidth for a moment, we're starting out with the Wii's 10:11 pixels, and then we're throwing 2:3 pixels at those, so we've got 0.6060...:1 pixels now, while the Game Boy Advance uses square pixels. The first thing we can do to improve this is switch our TVs to widescreen mode . This stretches the image by a factor of 4/3 (I know that sounds confusing, but 16:9 is quite literally four thirds the width of 4:3), so now we 've got a pixel aspect ratio of 0.8080...:1.
We're almost there, now we need to make our pixels about 24% wider. We do this by adjusting the combination of framebuffer width and viWidth. Right now we have 640/640, or a 0% increase. The highest we can go with viWidth alone is 720/640, which is only a 12.5% increase. So we need to drop the framebuffer or both to a point where the viWidth is about 24% wider than the framebuffer. So our formula looks like this:
The viWidth will define the constraints for how large we need the framebuffer to be, since it's hard-limited to between 640 and 720 pixels. So our constraints are as follows:
Minimum framebuffer width:
Maximum framebuffer width:
So to get an ideal image, our framebuffer must be somewhere between 518 and 582. How should we decide? Frankly, it doesn't matter much, the game will look about the same anywhere along this sliding scale--sometimes a fraction of a percent wider or slimmer but nothing noticeable. The game itself will only be displaying in 480 of those columns; anything outside will be empty and how much we leave empty is fairly irrelevant.
In theory, the truest square pixels should be found at a framebuffer width of 522 and a viWidth of 646. The full formula for square pixels thus ends up looking this this:
Presumably this is the absolute best choice for achieving true square pixels, so probably the best option for VBA GX if you were to include a 3* GBA mode for widescreen users.
Has anyone else noticed a sound issue with GB/GBC games in this fork? Over the course of about 2 and a half minutes, the sound gradually falls further and further behind the video (good place to test is somewhere like a game menu that beeps when you navigate it; try Pokemon Pinball for example). After a while, there's a jump in the sound as it "catches up" with the video and the sound is responsive again. I don't remember this in the mainline VBA GX, but it's a while since I've used it as I've been running GB/C games in RetroArch's Gambatte core, which doesn't seem to share this problem.
EDIT:
At the very least, the current 3x GBA resolution should be removed. It's just plain bigger than the Wii's maximum framebuffer size. Wii (and GameCube) max out at 640*528 (50Hz) or 640*480 (60Hz). It doesn't matter whether the TV or Wii is in widescreen mode, 720 is more than 640. As SuperrSonic described, the best way to do a 3* scale on Wii/GameCube is to do 3* vertically but only 2* horizontally and recover the extra third by fudging with framebuffer/viWidth and setting the TV to widescreen. This third magnification won't be a true integer scale, but the Wii's viWidth is high quality and most TVs should do a decent job of the 16:9 scale, so the pixels should maintain most of their sharpness and won't look uneven.
But that's getting ahead of ourselves, so let's go from the start. If we assume 4:3, 640*480 framebuffer and 640 viWidth for a moment, we're starting out with the Wii's 10:11 pixels, and then we're throwing 2:3 pixels at those, so we've got 0.6060...:1 pixels now, while the Game Boy Advance uses square pixels. The first thing we can do to improve this is switch our TVs to widescreen mode . This stretches the image by a factor of 4/3 (I know that sounds confusing, but 16:9 is quite literally four thirds the width of 4:3), so now we 've got a pixel aspect ratio of 0.8080...:1.
We're almost there, now we need to make our pixels about 24% wider. We do this by adjusting the combination of framebuffer width and viWidth. Right now we have 640/640, or a 0% increase. The highest we can go with viWidth alone is 720/640, which is only a 12.5% increase. So we need to drop the framebuffer or both to a point where the viWidth is about 24% wider than the framebuffer. So our formula looks like this:
Code:
f * 1.2375 = vThe viWidth will define the constraints for how large we need the framebuffer to be, since it's hard-limited to between 640 and 720 pixels. So our constraints are as follows:
Minimum framebuffer width:
Code:
640 / 1.2375 = 517.171717172
Code:
720 / 1.2375 = 581.8181...So to get an ideal image, our framebuffer must be somewhere between 518 and 582. How should we decide? Frankly, it doesn't matter much, the game will look about the same anywhere along this sliding scale--sometimes a fraction of a percent wider or slimmer but nothing noticeable. The game itself will only be displaying in 480 of those columns; anything outside will be empty and how much we leave empty is fairly irrelevant.
In theory, the truest square pixels should be found at a framebuffer width of 522 and a viWidth of 646. The full formula for square pixels thus ends up looking this this:
Code:
(10/11) * (2/3) * (4/3) * (646/522) = 1.000038701188126475483Presumably this is the absolute best choice for achieving true square pixels, so probably the best option for VBA GX if you were to include a 3* GBA mode for widescreen users.
This fork greatly improves the performance of the original VBAGX, only thing I can think of is the issues when loading colored GB hacks like Metroid II DX and SML 2 DX which show garbled sprites, but that happened in the original and last time I knew libertyernie was going to take a look at that.
But only that for now.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
If your not getting your pills from Psi's discount drugs who knows what your swallowing!+1 -
@
Psionic Roshambo:
Shawnita used to get her pills from some other street pharmacist and after switching to The Psi Discount plan she now only has to swallow two things a day!+1
-
-
-
-
-
-
-
