
… den ganzen Satz und das Post-Mortem lade ich später hoch, wenn alle Fehler behoben sind.
Freut mich, wenn es unterhältmarcgfx hat geschrieben:Sieht wieder mal gut aus Krishty! Bin schön gespannt wie dein Endprodukt dann ausschaut, bin weiterhin gebannt am lesen
One of the next write-ups will dive deep into the GPU memory management of the PSX, and this will be really impressive for anybody who’s into low-level stuff. It just takes me a lot of time to illustrate what’s going on. Stay tunedscheichs hat geschrieben:Alsways impressive how much NAMCO got out from a system like PS One and what tricks they used to accomplish that. Thanks for sharing your reengineering work with us guys!
No, it must have been someone else. However, when I first got the idea to extract AC3, your Romhacking thread was the first hit and the tools helped me a lot, so I’d like to say THANK YOU! hereDragonSpikeXIII hat geschrieben:Es gab jemand, der in meinem "AC3 text replacement" thread auf Romhacking.net nach Models fragte. Waren Sie es?
Of course; use it for whatever you like! That’s why I post it here, after allIch bin hier mehr weil ich würde eine Frage machen: könnte ich Ihre AC3 unpacker für meine AC3 Englisch fan-Übersetzung projekt benützen? Ihre program hat einige wichtige Vorteile, zum Beispiel einige neue menus und kleiner Grafische Elemente. Das ist besser als esperknight's AC3 toolkit und kann eine vollere Überstzung machen.
Ist gar nicht schlecht. Wir können aber genau so gut auf Englisch sprechen, denn hier lesen noch andere nicht-deutsche Modder mit (z.B. Infrid)Entschuldigung für mein schlechtes Deutsch
DragonSpikeXIII hat geschrieben:No, it must have been someone else. However, when I first got the idea to extract AC3, your Romhacking thread was the first hit and the tools helped me a lot, so I’d like to say THANK YOU! here
Of course; use it for whatever you like! That’s why I post it here, after allI can give you the source code if you need it, but be warned it’s a bit messy. I didn’t know it catches more files than the other tools, but I’m glad to hear that.
Ist gar nicht schlecht. Wir können aber genau so gut auf Englisch sprechen, denn hier lesen noch andere nicht-deutsche Modder mit (z.B. Infrid)
// Ensure that the triangle is counterclockwise on the texture!
// You may want to use a distance field to improve results on overlapping surfaces!
static int const BORDER_SIZE = 3;
// A copy of the texture, entirely resolved with a palette:
RGBA pixels[256 * 256];
resolve(indices, pixels, polygon.paletteIndex);
// Three vertices on the texture correspond to the three UV coordinates:
auto a = polygon.uv[0];
auto b = polygon.uv[1];
auto c = polygon.uv[2];
// Compute three planes:
auto a2b = b - a;
auto b2c = c - b;
auto c2a = a - c;
auto normal1 = a2b.perpendicular().normalized();
auto normal2 = b2c.perpendicular().normalized();
auto normal3 = c2a.perpendicular().normalized();
auto d1 = normal1.dot(a);
auto d2 = normal2.dot(b);
auto d3 = normal3.dot(c);
// Compute the triangle’s bounding rectangle; catch overruns:
auto minU = maximumOf( 0, minimumOf(polygon.uv[0].u, polygon.uv[1].u, polygon.uv[2].u) - BORDER_SIZE);
auto minV = maximumOf( 0, minimumOf(polygon.uv[0].v, polygon.uv[1].v, polygon.uv[2].v) - BORDER_SIZE);
auto maxU = minimumOf(255, maximumOf(polygon.uv[0].u, polygon.uv[1].u, polygon.uv[2].u) + BORDER_SIZE);
auto maxV = minimumOf(255, maximumOf(polygon.uv[0].v, polygon.uv[1].v, polygon.uv[2].v) + BORDER_SIZE);
// For each texel in the bounding rectangle …
for(auto v = minV; v <= maxV; ++v) {
for(auto u = minU; u <= maxU; ++u) {
// Compute the texel’s distance from the three edges:
auto uv = UV(u, v);
auto distanceFromPlane1 = normal1.dot(uv) - d1;
auto distanceFromPlane2 = normal2.dot(uv) - d2;
auto distanceFromPlane3 = normal3.dot(uv) - d3;
// Is it inside the (padded) triangle?
if(distanceFromPlane1 >= -BORDER_SIZE && distanceFromPlane2 >= -BORDER_SIZE && distanceFromPlane3 >= -BORDER_SIZE) {
r.resolved.texels[v * 256 + u] = pixels[v * 256 + u];
}
}
}
However, checking the specification, it’s more complicated … GPU TexPage drawing attribute, Bit 10 (we will analyze these flags in a future article):Krishty hat geschrieben:
- If the triangles exceed the display area (e.g. if they’re off the right screen edge), one must be careful not to overwrite the textures! The PSX maintains a hardware flag to mask off drawing to the display area or to off-screen space.
http://problemkaputt.de/psx-spx.htm#gpurenderingattributes hat geschrieben:Drawing to display area (0=Prohibited, 1=Allowed) ;GPUSTAT.10
In order to render to the screen, youGP0(E5h) - Set Drawing Offset (X,Y)
Sets the drawing area corners. The Render commands GP0(20h..7Fh) are automatically clipping any pixels that are outside of this region.
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast