Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Feature Request Thread?
#1
Hi there Smile

Really pleased with how open you are with feedback, and seeing as this may be the de-facto portable GBA emulator down in the future, I figured I might want to elaborate a bit on my.. wish list of stuff I'd really, really love to find in the game Tongue

So, without further ado, here I go Tongue

Color Correction

The older GBA models lacked back-lighting, hence why some games tended to overcompensate with altering their palettes to look far brighter than needed. As later models included back-lighting, some games disregarded this.
It would be lovely to have some custom palette correction options, kind of like with NES palettes.

SAPPY Sound Emulation Enhancements

GBA sound output is, bluntly put, often horrible. Sound gets processed through the CPU, and in most games it just tends to get the shorter end of the stick.
That aside, for games that do get the sound processed to the full potential of the hardware, the sound quality is full of crackling and noise, kind of like how sound gets distorted through phones.

While some games rely on chiptunes/GB sounds (Starfy 1, Castlevania HoD, Super Robot Taisen J), or the internal sound samples themselves have a very low bitrate to save ROM space (Lunar), ... in most cases, the sound samples found within the ROM are much higher quality than what gets output.

I often used this tool "GBA Music Ripper". It's a bit of a work-in-progress, and there are bugs at times (having to do with some instruments not being figured out, or in the case of both Golden Sun games not at all due to them using a different sappy format with reverb and stuff like that).

However, the sappy format is really widespread and almost universal in GBA games, and this tool takes the rom and rips all music, voice samples and sound effects, in sets of SoundFont files (.sf2) and midi files (midi). Using a tool like foobar to read the soundtrack, even Mother 3, often cited as a highlight of sound engineering in the GBA, pales compared to the ripped version which sounds like from a DS game. Zelda Minish Cap is a delight.

So, what I'm asking for is...

This reminded me a huge lot of 3D models rendering in shit resolutions... then emulators added upscale options to process the game's assembly instructions for graphic displaying (in our case it would be sound emulation) as normal, then recognizing specific calls to graphic hardware (here sound hardware, or just sappy sound engine assembly instructions), overriding them when it comes to end-user output to show a custom higher quality model/sound output done in real time.

Would this be possible here? I have the feeling this would be the biggest drawing point to this emulator if this ever materialized.

Debugger Suite

To help fan-translators and such folks.

Well, for starters we'd need some basic stuff, namely:
1/ Cheat support (we have already a really good base work, besides editing/deleting cheats it would also need external cheat files)
2/ Powerful cheat search engine (relative search with ability to set initial values, searching specific value, searching value equal to a given address, displaying values signed/unsigned/hex), and options for bigger/lower/equal... should be assigned to hotkeys in-game with HUD optionally displaying and telling how many results are there.
3/ Search for ranges of unused memory addresses throughout the game that never get written to aside from instructions blanking whole memory, could be running in the background as we play.
Useful for translators to find where to stuff their custom code.
4/ Save States, Rewinding, Frame Advance, Pause key, Reset key

With that out of the way:
1/ VRAM viewer (with ability to switch between various GBA modes)
2/ Map viewer (with ability to see what each square from each BG is from)
3/ OAM viewer (with info like rotation/palette/etc, palette viewer and exporter to same format as VBA, )
4/ Hex viewer/editor (divided by memory types ROM/VRAM/SRAM/...) and the ability to extract a specific range to an external file, pick a custom table (tbl) to change what each hex byte displays as as a letter/char in the right column (ascii, shift-jis, given by default, with option to get an external tbl file)

