Author Topic: Xeno-gears  (Read 27388 times)

RW_66

  • *
  • Posts: 74
    • View Profile
Xeno-gears
« Reply #25 on: 2006-01-29 00:24:39 »
Just so you know..

FF7 used hand-painted backgrounds that were photographed, digitized, and then re-rendered and palletized for storage in the PSX in 320x240 size, which are then stretched to 640x480 texture maps when "unpacked". While this "stretching" does not look too bad on an analogue TV set (due to the large pixel size and inate "fuzziness" of the normal TV image display), it definitely looks blocky and "ugly" when shown on a high resolution/definition monitor. The main reason for this was due to the speed, bandwith, and memory size limitations of the PSX (it was basically a graphically enhanced 486 with 2MB main RAM and 1MB VRAM). The pre-rendered backgrounds allowed for higher polygon characters, and also allowed for more "detailed" backgrounds than would have been possible if rendered with the 3D engine ( a win-win situation for the programmers and artists). If FF7 were completly rendered in "real" 3D using todays' technology it would easily be 20-30x the size of the original (like 4 DVDs!  :o  ).

Xenogears, on the other hand, used a different tactic.. somwhat akin to some of their SNES games. All the world charachters have 5 2D sprite animations (plus 3 "mirrored" for a total of 8 ) with no depth. The model shown is simply based on the camera angle. All the background are simple 2D texture surfaces that use a semi-simple scalular rotation model, somewhat simular to the SNES mode 7, though the PSX adds texture blurring at acute angles to give a more 3D effect to the process. So basically, Xenogears is mostly 2D sprites with 3D effects(except for the Gear battles and some SFX).

On an aside, I would speculate that Xenogears looks and acts like it was originally developed for the SNES and re-optimized for the PSX. Alot of the look and game mechanics of this game resemble those used in FF6 (FF3 US). I'd personally love to see a fully visually updated version with the missing content restored. This is one of the longest (except maybe FF Tactics) and most heavily dialogued games attempted (IMO) by any company. It definitely had a gripping story that, unfortunately, was gutted in the end to get it out the door.

ChaosControl

  • *
  • Posts: 741
  • ¤
    • View Profile
Xeno-gears
« Reply #26 on: 2006-01-29 00:36:49 »
sorry to ask but what means:

Code: [Select]
Lorem ipsum dolor sit amet,consectetuer adipiscing elit,sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.Ut wisi enim ad minim veniam,quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat.Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat,vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.Nam liber tempor cum soluta nobis eleifend option congue nihil imperdiet doming id quod mazim placerat facer possim assum.Typi non habent claritatem insitam;est usus legentis in iis qui facit eorum claritatem.Investigationes demonstraverunt lectores legere me lius quod ii legunt saepius.Claritas est etiam processus dynamicus,qui sequitur mutationem consuetudium lectorum.Mirum est notare quam littera gothica,quam nunc putamus parum claram,anteposuerit litterarum formas humanitatis per seacula quarta decima et quinta decima. Eodem modo typi,qui nunc nobis videntur parum clari,fiant sollemnes in futurum.

Aaron

  • *
  • Posts: 2818
    • View Profile
    • http://aaron-kelley.net/
Xeno-gears
« Reply #27 on: 2006-01-29 00:53:00 »
The lorem ipsum stuff is put in a document to take up space (to be replaced later).

Micky

  • *
  • Posts: 300
    • View Profile
Xeno-gears
« Reply #28 on: 2006-01-29 12:53:49 »
Quote from: RW_66
FF7 used hand-painted backgrounds that were photographed, digitized, and then re-rendered and palletized for storage...

I'm sure they used both: completely handpainted backgrounds, like Sierra adventures, and 3D models, like the original Resident Evil. They definitely painted most textures.
Quote
The main reason for this was due to the speed, bandwith, and memory size limitations of the PSX (it was basically a graphically enhanced 486 with 2MB main RAM and 1MB VRAM).

I'd say the MIPS R3000 in a PSX is more in the area of a 386 than a 486.
Quote
If FF7 were completly rendered in "real" 3D using todays' technology it would easily be 20-30x the size of the original (like 4 DVDs!  

I wouldn't be too sure about that. First of all, most of the memory on the FF7 disks is taken up by the movies, all the 3D models and field pictures are actually duplicated on each disk!
Quote
Xenogears, on the other hand, used a different tactic.. somwhat akin to some of their SNES games. All the world charachters have 5 2D sprite animations (plus 3 "mirrored" for a total of 8 ) with no depth.

