Posts for zeromus

1 2
22 23 24
45 46
Posted: 7/15/2015 9:18 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Beed28 wrote:
In a devbuild, you had to manually flush SRAM (or Memory Card) data for PSX games. Has that been addressed?
It's supposed to be happening when the emulator shuts down or the core/rom gets closed. Like every other core. This hasn't been addressed or changed whatsoever since december. The only thing that makes it different from any other core in bizhawk is that loading a state won't clobber the .saveRAM stored on disk unless the game actually edits the contents.
Posted: 7/15/2015 8:49 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
While we're on the subject... With bizhawk, it's useful to reference the implementation of an emulator core in bizhawk, independently of the core itself, because we've usually essentially forked it. Now, I called the PSX work `octoshock` because it's an important enough core that it needs its own name and writing mednafen/psx was annoying. I can envision a future where it takes on a life of its own outside mednafen, so I gave it a ready-made name. I consider the work I did to fork it essential enough that it isn't a -hawk fork, it's its own thing. So what do we call it in bizhawk? I dunno, whatever adelikat says. PSXHawk is fine. "PSXHawk is bizhawk's octoshock (the name of mednafen's PSX core, because it needed a name)" is how I would put it.
Posted: 7/14/2015 9:18 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
OK, well, crashing with performance + lua isn't expected, and it isn't normal. Savestate mismatch between compatibility/performance profile shouldnt create crashes, jsut fails loading the savestates.
Posted: 7/14/2015 6:18 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Anything you read about a 6400% limit is idiotic. There is no 6400% limit. Nobody is even achieving 6400%. Stop fiddling with the speed. Unthrottle the emulator. It won't go faster than that. What youre basically doing is saying "I want more speed. I see a speed option" and clubbing it with your first without thinking. The speed controls how fast it runs throttled. If you cant achieve that speed, you dont get that speed. If you want maximum speed, you dont want to control the speed. Run it unthrottled. The performance core doesnt crash for most people. Maybe youre doing something odd, or your OC isnt as stable as you think.
Posted: 7/14/2015 2:21 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
There's no possible way a pcsx run will sync on psxhawk. Anyway that's not a psxhawk feature, it's just a general feature.
Posted: 7/14/2015 2:18 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
The machine isn't as beast as you think. bsnes is a slow emulator. be sure youve picked the performance core..
Posted: 7/14/2015 1:27 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
if the cpu was infinitely fast, the ideal solution would be found in zero time. you're being limited by cpu. concurrency just lets you multiply your speed several times. the algorithms are tightly coupled with the 'domain' library because that's how they sense the world that's hosted in bizhawk. this isn't a problem, it's a basic principle. there's no solving it, or changing it. it just is. you have two choices. you can create a script which runs several emuhawk.exe instances, or you can edit emuhawk to run several bsnes cores. if you make the first choice, you will eventually regret it when you discover emuhawk is not easy to control from an external process or via the commandline. you will then make the second choice, which is the correct one. we have a multihawk project which is a (imho not great, but definitely successful) example of rewiring the bizhawk innards. I think it would be better still to make a new tool window in emuhawk which just takes control of everything. ditch the whole main form and existing lua scripting control.
Posted: 7/13/2015 12:04 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
http://gbdev.gg8.se/wiki/articles/Memory_Map
Posted: 7/10/2015 9:03 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
sounds like the songs are fading out and then not re-starting at the beginning of the track. sounds like an emulation bug.
Posted: 7/9/2015 4:56 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
now for the finishing touch, put it in your fork on github and send us a PR
Posted: 7/8/2015 6:45 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
https://github.com/TASVideos/BizHawk/blob/master/BizHawk.Client.EmuHawk/tools/Lua/LuaCanvas.cs Obviously it's half-baked. Kind of unfortunate that there's no way right now for them to spill into the automatic in-app documentation api search box I think it's a huge mistake for there to be any difference between the canvas functions and the gui drawing functions, but someone needed a canvas fast so they added this in
Posted: 7/6/2015 11:09 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
You can call some function to read a byte directly using the c# code. But this is a waste of time until you actually crack the source open. Youll see what I mean then.
Posted: 7/6/2015 9:42 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
1. Known bug, not having to do with the subject of prescaling. Will be fixed some day. 2. dont enter 4x3, enter 400x300, not having to do with the subject of prescaling Also not having to do with the subject of prescaling: There is no correct aspect ratio for any system as far as I'm concerned. Other people decided the aspect ratio for bizhawk's NES cores is approx 293:256. This is based on NTSC of course. There is no separate logic for PAL, and that option won't work for you. I don't know what puNES does. I have no interest in adding 8000 aspect ratios to this emulator when nobody's is correct. You can enter whichever number you want. As long as theyre full resolutions and not small fractions. If you're looking for exact "aspect ratio" junk in this emulator right now, you're looking in the wrong place. However we should probably take a stab at having a separate "system aspect ratio" for PAL
Posted: 7/6/2015 5:39 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
done in r9097 as a quick experiment. That's the first time I tried to tell someone a revision number from git. I wonder how well it worked? Please test it well: lua rendering, zapper It may interact oddly with your choice of window size. Basically the emulator core output (and lua drawing done on it) will then get scaled internally without controlling the meaning of "1x" or "2x" in the emulator client. Therefore a prescale of 2x with a view size of 1x will result in a window size of 1x. Another way to do it would be to cause it to redefine a window size of 1x, so that a perscale of 2x and a view size of 1x would result in a window size of 2x. I'm not sure which is better and I didn't check how other emulators do it. The way it's done now is best described as an automagic "improvement" to the bilinear scaling. The other way would be best described as a reconceptualization of the picture size at a certain stage. We have a very over-engineered video output system, only a fraction of the power of which is currently exposed to users. I didn't mind doing this because it was an opportunity to check how brain-bending it was after not working on it for a year. It was pretty easy, so I'm happy.
Posted: 7/6/2015 7:19 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
no, that's not what he's suggesting. he proposed to make a dll that lua can consume. lua would still be involved, as would the bizhawk to lua bindings. bizhaw's lua bindings are fairly tightly coupled. you could make a plugin api so people can write their own scripts using managed dlls. that would be c# dlls. he said c++ dlls. You'll find that theres no good place to actually put c# code right now to control the emulator with. Your best bet would probably be to extend the lua console system to be able to manage a list of c# coroutines activated by name via reflection, in addition to lua scripts, and have the c# coroutines run immediately after the lua coroutines, so that the means by which the main emulator frontend launches the coroutines is uniform.
Posted: 7/6/2015 4:09 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Well... that's a decent idea... it will be a bit odd due to needing to move a lot of data out of bizhawk, into lua, and from then to the dll, and the opposite: calling bizhawk (savestate, for example) methods curiously by passing delegates to do it out of lua and into c++. But--it might be easier overall than bolting a new controller onto a c++ core and you can do it piecemeal instead of taking the plunge all at once. Certainly worth considering.
Posted: 7/5/2015 10:18 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
dwood15, if youre thinking about using higan, stop and use lsnes instead
Posted: 7/3/2015 4:16 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
you guys should be able to select other C emulator cores to combine with C bot work. You can still use bizhawk for visualizing your most recent results, but it wouldnt be convenient to visualize it as it runs. If you choose the right core, you could even parallelize it across CPUs (if the core is what we call multi-instance capable). I'm not sure if any useful snes cores are multi-instance or structured well enough for this task at all. There should be something okay NES-wise but I'm not sure what it is offhand.
Posted: 7/2/2015 12:00 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
ok, you win the PCECD thing is probably a similar mismatch as GG vs SMS only in this case its PCECD vs PCE. I suggest just ignoring that red. obviously this is not a great situation. Keeping these kinds of things straight is not one of bizhawk's strengths right now.
Posted: 7/1/2015 10:24 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I don't see anything red. I just see pink, which it seems your OS is using to display the row of a list that you have selected. In both cases you selected the Platform row, so it's pink,.
Posted: 7/1/2015 3:04 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
You're not supposed to do anything. It's a terrible idea.
Posted: 7/1/2015 12:18 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Nopping the frameadvance is a terrible idea. With frameadvanced nopped the NES core won't do anything at all. It just proved that the emulator frontend could run faster.
Posted: 6/30/2015 11:45 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I still think you're confused. If you set the speed, you're doing it wrong. Setting the speed sets the throttle speed. Disable the throttle, and the speed you set it to is irrelevant. I just nopped the whole frameadvance on quickNES and got 27000fps.
Dwood15 wrote:
modding the rom to nop out all the draw calls used by the rom
In order to de-garble this, you would want to hack the rom to turn off the BG and OBJ display. This might or might not send bsnes down a faster codepath. It probably won't make any difference for NES. With SNES you could also SNES > Display menu item and it may or may not have the same effect as hacking the rom
Posted: 6/30/2015 10:11 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
You're pretty confused and it's a bit baffling to me why you'd be worried about barriers you havent hit yet. The speed rate controls the THROTTLED speed. If you're trying to run a script as fast as you can, you wouldn't be throttling; therefore the speedup level is irrelevant. You make more sense talking about stripping the display off. When I hack the code to do that I go from about 3300fps in SMB to 6600. With SMW on bsnes I go from 195 to 215. Not worth worrying about too much. Disabling the display should be a feature of whatever headless script/bot feature we may or may not still be working on.
Posted: 6/30/2015 7:13 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
What's this 6400x speedup cap? I'm not sure where that number would come from. I've seen emulator cores run in bizhawk at 3000s of fps which is only a 50x speedup and I've got a pretty fast cpu...
1 2
22 23 24
45 46