[Projekt] Extracting Ace Combat

[Krishty]

Habe am Wochenende Flugzeugtexturen entschlüsselt. Von Gebäuden bin ich aber leider noch ein Stück entfernt …


… den ganzen Satz und das Post-Mortem lade ich später hoch, wenn alle Fehler behoben sind.

[marcgfx]

bis auf das cockpit schauts gut aus, könnte da noch ein fehler vorliegen?

[Krishty]

Nee, die sehen alle so aus – ist ja Sci-Fi; die Cockpits sind komplett geschlossen und alles wird via Kamera gesteuert

Nachtrag: Nee warte – habe doch auch konventionell aussehende:

[Krishty]

Let’s extract a plane.

Planes can be found in folders 0066–0102 (Japanese version) and 0047–0068 (EU/US version). These all have the following layout:

• folder with 12 small binary files (from 0 B to 16 KiB)
• folder with a small binary file (~100 B)
• folder with two textures:

  

• a binary file of several KiB

Pretty obvious this is plane data. But where’s the vertices? We should take a look at the binary files from the first folder. You’d probably start with the first file, but I’ll pick #9 here because it contains some data that’s not present in the first file (and it’s not as complex as the other ones). Let’s repeat the process of finding patterns in binary data, and so we’ll find this structure throughout the files:

This looks a lot like the vertex data we found earlier. In fact, it’s pretty easy to recognize vertices in the same XY XY XY Z Z Z format. Triangle indices are pretty easy to spot as well (the consecutive integers from 00 to 0B):

Visualize what we just found:

mesh 0 wireframe.png (3.15 KiB) 2096-mal betrachtet

Makes sense! I’ll take a shortcut here: In some other files, the last block is not empty, but contains quads instead of triangles (4th index not always zero). However, many files come with no triangles/quads at all, just a set of vertices. Let’s have a look at all files from the folder:

Using this identification chart, we can clearly identify it as a F-18 Hornet

Now, what about the other data (X, Y, Z, Q)?

X does not make sense as triangle indices, but it does make sense as indices into block #3. (See how it counts to 0B == 12 decimal, and there’s 13 entries in block #3?)

So what’s in block #3? It’s not too difficult to figure out once you know what you’re looking for. It’s the vertex normals, scaled to 4096 and stored as 16-bit fixed point numbers (because the PSX has no floating-point support). These normals are indeed very pretty (I decided to apply a random color to individual meshes in order to tell them apart):

We have seen Z before: It’s the GPU instruction for drawing a triangle.

There is not much room left for Y & Q: It must be texture coordinates, because where else would they go? But there’s eight numbers for three vertices, so we need to pick the right ones. We can easily get this done by using the individual texture coordinates as red and green colors:

(I chose a different plane here because I was too lazy to take another screenshot for the article, sorry!) Nice smooth shading and the seams are exactly where a designer would place them!

We’ll apply the texture next time. It’s more difficult than one would think, and it requires the last pair of bytes to get it right …

[marcgfx]

Sieht wieder mal gut aus Krishty! Bin schön gespannt wie dein Endprodukt dann ausschaut, bin weiterhin gebannt am lesen

[Krishty]

Just announcing three new "hidden" levels in the Japanese version of Ace Combat 3.


One hidden level has been known for years: Game Show, the level that shipped on demo discs, with minor modifications. It can only be accessed through a GameShark code (i.e. overwriting a memory location) and it's pretty boring. Its internal name is "----", and the developers probably used it as a test bed for AI before deploying the game.


Another hidden level has been known for some time, but nobody ever managed to enter it: Mission Code. There are some snapshots of the briefing on Acepedia, but the game will crash right after that.

I'm pretty sure I got its map decoded, and there's two copies of that map in the Japanese game files. It's Expo City in an early development stage. The differences from the final city are subtle, but it's amazing to see all the improvements that have been done. The map data looks compatible with the final data format, but the only airplane is the carrier for the Sepia spacecraft. This may be the reason why the briefing loads, but the mission doesn't.


Then there's two completely new maps. This time, the binary format of the models is not compatible with the final maps at all. I suspect the game will crash right away, and this might be the reason no one ever investigated the data. It's Expo City in some state after Mission Code and Megafloat in a *very* early stage of development. I have yet to find out how texturing works; even the vertex colors are screwed up.


I'll try to post snapshots of the early Expo City soon. Snapshots of the two other maps follow later. I have so many things to write here, but my PC does not have an internet connection, so it'll take some time to publish it all.

[Krishty]

I proudly present the first snapshot of the Mission Code version of Ace Combat 3's Expo City map!

For comparison, this is the same region in the demo/final version of the game:

• Expo City's iconic underground airport (top-left corner) has been introduced rather late. The early version didn't have one.
• The early version featured more buildings. The remaining buildings have been scaled down to as little as half their original sidelength (bottom-right corner).
• Texture detail has improved significantly (bottom-right corner).
• The final color palettes are much less colorful. Some look just like stills from the Matrix movie (e.g. the mission Awakening:)

  

• Prebaked lighting has improved significantly.
• The early version is brighter (about twice as bright). I tried to correct for it in the snapshots, so it's not obvious. It's not an art thing -- I guess at some point they compressed the color range of the prebaked vertex lighting and instead improved the texture color range. The reasons could be obscure color processing problems with the PSX GPU, or optimizations, or anything else.

I'll resume the plane extraction tutorial shortly, then I'll write about extracting maps.

[scheichs]

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!

[Krishty]

Sieht wieder mal gut aus Krishty! Bin schön gespannt wie dein Endprodukt dann ausschaut, bin weiterhin gebannt am lesen

Freut mich, wenn es unterhält

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!

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 tuned


In other news, I’m close to having decoded all maps, entities, and planes (including the new hidden ones). That’s enough stuff for three more threads like this …

[Krishty]

Extracted the hidden/secret levels/maps/terrains/missions from Ace Combat 3.

I’m now pretty confident we can group the three Expo City versions of the Japanese game version into alpha/beta/final. The hidden version of Megafloat is a beta version (not alpha) for pretty complicated technical reasons I’ll explain later. First, some snapshots:

This is the alpha version of Expo City. I explained its unique features in an earlier post. This is probably what you’d see if the hidden Mission Code level worked.

This is the beta version of Expo City. It is much closer to the final version (iconic underground airport, smaller buildings, new textures, cleaned up level), but there are subtle differences:

• some textures have not yet been replaced
• there are some holes in the terrain in other places
• it still uses the old lighting

But most importantly, its rendering technology is very different from the other levels. It’ll take me some more tutorial posts to explain it in depth, but it looks a lot like they tried to implement some kind of mip mapping or LOD …

Here’s the final version for reference:

Moving on to Megafloat. Here’s the beta:

It’s not as close to the final version as Expo City’s beta is, but … it uses the same exotic mip mapping approach, so it must have been created at the same time.

Again, the final version for reference:

Two conclusions:

1. Megafloat was completed much later than Expo City.
2. At a late point during development (when Expo City was almost in its final state), Namco tried to replace the game’s entire texture management with a more efficient approach, which likely allowed for mip mapping or farther range of sight – but they failed and rolled back to the old system.

Speaking of hidden beta stuff … the Japanese version was to feature a model viewer, but it was cut before release. It is accessable via memory manipulation (cheat/GameShark code; video not mine):

I extracted the model viewer’s data as well, and to my surprise, the models were slightly different from the ones you see in the video. We could have known earlier: the first two planes in the video are not lit dynamically (turning them upside-down does not change lighting), while the 3rd plane (at 1:18) is indeed lit dynamically. The reason I found: some models are so buggy/have so bad resolution that Namco chose to use the in-game models instead!

[scheichs]

Again very cool stuff! Do you have some polygon numbers? It appears to me that the beta versions have higher polygoncount than the final ones.

[Krishty]

polycount Expo City:

• alpha: 261,673 (4,505 unique)
• beta: 261,172 (5,050 unique)
• final: 251,066 (4,856 unique)

I included the unique polygon count because a few (less than 300) tiles are copy-pasted all over the map and it’s a better metric of entropy IMO. E.g this map:

has a large polycount of 524,800, but it’s just a single tile over and over (512 unique triangles), so the total polycount is misleading

Megafloat:

• beta: 153,031 (7,468 unique)
• final: 147,267 (5,495 unique)

So you’re right – the betas were much more detailed!

Another interesting metric is texture load, in bytes. However, I don’t want to comment on this until I wrote the article on the GPU memory system …

[kimmi]

Amazing results, thanks a lot for sharing those results!

Kim

[Krishty]

I’d love to share more, but I fear sitting down and writing tutorials would break my flow

Extracting maps from Ace Combat 2 took me three evenings:

1. analyzing the game archive format – no compression involved this time, and the internal data structures are very similar to Ace Combat 3
2. extracting tile polygons – still way to go here
3. applying textures – such a good thing I made my code from Ace Combat 3 reusable, it fits perfectly

I can only extract terrain, no detailed objects, but here’s two maps:

Details to come.

[Krishty]

In case anyone wants to extract Ace Combat 2, here’s my decompressor (I don’t think one has been written before):

unpack_AC2.zip

(2.2 KiB) 79-mal heruntergeladen

Apart from the compression, both games’ formats are almost identical, so here’s a similar one for Ace Combat 3:

unpack_AC3.zip

(2.41 KiB) 93-mal heruntergeladen

• for Windows
• should work with all regions (EU, JAP, US)
• and versions (demo, 1.0, 1.1)
• place unpack_AC2.exe in one folder with ACE2.DAT (for the demo, rename D.T to ACE2.DAT) and run
• place unpack_AC3.exe in one folder with ACE.BPB & ACE.BPH and run

Source code (public domain; Visual Studio 2017 solution, builds with VS 2015 as well):

2017-08-04 sources of unpack_AC2 & unpack_AC3.zip

(233.03 KiB) 52-mal heruntergeladen

Ace Combat 2 Regional/Version Differences

Ace Combat 2 was re-released on PlayStation 2 in 2005. I was hoping to find bugfixes and other improvements in the game files, but the only difference in the PS2 version is … this:

It’s even more confusing when you see this tweet from the developers, where the trademark was already in place. They probably just forgot it in the original game files.

Speaking of version differences …

• except for a japanese character map, there are no regional differences (Japan/EU/US) in the game resources
• the executables are vastly different – no wonder regarding the different screen resolutions & refresh rates of PAL vs NTSC
• versions 1.0 and 1.1 differ in
  • the translation fixes I mentioned before
  • a string table in 1.0 being padded with “04EAS.PLY P:\UNIX\PX201\BRIEFING\WO” instead of zeroes in 1.1
  • the executables, again (had no look at the disassembly yet)

However, the Demo version does differ from the full games. More specifically, binary data on the levels is slightly different. This may be different placement of enemies, but I’ll have to check further.

[Krishty]

The project ain’t dead, I’m just still working on the giant GPU writeup.

I just learned that atmospheric scattering is the grilled cheese of terrain graphics: It makes anything look tasty as hell, no matter how bad or old it actually is. So enjoy Ace Combat 2’s Axel Bay! (PSX emulation for comparison.)

You may have noticed that many buildings are still missing – I already extracted their geometry, but I didn’t get around decoding the coordinates for placing them on the map. Meh.

[DragonSpikeXIII]

Mein deutsch ist nicht das beste aber ich möchte es ausprobieren. Ich habe diese topic mit Intersse schon verfolgt. Es gab jemand, der in meinem "AC3 text replacement" thread auf Romhacking.net nach Models fragte. Waren Sie es?

Ich finde das geil dass Sie haben alle diese alpha/beta/final Karten und informationen auf AC2 gefunden. Ich 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.

Entschuldigung für mein schlechtes Deutsch

[Krishty]

Glad to finally meet you As a quick introduction to the other members: You’re the leader of the English translation project I mentioned earlier.

Es gab jemand, der in meinem "AC3 text replacement" thread auf Romhacking.net nach Models fragte. Waren Sie es?

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

Ich 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.

Of course; use it for whatever you like! That’s why I post it here, after all I 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.

Entschuldigung für mein schlechtes Deutsch

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)

[DragonSpikeXIII]

Glad to finally meet you As a quick introduction to the other members: You’re the leader of the English translation project I mentioned earlier.

Likewise and thank you for mentioning my fan-translation project to the German side of the Internet.

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

That's thanks to esperknight and gipphe then, responsible for understanding AC3's compression and file structure. They have since moved on to other things, but they would definitely appreciate the fact that people other than me and my team have gotten some use out of their data and tools, even improving on them.

Of course; use it for whatever you like! That’s why I post it here, after all I 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.

HUGE thanks for this, more things can be translated now! I'm going to add this new development to the next progress report and I've already added your name to the credits. I've run some tests on the things I previously mentioned, such as the blue menus and the UPEO loading screen and they all work even without re-compression, which is very lucky because in AC3 some menus will break the game if the translated TIMs are too big/not re-compressed. And thank you for offering to share the source code, I would have accepted it if my team's programmers were still active but when it comes to me, I guess I'll just use your finished product. It works on every version and as far as I know, extracts and decompresses everything esperknight's program did plus a lot more, and all you have to do is drag and drop, great work!

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)

Genau Ich bekomme nicht viele Chancen zu Deutsch sprechen. Das ist genug für mich, danke!

That's pretty much all I have to say but before I go, I think your discoveries would make for a pretty cool new post on my AC3 blog, I think I'll post about it soon and link to your thread here.

[Krishty]

DragonSpikeXIII just published a blog post about this thread: USEA Today: Introducing Krishty's model viewer

You can grab my model viewer there!

[marcgfx]

cool

[Krishty]

Along with Ace Combat 3, Namco released a press kit with some promotional material for magazines.

It contains some screenshots. The look struck me, because they’re brighter than the final game … turns out, these are snapshots of the Expo City alpha version I decoded earlier:

If you look closely (snapshots of Expo City’s devolpment stages here), you can recognize the red buildings and the colorful textures which have been removed from the final version. There are more oddities:

• time has run out in all of the screenshots (0:00 at the bottom left)
• enemy planes are entirely white
• no artificial horizon or compass
• HUD symbols are different from the final version

I’d love to get my hands on an alpha or beta version, but sadly, there are almost no leaks of PSX games.

The autumn winter collection ’99 press cd 3 contains some of the same snapshots.

Edit: The white F/A-18 from the screenshots can also be seen in this beta trailer from the Ridge Racer Hi-Spec Demo:

There seems to be an even earlier version of Expo City as well, all green.

I’m desperately trying to find Japanese promo disks. There have been vast amounts of unique AC3 promo material (e.g. VHS videos from the final version), but most of it seems to be lost now.

[Krishty]

Texturing a Plane

Let’s continue where we left off last time.

If you just wrap the texture over the mesh using the UV coordinates we extracted, you will be pretty diappointed:



What happened to our beautiful F/A-18I? Well, Remember that a single texture can have multiple palettes:



We just picked the correct palette for the wings, which happens to be the wrong palette for anything else. The correct palette for a polygon can be read from the word between the first and second UV coordinates:

  paletteIndex = (unknown_word >> 6) & 7;

Finding this was a lot of trouble – I picked polygons from every palette region in a texture and compared their bits. Even more important, this is wrong and will not work with anything beyond planes. However, The Right Approach™ requires detailed knowledge of the PSX GPU, and I’ll dedicate a future article to it.

We got the UV coordinates. We got the textures. We got a palette index for each polygon. How do we wrap that up? There’s two possible ways:

1. Using the seven palettes in a plane texture, create seven textures. Every polygon picks the right texture.
2. Project individual polygons back to their textures and apply the according palette to the projected pixels.

The second approach sounds overly complicated. You probably won’t get what it’s doing until the next GIF. So why the hell should we do that?

Because 1. won’t work with other data for the same reasons as the palette index trick won’t work with anything but plane meshes. Been there, done that. You need to trust me on this one.

This is what we’ll do:

1. Project polygons back onto the texture using their UV coordinates …
2. … rasterize them using their selected color palette …
3. … and save the projected result.

It’s not as difficult as it sounds. Rasterizing polygons may be a hard topic, but we don’t care about performance here. Just iterate all pixels in a triangle’s bounding box, do a simple three-plane test do determine whether the pixel is inside of the triangle, and – if so – copy the “real” color to our output texture. It’s even easier if you consider that all UV coordinates are in pixels, not floating-point numbers in [0, 1] range. This code handles it all:

Code: Ansicht erweitern :: Alles auswählen

// 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];
                }
        }
}

Consider that I added a BORDER_SIZE parameter to grow triangles by three pixels. Otherwise, you’ll get jagged texture edges like these:



On the other hand, that’s a clear sign that the algorithm works well

All playable planes can be textured using this approach. You can grab the archive at USEA Today (thanks to DragonSpikeXIII for that)!

However, texturing the terrain is a little more complicated … I’ll dedicate another article to that.

[Krishty]

How PlayStation Video RAM works

If you are younger than 35 years (and also a graphics programmer), you’re probably used to the way memory is managed in modern graphics APIs. But memory management on the PSX is vastly different from that, and so in a surprisingly visual way!

Let’s see how OpenGL/Direct3D/allotherapis.jpg handle texture management:

1. You create a texture object and, in return, get a handle to it.
2. Using this handle, you fill the texture object – typically by passing an array of pixels.
3. When drawing, you pass the texture object handle to the API and it is applied to the new triangles in the back buffer.

This process is entirely transparent. You have no control whatsoever about where specifically in video memory (VRAM) your texture is placed. You cannot access VRAM directly. You don’t even know a single VRAM address!

I don’t want to go into discussions about whether this is a good thing, but on consoles, full hardware control is typically what developers want (and that’s where new APIs like Vulkan are heading as well). This means … addresses. Pointers. Bit twiddling.

Or does it?



phyiscal memory layout – sorry, I will only discuss the logical layout here


The PSX VRAM is 1 MiB large, but that’s not important here. The important thing is: It’s not an array of bytes, it’s an array of pixels. A two-dimensional array of pixels!

Read that again. The entire video memory is an image. An image of 1024×512 pixels, with a top-left corner of (0, 0) and a bottom-right corner of (1023, 511).

An image is displayed by drawing into these pixels and then selecting an area of your choice. This area is sent to the TV screen. (There are some limits on resolution and position here, but games generally use a rectangle in the top-left area.)




It gets weirder when textures come into play. In order to use textures – i.e. write textured pixels to the screen area of VRAM – these must be in VRAM in the first place! So there are at least three steps involved:

1. copy a texture from CD-ROM to VRAM (You better do this once during a loading screen!)
2. use the texture to draw textured polygons to the screen area (your usual frame business)
3. select the area you’ve just drawn as the screen (end of your frame)

Did we have a GIF yet?

Here’s the animated VRAM content for a shooter. Textures are streamed from the CD-ROM drive to VRAM during loading. The first frame uses two textures on textured triangles before the frame is sent to the TV screen – without pointers or addresses, just via 2D coordinates.

• Two changes for clarity:
  • PSX games wouldn’t use textured triangles for sprites; the PSX GPU has a hardware blitting device for sprite rendering. My 1337 MSPaint skillz are just not sufficient to draw real perspective polygons.
  • Front buffer omitted.
• Triangles can also be rendered into the off-screen area – Render-to-Texture – and the on-screen area can be used as a texture, respectively. This can be used to generate impostors, draw fancy particles, or to simulate haze.
  
  
• 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.
  
  
• Very few games used the 640×480 resolution from my sample. PSX games usually chose a significantly lower resolution in order to have more room for textures and intermediate values.
  
  
• You can use tools like PSX-vram to inspect the VRAM of games during gameplay.

Since the VRAM is addressed in pixels (16-bit color depth – R5G5B5A1), we’re left with a big problem – paletted textures. I’ll explain that next time.

[Schrompf]

Wow, thanks for that explanation. This is indeed a surprisingly manual management of VRAM. I wonder how they dealt with potential self-overwriting of drawing actions.

[Krishty]

You mean, with Z order?

[Schrompf]

No, more like: I draw a triangle at the "screen" border and it draws over a part of the texture I use right now.

[Krishty]

I wrote about it way down at the bottom:

• 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.

However, checking the specification, it’s more complicated … GPU TexPage drawing attribute, Bit 10 (we will analyze these flags in a future article):

Drawing to display area (0=Prohibited, 1=Allowed) ;GPUSTAT.10

GP0(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.

In order to render to the screen, you

1. specifiy drawing area = display area
2. pass the GPUSTAT.10 = 1 flag in each draw call (anything can be written to the display area)
3. the hardware automatically clips triangles on the edges of your display area (because that’s your drawing area)

Render-to-texture would be:

1. specifiy a drawing area = your texture
2. pass the GPUSTAT.10 = 0 flag in each draw call (nothing is written to the display area)
3. the hardware automatically clips triangles on the edges of your texture (nothing is written to neighboring textures because they’re outside of the drawing area)

[Krishty]

Amazing sidenote: I just had a look at Arthur Richards acanalysis tool.

This tool was made for Ace Combat 4 (2001), Ace Combat 5 (2005), and Ace Combat Zero (2006) – all of which were developed for the PlayStation 2, probably with the same game engine. The tool works barely with Ace Combat 5 – the UI shows a list of data items, but I can’t expand or read a single one of them. I can’t see airplanes like the screenshots promise.

However, when I extracted a data item, it started with … Ulz. That’s the Ace Combat 3 compression method I mentioned earlier on, which I discussed with Infrid.

My decompressor works with that specific data item. It even identifies the directory layout from Ace Combat 2 and Ace Combat 3 in the extracted data.

I didn’t even plan to extract the PS2 games, and it’ll be a huge amount of work. But what overwhelms me is Namco using the same compression method for CD-ROM data on the PSX’s 32-MHz CPU and for DVD-ROM data on the PS2’s 299-MHz CPU, and our extraction code working with two generations of game consoles. Namco even ported their 1997 data layouts to the 2005 game! Compatibility ftw!

[MasterQ32]

*lurk* just wanted to tell you that i really like this thread! keep it going, it's interesting !