#Pcsx reloaded plugins windows#

This is because the emulated game expects a low precision integer value which will be truncated to 0 for many small triangles. As PGXP calculates and stores vertices in high precision the implicit simplification doesn't happen but the default NCLIP behaviour still results in small triangles, that would have become degenerate, being culled. The PlayStation's GTE has a function to cull these degenerate triangles called NCLIP which also removes triangles that are facing away from the viewer (back-face culling). You can see this happening in the image where groups of small triangles form simple squares, two or three triangles stretch as their vertices snap to the same few points while other triangles disappear altogether. This causes those triangles to collapse into lines or points, becoming degenerate, with an area of zero. I can only assume those gaps are either in the original mesh or being created as part of the tessellation/LoD system before the vertices are transformed.Īll the triangles are being transformed but the low precision results in many vertices of small triangles getting the same position.

#Pcsx reloaded plugins windows#

I did get it working for Windows locally, with a lot of hacking about, but there seemed little point to releasing that version as most of plugins available are only compiled for TheDimensioner I've noticed those holes in Crash 3, unlike other cases I can't seem to influence those by modifying NCLIP, although the game does seem to use it for back face culling. The 64-bit dynarec is only used in the linux and MacOS versions, the Windows solution only includes the x86 version, I updated it to help CarterLi on GitHub build for Mac. There are vertices being transformed and added to the cache but not at their final screen space positions, so when GPU plugin does a lookup it's sometimes finding a value but probably not the right otherman good point about the VC++ redistributable, I've added it in now. What's happening when the cache is enabled looks like random false positives. The distortion effect on faces is also pretty gamax92 I suspect Hydro Thunder is writing individual bytes, PGXP currently only tracks 16 and 32-bit reads and writes because vertex coordinates are stored as two 16-bit values.

I do hope Sony does a good job on remaking these games, because as emulation already shows, remasters might not work very well. Unless someone discovers a way to change the FOV, and also re-position Crash so that he is further on the field, than maybe a vert- method would work. I think since the Crash games are 3D 'corridor' platformers, there was no need to create more scenario where the player would never get to explore, so the original PSX trilogy might never get a proper widescreen method, even if the widescreen hack is improved someday. I preferred to record this using the hack anyways, because that big overscan in the NTSC version is just stupid in 4:3, so the game will look kinda of 'cinematic' in widescreen XD (XMedia Recode gives me an aspect ratio of 1.9692).

This game does not work very well with the widescreen hack, but it's not as bad as Crash 1 and 2. Although there's an issue, where at a distance 'holes' will appear on the ground (like what the old GTE accuracy hack did on some games), the character models and the rest of the scenario are high precision, using 'Memory only' mode.