Introducing some coding fixes to blueshogun96's branch of Cxbx, which has been given the quick title correctness-fixes branch on github.
Changes are based off blueshogun96's public Cxbx code from January 2012, with changes for:
- Fix: Memory out-of-bounds access with XPP_DEVICE_TYPE in XTL::EmuXFormatUtilityDrive()
- Fix: Order of precedence for menu item inactive greying out
- Fix: Ensure correct error checking in EmuXGSwizzleBox()
- Fix: Fix for end of memory block in CheckIntegrity()
- Fix: Ordering of variables reported in CxbxRtlReallocDebug()
- Fix: Correct use of STL container method .clear()
- General better debug message support
Coding improvements will happen here alongside blueshogun96 and other's changes, and I'd be of course happy to see these fixes make their way back into mainline releases.
For the time being, I won't be releasing binaries as there are some further improvements in store.
Question, did you ever look into adding fibers while I was away? I did attempt to add support for fibers, but my implementations would always break. Since it's been a while, I forgot exactly what I was doing (can't remember if I ever found out the right FS register offset either). Team Ninja (DOA, Ninja Gaiden) uses this functionality and won't go any further than an intro without it.
Btw, do you have a change log? Or do you state all of your changes here? I'm curious as to what else you've come across in my absence.
Hello again,
I haven't looked directly at fibers, but can spend some time on it.
Getting that 64 bit fix into my branch is of interest, however I'm able to do most of my development on a 32 bit virtual machine.
Whilst not comprehensively posting in this thread, the best way to see my main line changes is via GItHub's commit messages. I think I did a decent job explain each change, and making each commit as atomic as possible: https://github.com/Echelon9/cxbx-shogun/commits/master
Okay, that's fair enough. I'll trudge though it later on.
Btw, I was thinking maybe a D3D11 renderer would be of use. I can see all sorts of functionality that could be added with D3D11, but would be impossible to do with D3D9 (at least, not efficiently).
- Eliminating the need for primitive patching via the geometry shader. The current implementation isn't very efficient either, it just "works" for most intents and purposes.
- Using shader model 1.1 isn't going to be effective enough to convert many shaders. There's too much functionality lacking in it and doesn't support enough shader instructions either. This is a big problem I had with Castlevania Curse of Darkness, and it will be an impediment to running games like Shenmue II. Instead of converting to assembly, we should convert to HLSL (this is what Xeon does). It will save us lots of trouble in the future.
- Up until D3D11, we've had no functionality equivalent to D3DDevice_BeginPushBuffer(). I abandoned working on 3 titles because I didn't have a solution for this (Metal Gear Solid II, Spy vs Spy, and Mad Dash need this). Now we can use command lists similar to how we had display lists in legacy OpenGL.
Just a few thoughts I had.
Shogun.
EDIT: I forgot to ask, did you document your change to the .exe generation code that fixes the headers for 64-bit mode? I'm looking for that now.
Ah, thanks. Added that to my branch, and now the 0xC000007b error is gone. Still didn't get the x64 fix running. If you still have SoullessSentinel's old source, do you think you can share it somehow? Or if you'd rather not, that's okay. Just curious as to how well this would work on my end since I'm running Win8.1 x64.
All I have left to test on is my old retro gaming PC, but I have an older version of Visual Studio on it (.net 2003) and I don't have a project file for that version anymore afaik. Tbh, I don't believe the runtime version matters so much. Could be wrong, who knows.
Probably best to work with the 32 bit development environment you have, and then we can progress through testing of the 64 bit fixes. We absolutely need to get 64 bit working well, for it to be viable (but fine now on WinXP/Vista/2003 32 bit).
Getting the 64 bit support locked down, will remove one block on a DirectX 11 renderer. AFAIK, Windows XP doesn't support DX11, hence why my first steps were in trying a DirectX 9 backend renderer first.
Oh yeah, I forgot about that. Direct3D11 is Vista and above. Although my initial attempt wasn't successful, I still wouldn't mind having an OpenGL backend, since it's closer to the hardware we are emulating. A short while ago, I dug up an old attempt to customize a D3D8 -> OGL wrapper for this. Maybe I could give it another go, and see how well it works. For SDK samples, it worked for the most part (minus shaders), but would always render a black screen on Cxbx. Wouldn't hurt to try again though.
How many are working on this emu currently? I'm hoping to be able to play Conker Live & Reloaded and Midtown Madness 3, Galleon, etc. on PC some day...
There are perhaps 3-4 of us, but each only working on it very intermittently.
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Related Threads
?
?
?
?
?
Next Generation Emulation
2.2M posts
459.8K members
Since 2001
A forum community dedicated to all emulation enthusiasts. Come Join discussion on all platforms from Nintendo, Microsoft Xbox, Sony Playstation, to PC. Coding, tips, builds, specs, tricks and more.