Jump to content
Visual Boy Advance-M


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About KunaiTeam

  • Rank
  • Birthday 07/01/1976
  1. KunaiTeam

    OS X: Constant Initializer Needed to Compile SDLAudio

    Huh, as far as I remember, the standard says they're optional. Maybe it's something new in C++0x?
  2. For some reason I haven't been able to figure out yet, OS X needs a constant initializer in SDLAudio.cpp for the private static _delay member variable. Attached is a patch.
  3. KunaiTeam

    SDL: vsync when using OpenGL

    Yes, I know it's not a great solution, however, it's no different than how the SDL renderer does it currently. IIRC, SDL_Flip() (which is called once per frame) waits for vsync when SDL_HWSURFACE is used. (Except, perhaps, in the X11 driver.) And considering that it made DMG games, which were unplayable on my system, playable, I decided to upload the patch. I'm willing to look into sync to audio, if you could provide more details as to how that works. It might also be worthwhile to include vsync as an option in the SDL port since it seems to me that syncing to audio wouldn't necessarily prevent tearing.
  4. KunaiTeam

    SDL: vsync when using OpenGL

    I recently tried playing a plain-old DMG game on vbam for the first time and found the graphics to be really choppy. I did not experience this when playing GBA games or when rendering through SDL. This is because on OS X SDL_Flip() automatically waits for monitor vsync. (IIRC, it does not do this on some systems.) I went in and added a line to make OpenGL do the same, and it made a world of difference. The game was unplayable before, but it worked perfectly after that. Patch is attached.
  5. Yeah, things always get really tight for me around the holidays. I literally have no free time until January, probably. Thanks for your encouragement though.
  6. Patch.cpp uses off64_t, fseeko64 and ftello64 to ensure that it can open files larger than 4 GB in size. In linux, off_t is 32 bits, necessitating the need for off64_t, but off_t has been 64-bit in BSD for years, so it does not have off64_t. Since OS X is based on BSD, it also does not have off64_t, and Patch.cpp fails to compile (as of revision 800, and possibly earlier revisions). Attached is a patch to correct this problem for OS X and BSD systems.
  7. KunaiTeam

    Mother 3 translation message...

    Yeah, that screen is kind of strange, because the only button you can use to get past it is A. That is whatever VBA-M is set to use for A, not the A key on the keyboard.
  8. KunaiTeam

    PPC core fix

    Yeah, but there are still quite a few people who use them, so I went out of my way to make sure the VBA-M Launcher I made was a Universal Binary. As far as I know, the SDL works on PPC Macs. At least it did a few months ago when I last had a PPC Mac. The VBA-M Launcher app I posted here may solve his problem.
  9. KunaiTeam

    Memory-based Patch support

    I think it's great that you're contributing back, Tantric, I'm not sure that we'll need memory-based functions for the desktop versions of VBA-M, but people porting it to other systems might find it useful.
  10. KunaiTeam

    Remove interframe.cpp

    I think interframe blending was the one feature of VBA that I never understood. It just seems unnecessary. I have no objections to removing it.
  11. KunaiTeam

    [split] Windows VBA-M build with UPS support

    Linear is the fastest, and bilinear will give you better quality, though with GBA games I'm personally hard pressed to notice the difference.
  12. KunaiTeam

    Any way to get VBA save file behavior?

    That's a good point. I currently organize my ROMs by system, not by emulator. So I think the best compromise is to allow the user to set the directory for battery saves, save states and screenshots. However, because keeping the saves in the same folder as the ROMs can cause problem for ROMs on multi-user systems, I would suggest that the default behavior to place them in their own folders within a VBA-M folder. That way ROM directories are not polluted with these files by default, but users like nathan who prefer to have these files in one directory can set the preferences however they want. I realize that this is essentially equivalent to what spacy51 suggested, except that, IIRC, %appdata% is a hidden folder in Windows. What I am suggesting is that this be exposed through the preferences in VBA-M rather than the location of a specific file. I would also suggest that there is an option to create separate directories for each ROM inside each of the battery/savestates/screenshots folder.
  13. KunaiTeam

    Any way to get VBA save file behavior?

    I believe that the correct thing to do on any multi-user system, which includes Windows NT/2000/XP/Vista, is to place the save files, save states and screenshots somewhere in the user's home folder. That way multiple users can play the same ROM and have different save states. Now, whether or not ROMs are personal user documents as well is less clear. I tend to believe that they are, but the system administrator may want to make a ROM available to all accounts. What I would recommend is allowing the user to specify a location for a V-BAM directory. Inside this directory there would be for soubdirectories: ROMs, Battery Saves, Save States, and Screenshots. (These are just suggestions. I think that "Battery Saves" might be confusing to some users, but "Game Saves" isn't quite accurate). I believe that this would satisfy nathan's desire to have everything in one directory, while still providing a clean split so that the ROMs directory doesn't get overrun with screenshots and battery saves. If someone really wants to have their ROMs in the same directory as the VBA-M executable, they can set the directory in the preferences.
  14. KunaiTeam

    OpenGL gvbam graphics corruption on load scaled

    Just to be clear on this, and after looking at the OpenGL code, there is no bug that should cause this to happen in the VBA-M code. As long as this is working on other video cards on Linux, it is definitely a card-specific issue. ATI cards have notoriously poor Linux support. So even if that card works for VBA-M in Windows, there's no guarantee it will work in Linux. No video card manufacturer has perfect Linux support, but You're going to have a much better experience in Linux if you have an Nvidia card (or even an Intel card, though you won't get the same kind of performance as ATI or Nvidia). This is because the ATI drivers on Linux are pretty poor. Both ATI and Nvidia refuse to release the specs for most of their cards because they fear that if they do so, the other company will steal their trade secrets. That means that it has been up to the Linux community to reverse-engineer the cards and write their own drivers. Since it's mostly volunteers doing this, some cards have solid Linux drivers and others don't. Currently the reality is that Nvidia cards tend to have better Linux drivers than ATI cards.
  15. Right now I'm using Objective-C++ to make the port. This is just regular Objective-C with the ability to call methods from C++ objects. Learning Objective-C would be a good start, but not all of Apple's frameworks use Objective-C. For example, Core Audio is a C framework. I have not started at all to port the SDL code over to CoreAudio. I've been using the SDL code. Porting the SDL sound code to Core Audio (using the Quicktime API, not the OpenAL API) might be a good place to get your feet wet. In the same vein, I haven't started with the Quicktime movie capture code yet. This will require the Core Audio implementation to work. You can look at the source code for SNES9X to get a good idea of how this is done, but keep in mind that SNES9X's code only works on PPC machines or on Intel machines under Rosetta, since 16-bit RGB 555 pixels are not supported on big-endian machines. The code is also a little outdated, using QuickDraw instead of Core Video. There is example code on Apple's site on how to use Core Video to accomplish the same task. The difference is minimal.