Posts for zeromus

1 2
31 32 33
45 46
Posted: 11/11/2014 8:07 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
It was automatically selecting neshawk for me even when i chose quicknes. I dont know why it wasnt for him. Maybe he's using an ancient version of bizhawk. Anyway I thought we selected neshawk when quicknes wasnt supporting the mapper.
Posted: 11/11/2014 4:27 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
0a. This does seem jacked up. following are notes for future debugging: 0b. check line 590 in Watch.cs. cheat.PokeValue() happens, and then return true; note that theres no way to get to PokeByte below. Was PokeValue intended to internally do the PokeByte()? 0c. It appears (to the hex editor) as if the value is truly frozen. Is this because the involvement of the cheat layer? Imho, it should read back out from the core directly instead of trying to create a fraudulent reality 1. By "No frame limiter setting" you clearly mean speed setting, and when theres nothing checked, it's because youve used the -/+ hotkeys to change it to a value not in the GUI. "unpredictable" in this case should mean "completely predictable based on the value you left it at" 2. Dont do that. 3. It's changed to be relative to the client window and not (brokenly) relative to the emulator output. Since gui.text isnt capable of scaling, and is intended to be more primitive than the other drawing functions, it occurs in client-window-space. So the coordinates you enter there will be fixed even as you resize your window. If you want the text to appear at a certain point in the game world, youll have to use a different lua drawing function. More generally, anything related to lua drawing is subject to change at any time, since it's all in a state of half-brokenness.
Posted: 11/11/2014 4:02 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Its working fine for me. Have you somehow got it loading in the quicknes core? Are you sure it's a good rom?
Posted: 11/9/2014 1:52 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
which version of bizhawk are you using, have you tried disabling your security software, and what GPU and OS are your system running? have you googled for bizhawk "task manager" and followed any of that guidance?
Posted: 11/9/2014 1:50 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
perhaps your hooks are being executed continuously? if they get executed on every single cpu cycle, for example, then you should expect the software to run at 1/1000th its original speed. Are you using bizhawk in bsnes or snes9x mode? It wouldnt be fair to compare your overall performance in snes9x with the hooks to bsnes with the hooks. If youre comparing the proportional speed hit of the hooks in snes9x vs bizhawk, then bsnes in bizhawk will suffer exceptionally due to problems communicating efficiently with the bsnes core.
Posted: 11/8/2014 5:28 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I doubt that's true. Try running a lua script that doesn't draw anything. You should see that it's faster. Drawing is slow, for now, and all you can do is upgrade your CPU.
Posted: 11/8/2014 5:22 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
aa is CPU internal crap, ignore it. dp is CPU internal crap, ignore it. in other words, everything is 100% normal and theres some extra crap. I wish we would have this documented somewhere. I think I'll just take out the extra crap. It upsets me if someone who knows what an A register is has his time wasted by wondering wtf an AA is.
Posted: 11/8/2014 3:37 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
you already knew emu.getregisters returns a table. so why not try getting ["A"] from the table? MDR - "memory data register" (google it) RD - I think this is the last byte read from memory? it's a cpu internal state, probably only used in the middle of instructions. I doubt we need to be exposing this. Vector - the address of the IRQ about to get executed.. it's not clear if this is a real thing at all, it may just be a BSNES implementation detail. It's probably exposed through emu.getregisters for no good reason Z - this appears to be a "Z index" register used to re-base zero page operations somehow. I'm not sure if it is active in the SNES version CPU, but I found it in BSNES so I exposed it. If someone can confirm whether it's operational, I might could remove it.
Posted: 11/7/2014 3:51 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
They operate the virtual pad. I suppose the dialog could make this clearer. You can't make an analog modifier for n64 games unless youre a c# programmer or a lua scripter. It sounds like a good thing to put on our bugtracker as a feature request. I just modified the code to display a tooltip to that effect. It's better than nothing. We might could find a more visible way to display that in the future.
Posted: 11/7/2014 3:31 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
the general rule is: you must not edit dialogs while using a non-96 DPI, otherwise your visual studio editor will emit other code which will break the scaling. Namely, an AutoScaleSize will change from 13 to 12 or something like that. However, since what we're doing here is _disabling_ the auto-scaling, it should be benign. Please go ahead and fix whichever dialogs you need to, as long as how youre fixing it is precisely what r8154 did.
Posted: 11/6/2014 9:52 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
OK, I can fully explain this problem. Our forms were all set to AutoScaleMode.Font. This means that the dialog is resized according to the font size used for the dialog. .Net uses a 9pt font on Japanese systems (vs a 8.25pt font on others) by default. Therefore, the dialog will be resized for japanese users to fix the mismatch between developers and users font sizes. This should work. However, there are bugs in .net which make certain dialogs malfunction. In our case, for the record, it's the use of Bottom and Right Anchor styles. I tried to fix this by various font substitution methods, but the problem seems to be the use of a 9pt font, and there's no way around that short of hacking .net. Therefore, to fix it, we have chosen to suppress the auto-sizing. The work needs to be done for each dialog, so if you encounter similar problems in other dialogs, we'll need to fix them also. I suggest that you keep an english windows XP VM for testing things like this, if you're going to be using english language software. This particular GB config problem was fixed, I hope, by r8154.
Posted: 11/6/2014 12:33 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
It sounds like your computer is the only one in the world with this problem. Can you try it on another computer? I think it has to do with fonts, desktop enhancements, DPI, etc. Something is making two buttons disappear. I'm sure you've tried resizing that window, right? It has a size grip in the corner.
Posted: 11/5/2014 11:09 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Which URL did you download bizhawk from? Which version are you testing now? Please delete your bizhawk config.ini file and try to find the 'Palette...' button in the GB config. Do not set a custom path. Does it work? Now, set the custom path to c:\ ; Does the 'Palette...' button appear? Now, set the custom path to what you want; Does the 'Palette...' button appear?
Posted: 11/5/2014 6:10 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
It seems like you are writing about three bugs at the same time. It is very confusing. Let us talk about only one bug. So, let's ignore everything you already wrote. Now, using 1.8.4 I have set the GB palettes path. Bizhawk remembers it after I close it. It is used when I pick "Gameboy Settings > Palette..." and then pick load. The configured palette is remembered after I close the emulator. Everything is working perfectly. Which of those steps does not work for you?
Posted: 10/31/2014 1:16 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
A "timing issue" won't cause a movie to desync after playing back properly 5 times. A _bug_ causes that. Therefore I suspect you're asking about the desyncs you mentioned in another thread which you created, which was left at a "OK, I'll test it in 1.7.1" state, but just randomly guessing some crap about timing being involved because it sounds super serious.
Posted: 10/26/2014 4:02 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
biosolids wrote:
I cant remember where i got it
That's not a good answer. You mightve got it from buggyvirusbuilds.info in which case youre wasting your own time, and your system is being used to send spam. You need to know these things. We can't support builds from buggyvirusbuilds.info.
Posted: 10/26/2014 1:23 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
biosolids wrote:
Im using r874 , so that's outdated ??
r874 is from 2011
Posted: 10/14/2014 10:13 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
you talked about black area, i replied about letterboxing. therefore, either I am confused, or they're equivalent.
Posted: 10/14/2014 8:58 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
feature for reading letterboxing area was added after 1.8.4. youll be able to get the screen size as well. Q: do other lua-bearing emulators youve used have or need this? is this problem bizhawk-unique for having a frontend which does the letterboxing? are other emulators displaying the frontend-space rendering only within the black-boxed area (such that it is impossible to draw outside it?)
Posted: 10/11/2014 8:45 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
you can always check youtube videos or other emulators for comparison. usually your instinct is adequate. i forgive you in advance for any incidents of 'nope, its actually like that on hardwares'
Posted: 10/11/2014 8:00 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
become an expert on mednafen psx. i know it's not very rewarding now, all you can do is sit there and play games, but it will be extremely valuable later when we can say "????" and feos can say "oh thats a mednafen bug. heres 3 other games with that same bug". see what i'm saying?
Posted: 10/11/2014 12:18 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I dont believe we can guarantee that a .lsmv will sync. We each had to butcher our bsnes cores in different and exciting ways to make them useful as a rerecording emulator.
Posted: 10/11/2014 12:15 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
no
Posted: 10/7/2014 5:15 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I used to think git revision hashes were dumb, but if they train people not to expect sequentiality of releases and wonder where missing revision numbers went, as if there's gonna be a missing volume on their collection shelf, then maybe there's something to it after all...
Posted: 10/7/2014 12:37 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
You should probably learn how to use autohotkey, but I don't think it would be too hard to add a hotkey to bizhawk to close it. edit: Added as "Exit Program" in r7948
1 2
31 32 33
45 46