We're going to have something like this eventually. I think we're more interested in the crazy thing youre doing and what kind of snags you run into than your exact implementation so far, so please report your findings, in a separate thread if you wish.
probably.
your cpu is also on the old and weak side. 7 years old and optimized for multiple threads (useless for emulation) even when it was made. call it 8 years old then.
still it seems a bit slower than it should (im not sure i would expect 60 on your system though)
make sure you're using opengl or direct3d display method (config > display > display method)
Some systems will revert to gdi+ and then run reaaaly slow.
Well, that's odd, but ask him to try. Maybe only he's got the magic touch. If it happens in stock mGBA (for anybody) then the mGBA author should suddenly be more interested than something that only happens in our frontend
Can you get him to check it on a stock mgba? I don't know how early/often it happens or how annoying it would be to test that, but it's the best step to work on getting it fixed.
Ever since I started using it, Bizhawk keeps crashing on me especially if I try to do certain things one after the other or when using a luascript
Can you try doing those things with a core other than mgba?
MUGG wrote:
When I do memory search and have got some results, but it's in 4 byte form and I want to switch to 1 byte, it doesn't refresh the results. So I click the refresh button but it seems to wipe my results completely.
The tooltip for the reset button says "A new search needs to be started in order for these changes to take effect" because that's just how it is. Changing the byte size with an active search would have to be a feature request that I wouldnt count on seeing soon
MUGG wrote:
If I want to switch to a different memory domain in memory search, it does not update it until after the search is reset. It is a confusing thing for memory search to do because it doesn't indicate that it updated the memory search because it still shows the name of the old one when you switched.
It _did not_ update the memory search, and it still shows the name of the old one to prove it. Also it throws up the red reset button. This all makes sense to me. What do you want, alarm bells and blinking lights? Popup boxes full of warnings?
MUGG wrote:
In memory search, I can only do searches for one memory domain, apparently
There's a "Combined WRAM" memorydomain for the VBA core, we need to add it for mGBA. Please bugtrack it.
MUGG wrote:
When I switch to a domain other than IWRAM (in a GBA game) in memory search, then close memory search and reopen it, it's set to IWRAM again. I would prefer if it stayed where I set it.
Good feature request, please bugtrack it. This one frequently annoys me too.
MUGG wrote:
There seems to be a problem with Dragonball Z Legacy of Goku 2's sleep mode. See related post.
When activating it in standalone mGBA, it will cause strange behavior explained in the linked post. When doing it in mGBA core in Bizhawk, it will awake from sleep mode even though I haven't pressed L+R+Select at all.
I think the right way to do this is to romhack it enough to find the program subroutine that processes or prints text, or is some part of the chain in preparing it for display. Put an execute breakpoint on that, and at that point youll know where the text parameters are being stored (on stack, in registers)
If what you're asking about is how to _find_ that place to put the execute breakpoint, then: use a debugging emulator and reverse engineer the code. You can start by looking at the code that populates the VRAM containing the text; it's probably the final string printer (names and numbers will have been substituted). Youll have to go up some more steps to find the original raw string, if you need to. I think it's probably still about 2% as hard as a complete rom hack.
You know what address is written to when event.onmemorywrite() fires by creating a unique function for each address. pseudocode:
for(int addr in 0x100 .. 0x120) event.onmemorywrite(function() mywritecb(addr) end)
brandaman has some useful ideas, but that's just not how it's gonna be for now.
I _think_ (im not completely sure) what I was doing was trying to bob deinterleave, although the fact that it happened at higher resolution was kind of nonsense. My notes say I hadn't had a test case (although I find that hard to believe). At any rate, now I do.
After more contemplation, I realized the snes wouldve been outputting 480p resolution in principle from the GPU circuitry (even though NTSC out cant handle it) so it made perfect sense to just output it as 'progressive scan' 448 scanlines.
So it should be fixed for you now.
I just fixed the crash. Now it behaves like mednafen--runs (but with what later errors, who knows).
The rip was definitely bad, though. The ccd isn't listing the individual audio tracks (even though the data is in the .img). The game expected them to be there and went nuts.
It doesn't mean it's a bad dump. It means its not a known good dump. And from the evidence at hand (crashing) it's actually a bad dump, but I would like bad dumps to malfunction instead of crashing, so if you want to help me debug it, i'd still like a PM with info on how you dumped that disc. At any rate, finding another dump is your resolution strategy.
@Weegeechan15 : please dont post identical bug in two places. we'll handle this on the bug tracker
@cooljay: is bizhawk showing it's a good dump in the bottom left corner 'dump status report?' if its not a good dump, then thats the end of the story, although i'd appreciate it if you'd PM me with info on how you dumped that disc.
disc number -1 and 1 are kind of equivalent. i think i may have bugfixed this at some point. -1 means "the exact disc is not set, but if there's only one disc, it must be that one." 0 means no disc is inserted. I didn't intend for anyone to see -1. Don't know what it's doing right now. The way the method for switching discs interacts with the movie system in bizhawk is less than ideal, but it does work and thats good enough for now.
there's already a system for importing other emulator movie files into bizhawk, and even a stub for PJM (labeled "todo"). So if you can do c#, you can get the c# and make that converter, especially since there are many examples for other platforms.already
bizhawk introduced no such bug. super road blaster worked fine. bsnes doesnt use the xml. therefore it will play music according to how the music files are named. you tried to fiddle around with the off by one error. there was still an off by one error. therefore, your trial was a failure. try again.
or perhaps youre finding a difference between bsnes 083 and 087 (which we're based on)
i suspect bsnes looks for *-0.pcm when playing track 1 and when the game plays track 1, no sound comes out because theres no *-0.pcm. then when the game plays track 2, *-1.pcm plays
that corresponds to this XML:
http://pastebin.com/d2tAGkv3 (how to paste xml in this forum?? i dont know)
In other words: an off by one error, fixed differently; try again.
The problem is new "tilt" controls have been added to the GBA core and old movies can't be loaded. Someone more familiar with the movie system will have to chime in here to say how this was intended to be handled. Old movies can be fixed readily with a regex and text editor though
i would imagine many people have run it for something like 26 hours. there must be something weird about your system configuration that kills bsnes eventually. in a few days ill run a mari/o of my own and see if it crashes eventually. which bsnes profile are you using?
Our code doesn't load the rom, and our code doesn't load the xml. I don't know anything about what bsnes requires when it ingests an msu-1 xml. But it sounds sensible to me that it should be headerless. The XML based rom loading approach is supposed to be for purified stuff and the old legacy sfc loading (dropped after 087, wasnt it?) needs headers. This isn't a bug or anything we're going to address, but thanks for finding it out. I'll get it in our wiki somehow.
The missing intro music is in SuperRoadBlaster-121.pcm. The SuperRoadBlaster.xml version 1.2 distrubuted by the author does not reference PCMs above -109.pcm. This is blatantly wrong. It's easily fixed.
I don't know for sure how bsnes works (it must be guessing filenames based on *-N.pcm based on the base rom filename and with N matching the track number. This is in keeping with bsnes's use of the .sfc file and implied accessory files) and I don't care. I'll wager if you have an off by one error in your track assignments, you too have made an error in your xml. Bsnes must be guessing correctly for you too.
In these respects, we are not going to be compatible with bsnes's disregard for its own formats. I have confidence with this intel you can fix your msu-1 game.