Akari has already decoded most of that.
Quote
All the background are simple 2D texture surfaces that use a semi-simple scalular rotation model, somewhat simular to the SNES mode 7, though the PSX adds texture blurring at acute angles to give a more 3D effect to the process. So basically, Xenogears is mostly 2D sprites with 3D effects(except for the Gear battles and some SFX).

No, that is not true. Mode 7 basically allows a affine transformation of a texture (scaling, shearing, rotation), and with some tricks you can get a projective transformation, but only for floor/ceiling textures parallel to the X axis. Xenogears uses all 3d models for battles, field and the worldmap. Akari has all of that decoded.
Quote from: chaoscontrol
sorry to ask but what means: Lorem Ipsum...

More than you ever wanted to know.

Akari

  • *
  • Posts: 766
    • View Profile
Xeno-gears
« Reply #29 on: 2006-01-29 16:49:20 »
Quote
On an aside, I would speculate that Xenogears looks and acts like it was originally developed for the SNES and re-optimized for the PSX. Alot of the look and game mechanics of this game resemble those used in FF6 (FF3 US).


I believe that Xenogears engine is reworked Final Fantasy Tactics engine. The music formats are absolutely the same. The sprite and sprite animation format are very similar. Even 3d models format are very similar (but the differences are much greater than in sprites).

The next games of that engine was Vagrant Story and Chrono Cross. May be not whole engine, but some parts of it (3d in Vagrant Story are very like one in Xenogears)

Quote
All the world charachters have 5 2D sprite animations (plus 3 "mirrored" for a total of 8 ) with no depth.


Do you know format of animation files? I understand frames but couldn't get them togather. If you know anything please tell me, it would be very helpfull.

RW_66

  • *
  • Posts: 74
    • View Profile
Xeno-gears
« Reply #30 on: 2006-01-29 21:27:14 »
Ok. I just wish to clarify some of the things I was trying to convey:

Quote
I'd say the MIPS R3000 in a PSX is more in the area of a 386 than a 486.


You can be right either way, it just depends on how you define the CPU. Clock-wise (33 MHz.) it was in the 386 range. However, the 386 was internally 16 bit, with 24 bit addressing. The 486 was the first processor (intel-wise) to feature  32 bit internal processing with (again) 24 bit addressing. The Pentuim was the first true 32/32 processor.

The MIPS R3000 is a 32 bit (internally) processor. And yes, it isn't quite as fast or powerful (computation wise) as a full blown 486. So, how you define it depends on what criteria your looking at.

Quote
I wouldn't be too sure about that. First of all, most of the memory on the FF7 disks is taken up by the movies, all the 3D models and field pictures are actually duplicated on each disk!


I do realize that each of the disks contains the 'world' as it evolves through each disc.  What I was trying to point out was that if each of those "painted" backgrounds were rendered in real-time using an in-game engine (like most games do today), it would use an exponentually increased amount of data to describe and store all the data for them. While I am not a programmer.. I'll never make the mistake of claiming that.. I do know that Square's use of pre-rendered backgrounds saved them an enormous amount of data, and made the gorgeous graphics that it has possible.

Quote
No, that is not true. Mode 7 basically allows a affine transformation of a texture (scaling, shearing, rotation), and with some tricks you can get a projective transformation, but only for floor/ceiling textures parallel to the X axis. Xenogears uses all 3d models for battles, field and the worldmap. Akari has all of that decoded.


Ok.. I admit I may have came out a little too positively on this, in that I was conjecturing and it came out as stating facts. I apologize for that. Still, are you positive that ALL the battles are rendered in 3D? I ask because the character fights (non-GEAR) look ALOT like most 2D side-scrollers ever made.. (maybe on purpose?)

Still, I accept your rebuke on the way Mode 7 on the SNES worked. XenoGears just LOOKS so damn sprite-ish. Even the Model textures on most of the 3D models look like sprites (maybe they were lo-res to save room?).

Cyberman

  • *
  • Posts: 1572
    • View Profile
Xeno-gears
« Reply #31 on: 2006-01-29 23:18:04 »
Quote from: Akari
I believe that Xenogears engine is reworked Final Fantasy Tactics engine. The music formats are absolutely the same. The sprite and sprite animation format are very similar. Even 3d models format are very similar (but the differences are much greater than in sprites).
 (Grabs material to check) FF7 is 1997 FF Tactics 1997/1998 (on the package) Xenogears was 1998.  It's likely this is true, perhaps an improved engine instead of a new engine was cheaper.
Quote from: Akari
The next games of that engine was Vagrant Story and Chrono Cross. May be not whole engine, but some parts of it (3d in Vagrant Story are very like one in Xenogears)
Vagrant story's engine seems very different than CC but a VERY good  engine. (I liked the game too :D ). CC was done in FF7's style whereas VS was done with complete 3d backgrounds.  If it's the same engine, that would be really insteresting.  It might be the identical engine used in FF8 and FF9 too. Just slightly upgraded. Hmmm.  It would make sense square not try to reinvent a perfectly good engine, and leave the scripting and events to be similiar. FF7's engine was modular the only changes really needed would be the battle engine, menu system, and content type.

Cyb

Borde

  • *
  • Posts: 891
    • View Profile
Xeno-gears
« Reply #32 on: 2006-01-29 23:21:58 »
The characters that appear in battles are also sprites, but the background are 3D.
About the possible space requeried to store a fully 3D FF7, I think you are exaggerating a bit. Just look at HL2: it's pretty hi-detailed, fully 3D and it doesn't fills a single DVD. 4 DVDs is way too much. Also keep in mind that if you remove all the videos from the game and compress it, it fits in arround 150 MBs. Moreover, if you compress the videos with a better codec (such as divx), you can fit them all in less than 300 Mbs without a noticiable quality loss.
By the way, my old 486 was clocked at 33 Mhz :-P

Cyberman

  • *
  • Posts: 1572
    • View Profile
Xeno-gears
« Reply #33 on: 2006-01-30 02:53:22 »
Speed is relative. Size is relative :D

Anyhow to alay aside all silly things.  The Playstation One is about the same performance of a 485/66 SX Note the SX (IE no FPU).  If we speak about the graphics system it's similiar to the earlier 3dFX cards in performance.  Add in 3d data abilities things get a bit more blurred.  It was actually quite a powerful system for it's time.

Aside from such apples and iron spike comparisons (cough cough).
You have a data volume issue with larger backgrounds (which is what RW_66 was talking about).  I'm not sure WHY he was talking about larger backgrounds (unless someone mentioned them earlier).

On a side note, JPEG images are quite decodable on a playstation.  This  is because it has built in hardware for it.  That being the case if ones backgrounds were very large, storing it in JPEG files with the proper matrix for the DCT transform hardware in the playstation would make it possible to have HUGE prerendered backgrounds.  The real issue then becomes one of data management. I don't believe you would get sharp details this way at all but you could reduce your background size storage to about 1/6 what it is stored as now (LSZ compressed data).  This does require some very tricky programing and more of it.  It is not likely they could do it as a comercial entity since the contract with Sony was that they could not directly access the hardware. :D

That all being said.

I'm working on adding Xenogears support for my game viewing tool soonish.  The nice thing about Xenogears is that that it uses 2d sprites in a 3d world.  This makes setting the areas up for rendering easier for me, as I can just make the scene and move stuff around in them (when I get to that point though FF7 might be doing well too).
2d backgrounds with 3d sprites is actually more difficult to implement than visa versa in OpenGL.
For backgrounds I believe Xenogears will be easier of the two to do (as opposed to FF7), thus more likely I'll have that done first.

Cyb

Micky

  • *
  • Posts: 300
    • View Profile
Xeno-gears
« Reply #34 on: 2006-01-30 07:37:08 »
Quote from: RW_66
However, the 386 was internally 16 bit, with 24 bit addressing. The 486 was the first processor (intel-wise) to feature  32 bit internal processing with (again) 24 bit addressing. The Pentuim was the first true 32/32 processor.

Not to get too far off topic, but you're mixing this up with the 286. The 286 had 16 bit registers. From 386 on you had 32 bit registers, and from 486 you had the FPU, which was an optional external chip on 8086-80386. There was a special low-cost 386 with a 16 bit bus, though. That is why I put the R3000 nearer to a 386, even though you can't really compare RISC and CISC architectures. (BTW: I am a programmer, and I worked on everything from a 80286 to a Pentium, and lots of other stuff.)
Quote
Still, are you positive that ALL the battles are rendered in 3D? I ask because the character fights (non-GEAR) look ALOT like most 2D side-scrollers ever made.. (maybe on purpose?)

I used Akari's information to write my own model viewer. Yes, I'm positive.

ChaosControl

  • *
  • Posts: 741
  • ¤
    • View Profile
Xeno-gears
« Reply #35 on: 2006-01-30 07:57:54 »
Quote from: Micky
and from 486 you had the FPU, which was an optional external chip on 8086-80386.


Only the 486 DX had a co-proc built in de SX was still without one i believe :o

The Skillster

  • *
  • Posts: 2284
  • Loving every Final Fantasy
    • View Profile
