Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Akari on 2005-11-10 03:49:45
-
Oh well, I finished. I spent all the night arranged all I know about Xenogearses formats. I put it all into single html page. Here it is XENO-GEARS (http://server.titansoft.ru/akari/xeno-gears.htm), the beginning =)
-
Nice :) ( although I have no idea about Xenogears )
-
Xenogears is a square soft game written coeval with FF7 actually a little bit after it was released 1998. It was also a incomplete release but pruned considerably more than FF7's very minor removals. (FF7 is quite complete in my opinion).
Akari - Eeee :D I'll hopefully have time to add Xenogears 'probing' into my PSXviewer soon enough. I just have things like WORK to do LOL
-
This is soo cool. Now I'm ripping my Xenogears CD and have a look at it!
It was also a incomplete release but pruned considerably more than FF7's very minor removals.
True. You could say most of the second disc is missing.
Does anyone know if the Xenosaga guys have the rights to remake or rerelease Xenogears, or if they can just make prequels and sequels in the same scenario?
-
It was also a incomplete release but pruned considerably more than FF7's very minor removals.
Hmm =) I'll add your description to introduction.
Does anyone know if the Xenosaga guys have the rights to remake or rerelease Xenogears, or if they can just make prequels and sequels in the same scenario?
I don't think they have rights to that name, since it still a trademark of Square, but they seems was able to use the scenario of the game. But since the Soraya Saga left project it seems that we never see the same Xenogears as before.
-
Guys Xenosaga is Xenogears complete. Some of the people who worked on Xenogears are working on it (namely the person who created the concept of Xenogears). Yes 45% of the game was scraped by Squaresoft because it wasn't complete enough to package and send out the door. The project had already taken 3 years and they decided to ship what they had.
Xenogears is the tail end of a long epic saga. (chapter 6) and Xenosaga was Chapter 1
So you will be seeing prequels for Xenogears without using the copyrighted stuff from the original. If you have played Xenosaga (I am almost done myself) you'll find lots of parallels to Xenogears.
Back to the subject (cough cough) ;)
I see you have been toying with sprites :D
Cyb
-
...You're kinda wrong.....
Xenogears and Xenosaga are not from the same storyline. They were never meant to be part of the same story. Not that it matters, now. But Xenosaga was never intended to be a prequel of Xenogears.
You can think of it as a Tenchi Muyo anime, I guess. But even less so, being that most if not all of the characters are different. Even if Nephilim looks like Elie as a little girl. And the boy with the blocks looked like Fei.
And by the looks of it.... unless he's introduced in Ep3... looks like that boy might be a dropped plot.
-
Oh well, I finished. I spent all the night arranged all I know about Xenogearses formats. I put it all into single html page. Here it is XENO-GEARS, the beginning =)
I tried to decode the file table from an image of my NTSC U/C version and so far didn't get very far. How do the first few entries look like in your version?
Xenogears and Xenosaga are not from the same storyline. They were never meant to be part of the same story. Not that it matters, now. But Xenosaga was never intended to be a prequel of Xenogears.
From what I understand Xenosaga plays > 10000 years before Xenogears, so obviously the characters are different. After the events in Xenosaga 1-3 (which I don't want to spoil for people who haven't played) they load the Zohar onto a ship. There someone starts it up again and triggers the events of the Xenogears intro cutscene.
I think there was a complete timeline published around the time Xenogears was released, as a part of an artwork or data book. There are differences between that timeline and the events in Xenosaga, but they are either the result of licensing troubles or because the Xenosaga team liked the revised version better.
Update:
Okay, looks like there were quite some changes (http://www.escaflowneonline.com/xenogears/pw/history.htm) :) (spoiler alert!)
-
I tried to decode the file table from an image of my NTSC U/C version and so far didn't get very far. How do the first few entries look like in your version?
I own English, Japanese and Russian version of the game. And all of them has first file starting from 24sector and lasts till the 40sector.
The beginning of that file looks like
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
0000C000 29 00 00 EF FF FF FF 29 00 00 00 F2 1B 00 39 03
0000C010 00 00 4D 8A 00 61 12 00 00 99 84 00 E9 20 00 C0
0000C020 BE 5D 00 2F 2B 00 00 BF CA 00 67 41 00 00 DB DB
0000C030 00 7F 59 00 C0 00 6C 00 55 65 00 00 41 7D 01 1D
0000C040 8F 00 00 CE 3E 01 0D B2 00 00 58 BD 00 CD C6 00
0000C050 00 57 2D 00 C5 CB 00 00 13 23 00 9D CF 00 00 13
I used this function to parse this file
extract(char *filename)
{
unsigned long start_sector, file_size;
unsigned char start[3], size[4];
char numero[10];
// first directory number 0
int directory_number = 0;
// create file with cd file index
create_index_file();
index_file = fopen("index_cd.bin", "rb");
for (i = 0; ; i++)
{
file_position = fread(start, 1, 3, index_file);
file_position = fread(size, 1, 4, index_file);
// reverse bytes order (low endian)
start_sector = start[0] | (start[1] << 8) | (start[2] << 16);
file_size = size[0] | (size[1] << 8) | (size[2] << 16) | (size[3] << 24);
// end of file
if (file_size == 0x00ffffff)
{
break;
}
if (start_sector == 0 && file_size > 0)
{
filename[9] = 0;
}
// directory
if (file_size > 0xff000000)
{
// create directory name (name - number of directory)
filename[9] = 0;
sprintf(numero, "%d", directory_number++);
strcat(filename, numero);
strcat(filename, "\\");
mkdir(filename);
}
// file
if (start_sector != 0 && file_size < 0xff000000 && file_size > 0)
{
printf("file number %d, size: 0x%x byte - ", i, file_size);
parse_file(start_sector, file_size, i, filename);
}
}
}
I hope it helps.
-
Thanks. It looks like I wasn't skipping the 8 byte for the CD-XA header correctly, which messed up my whole image file ....
Did you notice, if you interpret the directory size as a negative number it sometimes matches the number of files in it?
-
Thanks. It looks like I wasn't skipping the 8 byte for the CD-XA header correctly, which messed up my whole image file ....
Did you notice, if you interpret the directory size as a negative number it sometimes matches the number of files in it?
I read disk with winhex, it has option row disk access or not, so for the first time I access files by saving them from this utilite =)
It's much easier.
I check first five directory... so its
from_file/real number of file
16/20
5/6
5/12
48/49
6/7
Well even if it is number of files its very strange number of files =)
But it always less than real number of files... hmmm
-
Did you use ~filesize or -filesize? I used -filesize, and this is the table I get for disk 2 (size/count):
12/15
6/6
6/12
49/49
7/7
146/146
11/11
2/2
33/33
91/91
7/7
1460/1460
145/145
121/121
88/107
4/4
152/153
2/2
150/150
62/222
231/231
534/540
16/16
17/17
2/2
3/3
10/10
...several 10/10...
10/10
-
2Micky: Sorry, I didn't has time this week as I got new job =) I'm game beta-tester right now.Maybe next year I could get job of a game programmer in the same company 8)
Well anyway. Xenogears (http://server.titansoft.ru/akari/xeno-gears.htm) was added with some new info about 2d sprites and 3d backgrounds. Now almost all of them displayed correctly. The only thing I need to find now Its where semi-transparency are set. The two hardest background are now all clear. Some time soon I'll write a viewer with usual GUI (I think I use QT for that) and switch to the 3d enemies that share the same 3d format. Although a background image and skies that almost all the background has are not understanded yet =) It seems that they are in the second file. (textures for them are in the first file)
tho hardest battle backgrounds are
(http://server.titansoft.ru/akari/xenogears/bg1.gif)
(http://server.titansoft.ru/akari/xenogears/bg2.gif)
-
Woo Akari that is quite a bit of work..
I suppose this means I should begin adding the 3d code to my Viewer software soonish. I'll have to add software to work with ISO images (Raw mode reading of a CD is too much of a hassle at the moment).
I guess Xeno stuff will following FF7 :D
It's odd that Xenogears world is 3d and characters are 2d where as FF7's world is 2d in the scenes but the characters are 3d. Kind of funny that :D
Cyb
-
I'll have to add software to work with ISO images (Raw mode reading of a CD is too much of a hassle at the moment).
I just wrote code that splits the image into files and directories, so I don't have to worry about the iso at all.
It's odd that Xenogears world is 3d and characters are 2d where as FF7's world is 2d in the scenes but the characters are 3d.
But if you think about it, at the size the characters are drawn and with the playstation's resolution a textured character with the same detail as the 2d sprites would've probably glitched a lot.
Xenogears feels in many ways ahead of Final Fantasy. For example you see all characters of your active party following you and you can rotate the viewpoint (something you can't do even in Final Fantasy 10). Xenosaga looks almost like a step back from Xenogears...
-
actually not having to render 3d environments and then actually have to make them into 2d backgrounds reduces production time and cost, which is what xenogears didnt have enough of (time and budget).
So FF7 looks far more detailed on a PSX as opposed to Xenogears.
but the 2d sprites make for a messy feel
-
actually not having to render 3d environments and then actually have to make them into 2d backgrounds reduces production time and cost, which is what xenogears didnt have enough of (time and budget).
So FF7 looks far more detailed on a PSX as opposed to Xenogears.
but the 2d sprites make for a messy feel
Considering Xenogears is missing 45% of itself.. not surprising that.
They estimate the cost of game production is going to go up from 3.3 -5 toward 6 - 10 million US because of the amount of artwork now needed in games.
:D
The odd thing is FF7 DOES have 3d scenes just 2d rendering. The walk mesh doesn't require art work but it is 3d :D
Cyb
-
They estimate the cost of game production is going to go up from 3.3 -5 toward 6 - 10 million US because of the amount of artwork now needed in games.
Well, that is a bullsh*t argument, mostly from publishers who want to raise the software prices.
If a 30,000 polygon background costs $X, then a 300,000 polygon background doesn't cost $X * 10, because the artists don't put the polygons down one by one. In the end it evens itself mostly out, because time spent on making a good looking low-poly background just gets used to put down the required number of polygons for a high-poly background.
The biggest money-sink I experienced is marketing, where one bit of the campaign can cost as much as a whole team gets paid in salary.
Considering Xenogears is missing 45% of itself.. not surprising that.
I don't know the details of what went wrong in Xenogears. But everyone who played it definitely notices the holes, where they just explain the story in front of a slideshow. So some of the artwork must have been already modelled. My guess is what was missing wasn't artwork, but scripting the game (like "speak with person X to get information Y to progress") and programming bosses.
You could argue if the backgrounds in FF7 were easier or more difficult to make than in Xenogears. On one hand not many people had experience modelling 3D environments or how to organise the required workload. Work could've been wasted on both projects modelling stuff that wasn't useable. The FF7 team didn't have to worry about runtime performance, as it just needed to render once. On the other hand some of the dungeons in Xenogears are very simple, just the edges of the floor lofted up and textured. In the end, we'll never know until we do similar work ourselves.
-
They estimate the cost of game production is going to go up from 3.3 -5 toward 6 - 10 million US because of the amount of artwork now needed in games.
Well, that is a bullsh*t argument, mostly from publishers who want to raise the software prices.
If a 30,000 polygon background costs $X, then a 300,000 polygon background doesn't cost $X * 10, because the artists don't put the polygons down one by one. In the end it evens itself mostly out, because time spent on making a good looking low-poly background just gets used to put down the required number of polygons for a high-poly background.
The biggest money-sink I experienced is marketing, where one bit of the campaign can cost as much as a whole team gets paid in salary.
I agree it's partial fluff. It seems many people are more interested in making money than making games. So if you can't make a good game you make up for it in marketing. That's the idea at least. However you need both production and marketing.
So it's six of this half dozen of the other. The most obvious cost barrier with games these days is unrealistic expectations of how long something will take. In essence it's a management problem.
Back to the subject, I have been using GLScene objects and these have a huge learning curve if you don't program in Delphi.. Dang :(
Cyb
-
Correct me if I am wrong, but what I meant to say was this:
FF7/FF8:
1. Super powerfull 3d Computer is programmed to make nice 3d environment.
2. This is then captured into a 2d image for use on PSX
Xenogears:
1. Make a simply Polygonal backdrop and some simple textures to map it with.
There is a massive difference in the costing for both.
Xenogears was overbudget and out of time, so they chopped scenes and made it into a story telling session most of Disc 2.
Enough said.
Lets get back to the point of this thread.
How about a Xeno-Remake :)
-
1. Super powerfull 3d Computer is programmed to make nice 3d environment.
2. This is then captured into a 2d image for use on PSX
I'm sure you already got off-the-shelf software like Alias or Softimage when FF7 was made. As I said, it evens itself out in the end.
How about a Xeno-Remake :)
Similar to SCUMM, AGI and SCI, a FF7 or Xenogears engine would be cool. Have a look at Akari's work, I'm sure that can be turned into an engine at some point.
A Xenogears-Complete would be cool as well, but whenever I get excited about that idea I come to the conclusion that investing that effort into my own projects is even better.
-
A lot of new info about content of different directories. The info was shared to me by group of hackers that translate this game to Italian. The credits are in xenogears now
XENO-GEARS (http://server.titansoft.ru/akari/xeno-gears.htm)
-
Xenogears was updated.
Added: Info about Model HRC. Info about Model Animation
Changed: Moved Archive info in separate chapter.
Xeno-Gears (http://server.titansoft.ru/akari/xeno-gears.htm)
-
Xeno-gears...
how quaint ^_^
-
I'va update XENO-GEARS with info about field files.
http://server.titansoft.ru/akari/xeno-gears.htm
-
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.
-
sorry to ask but what means:
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.
-
The lorem ipsum stuff is put in a document to take up space (to be replaced later).
-
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.
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.
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!
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.
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.
sorry to ask but what means: Lorem Ipsum...
More than you ever wanted to know. (http://en.wikipedia.org/wiki/Lorem_ipsum)
-
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)
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.
-
Ok. I just wish to clarify some of the things I was trying to convey:
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.
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.
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?).
-
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.
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
-
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
-
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
-
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.)
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.
-
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
-
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.
-
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.
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.
-
What program is used to view the 3d files and stuff?
Thanks,?
~SKy
-
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)
-
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?
-
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
-
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
-
All right I work with the xeno classes that might make it easier to glean the data :D
Thanks
Cyb
-
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
-
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
-
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:
// 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.
-
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.