Uhmm that sounds a bit unlikely. I havent touched anything in that department. Maybe it's savestate related. But if you can notice it when richter fights dracula then thats fortunate and it should be pretty easy to test further
retroarch doesnt count. their mednafen psx core has unknown changes. find a way to run mednafen. If youre on OSX, openemu might count, as long as you find out which version of mednafen psx core its using. If youre not on OSX, I cant fathom why you can't run mednafen.
I will be glad to support SBI if I have a known test case. Google suggests crash bash isn't about the SBI files but some other copy protection, but I don't know for sure.
I see absolutely nothing about whether you tested anything in mednafen. This is a required step for the crash bash problem.
But the dump of cash bash I have comes with an SBI file which is not currently supported. It might be necessary to get the game to boot. I'll work on that soon.
I don't have a game called magical drop F, so I don't know what you're talking about, but it sounds like the disc type detection failed. Probably your dump is terrible junk.
I can't make any sense of what youre mumbling about pcsx-rr, but we dont need exhaustive support of games that dont work on pcsx-rr but do in mednafen. Pcsx-rr's days of relevance are numbered.
But if soft anti-aliasing could improve it, why not have an option? So the question is, would it look improved?
We'll have options. You'll have a nice blurry screen to match mednafen soon if that's what you want. I'm not a fan of blurring and I insist that octoshock have a non-blurry mode for debugging which is why I did it first, but mednafen's default approach looks pretty decent. Besides which, bizhawk should eventually support a number of post-processing filters.
As far as plugin-style graphical enhancement, don't waste your wishes thinking about it right now. Mednafen's GPU plugin is still in hot development, supporting graphical enhancement for something like that essentially seals it off from all future development by turning it into a convoluted mess.
TheThrillness wrote:
Will I be able to continue the TAS with the movie I have right now or when BizHawk finally does support disc swapping, will my movie no longer sync or even work?
disc swapping is a priority. Your movie will need some hand-editing to repair once disc swapping is installed. I'm fairly confident it will work, but I'm not sure I can recommend proceeding just yet for that reason. Besides which it's still very new, and I'm glad you survived with no desynchs but before you get too invested in something you should probably wait and see what other issues we run into.
Yeah, well, in principle, it's just to ID the disc. Although.. the main reason for IDing a dump is to find a bad one... but we've historically conflated IDing a dump with confirming that it's a good dump, and that is only because we can hash the whole thing.
We want bizhawk to display a green checkmark and then you can TAS with confidence. To do that I think its clear we have to scan the whole disc.
I had always thought we might have to add later, as an optional feature, a background thread that is a complete disc scanner. Maybe now we have to do it as a mandatory feature. Another option would be for the icon to be ambiguous and suggest a tool to use and print the hash that the tool better tell you for this disc, which has been ID'd by a partial hash, to actually 100% match.
I don't know for a fact, but I would assume their hashes are over the entire disc, and we dont want hashes over the entire disc, as it would take too long to run and be annoying. Exactly what hash we should use is an open question, but I don't think it should be that hash.
What we can do though is, once we've decided on a policy, run a hashing tool against that database and a pile of redump discs, in order to produce hashes of our type. I feel like this might be what we end up doing eventually.
EDIT 12-jul-2015 - Bizhawk now checks discs with a small 99.9% accurate identification hash and compares that to entries in its gamedb populated from a redump discset. Games will show up as "good" green checkmark roms if they pass this.
The "Dual Shock or Not" requirement can be dropped. Most players are used to the two stick controller anyway. The PSX came without them initially. It shouldn't effect things if we have it.
Uhh we should get this in the other thread, but now's the time to say it: reportedly, which input devices are attached can have substantial impact on the timing of the game. The peripheral IO is kind of slow, and the way its set up you kind of have to wait to read extra data even if you didnt want it? Or something like that.
So, bottom line, some elementary TAS may be faster simply for having a different controller attached.
This could be verified readily by trying different in mednafen different input configuration options for known problem cases or high profile games. You shouldnt have to play very far before observing a discrepancy. If we get hard data that indicates this is a problem, we may be forced to handle the input configurability early on.
There are some things that I want to be resolved before I will be comfortable saying "This is Good to Go"
Hey, we should probably have a new thread just for this. The "PSX core development/testing thread"
It's interesting you listed some things I'm not sure I would have put on the list for the first release. We may have to debate that a bit. I think some of the trickier stuff will probably slow us down more than we'll want, when we could have a release that folks could be using for simpler cases.
Of your items, here's what I think: first release can be 1 player dualshock only. But multiple discs must be supported (including movies) and dealing with that savestate annoyance. The memory card sharing could be accomplished right now for casual gaming by managing your files carefully, but I have no clue what this means for movies. Do we need a TAS which has actually multiple games in the queue and boots one game, saves, then boots the next, and loads the same memory?
Oh thats just a toolbar or ribbon based UI. Toolbars suck, but ribbon is kind of a cool principle, if it werent in a program that you were already used to and didnt need to change.
creaothceann, I dont understand what im looking at. I see some tabs and some broken buttons with no labels.
The proposal on the table doesn't have anything to do with having to click lots of checkboxes. It's basically just one more (optional) click to pick what platform you want.
These checkboxes in menus are done for
1. convenient programming
2. user convenience: when you DO want to set these types of options, it's frequently just one at a time
yes, it's annoying when setting things up initially. we're not going to optimize for initial setup. adding additional convenience for initial setup is extra work.
quality, cpu, irrelevant. The main problem is that openGL is a universe of bugs.
You're right, microsoft has a lot of the blame. But GPU vendors have blame for making lousy drivers, and opengl ARB has blame for being irrelevant for many years when d3d was taking over.
probably that, with one item at the top that pops open a listbox of consoles.
Later when we have 'open advanced' we could jam it in there instead of adding yet another thing to the file menu.
c:\my\nes\roms
d:\bigfiles\psxisos
q:\roms\oldroms\completearchiveofroms\sms\usa
suppose those are where my roms are.
now, I want to play a NES game. so I open rom, and the current path is... where? who knows. Now I want to play a SMS game.. and the current path is... where?
What I want to do is say File>Open Console>NES and have it already in the NES roms. or File>Open Console>SMS and have it already in the SMS roms.
He wants to actually use different rom paths for different consoles, and the only way that makes sense is to pick the console before opening a rom. Seems clear enough to me.
Fastforward while vsyncing was fixed some time ago. If it isn't in the latest version, it should be in the next one.
If you dont want to see skipped frames while using vsync, you must use the vsync throttle.
OpenGL sucks for gaming, I don't know why our using opengl should make you happy.
I dont think we can force triple buffering. Ask google about the subject. Only your driver control panel can do that. If we could do it, it would be done in GraphicsControl_TK.cs line 22
Desync doesnt mean what you think it does. Stop using that word.
I'm not sure what the ROMs path configuration for each platform means anyway. It doesnt seem sensible. There is no way to pick a core first, so the ROMs path for a platform can't be used. If someone finds this valuable, it should be implemented in the file menu as "open core" or somesuch and cascade to cores with known ROMs path
bizhawk doesnt make any particular effort to 'register itself with the windows audio stack'. You changed windows versions, and wonder why something else changes? Microsoft ignores compatibility with every new release. About the only interesting new thing you get with new windows versions are new incompatibilities.
update: problem doesnt occur on any windows 8.1 machines we tested on. not that many users of the cutting edge OS, youll have to wait for a developer to repro it or avoid using MS cutting edge unless you like bugs.
BSNES must run in an executable since its use of coroutines renders it incompatible with .net, and thus there is substantial overhead in IPC between emuhawk.exe and libsnes.exe. Presently, the hooks are evaluated on the bizhawk side, so each instruction executed in libsnes needs to communicate back to bizhawk. Communicating the hooks to bsnes is possible, but it is a lot of work and isn't a high priority since the number of people running pentiums trying to run bsnes in the first place are minimal.
never mind, we discovered theres a semi-broken rom for this game out there that makes it behave my way. you had the better rom, and must have fixed your problem by changing back the core selection