Next Generation Emulation banner

1 - 20 of 86 Posts

·
Registered
Joined
·
80 Posts
Discussion Starter #1 (Edited)
Hi,

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.
 

·
Registered
Joined
·
45 Posts
Great job!

There was one issue I was looking at related to power-of-two textures, where Cxbx was "fixing" the size of a secondary surface used by Panzer Dragoon to render the full-screen post-processing effects which was 512x384 or 400x300 depending on the effects. Cxbx changed these to 512x512 and caused the game not to render properly because it expected those exact sizes. I never got to fix that, so maybe this is something you'd be interested in looking at?
 

·
Registered
Joined
·
80 Posts
Discussion Starter #3
Great job!

There was one issue I was looking at related to power-of-two textures, where Cxbx was "fixing" the size of a secondary surface used by Panzer Dragoon to render the full-screen post-processing effects which was 512x384 or 400x300 depending on the effects. Cxbx changed these to 512x512 and caused the game not to render properly because it expected those exact sizes. I never got to fix that, so maybe this is something you'd be interested in looking at?
Thanks

Do you have a listing of API function class from the log, leading up to the point where this graphics corruption is reproduced?
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Great to see another person trying to improve CXBX :)

how long have you been lurking?:p
 

·
Registered
Joined
·
45 Posts
Do you have a listing of API function class from the log, leading up to the point where this graphics corruption is reproduced?
Here's the KrnlDebug file using a modified version of Cxbx SVN rev 163. Unfortunately, the trace was disabled because it was causing serious issues with my virtual machine (BSODs and whatnot), but still, the relevant parts are present.

This is what happens right after you get in game (on the first episode):

EmuWarn (0xA50): Needed to resize height (384->512)
Texture created @ 0x0194DD50 [hRet = 0x00000000]: 512x512, 1 levels, usage = 0x00000001, format = 0x00000017

EmuWarn (0xA50): Needed to resize height (384->512)
Texture created @ 0x0194DE70 [hRet = 0x00000000]: 512x512, 1 levels, usage = 0x00000001, format = 0x00000017
Keep in mind these values are the converted PC values, not the original Xbox values.
The texture is created with a call to EmuIDirect3DDevice8_CreateTexture.

These two surfaces are used as render targets for the game world. As you can see, the game tried to create two D3DFMT_R5G6B5 512x384 textures with usage = D3DUSAGE_RENDERTARGET, but Cxbx readjusted them to 512x512. My best guess is that it renders the scene into one texture, then uses that as a source to apply pixel shader effects onto the other surface which is then rendered on a single large quad on the actual screen.

Later on:
EmuWarn (0xA50): SetRenderTarget Failed! pRenderTarget = 0x0146D5A0, pPCRenderTarget = 0x03E00060, pNewZStencil = 0x00E18830, pPCNewZStencil = 0x006E315C, hRet = 0x8876086C
This is EmuIDirect3DDevice8_SetRenderTarget, and 0x8876086C is D3DERR_DRIVERINVALIDCALL.

This causes the game to render the world into the last render target, which happens to be the screen surface. After that, the quad that was supposed to be the actual render target is rendered on top of that, obstructing everything. You can see the scene behind it if you enable the wireframe mode. The end result looks like this -- the world scene is rendered on a smaller part of the screen (512x384 inside 640x480, you see). In some cases the scene is rendered into a 400x300 surface (such as when performing a glide attack), presumably due to higher processing costs of the effects.
 

·
Premium Member
Joined
·
6,071 Posts
This is an issue that has been bugging me too. Unfortunately, since I don't have access to a PC running Vista or Win7, I can't even get ingame with PDO (except for the demo which now just keeps crashing). I commented out the resizing texture thing for Outrun 2 and it partially fixed it.

Try the SVN update.
 

·
Registered
Joined
·
13 Posts
I still need to try the svn version but it aint working on my netbook. No Intel support (duh, Nvidea) .. Vm also dint fixed it. Last Nvidea laptop I had broke, so need that PC again. I has win7 serial if you need (But im sure you dont need such a thing).

Nvidea is easier to support I suppose XD
 

·
Registered
Joined
·
45 Posts
I am unable to compile the project because the XTL namespace is causing <cmath> to fail to compile. It's not a good idea to include files inside a namespace declaration (as in EmuXTL.h); you should define the namespace in each header file. Also, the following symbols are missing:
- DXGetErrorDescription8A
- D3DXSaveSurfaceToFile
- D3DXIFF_BMP

Using Visual Studio 2010 btw. I lost my copy of VS2008, but I guess I could grab the express edition.
 

·
Premium Member
Joined
·
6,071 Posts
I haven't tried with VS2010.

Another member was PMing me about it. I don't know why all of these errors are showing up with 2010. 2008 express works fine.
 

·
Registered
Joined
·
45 Posts
These errors happen because of certain changes in the cmath header file on VS2010:

...
using _CSTD acosf; using _CSTD asinf;
using _CSTD atanf; using _CSTD atan2f; using _CSTD ceilf;
...
_CSTD is defined as either :: or ::std:: in yvals.h.
cmath is included inside the XTL namespace by some other include, which means the functions defined in math.h included before the above lines by cmath are under that namespace. The compiler tries to locate ::acosf, but the function is actually defined as XTL::acosf, and there's nothing we can do about it except avoiding including files under namespaces. Yeah, this is not gonna be easy...
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
I am unable to compile the project because the XTL namespace is causing <cmath> to fail to compile. It's not a good idea to include files inside a namespace declaration (as in EmuXTL.h); you should define the namespace in each header file. Also, the following symbols are missing:
- DXGetErrorDescription8A
- D3DXSaveSurfaceToFile
- D3DXIFF_BMP