5/ you can drag to select a given area in either hex viewer or map/vram viewer, then
a: copy it to the clipboard (for VRAM: as a bitmap, for HEX: depending if it's the letter area or the hex area, as a string of characters/hex bytes selected in raw text)
b: paste with overwriting from the first byte onwards, byte number gets unchanged
c: track from ROM : meaning, relying on the rewind feature, tracking where this byte originated from in the ROM - either until a MOV instruction of a block of stuff from the rom, an LZ/Huffman compression scheme or just displaying the instruction that generated it the instant we reach a dead-end.
Figuring out where stuff is in the ROM is the bane of translators Tongue
d: watch value for RAM addresses. Like with SNES9X, it can show a tiny HUD with the value real time in-game. Could be useful too if available in the cheat engine

Of course, there's the debugger:
1/ Disassembler
2/ All Breakpoint options (on write, on read, on execute, run, break...) with keyboard shortcuts too Big Grin
3/ A good status viewer of various hardware flags
4/ Tracer (just dumps all instructions executed between instants t1 and t2)
5/ Assembler (like with FCEUX)

Unemulated Stuff

* Various rumble features: GB Player Rumble, Drill Dozer variable Rumble, WarioWare Rumble...
could use smartphone rumble, joypad rumble, wiimote rumble, or alternatively just a colored HUD square (that turns orange, or shades of orange/yellow/red for Drill Dozer's variable speed rumble)

* Key mapping for gyro controls in Yoshi/WarioWare with various schemes - key inputs with four keys, wiimote emulation (better), wiimotion plus/gyroscopic smartphones (best). And maybe the screen could rotate too?

* Figurine stuff (LegendZ, among 4 other games, but it's really obscure)
Reply
#2
Issue #1 is being addressed, dunno about other stuff.
Reply
#3
(05-25-2015, 01:30 PM)GH56734 Wrote: Hi there Smile

Really pleased with how open you are with feedback, and seeing as this may be the de-facto portable GBA emulator down in the future, I figured I might want to elaborate a bit on my.. wish list of stuff I'd really, really love to find in the game Tongue

So, without further ado, here I go Tongue

Hi! Yeah, I'm definitely very open to feedback at this point. I know there are lots of things that are a bit lackluster in general that the moment, either in mGBA or in GBA emulators in general, so I want to make mGBA as advanced as possible. The more suggestions, the better! I want to make 1.0 the best it can be.

(05-25-2015, 01:30 PM)GH56734 Wrote: Color Correction

The older GBA models lacked back-lighting, hence why some games tended to overcompensate with altering their palettes to look far brighter than needed. As later models included back-lighting, some games disregarded this.
It would be lovely to have some custom palette correction options, kind of like with NES palettes.

This is one of the video filters that I intend to implement when I get to video filters, hopefully either late in 0.3 or early in 0.4. 0.3 is going slower than I want it to be, so it'll probably be in 0.4. See Issue 15 and Bug 192.

(05-25-2015, 01:30 PM)GH56734 Wrote: SAPPY Sound Emulation Enhancements

GBA sound output is, bluntly put, often horrible. Sound gets processed through the CPU, and in most games it just tends to get the shorter end of the stick.
That aside, for games that do get the sound processed to the full potential of the hardware, the sound quality is full of crackling and noise, kind of like how sound gets distorted through phones.

While some games rely on chiptunes/GB sounds (Starfy 1, Castlevania HoD, Super Robot Taisen J), or the internal sound samples themselves have a very low bitrate to save ROM space (Lunar), ... in most cases, the sound samples found within the ROM are much higher quality than what gets output.

I often used this tool "GBA Music Ripper". It's a bit of a work-in-progress, and there are bugs at times (having to do with some instruments not being figured out, or in the case of both Golden Sun games not at all due to them using a different sappy format with reverb and stuff like that).

However, the sappy format is really widespread and almost universal in GBA games, and this tool takes the rom and rips all music, voice samples and sound effects, in sets of SoundFont files (.sf2) and midi files (midi). Using a tool like foobar to read the soundtrack, even Mother 3, often cited as a highlight of sound engineering in the GBA, pales compared to the ripped version which sounds like from a DS game. Zelda Minish Cap is a delight.

So, what I'm asking for is...

This reminded me a huge lot of 3D models rendering in shit resolutions... then emulators added upscale options to process the game's assembly instructions for graphic displaying (in our case it would be sound emulation) as normal, then recognizing specific calls to graphic hardware (here sound hardware, or just sappy sound engine assembly instructions), overriding them when it comes to end-user output to show a custom higher quality model/sound output done in real time.

Would this be possible here? I have the feeling this would be the biggest drawing point to this emulator if this ever materialized.

I'm honestly not sure this is possible. I can look into it, but I suspect it will be very difficult. I'd have to bypass the GBA's sound system entirely and detect when it's doing mixing without actually letting it play the mixed sound. This is definitely an 0.4 feature at the earliest, and probably 0.5 or later. I'd like to look into it, but I'm not sure how to feasibly do it.

(05-25-2015, 01:30 PM)GH56734 Wrote: Debugger Suite

To help fan-translators and such folks.

Well, for starters we'd need some basic stuff, namely:
1/ Cheat support (we have already a really good base work, besides editing/deleting cheats it would also need external cheat files)
2/ Powerful cheat search engine (relative search with ability to set initial values, searching specific value, searching value equal to a given address, displaying values signed/unsigned/hex), and options for bigger/lower/equal... should be assigned to hotkeys in-game with HUD optionally displaying and telling how many results are there.  
3/ Search for ranges of unused memory addresses throughout the game that never get written to aside from instructions blanking whole memory, could be running in the background as we play.
Useful for translators to find where to stuff their custom code.
4/ Save States, Rewinding, Frame Advance, Pause key, Reset key

With that out of the way:
1/ VRAM viewer (with ability to switch between various GBA modes)
2/ Map viewer (with ability to see what each square from each BG is from)
3/ OAM viewer (with info like rotation/palette/etc, palette viewer and exporter to same format as VBA, )
4/ Hex viewer/editor (divided by memory types ROM/VRAM/SRAM/...) and the ability to extract a specific range to an external file, pick a custom table (tbl) to change what each hex byte displays as as a letter/char in the right column (ascii, shift-jis, given by default, with option to get an external tbl file)

5/ you can drag to select a given area in either hex viewer or map/vram viewer, then
a: copy it to the clipboard (for VRAM: as a bitmap, for HEX: depending if it's the letter area or the hex area, as a string of characters/hex bytes selected in raw text)
b: paste with overwriting from the first byte onwards, byte number gets unchanged
c: track from ROM : meaning, relying on the rewind feature, tracking where this byte originated from in the ROM - either until a MOV instruction of a block of stuff from the rom, an LZ/Huffman compression scheme or just displaying the instruction that generated it the instant we reach a dead-end.
Figuring out where stuff is in the ROM is the bane of translators Tongue
d: watch value for RAM addresses. Like with SNES9X, it can show a tiny HUD with the value real time in-game. Could be useful too if available in the cheat engine

Of course, there's the debugger:
1/ Disassembler
2/ All Breakpoint options (on write, on read, on execute, run, break...) with keyboard shortcuts too Big Grin
3/ A good status viewer of various hardware flags
4/ Tracer (just dumps all instructions executed between instants t1 and t2)
5/ Assembler (like with FCEUX)

A good debug suite is one of the highest priorities for mGBA, and has been in progress for quite a while as it is. Current progress is as follows:
  • Cheat support for Action Replay, GameShark and CodeBreaker is in place in 0.2, and there's a really flexible backend behind them. I don't know if there's a standard file format for them, but I'm using a pretty bare text format with some directives for changing things. I'd be interested in hearing if there is a standard format! Cheat search has not been implemented at all, nor a bare format to access the full power of the backend.
  • Savestates have been present since 0.1, as well as reset and pause. Shortcuts are customizable (with some restrictions) as of 0.2, and fully customizable in 0.3 (not yet released, but nightlies and source are available). 0.2 also has rewind, but it's a bit buggy. Most bugs were fixed in 0.2.1.
  • VRAM/Map/OAM viewers are planned for 0.3, but haven't been started on yet due to concerns about being really slow. I was thinking about trying to reimplement the rendering backend a bunch to try and make it faster, but I think that's going to get delayed until 0.4. Palette viewer is mostly done in 0.3, although export and import aren't supported, mostly due to not knowing what format people would want. Suggestions welcome!
  • Hex editor is almost done in 0.3. There are some bits of polish needed still, but memory is editable, including ROM portions. It will even resize the ROM in memory if needed. Export and import are not yet supported, but will be by the time 0.3 is done. tbl support is on the todo list, but I've not found comprehensive documentation and have had to piece together info from random places. A list of things left to do in the hex editor is also on the todo list.
  • I'm not sure how to effectively do track from ROM. I'm very interested in this, but am not sure how to manage it yet. I'll figure it out I'm sure.
  • Disassembler is mostly done, but not present in the GUI. It needs a bit of polish, but it will be available in the GUI in either 0.3 or 0.4, depending on how long it takes. This debugger debugger is available via in the SDL version.
  • Read/write (currently merged), execute, etc are all available on the CLI, or the GDB stub.
  • I/O viewer is planned for 0.3.
  • Tracer and assembler weren't planned, but I can add them. I'm not too keen on implementing an assembler myself, so I might try to shell out to r2 or something for that. Not sure yet.

(05-25-2015, 01:30 PM)GH56734 Wrote: Unemulated Stuff

* Various rumble features: GB Player Rumble, Drill Dozer variable Rumble, WarioWare Rumble...
could use smartphone rumble, joypad rumble, wiimote rumble, or alternatively just a colored HUD square (that turns orange, or shades of orange/yellow/red for Drill Dozer's variable speed rumble)

* Key mapping for gyro controls in Yoshi/WarioWare with various schemes - key inputs with four keys, wiimote emulation (better), wiimotion plus/gyroscopic smartphones (best). And maybe the screen could rotate too?

* Figurine stuff (LegendZ, among 4 other games, but it's really obscure)
  • Rumble is all implemented except for GB Player Rumble, which is slated for 0.3.
  • Gyro and accelerometer controls are currently exposed, albeit fixed in how they work (controllers + analog sticks only at the moment), in 0.3 nightlies already. Unfortunately, wiimote libraries are rather lackluster, especially for advanced features, and haven't been able to get that working well at all, so wiimote support is sort of a pipe dream at the moment. I'm not sure about screen rotation, but I might try to get that working.
  • There appears to be 0 documentation on the figurines, and I don't think I'll be able to get my hands on any, so I don't think I'll be able to manage this.

The aforementioned todo list is here: https://forums.mgba.io/showthread.php?tid=3
Reply
#4
Really appreciate your answer Smile


If that could help, table files are usually like this one. The encoding of the file itself (UTF-8/Unicode) should be irrelevant, as long as it's a regular text file consisting solely of lines like "X=Y" separated by line breaks (X being either 1 byte, or even 2 bytes.. and Y being a latin/JP/space/etc character or sequence of characters).

As for the palette file file format, the same exact one as VBA should be the way to go. "pal" files VBA outputs can be then used with the Crystaltile2 GBA tile editor to modify games like a charm. 
LZ77Restructor2, a viewer (that's not very comprehensive though) for handling the LZ77 compressed graphics does request ACT palette format... so you might want to include that one too?

And, well, most cheat files are emulator specific anyways. Maybe the format used in VBA could work, but if it's limited or obsolete one might want to go with a new one.

The figurine games are, if that helps, Legendz: Isle Of Trials, Legendz: Sign Of Necromu, Plaston Gate (Fix), Plaston Gate DX (Fix).

All Japan-only. Two of them have been "fixed" by release groups so that the ASM instructions for scanning the figurines always return a success and the value for the first figurine. No such luck for Megaman Battle Network external peripherals.
Dolphin has a bunch of bundled cheat/patch codes for fixing some games so that they run at all (Mario Kart GP, namely). Maybe something similar could do the trick here for figurines and enabling on-cartridge e-Reader stuff - but it would be more a case per case thing rather than genuine emulation. Still, that could help a lot to get these games to run at all.
If you ever go with this idea, I can help with such a cheat file (namely for e-Reader content in a bunch of GBA games, including US/PAL releases, collected from around the internet).

Speaking of e-Reader, I'm pleasantly surprised with it being featured in the todo list. (I can't wait for Joylink GBA/GC, and Joylink e-Reader/GC connection too!)
And I'd like to request something regarding that part too.

All current emulators who emulate GBA e-Reader require for connecting a game such as SMA4/Pokémon Gen3 JP some save from real hardware for the e-Reader rom, where the connection has been already established (you can tell by the e-Reader having the third option and "SMA4 Data Saved", rather than just two options) so that reading e-Cards for these games will work at all.
People who didn't get the save, will just have the "Transmission>To GBA" menu failing the transmission from the other side, and trying to open the e-Card without doing that would just give that error message "can't be used without a copy of SMA4".

Problem is, e-Reader hardware is rare enough one can't be expected to get both regions for it for JP and US games (it's region-locked), and the only saves available online are for SMA4/Pokémon Gen3, while the games that used it -and require such saves in the current state of events- are much more than those two.
Any chance for 100% emulation of this feature if you ever get around to doing it? Would be really lovely Smile
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)