memset is a relic from C, but sometimes it’s still a good solution – especially when used on primitive types or.In this specific case my conclusions are:
#IS CXBX RELOADED DEAD HOW TO#
How to avoid such issues in the future? To be honest, it’s not trivial because the code was not “wrong” per se. With this simple change, the game again looks like it’s supposed to! Since we cannot change the D3DXVECTOR4 constructor, IMO the best fix is just to replace brace initialization with memset. This explains all the differences – compiling in Debug or Release, changing optimization settings, moving code around allĬan affect the stale values on the stack, and thus change the effects of this code. - // 4D Vector //- typedef struct D3DXVECTOR4 Īn empty constructor, doing nothing! Normally, brace initialization zeroes values,īut because of this empty constructor, they are still left uninitialized! Knowing this, I can inspect the code which puts this immediate data on the final submitted buffer: So they are only updated when they need to be changed. Which treats all those attributes as states – setting them once persists them for next vertices, While this might sound counter-intuitive, I’ve been told that this again matches the behaviour of OpenGL immediate rendering, Game uses a set of 4 texture coordinates of two components each, but updates only two of those texture coordinates. Uncorrupting the dataīy placing a few carefully crafted conditional breakpoints in this function, I was able to determine that for those draws the Since we know they come from immediate buffers, I inspected the only function which could have submitted them – D3DDevice::SetVertexData4f. In the frame capture from a Debug version of Cxbx-R, those were zero – so it’s very likely they are the culprit. One of the input values were… suspiciously high: With this info, I went to the code and disabled push buffers completely – and sure enough, the tint is gone:īack to the PIX frame – why exactly is the draw producing such results? Checking the output mesh, I’m not knowledgeable enough about Xbox-specific Direct3D parts to be able to describe them properly,īut in principle, they are a concept nearly identical to an immediate mode in OpenGL. I did not find them, but instead, I found something else – namely, push buffers. I could use this information to find such sequences of calls in the log file. Then uses DrawIndexedPrimitiveUP to draw primitives from the memory pointer. The sequence of calls there is quite specific – the code opts to use a fixed-function vertex transformation, Understanding push buffersĪt this point, I decided to instead understand what are those draws and where they come from. It could have also been reading past array bounds of a global variable, but shuffling around the variables I modified in my PRĪlso did nothing.
Since it started happening after an unrelated change, I suspected that some code might be reading past array boundsĪnd interpreting unrelated variables as color however, a quick check with page heap proved this not to be the case.
That doesn’t help much, though – I identified the draw but not the reason why it’s miscolored. It didn’t take long to find a fullscreen draw whoseĬolors correspond to the artifact visible in-game: Since it’s a graphical issue, I fired up PIX and inspected the frame.
Was glitched, but… it displayed a different color:
A Release version with optimizations disabled This turned out to be true for my PR too – the version compiled with Visual Studio 2017 did not have this artifact.Įven more curiously, neither did the Debug version compiled with Visual Studio 2019. To verify this properly you need to use the VS2017 build. Using a VS2019 build will produce a green overlay screen in a similar way yellow to an overlay screen. I didn’t know how it is possible so I assumed I introduced a regression, but then RadWolfie, one of the main Cxbx-Reloadedĭevelopers, dropped a very important piece of information: It should not be yellow at all.Īt the same time, I was told that this is some old bug that was resolved a while ago, and apparently, it came back. Sure enough, with my PR the game looked hopelessly broken: I could not push a change that fixes the game I care about at the cost of breaking others, so I decided to look into it. That one of my changes breaks another game – Star Wars: Knights of the Old Republic. Things were going smoothly until I got a report Getting the game from an unbootable state to very close to playable in around one week. My mini-goal was to get a particular NASCAR game working, and I succeeded in that, Fixing a completely random bug in Cxbx-Reloaded - Star Wars: KotORįor the past two weeks, I’ve been fixing various issues in Cxbx-Reloaded, the original Xbox emulator.
0 kommentar(er)