Xeno-gears
« Reply #36 on: 2006-01-30 13:04:25 »
I personally would like to challenge the idea that FF7's backgrounds (field maps) were painted and then digitised.

If you carefully study all the images on a decent screen (ie PC using say LGPTools, I back my original idea that the backgrounds where first designed and then created on powerful 3d platforms from which the 2d image was captured, edited and compressed into a PSX friendly format.

Micky

  • *
  • Posts: 300
    • View Profile
Xeno-gears
« Reply #37 on: 2006-01-30 19:51:46 »
Quote from: chaoscontrol
Quote from: Micky
and from 486 you had the FPU, which was an optional external chip on 8086-80386.


Only the 486 DX had a co-proc built in de SX was still without one i believe :o

That's right. There was this amusing thing that you could add a 487SX FPU... which was actually a 486DX! Once you inserted that into its socket it disabled the 486SX, which still consumed energy but didn't produce anything of value. I think you could actually remove the 486SX from its socket and still use the computer. :) Good times.

Quote from: The Skillster
I personally would like to challenge the idea that FF7's backgrounds (field maps) were painted and then digitised.

If you carefully study all the images on a decent screen (ie PC using say LGPTools, I back my original idea that the backgrounds where first designed and then created on powerful 3d platforms from which the 2d image was captured, edited and compressed into a PSX friendly format.

I'm sure you're right. But some things do look painted, be it because of a matte painting or just because of the texture. I don't think it really matters, though, as only the result counts.

Lord_Skylark

  • *
  • Posts: 115
    • View Profile
Xeno-gears
« Reply #38 on: 2006-03-11 03:24:12 »
What program is used to view the 3d files and stuff?

Thanks,?
~SKy

Chrisu

  • *
  • Posts: 363
  • Simply there
    • View Profile
    • Christian's Programs
Xeno-gears
« Reply #39 on: 2006-03-13 20:22:30 »
Does anyone no what cloud wants to say with this:
Image-Link:http://cbartsch.lima-city.de/Shot0111.jpg

(He is ill after he fell into the life stream and says: Hundreds of Mirror-splitters have angel-like voices.....Xeno...Gears)

Akari

  • *
  • Posts: 766
    • View Profile
Xeno-gears
« Reply #40 on: 2006-03-16 17:14:00 »
Quote from: Lord_Skylark
What program is used to view the 3d files and stuff?

Thanks,?
~SKy


Every programm written by the people themselves. Most of them are specialized to view only one thing. Tell what do you want to see?

Cyberman

  • *
  • Posts: 1572
    • View Profile
Which reminds me
« Reply #41 on: 2006-03-16 18:54:50 »
Akari I remember you posted (URL) some source in reguards to Xenogears a while back. I was wondering if that was still about or would I be better to BYO (Build Your Own).  Currently I just have some of the FF series 'stuff' viewable however it would be kind of fun to view Xeno's as well. The fact that the the game was mostly in 3d I suppose would make it more intriuging LOL.

Cyb

Akari

  • *
  • Posts: 766
    • View Profile
Xeno-gears
« Reply #42 on: 2006-03-18 01:15:14 »
All my stuff are posted here http://server.titansoft.ru/akari/xenogears/
engine.rar are number of classes which I used to view all stuff, but you must type everything manually, because i never write complete viewer, i just describe the format of data =)

By the way engine use bin/cue game image, you could write way to it in config

Cyberman

  • *
  • Posts: 1572
    • View Profile
Xeno-gears
« Reply #43 on: 2006-03-19 01:54:10 »
All right I work with the xeno classes that might make it easier to glean the data :D

Thanks

Cyb

Lord_Skylark

  • *
  • Posts: 115
    • View Profile
Xeno-gears
« Reply #44 on: 2006-03-23 03:47:07 »
I want to use the program to view the models and rotate them and zoom on them and do everything like every other model program that's out there. I just don't know the name of the program you guys are using so I can download it and view them.

Thanks,
~Sky

Cyberman

  • *
  • Posts: 1572
    • View Profile
Xeno-gears
« Reply #45 on: 2006-03-25 23:44:58 »
Lord Skylark http://server.titansoft.ru/akari/xenogears/engine.rar I believe is what you are looking for.

Akari I've had success with getting the ISO_FS semi functional and extrracting Xenogears FileSystem. I seem to have a problem finding the end of a directory.  Do you use a new directory or empty file pointer as the terminator? (or both?)
Square is rather anoying in how they approached there disks. It's hard to identify an FF8 FF9 or disk since they didn't use the ISO_FS properly. However there was an interesting little thing I found on FF7 disks the publisher isn't square but Hironobu Sakaguchi :D

