Jump to content
Visual Boy Advance-M


  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Iconoclast

  • Rank
  1. Iconoclast

    Dear Indian Spammers

  2. Iconoclast

    Wisdom Tree compatibility (and here's how)

    Well, if the header is "invalid," but it loads on an actual GBA anyway, maybe the header should be almost ignored by an accurate emulator, or the header is just not thoroughly documented enough to understand the functionality of all of the bits? I know there is a bare minimum of which bits need to be set in an N64 header for games to boot there.
  3. Iconoclast

    Help understanding sound system and timing.

    Might not necessarily be that the sound code is timing the emulator. Might be that the operating system places a greater thread priority for audio than it does with graphics. I know with other platforms like the N64 this was done. In that case the graphics rendering will constitute a speed rate in video frames per second, but the operating system itself was still not timed by this measure. The actual number of vertical interrupts per second of drawing the screen in an emulator was untimed by default, so N64 emulators used the audio interface (sound plugins) to synchronize the audio to the video to keep the speed controlled. So I can't really tell you anything about SDL or what might internally be done within the sound threading, but maybe it's just a choice done by the operating system here, too? After all sound is constantly in the background, while there aren't always video updates to draw.
  4. Iconoclast

    GBC+SGB Border feature (like in Rew)

    I'm used to it on "fagGit". It's a bit of a pain to memory match while binary-sorting through commits, but when it comes to balancing when to rewrite zilmar's code and when to revert to test where and why he might have done something his way it's the only option. It's a lot easier too with simple projects where the code compiles straight out of the box with just copy-paste, which I don't think that VBA-M is that sort of thing since it uses a very big chain of source files compared to what I maintain. But I don't know how CVS works anyway, so it's not like I'm being helpful here.
  5. Iconoclast

    Text to Speech or Screen Reader Support for Blind

    Yeah, probably. More likely it would have to use the same render API as VBA-M. Like if VBA-M was running DirectX, have some external Direct2D (or maybe use Direct3D?)/DirectDraw debugger application running and tracing all the pointers to texture locations, distinguishing which ones are ASCII text pointing to them and which ones are look-ups on extended offsets. Even then though that does require a number of rules or assumptions to be put in place. It would just be way easier to redesign the game.
  6. Iconoclast

    Translation Project

    lolXD well you might say that Technically, it's for handling the Controller Pak file (At least, that's Nintendo's legal name for it.) inserted in the back of the standard controller. N-Rage's DirectInput currently provides these features for managing the memory pak file system: format: Re-format the mempak for standardization and erase all current game note data save note: Export an Adaptoid64-encoded game note from the Controller Pak. insert note: Import an Adaptoid64-encoded game note to the Controller Pak. delete note: Destroy the game save record in the respective game note index slot in the memory pak. My mempak manager handles the N64 controller RAM with a few other options that N-Rage doesn't support, including: more detailed system-reserved page formatting when formatting the mempak (upon request) exporting single 256-byte page binaries (from 0 to 127, 128 * 256 = size of mempak file in bytes) renaming the game note label, like changing a game save name from "MARIOKART64" to "HAHAUDIENIGGA!" exports save data from the N64 mempak without including excessive text/ASCII bytes like in the standard A64 files N-Rage exports, using binary file output for smaller sizes that are a multiple of 256 bytes fragmented page overwrite when re-importing hacked game notes (like, export the game note, edit it with a hex editor to change game save progress, then re-import it back in with this option) I'm thinking about other stuff to add, like a defragmenter utility to rearrange all the pages that compose game note saves into a linear order instead of letting them be scattered around in the mempak system-indexing reserved pages, although this occurrence is rare...at least when using a good emulator to write mempak data or the official N64. Most of that stuff isn't all that useful; I'm just writing a mempak file manager so that I can start writing save editors for any of the N64 games that save data to the mempak instead of the save chip (SRAM/EEPROM/Flash).
  7. Iconoclast

    Translation Project

    Yaaay! Problem solved ; they'll take care of the nasty code page shit...while I can solve more productive problems like my N64 memory pak manager application.
  8. Iconoclast

    Translation Project

    Note that's why I said "if" you could get it; even so it doesn't make it impossible to get the data anyway. Why would it be a waste of time? They're not translating it to English. I thought that was the language you were intent on translating it to. If you prefer it in French, then by all means, it would be a waste of time to not let them finish it first.
  9. Iconoclast

    Translation Project

    Knowledge of ROM-hacking is knowledge of programming. It may not be knowledge of a programming "language", but, more often than not, the technicalities pertinent to a specific language are irrelevant. Either way when I was hacking ROMs, I didn't know shit about "strings" and "pointers" and those terms , even though I actually understood them anyway without knowing. It's all language vs. concept. And if you can get a hold of that ROM, translated to lololol is that Korean or sumshit (jk it's French), then that is definitely ASCII text, although the code points used to map the character glyphs might not necessarily be those of ASCII. Still, it will fit much more nicely, so extending off of that will be easier anyway. And if they don't want any help, all the more reason to have no guilt in taking that work and rewriting everything for your own project. It's not their software, after all.
  10. Iconoclast

    Translation Project

    Thing is, it's easy for me to do with ASCII text. Japanese characters unfortunately don't fall under that category. Unless the game is backwards-compatible with ASCII (i.e., Unicode code page for supporting the kana alphabet) then you would definitely have to rewrite the code page interpreter. Honestly I am not an experienced translator; I don't even know any spoken languages besides English. But otherwise, apart from that, it's easily done, without space being an issue (just offsetting some data most likely, as is the case for surely any translation). Also from what you said in that first edit it sounds to me as though you do in fact have the skills to build a program. Hell, when I first started building programs off of tutorials, I was like..."Man, this shit is gay," but then I was like (years later), "Man, this shit is Grrrrr-REAT!!!" *Kellogg's*
  11. Yeah, I know that. DirectSound precedes XAudio within the DirectX API. I'm not saying that means XAudio is like, more portable than DS or anything, but, eh, it's kind of why I'd rather write an XInput controller plugin than a DirectInput one. Then again, I'd rather use GDI than GDI+ . GDI isn't as portable as OpenGL, but it's still more portable than Direct3D or Direct2D due to other operating systems having similar OS-level render calls. Bah, I suck with APIs. Just don't know of any equivalent for audio; I guess that would be like waveout or something. Good thing there's a much smaller choice.
  12. Better to control the APIs than to rely upon their internals as a solution. Register underflow and overflow are consequences of manageable memory that were not managed stably. But I've always wondered what sound output API I could use for a plugin.... I want to avoid DirectSound since it's specific to DirectX in Windows. I hear there's the newer XAudio, OpenCL, something else I forget. ...Erm, but anyway, last I checked audio stuff that I remember being off in VBA-M had since been fixed in the past months. I haven't had any audio buffer problems since then. I do hate deadlines though .
  13. Iconoclast

    Translation Project

    The various text strings are going to be referenced by a table of memory addresses to look them up before printing them to the screen, so with enough dedication, anyone could write an application to read the string pointers from the earlier section of the ROM and convert all the Japanese characters to Unicode code points to display on the common personal computer. I've done something similar with the N64 Zelda games, but I haven't hacked much outside of N64 stuff . There's also that chance that the game uses the standard Unicode convention, too, just like most devices in the world do today. With at least that much luck, any hex editor could search the game for Japanese text that you'd see in the game. That would speed up the process, too.
  14. Iconoclast

    Translation Project

    As far as the text exporting, although I have never done it, I have taken notes on the official Unicode layout of Japanese characters as well as the code page for pointing to the characters in The Legend of Zelda: Majora's Mask, so with enough dedication I'm sure locating the entry point into ROM where the code points are stored would be a start to devising an automated way to do it.
  15. Iconoclast

    Translation Project

    Yeah, with a text dump ... here are some tools I have used successfully: http://www.animelab.com/anime.manga/translate/ http://www.dicts.info/dictionary.php?l1=english&l2=japanese_romaji http://www.romaji.me/ Those are all for converting between English and Romaji. http://www.romaji.org/ http://www.whiteagle.net/ http://translate.google.com/ Those are all for converting between English and the kana alphabets (or Romaji).