Then I recommend you test your games in endrift's mGBA. Like Anty-Lemon said, it aims to fix all bugs in GBA emulation. If the emulation issues are still there, please post your results here or through the bug reporting options on the site.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
I'd like to hear about any vba version that emulates these games correctly.
And also any feedback about mGBA, as that is an emulator I'm hopeful about adding to BizHawk
Joined: 2/12/2015
Posts: 153
Location: Everett, WA
CoolKirby wrote:
d-feather wrote:
I'm not TASing them, I'm just playing them.
Then I recommend you test your games in endrift's mGBA. Like Anty-Lemon said, it aims to fix all bugs in GBA emulation. If the emulation issues are still there, please post your results here or through the bug reporting options on the site.
I tested Final Fantasy I & II: Dawn of Souls, and there aren't any graphical glitches. When I get a chance, I'll test the other games, but I'll exclude Pokémon Mystery Dungeon: Red Rescue Team since endrift said that works perfectly fine.
:shrug:
I'm more active on Twitter nowadays: @HunterCoates5
[URL=http://s63.photobucket.com/user/franpa/media/Untitled_zpsdwbwqsr5.png.html][/URL]
Wouldn't it just be wiser to call the option "Windowed Fullscreen" or something and remove the lengthy explanation of what it actually does (Maybe keep the warning about increased latency)? Also there seems to be no difference between 4x and 5x window size.
Edit: by default my Back button on my Logitech 310 controller was bound to Rewind and Fastforward by default (Rewind seemed to take precedence).
The option isn't windowed fullscreen. We don't have a true fullscreen mode, so windowed fullscreen is all that's available. That option prevents windows from forcibly turning it into a 'fullscreen' mode on some video cards. Some systems will never go fullscreen, so describing that option as controlling fullscreen is untruthful. This situation isnt simple, so theres a lot of text.
There are many X window sizes which have no differences. It differs by platform and your AR settings. Unfortunately it is _impossible_ to provide simple 1x/2x scales with some AR settings due to the solutions of the math being chaotic. In the future I intend to make the meaning of 1x/2x not be strict but instead choose values which result in a steady increasing grade of window size. It regularly confuses me the way it is right now.
Default bindings for gamepads are illogical. Every one is different. IMO we shouldn't even have them except for xbox pads but I got overruled long ago. This doesnt count as a bug.
I've never seen the whitenoise/nowhitenoise function fail to work and have no clue why it wouldn't for you.
I've never seen the whitenoise/nowhitenoise function fail to work and have no clue why it wouldn't for you.
Sorry, what I meant was that disabling the option does not result in the emulator displaying "Oxoo", I don't even know what Oxoo IS. Also in my image included in my previous post, a part of the description of the fullscreen Hacks setting doesn't seem to make much sense in terms of wording (It should be reworded slightly).
(Since in Microsoft's new and disimproved operating systems, windowed mode things may have higher latency.)
Probably change it to:
(Since in Microsoft's new and disimproved operating systems, windowed mode applications may have higher latency.)
or
(Since in Microsoft's new and disimproved operating systems, windowed mode may have higher latency.)
I mean I can kinda see what you mean with the word "things" it just doesn't gel right imho. I realize I'm being a bit pedantic here.
Well:
1) Wouldn't it make more sense to say "nothing" instead of "an Oxoo"?
2) Enabling the option causes the emulator to display snow, so the first word should be changed to disabling.
So it should say "Disabling this displays nothing instead." Or alternatively "Disabling this option will result in the emulator displaying nothing instead of snow."
I'm not sure why you're getting so fussed up about word choice, especially when it's about an option which has nothing to do with emulation
Anyway, imo it wouldn't hurt to at least use "0x00" instead of "Oxoo" so people don't confuse the option for showing an animal from a Doctor Seuss book or something.
The idea was for you to read '0xoo', imagine a dr seuss character, smile, think about what it means, and figure it out. Now all the joy's been sucked out of it.
Wouldn't it make more sense to say "nothing" instead of "an Oxoo"?
Black isn't nothing though. A program literally drawing nothing would look like this if you drag another window across it.
That's only true in the scenario you've captured.
On older versions of Windows, (or when WDM is disabled such as Windows classic) any time you uncover a portion of a window that was previously covered it would send a request to the application to redraw that area of the window. Until it's been re-drawn, you see what was previously on that portion of the screen. On newer versions of Windows with GPU acceleration and WDM, each window is a separate layer and the rendered content of the window is retained whether it's visible or not. This was necessary for features like peek when you mouse-over a minimized window in the task bar to see what's in it. (Not to mention important for Aero glass, so they could quickly blur the underlying content without asking for everything to redraw as you move things)
Back to the topic at hand, it's 0x00, not Oxoo. Those are zeros. A 0x prefix before a number is the standard used by many programming languages, including C and C#. For clarity, sometimes it's a lot clearer to initialize a short to 0xFFFF instead of typing 65535 because then you can easily see that "oh, all of the bits are on". For 0 it doesn't really matter though. In HTML and CSS, it's the equivalent of putting # in front of your hex color.
Windows 10 x64 9926
Taskbar located along the bottom of the screen
1) Maximize the emulator
2) double click it to enter fullscreen mode
3) Bug = Emulator doesn't appear over the top of the taskbar
4) double click again to exit full screen and enter a restored Window mode
5) double click to return to fullscreen mode, now it is properly fullscreen
You could also just double click while the window is restored to begin with to avoid the bug.
works fine for me in windows 10 9841. We'll hear more about this I'm sure when it's not a beta OS anymore. Sounds more like an OS bug than a bizhawk bug anyway.
Then I recommend you test your games in endrift's mGBA. Like Anty-Lemon said, it aims to fix all bugs in GBA emulation. If the emulation issues are still there, please post your results here or through the bug reporting options on the site.
I tested Final Fantasy I & II: Dawn of Souls, and there aren't any graphical glitches. When I get a chance, I'll test the other games, but I'll exclude Pokémon Mystery Dungeon: Red Rescue Team since endrift said that works perfectly fine.
I tested LEGO Racers 2 (I didn't see any problems) and Hamtaro (which does have the aforementioned bug). I filed a bug to track the Hamtaro bug. If you wish to do any additional testing, please post results to the mGBA thread. Thanks for finding this!
Freezing SNES RAM addresses does not work in Bizhawk 1.9.1. Just noticed this today while trying to investigate Demon's Crest. I found a bunch of addresses I was certain were significant, but freezing them had no effect. I got suspicious and tried loading up Dragon View and freezing addresses I knew for certain, and it had no effect whatsoever. I tried freezing them both through the Hex Editor and RAM search window and same result in both. It works as expected in 1.8.1.
Example address: $007028 in Dragon View is your Y-velocity. Freeze it while jumping and you should fly upwards.
EDIT: This is only an edit because it's probably old information, but... Was dicking around in 1.8.1 and had a problem where an address would always re-freeze itself every time I rebooted the core for some reason. I fixed that by closing bizhawk, but then SOMEhow, the ROM I was running got overwritten... It was originally 2MB and somehow became 128kb. I have no idea what happened.
EDIT EDIT: I notice RAM Freeze seems to be fixed already in the latest SVN.... sorry for wasting your time...
12:05 - discovered sound bug in game X
12:12 - discovered sound bug in game Y
12:15 - discovered sound bug in game Z
12:22 - discovered sound bug in Aero Fighters Assault
12:34 - wrote on forum "discovered sound bugs in some games and aero fighters assault"
Are there any CLI switches to set when I launch EmuHawk? I grabbed 1.9.2 (my lappy's old video card doesn't do OpenGL 2, I was hopeful I could finally run one of the post-1.6 bkm's) and my attempts to launch it come up empty, no dialog, no log, no nothin'. Sometimes it just sits there in the background waiting for me to kill it, sometimes it starts and stops without ever making a window. If there's some way to at least force stdout I'd might figure out what it's not doing.
No useful options for that. There's no way to force stdout, blame microsoft for that one. Useful information will often find its way to event viewer. If you got a config.ini dumped then you can change DispMethod to 1 instead of 0 to make gdi+ try to startup instead. Theres no commandline option for that for long complicated reasons.
Sure, it could be done. It's just a big headache. Actually I've thought about doing this approach once and for and applying it to several emulators, maybe trying to make a bit of a standard out of it. So one CLI frontend could capture the output from several programs. I mostly say this in case anyone else has heard of such a thing and so can save me the effort.
[/URL]
Wouldn't it just be wiser to call the option "Windowed Fullscreen" or something and remove the lengthy explanation of what it actually does (Maybe keep the warning about increased latency)? Also there seems to be no difference between 4x and 5x window size.
Edit: by default my Back button on my Logitech 310 controller was bound to Rewind and Fastforward by default (Rewind seemed to take precedence).