I find it anoying that Square practically randomly filled these fields though.
I suppose this means I actually have to find the information in the system file for the BOOT = (yada yada) in it :/ Which also means I have to actually add functions to read the Path 'stuff' in ISO FS (there description of the the file system is so convoluted it's not funny).

So apart from knowing each Disks SLUS SLSP SLEU etc. IDs (it's a joke :) ). I can't think of a way to indentify the PS1 disk the volume ID isn't filled on several of Square's disks (woo mutter).

Cyb

Micky

  • *
  • Posts: 300
    • View Profile
Xeno-gears
« Reply #46 on: 2006-03-26 14:43:37 »
Quote from: Cyberman
So apart from knowing each Disks SLUS SLSP SLEU etc. IDs (it's a joke :) ). I can't think of a way to indentify the PS1 disk the volume ID isn't filled on several of Square's disks (woo mutter).

Store an MD5 checksum of the executable and use that to identify the game. If a user reports that his game isn't identified let him select it from a list, and ask him to send the MD5 checksum to you to use in new versions.

And here is my file extractor, it assumes you have a raw dump (=sectors of 2352 byte) of your disk:
Code: [Select]

// C interface
#include <cstdio>
#include <cstring>

// C++ interface
#include <string>

// Unix interface
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <paths.h>
#include <sys/ioctl.h>
#include <sys/param.h>
#include <sys/types.h>
#include <sys/uio.h>
#include <sys/stat.h>

typedef unsigned long int u32;
typedef signed long s32;
typedef unsigned char u8;

#define BLOCKSIZE 2352

using namespace std;

void * getFile(FILE * file, u32 sector, u32 length, bool raw)
{
if (raw) {
u32 numSectors = (length + 2048 - 1) / 2048;
u8 * data = (u8*)malloc(numSectors * BLOCKSIZE);
fseek(file, sector * BLOCKSIZE, SEEK_SET);
fread(data, numSectors * BLOCKSIZE, 1, file);
return data;
} else {
u8 * data = (u8*)malloc(length);
u32 numSectors = (length + 2048 - 1) / 2048;
fseek(file, sector * BLOCKSIZE, SEEK_SET);
for (int i=0; i<numSectors; i++) {
u8 block[BLOCKSIZE];
fread(block, BLOCKSIZE, 1, file);
u32 remainingSize = length - i * 2048;
u32 dataSize = remainingSize > 2048 ? 2048 : remainingSize;
memcpy(data + i * 2048, block + 16 + 8, dataSize);
}
return data;
}
}

int main (const int argc, char const * const argv[])
{
FILE * file = fopen(<path to your disk image>, "rb");
string root = "<path to the root of the extracted files>";
string directory = "";
u8 * fileTable = (u8*)getFile(file, 24, 16 * 2048, false);
int index = 0;
bool end = false;
int directoryCount = 0;
int fileCount = 0;
bool movies = false;
do {
u32 startSector = fileTable[index * 7 + 0] | (fileTable[index * 7 + 1] << 8) | (fileTable[index * 7 + 2] << 16);
s32 fileSize = fileTable[index * 7 + 3] | (fileTable[index * 7 + 4] << 8) | (fileTable[index * 7 + 5] << 16) | (fileTable[index * 7 + 6] << 24);
if (startSector != 0xFFFFFF) {
if (fileSize < 0) {
char tmp[256];
sprintf(tmp, "dir%i", directoryCount);
fileCount = 0;
directory = tmp;
mkdir((root + directory).c_str(), 0777);
movies = directoryCount == 0;
directoryCount ++;
} else if (fileSize > 0) {
char tmp[256];
sprintf(tmp, "file%2.2x.bin", fileCount);
// printf("%8.8x %8.8i\n", startSector, fileSize);
#if 1
void * data = getFile(file, startSector, fileSize, movies);
FILE * dataFile = fopen((root + directory + "/" + string(tmp)).c_str(), "wb");
fwrite(data, fileSize, 1, dataFile);
fclose(dataFile);
free(data);
#endif
fileCount++;
}
} else {
end = true;
}
index++;
} while (!end);
free(fileTable);
fclose(file);
}

I'm using MacOS, btw, so you may have to tweak system-level calls like mkdir. I've got another tool to dump a raw image of a disk, but that is 100% system specific and mostly based on an SDK sample anyway.
All my other tools work of the files extracted from the disk.

Shinohara

  • Guest
Re: Xeno-gears
« Reply #47 on: 2008-02-27 20:10:15 »
Does anyone know where Akari's relocated the Xeno-gears information? I went looking for it today and his site seems to no longer exist.