Using Visual Studio 2010 btw. I lost my copy of VS2008, but I guess I could grab the express edition.
I had problems with VS2010 and I had to readjust the order of some includes before it compiled
dont remember exactly what i changed but i'll be compiling shoguns latest svn commits in a few hours so i'll post details then
 

·
Registered
Joined
·
33 Posts
StrikerX3,

As temporary solution for cmath - open "X:\Program Files\Microsoft Visual Studio 10.0\VC\include\" and backup cmath file. Make a copy of math.h and rename it to cmath. It works for me. :D
 

·
Registered
Joined
·
80 Posts
Discussion Starter #15 (Edited)
I am unable to compile the project because the XTL namespace is causing <cmath> to fail to compile. It's not a good idea to include files inside a namespace declaration (as in EmuXTL.h); you should define the namespace in each header file. Also, the following symbols are missing:
- DXGetErrorDescription8A
- D3DXSaveSurfaceToFile
- D3DXIFF_BMP

Using Visual Studio 2010 btw. I lost my copy of VS2008, but I guess I could grab the express edition.
StrikerX3, I'm seeing those same missing symbols on VS2010, when linking against the version of DirectX8 within the SVN checkout at import\DirectX8\include.

I believe the version on SVN may be old, as inside of dxerr8.h the DXGetErrorDescription8A is missing, whereas I've seen copies of dxerr8.h that have it after DXGetErrorString8.

blueshogun96, are you linking against the DirectX8 in the SVN checkout path, or a version installed under C:\Program Files\ from the last Microsoft DirectX SDK to include DX8 (August 2007)?
 

·
Registered
Joined
·
80 Posts
Discussion Starter #16
This is an issue that has been bugging me too. Unfortunately, since I don't have access to a PC running Vista or Win7, I can't even get ingame with PDO (except for the demo which now just keeps crashing). I commented out the resizing texture thing for Outrun 2 and it partially fixed it.

Try the SVN update.
blueshogun96, I believe you have made a slight typo when implementing XTL::EmuIDirect3DDevice8_GetScissors().

There is a section of code like this added recently in SVN r174, which appears to set the top left corner of a D3DRECT structure to 0,0 and the bottom right corner to the size of the viewport.
Code:
 D3DRECT *pRects
...
D3DVIEWPORT8 vp; 
g_pD3DDevice8->GetViewport( &vp ); 

pRects->x1 = pRects->x2 = 0;  // <---- Whoops
pRects->x2 = vp.Width; 
pRects->y2 = vp.Height;
The problem is that you are setting x1 and x2 to 0 (top left), rather than x1 and y1.

Suggested fix below and attached as a patch file:
Code:
Index: CxbxKrnl/EmuD3D8.cpp
===================================================================
--- CxbxKrnl/EmuD3D8.cpp	(revision 174)
+++ CxbxKrnl/EmuD3D8.cpp	(working copy)
@@ -10400,7 +10400,7 @@
 
 	g_pD3DDevice8->GetViewport( &vp );
 
-	pRects->x1 = pRects->x2 = 0;
+	pRects->x1 = pRects->y1 = 0;
 	pRects->x2 = vp.Width;
 	pRects->y2 = vp.Height;
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
I fixed the cmath issue by placing #include <cmath> on top of HLEIntercept.cpp

I also had to exclude uXboxAdpcmDecoder.c because it didnt exist o_O

I then built cxbe, cxbxKrnl and cxbx individually

I added Echelon9's fix to my compilation :D


EDIT: in visual studio 2010 you have to readd the Directx include paths if you want to compile debug and release versions.
 

·
Registered
Joined
·
80 Posts
Discussion Starter #19 (Edited)
EDIT: in visual studio 2010 you have to readd the Directx include paths if you want to compile debug and release versions.
Yup, this is a known issue with the June 2010 DirectX SDK, when the Visual Studio 2010 IDE changed the manner by which include and lib paths are set to be per project, rather than global.

DirectX SDK Does Not Register Include/Library Paths with Visual Studio 2010

With Visual Studio 2010, the model for adding include, library, and executable paths has changed. In Visual Studio 2008 and previous versions, paths were specified as global settings under Tools\Options. With Visual Studio 2010, paths are now specified on a per-project basis on a VC++ Directories page. All the Visual Studio 2010 projects for the DirectX SDK samples and tools include direct per-project references to the DirectX SDK--via the DXSDK_DIR environment variable--and will compile without any additional steps. New projects that make use of DirectX SDK headers, libraries, or tools should have these references added to the VC++ Directories property page. For more information, see the topic "Installing DirectX with DirectSetup" in the section titled "Install the DirectX SDK", as well as the Visual Studio team blog entry: Visual Studio 2010 C++ Project Upgrade Guide.
http://www.microsoft.com/en-us/download/details.aspx?id=6812

What I'm interested in is if blueshogun96 has set include and lib paths to the copy of DirectX included in the SVN checkout (per comments within, copied from the Mechcommander 2 source code release), or the platform wide one on his dev computer. I'm suspecting the later, based on methods that have been included in r174.
 

·
Linux's worst nightmare..
Joined
·
1,510 Posts
Bill_gates, i got those missing sources from google, and placed them into "src\CxbxKrnl\EmuXBAudio" folder. And finally compiled Cxbx on VS2010. :)
uXboxAdpcmDecoder.c / uXboxAdpcmDecoder.h
Thanks. I'll ask shogun if those files were meant to be in the current revision of the project before adding them.

For now im testing sdk 5933 sound samples and some of them finally work with this revision! :D A few of them keep playing their sounds even after the xbe crashes :p
 
1 - 20 of 86 Posts
Top