|
greatflash
-
Posts
1576 -
Joined
-
Last visited
-
Days Won
9
Content Type
Profiles
Forums
Events
Downloads
Store
Articles
Posts posted by greatflash
-
-
Ok,
Seeing I have harped on about this somewhat (Sorry Tom), I want to confirm that for me it is working a BLOODY treat....... Battle Arena Toshinden - here I come
-
Well done on fixing it, can't wait to enjoy some Saturn magic.
-
Awesome Tom,
Will check it out when I get home.
Any clue for us to what the issue was?
-
Just to backtrack on this,
Using the latest build of GX along side Virtual Clone Drive:
Whilst GX is running (in a widow for ease) and you launch (manually) SSF - it will start to launch and then close. The debug I post shows that the reason is that SSF cannot find a valid drive to use, and so closes.
If GX is not running and SSF is launched, SSF runs fine and launches any media mapped to VCD.Using the GameEx.EXE from version 14.32 within the folder of the latest GX:
Whilst GX is running (in a widow for ease) and you launch (manually) SSF - SSF starts and runs as expected. Debug shows that the virtual drive is free and ready to be used.
So, this means it is not a library change from 14.32 to the latest build, but something within the main code base that is causing the issue. Somehow the drive is becoming locked so that SSF cannot get access to it. Very puzzling.
The picture below shows SSF ruling alongside GX using the exe from 14.32, something not possible with later (no idea which build after .32) builds.
I cannot (and will never install it) test using Daemon Tools. So have no idea if it is the same there. But if the problem was the same, then i expect the solution to be the same also. Perhaps someone can do these 2 steps (in bold) using Daemon Tools?
-
On 18 March 2016 at 10:14 PM, Zyon2323 said:
With a little searching, I found 14.33, installed it and it worked great! So its narrowed down between 14.33-14.43.
It had already been mentioned that .32 and .33 appear to work fine.
-
On 19/03/2016 at 11:35 PM, Adultery said:
/side note: It could be that VCD itself is the problem. For those of you who tried several, if you had VCD installed somewhere and just weren't using it, that would further the theory.
I only use DTools, never even installed anything else. And SSF works for me.
I'm pretty sure that GameEx relied on VCD for quite a while, so maybe the issue is with those of you who used/installed GameEx internal mounting support?
It could well be just an issue with VCD, though the same issue has been mentioned using DT as well, though that may not be the case.
I prefer to use VCD myself as it is tidy, compact, and comes with 0 'extras', unlike the tons of things wrapped in a DT install.
-
Sadly Win10 mounting only supports ISO, everything I have is cue/bin. I could convert one tomorrow and try though. But even so, I don't fancy converting several hundred images.
-
On 19/03/2016 at 10:20 PM, Zyon2323 said:
I tried it using every mounting configuration possible, Same result. Both using deamon and VCD.
Can you try uninstalling whatever virtual drive software you are using and then ,
Run GX in a window,
Launch SSF.See if it then runs alongside GX? I know you cannot then run a game, this is just to isolate the issue. If all Virtual Drive software is affected (and it runs when the software is uninstalled), then we are getting somewhere!
-
A quick question for all those that are experiencing the crash of SSF, what virtual drive software are you using?
At HK's request, I examined the processes in depth in ProcMon, and found this,
50:56.8 SSF.exe 27952 Thread Create SUCCESS Thread ID: 10720 50:56.8 SSF.exe 27952 IRP_MJ_CREATE V: SHARING VIOLATION Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a 50:56.8 SSF.exe 27952 Thread Exit SUCCESS Thread ID: 10720, User Time: 0.0000000, Kernel Time: 0.0000000 50:56.8 SSF.exe 27952 Thread Exit SUCCESS Thread ID: 4920, User Time: 1.1093750, Kernel Time: 0.0156250 50:56.8 SSF.exe 27952 Thread Exit SUCCESS Thread ID: 8284, User Time: 0.0156250, Kernel Time: 0.0000000 50:56.8 SSF.exe 27952 Thread Exit SUCCESS Thread ID: 29712, User Time: 0.0000000, Kernel Time: 0.0000000 50:56.8 SSF.exe 27952 Thread Exit SUCCESS Thread ID: 27980, User Time: 0.0000000, Kernel Time: 0.0000000 50:56.8 SSF.exe 27952 RegCloseKey HKLM\SOFTWARE\Wow6432Node\Microsoft\Direct3D SUCCESSUninstalling (yes, I know it is not much help for an emulator that needs a virtual drive) VirtualCloneDrive fixed the issue at least. SSF and GX now play nicely together again (also, SSF opens to full window a lot quicker).
So, is it just VirtualCloneDrive or all virtual drive software?
-
I am sure it is somewhere. The initialisation on ssf is pretty long with the final stage being the opening of the full window/screen view. So. Seeing it balls out at around a quarter of this duration I would think it was not video related as I would expect the video initialisation to be later on the list?
one thing I noticed in the events was the ssf.exe runs with virtualisation
-
I will give it a go when I get home.
I didn't say it was killing a process, I was just looking at the two options
so. It looks like something during the init of ssf is locked and causing it to drop back. Sadly ssf does not write a log and the source is not available, making it a little hard to debug. Shima has had requests for the source before and has not released it to anyone afik.
Sadly, that leaves Yabuse! Benefit that there is no need for a virtual drive, bad news is that it is way behind ssf!
-
Yes, there are no logs at all.
-
Thanks for the 'shout' Stig
There has also been quite a lot of work on the databases recently and the slow (but coming) addition of the new MAME system rom names. This can be seen when looking at the SNES database. GX currently does not know about the new data, but that will come once it is improved within the databases. There are also some other important additions, more about that at a later time.
ps. I really must output another developer list
QuoteOh, and he's a UK C64 fan too!
You have to love the 64. It's pretty much what I cut my teeth on with coding games.
-
1
-
-
On 18/03/2016 at 5:10 PM, tthurman said:
Disclaimer: If this is mentioned elsewhere in, I want to mention that I didn't read this entire thread.
I've been searching on this, and one solution I found was to delete the ssf.ini and settings.ini and start over. For some the ssf.ini was the problem, but seemingly this method has corrected the problem for some..
I didn't think this would make any difference, and it doesn't. As far as I am concerned, it has nothing to do with settings or anything else along them lines, it is a process or resource issue I believe.
-
I don't think log posts are going to be much use here. Gx does not report an event at all.
All have to do is,
launch gx and window it
launch ssf
ssf exits
if I don't have gx running, all is fine. The thing I notice about ssf that is different to other emulators is, when opened it appears not to gain focus until it enables it's window view. The first part of the launch is just the title bar (a collapsed view) and gx kills it just before it opens the full window.
The means it is one of two things (perhaps)
ssf needs a locked resource that gx is using and fails because it cannot gain it (has anything changed here in the last few revisions?)
Gx sees or confuses the process of ssf and kills it.
Why this affects some and not others, I have no idea. I use Nvidia (not that it matters) and run Windows 10 ultimate 64bit along with the latest gx build. Though I am sure this has worked before on an earlier revision (though I cannot guarantee it).
I will ill check later if ssf writes any kind of log. Forgot to check that this morning.
-
1
-
-
I have just ran into the exact same issue. It has nothing to do with any mounting options.
If Gameex is running and I just launch SSF in the background, it is killed just before the SSF window becomes full-size. That is all it takes, just having GX running is enough to stop SSF from completing it's launch. All rather odd?
-
1
-
-
The databases are slowly evolving to add support for mame emulated systems. This is a big job though.
Currently not sure if the enhanced database support will be in gemeEx or Evo first.
-
Damn - now that'd been a good source a few months ago!
I've got a terrible feeling that Flash may hit us up again with a long list soon, given all the db renovations.
Um. Yep. Lol
-
1
-
-
There is a fairly extensive database for the Saturn.
-
I had the same problem a couple of months ago. Not sure if this is relevant but I then grabbed all the mame support files like MameInfo.dat etc and placed them in the mame directory and updated the list. All the games returned. It could just be fluke. But may be worth a try?
-
1
-
-
The centred selection option is in Evo (along with much more).
Not much help currently I know - but.....
-
2
-
-
I am currently finishing off the snes database. The nes one is progressing nicely as well and work will continue on that after snes.
-
2
-
-
I also notice that the slow down goes away when switching Snes9x to windowed mode, or if tabbing away from Snes9x (leaving it running in the background). As I said I don't see any of this when running Snes9x standalone.
I was just picking up on this part of the post as execution from within GX would be full-screen and am not sure if the report of it working fine out of GX is related to windowed mode.
-
This may not be related, but thought I would mention it just in case.
I have been experiencing very similar problems with emulators (SNES and NES being main offenders). If I run them in a window, I get a silky smooth 60fps, but as soon as I run them full screen (as is my want from GX) the frame rate drops to 30fps. This is not GX, but more the full screen display being the cause (in my case).
I still have not found the reason why this happens, but it certainly does.
is this related, if not, I will return to the back of the room and sit silently?
Run Snes9X in a window with fps display enabled and then ALT-ENTER to full screen and see if it suddenly drops to 30fps?
I am using windows 8.1 64 if that has any relevance, I never had this problem under win7.
Really crucial question...
in General
Posted
There may be others, though my preference would be for the GX names as well. There are a lot that use odd characters like Japanese names etc. Not sure if they would be a problem though.