Cogwheel 1.0.3.0 beta 3

Published August 24, 2009
Advertisement
I managed to break save states in the last build of Cogwheel (attempting to load a save state would fail, not being able to set a property). I've marked the offending read-only property with [StateNotSaved] and made the loader slightly more robust in Cogwheel 1.0.3.0 beta 3. It's beta 3, not 2, because I uploaded 2 and then noticed another issue - you couldn't change the controller mappings! This is something that must have been broken for ages, but either nobody noticed or they just didn't care to report it. Oh well, that's been fixed now. For some reason Google don't let you re-upload files, so beta 3 it has to be.

Phantasy Star save screen
Another addition is this build is preliminary support for persistent cartridge RAM. Some games, such as Phantasy Star (pictured above) let you save your progress in the game onto battery-backed RAM built into the cartridge. If you come back to the game later you should now be able to continue your progress without needing to manually save the entire emulator state.

I've had reports of rather bizarre crashes bringing one poor user's machine to its knees. I'm at a loss to establish why; I've tried the emulator on four machines (two Vista, two XP) and although one of the machines displays a white screen instead of the emulator output (no pixel shader 2.0 support on its Radeon 9000) the software trundles along just fine otherwise (I can at least hear the game music!) The one notable difference between my machines and his machine is that he's using a 64-bit version of Windows, and all of the ones I have access to run 32-bit Windows. To see if this is the issue, I've changed the configuration to x86 (I've encountered strange bugs with .NET code using unmanaged 32-bit code on 64-bit Windows) to see if this will remedy issues, but if anyone has any bright ideas I'd be interested to hear them.
0 likes 2 comments

Comments

shadowcomplex
Unfortunately I don't have any other bright ideas, but I can confirm what you suspect has been a problem for me. I had written several tools in C# and never had a problem with them on XP or Vista. However, the last game I was contracted on, one of the artists was using 64 bit Vista and the tools all exploded with bizarre (read: cryptic) errors. After trying numerous things, I changed the build settings explicitly to x86 and the problems went away.
August 25, 2009 08:18 PM
benryves
Quote:Original post by shadowcomplex
Unfortunately I don't have any other bright ideas, but I can confirm what you suspect has been a problem for me. I had written several tools in C# and never had a problem with them on XP or Vista. However, the last game I was contracted on, one of the artists was using 64 bit Vista and the tools all exploded with bizarre (read: cryptic) errors. After trying numerous things, I changed the build settings explicitly to x86 and the problems went away.
Thanks for the confirmation, the chap who was having the problems reported that the latest version (explicitly set to x86) now works on his machine, even though there are no changes to the main emulator code. His symptoms appeared to be excessive memory usage (which led to hard disk thrashing when he ran out of physical memory), rendering the machine unusable. Most peculiar!
August 26, 2009 07:00 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement