[Projekt] Extracting Ace Combat

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 10.06.2017, 19:47

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

2017-06-09 Axel Bay coast zoom.png
2017-06-09 Axel Bay alpha blending artifacts.png

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon DragonSpikeXIII » 10.06.2017, 21:30

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
Benutzeravatar
DragonSpikeXIII
 
Beiträge: 2
Registriert: 10.06.2017, 02:26

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 10.06.2017, 23:06

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.
DragonSpikeXIII hat geschrieben: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) :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon DragonSpikeXIII » 11.06.2017, 01:07

Krishty hat geschrieben: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.

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 :)

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! :o 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.
Benutzeravatar
DragonSpikeXIII
 
Beiträge: 2
Registriert: 10.06.2017, 02:26

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 18.06.2017, 23:09

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

You can grab my model viewer there!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon marcgfx » 19.06.2017, 15:07

cool :D
Benutzeravatar
marcgfx
Establishment
 
Beiträge: 1046
Registriert: 18.10.2010, 23:26

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 27.06.2017, 02:20

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:
presskit.png
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.
Zuletzt geändert von Krishty am 05.07.2017, 22:23, insgesamt 2-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 05.07.2017, 00:21

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:

Bild

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

Bild

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.

Bild

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:

Bild

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)!
ac3 playable planes.png

However, texturing the terrain is a little more complicated … I’ll dedicate another article to that.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 09.07.2017, 03:01

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?


Bild
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.)

Bild


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.

Bild


  • 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon Schrompf » 09.07.2017, 11:31

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.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3614
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 09.07.2017, 11:45

You mean, with Z order?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon Schrompf » 09.07.2017, 12:09

No, more like: I draw a triangle at the "screen" border and it draws over a part of the texture I use right now.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3614
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 09.07.2017, 12:30

I wrote about it way down at the bottom:
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.
However, checking the specification, it’s more complicated … GPU TexPage drawing attribute, Bit 10 (we will analyze these flags in a future article):
http://problemkaputt.de/psx-spx.htm#gpurenderingattributes hat geschrieben: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)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon Krishty » 11.07.2017, 22:45

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!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6041
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Extracting Ace Combat

Beitragvon MasterQ32 » 11.07.2017, 23:14

*lurk* just wanted to tell you that i really like this thread! keep it going, it's interesting !
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 958
Registriert: 07.10.2012, 14:56

VorherigeNächste

Zurück zu Vorstellungsbereich

Wer ist online?

Mitglieder in diesem Forum: Ahrefs [Bot] und 2 Gäste