Mask of Destiny wrote:It should remember the folder within a single run of the program (press Esc to go back to the menu after you've loaded a ROM), though it won't remember what page you're on in a long list of files. The folder it starts in on a fresh run of the emulator is configurable by changing the initial_path option inside the ui section of the config file (default.cfg in the same directory as the executable).
Ah, seems like I have missed this. Personally I would save some settings file or something in registry on programs I make, to be smart about the last folder you used. Many programs do this but arent too smart about it generally. It would be good to see this implemented some day!
Mask of Destiny wrote:Ah, sorry about that. It really should only capture the mouse when there's an emulated mouse connected which won't be the case for the vast majority of games.
Just for simplicity for the user and consistency, a button to do it would be preferrable than the emulator just doing it and the user may get confused with it. You could also add 2 modes where the user can decide between them, and then they at least know what they are selecting.
Mask of Destiny wrote:Do these by any chance keep the S&K product ID in the header?
Yes, but even playing about with it did not fix my issues, so that does not seem to be my issue.
Mask of Destiny wrote:The reason I ask is that Sonic & Knuckles is treated specially because it's a weird cart. Partly this is to support arbitrary lock-on (not yet exposed in the UI, but accessible through a command line option) and partly this is because S&K won't work at all with the normal behavior. Most carts have incomplete address line decoding which causes the ROM to mirror itself throughout the bottom 4MB of the address space and by default BlastEm replicates this behavior. This is not true of S&K; however, and if you mirror the ROM you'll end up with the "No Way" message. Anyway, I'd be open to suggestions on the best way to handle this. I could switch the ROM DB entry for S&K to be hash based rather than product ID based. This would cause S&K based ROM hacks to get the "normal" behavior which is probably what you want for a hack that's >2MB in size, but not for ones that are the normal 2MB. Maybe adding a size filter is the right option? This way 2MB hacks would work fine and could be used with lock-on support and >2MB hacks would just be treated like a normal ROM.
The big issue is that if the people edit the header and yet only do something like level edits. How are you gonna handle this? Or, if they only editing code very intensively, but leave the header alone, you also need to detect that. I guess the best compromise is check a few fields in the header, and maybe search for the header checking code, and then based on all of those info decide if its supposed to be S&K hack. But you also risk breaking non-S&K hacks that kinda look like they may be S&K hacks based on the header and some of the code. You could also add a little field in some unused string in the header to help the emulator to do few things, and add it to the documentation. No emulator really can do everything like this perfectly because of how big edge-cases ROM hacks can cause.
Mask of Destiny wrote:If that doesn't sound like it applies to the hacks in question, please post a link or send them to me so I can investigate.
I would be happy to, but these hacks are work-in-progress and are still really hush-hush, so I can't show them off. However, I could debug them myself, only if the debugger in BlastEm was something I am more familiar with (I use Regen for debugging, as it works sometimes without problems and does what I need it to do usually). I was not able to find much help from the debugger, but honestly I did not try too much, it felt clunky to use for me.
Mask of Destiny wrote:This appears to be a separate issue. I can reproduce the crash by selecting Sonic 3 and I'll investigate that tonight since that's obviously a bug. I'm pretty sure this is because Sonic 3 has save RAM and my SSF2 mapper support is probably not playing nice with that. I'm not sure what you mean by "spits out mapper errors all the time" though. I didn't see any noticeable problems when I tried the other 3 games
I tried Sonic 3 & Knuckles and got the errors, for it to quit immediately after. I checked out S1-S3 too, and the first two worked all fine. I'll admit, this hack was quite hard to even get to work on many of the emulators it currently does, so I have some sympathy on that end; I had a hell of a time trying to figure it all out, based on very little information. I even had to debug some issues with Everdrive for days (A friend in another country had one, so it made it so much harder) just to find out I was not clearing some RAM I should have been. If I didn't bother fixing it for emulators, no emulators would be able to run the hack in any form.
Mask of Destiny wrote:
I take it you've never tried to run a Genesis/MD ROM in MAME/MESS then
Well since I've heard its awful anyway, I haven't bothered, you got me
Just to clarify afterwards, I don't mean to be dick about it, it was more about frustration with the apparent flaws I was facing. Its frustrating when something that seems to have promise, has many flaws that turn me off from using it. The amount of times I've gotten frustrated with using Regen for various reasons, is off the charts. Its a huge shame its still the most useful emulator ever made, with the huge amount of issues it has. Especially because of its debugger actually working (unlike certain some emulators >_> *cough Exodus cough*). In fact I am quite frustrated I still have to deal with it, and would jump ship as soon as I can get my hands on something more working solution...
Mask of Destiny wrote:I'll add drag and drop and hopefully the initial_path setting will address your concerns about having to navigate through a directory tree on each invocation.
It seems fair enough, though I would still like to have something more 'smart'. Of course, having the option is still good always. Having to never navigate menus will help a lot though, since I wont be needing too many paths if I have my hacking folder already open anyway
Mask of Destiny wrote:I am working on a new UI that's not ROM-based (though that will stick around as an option), but since being gamepad friendly is important for me it still won't be drop-down menu driven like Fusion or Gens.
Now, I understand you want to make things work with gamepads, but if it means harder for mouse users, or developers, you aren't gonna get much support. Unless you can implement a menu system that is both easy for mouse users and gamepad users, I would suggest finding some ways to accommodate mouse only users, and gamepad only users.
Gamepads reminds me, I had my USB controlled hooked on my computer from playing some other games few days ago, it would complain about every single button it has, not being mapped to anything. It would be fine, but there is a lot of them, so I ended up holding Enter to skip them quickly... Only for the emulator to exit and open 10 instances. I'll admit, its an user error, but surely you can find a better way to deal with it than complain about each button separately?
Mask of Destiny wrote:If you have any other specific feedback about the usability of the current UI apart from the obvious stuff like the ugly text rendering and the inability to edit the config from within the UI please let me know. My use cases are not yours and so what seems like a major usability issue to you might not be obvious to me.
I had easier time using my arrow keys than my mouse for navigation. Also, I for some reason was able to change the FPS in the menu, only for the FPS to reset to 60 ingame. ...Only for it to go back to 200 in the menu. Seems a little strange to me. Also I was able to mess up the menu somehow when I was playing around with the FPS hotkeys (I guess, I didn't bother reading the README enough to find more info, found them by accident lol), but after changing to 60 FPS it worked just fine afterwards.
Mask of Destiny wrote:I think your perspective on this is colored by the specific ROMs you are trying to run. In general, 0.5.0 has been pretty extensively tested against the commercial library and high profile demos/homebrew. ROM-hacks have not been a priority for testing, but perhaps this demonstrates that was a mistake.
I guess thats a fair criticism, I did test out quite a few games though and most seemed to function well aside from minor issues (Some games seemed to lag a lot more than they actually do), but the issues seemed surprisingly major in the mentioned hacks. There is a few S3K hacks around (aside from basic layout mods might I add) that is worth testing to see if they have similar issues to what I was having... Generally, the problem with ROM hacks and hackers is that many do not have good access to hardware testing, and neglect to do this, not realizing how inaccurate all emulators we have really are, and how many things can go wrong. Therefore, I do not suggest testing just all the ROM hacks, but asking skilled hackers (Like Vladikcomper) what hacks are worth evaluating, because there are many technically well done hacks, but 10x more that are the opposite.