Author Topic: Halkun is back! Prepair to be r0xored.  (Read 13541 times)

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« on: 2004-06-06 23:29:03 »
Once upon a time....

(Wow, that's how it always starts, huh ^_^)

Once upon a time, almost four yars ago, I came to this board and tought a little about how to reverse programs. I, like yourselfs, enjoy picking apart things and learning more about the world.

This is the basis of science.

I tought a little bit about how to look at data in diffrent ways. I showed how programmers can be lazy (and the contract workers for the FF7 port to the PC doublely so). The therory being if programmers were really motivated, they woudn't of persued a carrer sitting on thier butts for more than 8 hours a day.

Between the fact that programmers are lazy, and computers don't care, this causes arifacts that, over time, can tell a story about how things came to be.

We are, in fact, data archiologists.

So it has come, where I have decided to grab my shovel and bit-bucket and see what I can find. Sometimes, when people are busing blowing the dust off a particular rock, or examining the attibutes of some long cast out stone, it's easy to lose the big picture.

To help, in the little way I can, I have decided to assist and paint for you not a complete picture, but something that may assist you. If not, it's at least intresting as hell to look at.

I gave you the following....

Code: [Select]

c:\ff7\chocobo\ch_app.cpp
c:\ff7\chocobo\ch_chr.cpp
c:\ff7\chocobo\ch_ddraw.cpp
c:\ff7\chocobo\ch_init.cpp
c:\ff7\coaster\psxdata_c.cpp
c:\ff7\condor\cd_app.cpp
c:\ff7\condor\cd_ddraw.cpp
c:\ff7\condor\cd_init.cpp
c:\ff7\condor\cd_tim.cpp
c:\ff7\field\src\ad_app.cpp
c:\ff7\field\src\ad_bk.cpp
c:\ff7\field\src\ad_cdr.cpp
c:\ff7\field\src\ad_data.cpp
c:\ff7\field\src\ad_ddraw.cpp
c:\ff7\field\src\ad_human.cpp
c:\ff7\field\src\ad_image.cpp
c:\ff7\field\src\ad_list.cpp
c:\ff7\field\src\ad_list.cpp
c:\ff7\field\src\ad_obj.cpp
c:\ff7\field\src\ad_pal.cpp
c:\ff7\field\src\ad_tile.cpp
c:\ff7\field\src\tutaddr.cpp
c:\ff7\highway\psxdata.cpp
c:\ff7\snobo\memory.cpp
c:\ff7\snobo\tmd.cpp
c:\ff7\src\battle\b3ddata.cpp
c:\ff7\src\battle\battle.cpp
c:\ff7\src\battle\battle3d\amptoanm.cpp
c:\ff7\src\battle\battle3d\bdata.cpp
c:\ff7\src\battle\battle3d\char.cpp
c:\ff7\src\battle\battle3d\enemy.cpp
c:\ff7\src\battle\battle3d\limitbrk.cpp
c:\ff7\src\battle\battle3d\lmd.cpp
c:\ff7\src\battle\battle3d\lmd.cpp
c:\ff7\src\battle\battle3d\mdl.cpp
c:\ff7\src\battle\battle3d\stage.cpp
c:\ff7\src\battle\battle3d\stage.cpp
c:\ff7\src\battle\myoshiok\lasboss3.cpp
c:\ff7\src\battle\yama\coloss.cpp
c:\ff7\src\battle\yama\init.cpp
c:\ff7\src\battle\yama\inits.cpp
c:\ff7\src\battle\yasui\deadsef.cpp
c:\ff7\src\battle\yasui\sting.cpp
c:\ff7\src\battle\yasui\vahamut0.cpp
c:\ff7\src\credits\credfile.cpp
c:\ff7\src\main\initpath.cpp
c:\ff7\src\main\main.cpp
c:\ff7\src\menu\btlmenu\english\callback.cpp
c:\ff7\src\menu\english\loadmenu.cpp
c:\ff7\src\movie\sm_movie.cpp
c:\ff7\src\wm\wmdefine.cpp
c:\ff7\src\wm\wmfile.cpp
c:\lib\h\graphics\sw\offset.hpp
c:\lib\src\file\direct.cpp
c:\lib\src\file\file.cpp
c:\lib\src\file\is_lib.cpp
c:\lib\src\file\registry.cpp
c:\lib\src\file\smcdfile.cpp
c:\lib\src\graphics\directx.cpp
c:\lib\src\graphics\driver.cpp
c:\lib\src\graphics\dx_3d2d.cpp
c:\lib\src\graphics\dx_dbg.cpp
c:\lib\src\graphics\dx_graph.cpp
c:\lib\src\graphics\dx_mat.cpp
c:\lib\src\graphics\dx_mesh.cpp
c:\lib\src\graphics\dx_pal.cpp
c:\lib\src\graphics\dx_rend.cpp
c:\lib\src\graphics\dx_rend.cpp
c:\lib\src\graphics\dx_rend5.cpp
c:\lib\src\graphics\dx_rend5.cpp
c:\lib\src\graphics\dx_rendi.cpp
c:\lib\src\graphics\dx_rendi.cpp
c:\lib\src\graphics\dx_rendx.cpp
c:\lib\src\graphics\dx_sfx.cpp
c:\lib\src\graphics\dx_spr.cpp
c:\lib\src\graphics\dx_stat.cpp
c:\lib\src\graphics\dx_view.cpp
c:\lib\src\graphics\g_drv.cpp
c:\lib\src\graphics\instance.cpp
c:\lib\src\graphics\light.cpp
c:\lib\src\graphics\psx.cpp
c:\lib\src\graphics\psxgraph.cpp
c:\lib\src\graphics\render.cpp
c:\lib\src\graphics\shp.cpp
c:\lib\src\graphics\sw\sw.cpp
c:\lib\src\graphics\sw\sw.cpp
c:\lib\src\graphics\sw\sw_vert.cpp
c:\lib\src\graphics\sw\z.cpp
c:\lib\src\input\input.cpp
c:\lib\src\list\list.cpp
c:\lib\src\mem\heap.cpp
c:\lib\src\mem\mem.cpp
c:\lib\src\movie\movie.cpp
c:\lib\src\polygon\anm.cpp
c:\lib\src\polygon\plytopd.cpp
c:\lib\src\polygon\polygon.cpp
c:\lib\src\polygon\rsd.cpp
c:\lib\src\polygon\tim.cpp
c:\lib\src\sort\sort.cpp
c:\lib\src\sound\acm.cpp
c:\lib\src\sound\creative\sfutils.cpp
c:\lib\src\sound\dx_snd.cpp
c:\lib\src\sound\midi1.cpp
c:\lib\src\sound\sound.cpp
c:\lib\src\stack\stack.cpp
c:\lib\src\thread\thread.cpp
c:\lib\src\token\token.cpp
c:\lib\src\trans\trans.cpp


I'm not done yet, I think I have some enums and reconstucted filenames...

This is just the beginning, I have made some rather intresting discoveries that I may share later. I have to experiment first...

That and buy another copy of FF7 PC ^_^

Darkdevil

  • *
  • Posts: 728
    • View Profile
    • Http://darkdevil177.5u.com
Halkun is back! Prepair to be r0xored.
« Reply #1 on: 2004-06-07 08:15:43 »
Which .LGP file is that Halkun?
And what tools are available for unpacking the .LGP files?

The Skillster

  • *
  • Posts: 2284
  • Loving every Final Fantasy
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #2 on: 2004-06-07 11:45:51 »
for unpacking lgp files go to www.ficedula.co.uk
but these arent files
they are references to portions of source code, broken down in the original files they where programmed from.
i suppose looking for these "filenames" inside a decompiled FF7.exe (or using a hex editor) you might be able to locate the area that you need to work on in FF7 pc terms.

I hope im right, someone correct me

Qhimm

  • Founder
  • *
  • Posts: 1996
    • View Profile
    • Qhimm.com
Halkun is back! Prepair to be r0xored.
« Reply #3 on: 2004-06-07 15:44:13 »
They're strings extracted from FF7.exe. Thanks to how FF7 for PC was compiled (it actually looks like debug mode!), every time a memory allocation (or similar operation) is performed, both the name of the source file and the current line in the source code is included as part of the function call, for debugging purposes. Unfortunately there are lots of files which doesn't use memory allocation or only use it indirectly through other translation units, so they're not included in the list. You can however scan through FF7.exe with a disassembler and be able to split the code up in the original translation units, and retrieve the original file name for a great deal of them thanks to these references.

DeadLajik

  • *
  • Posts: 53
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #4 on: 2004-06-07 15:46:10 »
Wow halkin,

That is an interesting post/discovery you have made. I welcome you back and look forward to learning more about the techniques you use..

How did you get those filenames? Even running strip on the executable and such wouldn't give you that much information.. unless they shipped the an executable with debugging symbols included.

Nori

  • *
  • Posts: 792
    • View Profile
OFF TOPIC:
« Reply #5 on: 2004-06-07 17:24:41 »
J.W, O-hisashiburi!
Defiantly, welcome back...

The SaiNt

  • *
  • Posts: 1300
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #6 on: 2004-06-07 19:40:27 »
It's still a pain to look through all the assembler though.

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« Reply #7 on: 2004-06-07 23:06:45 »
<Professor Farnsworth>
Good news Everybody!
</Professor Farnsworth>

I got disk 1 of the PSX FF7 and will be running it though an R3000 disassembler muchly. It will be intresting to see where what is where.

Also Nori-pyon, I'll have to write you an email! I haven't talked to you in ages!

I'm off now to push some data around for a bit...

DeadLajik

  • *
  • Posts: 53
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #8 on: 2004-06-08 04:33:44 »
halkun,

which R3000 disassembler are you using? Maybe you have a better one then me.. I'm currently using the one from MESS.

Thanks..

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« Reply #9 on: 2004-06-08 06:35:21 »
haven't picked one yet. I would love to have one I can trace through code with. The the old one on PSXEmu was cool.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #10 on: 2004-06-10 21:40:09 »
Quote from: halkun
haven't picked one yet. I would love to have one I can trace through code with. The the old one on PSXEmu was cool.


Try compiling PCSX in debug version for your abuse.. I mean use.
:)

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« Reply #11 on: 2004-06-11 04:20:00 »
Bah, Pcsx is teh Sux0r. The only really cool thing is that it's open source, but it's not written very well. My compiler has fits with it and the precompiled bin bombes out.

I wish ePSXe allowed you access the the dubugger with a command line switch. The devel version has one, but the public version is lacking.

Also my fav debugger on psxdev.de is offline. What a drag.

I can pick through the PC version and compare/contrast with the psx datafiles.

I have an itching to figure out how the filesystem obfuscation system works. It's pretty bad that the PC version has the tables in plain text (well, they are backwords, files, then the directory) Once I develop a logical grouping of data, it will make it much easier to "atomize" the data and then systemataclly decode them.

Whoever did the PC conversion did an absolutly horrific job!

The debug data is stripped out, because that resourse is gone, a PE debugger has no access to any symbols other than what's imported.

The really really sad thing is that it seems no one on the PC deveopment staff has ever heard of a an #IFDEF precompiler directive....

I can understand that it's nice to have the engine toss out what it's doing to stdio so you can follow along. However, when you want to make a production biniary, using #IFDEF will allow the compiler to skip whole blocks of unneeded code.

the command "cc -DDEBUG_CODE whatever.c " would automagicly include any debugging code you put into your .c file within a #IFDEF DEBUG_CODE directive. Not using the -D switch will cause the precompiler to *SKIP IT* and not allow it into the final binary. Wow! Even I know that! (Though I may have the sentax wrong)

Not only that, they used printf strings to spill out debugging data. So now not only do I have the names of very important engine varibles and concepts, I also have thier format. Here a quick example...

(In c:\lib\src\polygon\tim.cpp)
%s total palettes %d entries per palette %d
tim file %s
palette index %d rgba %2x %2x %2x %2x

This tell me that the textures have mutiple palettes and are accessed by a numerical index (Not a pointer) and it uses a red, green, blue, and alpha channel that ranges from 0-255

It's not the code, but it's enough.

I'm really keen on finding the scripting tolkens for the magics. Lucky for us, FF7's magics all start small and get more complex. You can start with cure, which repeats the same green (monochomatic?) sprite sequence about 8 times around a chracter and plays a single sound. It's the same sequence used for "potion"

But I bet the same scripter that runs "cure" runs "supernova"

Where is the script?

It's everything not a tim, spr, or rsd. in a PSX bin file ^_^ I betcha it's in the beginning somewhere...

Anyway enough theroies...

I'm gonna play some ff7 for a little bit.

Darkdevil

  • *
  • Posts: 728
    • View Profile
    • Http://darkdevil177.5u.com
Halkun is back! Prepair to be r0xored.
« Reply #12 on: 2004-06-11 10:15:12 »
Could "supernova" be using the scripter from "cure", but simply using parts from other magics/summons/attacks?


And I hope the data i sent you helps.

DeadLajik

  • *
  • Posts: 53
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #13 on: 2004-06-11 19:18:52 »
Quote from: halkun

The really really sad thing is that it seems no one on the PC deveopment staff has ever heard of a an #IFDEF precompiler directive....

I can understand that it's nice to have the engine toss out what it's doing to stdio so you can follow along. However, when you want to make a production biniary, using #IFDEF will allow the compiler to skip whole blocks of unneeded code.

the command "cc -DDEBUG_CODE whatever.c " would automagicly include any debugging code you put into your .c file within a #IFDEF DEBUG_CODE directive. Not using the -D switch will cause the precompiler to *SKIP IT* and not allow it into the final binary. Wow! Even I know that! (Though I may have the sentax wrong)

Not only that, they used printf strings to spill out debugging data. So now not only do I have the names of very important engine varibles and concepts, I also have thier format. Here a quick example...



It's still quite possible that they may have used #IFDEF.. a compiled binary wouldn't give us a yes or no answer to that..  Judging from the binary though, I guess they did ship a debug build instead of one compiled for release mode.

Off topic, but a lot of games are released in a debug mode.. Even games like GTA (on the PS2) have loads of text and information inside the binaries.. The GTA data is even in easy to read text files.

Oh, I couldn't get pcsx to compile under Mingw or Visual C++ 6.  It seems to have errors with plugins.h or plugin.h   at the CALLBACK* lines..

I'll have to see if I can compile it on Linux some time in the future.

Anyways, I know my comments bring no further help for you.. so I'll just end my post with a..

Good work halkun.

mirex

  • *
  • Posts: 1645
    • View Profile
    • http://mirex.mypage.sk
Halkun is back! Prepair to be r0xored.
« Reply #14 on: 2004-06-14 10:22:55 »
Yup many of game executables are released in Debug mode. Dunno why. Maybe programmers dont know how to switch to Release mode :) Or, its like in the company where I worked before Its like "I've made these new changes which were needed, Debug runs ok, but Release crashes somewhere in the cf#f4$as ... and product should be shipped tomorrow ! There is no time to fix Release, we have to ship Debug and then later on we will ship patch for it"

Programmers aren't so much lazy (well, in general :) ) but they are pressed by time/deadlines/bosses/users.

Quote from: DarkDevil
And what tools are available for unpacking the .LGP files?
There is also mine tool Unmass here: http://mirex.mypage.sk/index.php?selected=1

Quote from: halkun
<Professor Farnsworth>
Good news Everybody!
</Professor Farnsworth>

hehe futurama roxorz ! :)

Cyberman

  • *
  • Posts: 1572
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #15 on: 2004-06-14 13:17:58 »
Quote from: halkun
Bah, Pcsx is teh Sux0r. The only really cool thing is that it's open source, but it's not written very well. My compiler has fits with it and the precompiled bin bombes out.

I wish ePSXe allowed you access the the dubugger with a command line switch. The devel version has one, but the public version is lacking.

Also my fav debugger on psxdev.de is offline. What a drag.

I can pick through the PC version and compare/contrast with the psx datafiles.


Well PCSX is being secretly rewritten, that's all I have to say, so that it compiles more cleanly first of all and secondly its debugger interface is GDB compatible.

If you want a broken down and hex dumped PSX battle model I can give that to you, my big problem has been getting OGL showing the textures, once that would work the rest would be easy by comparison. OGL hates me I think ;)
I suppose I should have the 'cookie' cutter plotting I am using with FF8 textures applied to FF7 textures as well (plot on a bitmap where the textures cut into the bitmap so to speak).

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« Reply #16 on: 2004-06-14 23:13:48 »
Cyb,
 I can't get epsxe to display the VRAM anymore. I think there was a key you pushed to have it come up, but I seem to have forgotten it.

I'm runnin linux, that might be an issure.

Wasn't that a GPU plugin thing? which one was it?

mirex

  • *
  • Posts: 1645
    • View Profile
    • http://mirex.mypage.sk
Halkun is back! Prepair to be r0xored.
« Reply #17 on: 2004-06-15 10:03:51 »
Cyberman: whats an OGL ? anything similair to OpenGl ?

Kislinskiy

  • Guest
Halkun is back! Prepair to be r0xored.
« Reply #18 on: 2004-06-15 10:09:00 »
OGL == OpenGL  :wink:

mirex

  • *
  • Posts: 1645
    • View Profile
    • http://mirex.mypage.sk
Halkun is back! Prepair to be r0xored.
« Reply #19 on: 2004-06-15 11:57:10 »
If help with OpenGl is needed I can give some advice.
To display textures you need to load it into memory, then set it to opengl memory, then bind it when you want to use it and then to set proper texcoords for vertices.
If more details are needed then tell me.

-edit-

i have some time so I'll post brief info how to do it (in C++)

Code: [Select]

GLuint  *textures;   // here are stored GL texture indexes
long textures_count;   //here is your number of textures that model uses

// --- code for setting up textures ---

//alloc place for texture indexes
textures = malloc( sizeof( GLuint ) * textures_count );

//generate texture id's
glGenTextures( textures_count, textures );

// lets set up textures into openGl memory
for( i=0; i<textures_count; i++ ) {
  //set index of texture of which data are we going to change
  glBindTexture(GL_TEXTURE_2D, texture[ i ] );

  //and set data
  glTexImage2D( GL_TEXTURE_2D, 0, 4, texture_size_x, texture_size_y, 0, GL_RGBA, GL_UNSIGNED_BYTE, data );
  //data should be ordered bytes of red, green, blue and alpha, each taking one byte. So data size is sizex * sizey * 4

  // texture filtering when zooming out
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST );

  // texture filering when zooming in
  glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

} // end of i cycle


// --- displaying ---

long  last_texture = -1;

glEnable( GL_TEXTURE_2D );  // enable texturing
glEnable( GL_BLEND ); // enable alpha texturing

//displaying loop for all polygons
for( p=0; p<polygons_size; p++ ) {

  //switch texture if polygon has different then last used.
  if ( polygon[ p ].texture != last_texture ) {
    last_texture = polygon[ p ].texture;

    if ( last_texture == NoTexture )
      glBindTexture( GL_TEXTURE_2D, 0 ); // 0 means turn off texturing for this polygon
    else
      glBindTexture( GL_TEXTURE_2D, texture[ last_texture ] ); // set texture to use
  }
  //by the way, calls to glBingTexture wont do anything if they are called between glBegin() and glEnd() so take care on that.

  //vertices loop
  glColor3f( 1.0, 1.0, 1.0 );
  glBegin( GL_TRIANGLES );
  for( v=0; v<3; v++ ) {
    glTexCoord2f( vert[ v ].u, vert[ v ].v );  // set texture coords for vertex
    glVertex3f( vert[ v ].x, vert[ v ].y, vert[ v ].z );  // vertex coords
  }
  glEnd();
} // end of poly loop


// -- freeing --
// i think this should do the trick
glDeleteTextures( textures_count, textures );
free( textures );

Cyberman

  • *
  • Posts: 1572
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #20 on: 2004-06-15 17:57:05 »
Mirex:
Apart from the fact I just need help? ;)
I've posted the code someplace, no one could figure out WHY it didn't work.

Kelsinky:
Yo! how have you been? ;)

I suppose this is the appropriate forum to now that I think about it (LOL).
Cyb

mirex

  • *
  • Posts: 1645
    • View Profile
    • http://mirex.mypage.sk
Halkun is back! Prepair to be r0xored.
« Reply #21 on: 2004-06-15 18:18:49 »
try this out, or find that code of yours ... i'll take a look

DeadLajik

  • *
  • Posts: 53
    • View Profile
Halkun is back! Prepair to be r0xored.
« Reply #22 on: 2004-06-16 00:57:00 »
Halkun,

Do you plan to put together a document describing your findings (data structures, data organization and algorithms) on FF7 like you did with your PSX tech docs for Zophar.

Your PSX doc is definently informative and very helpful, and I know a document describing the details of FF7 would be very interesting to not only me, but also a handful of other people on this forum as well.

Thanks..

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« Reply #23 on: 2004-06-16 06:00:24 »
I build on the sholders of gaints. I originally came here because I wanted some help ripping the battle fields in FF8. There is a long story to that.

You see, when FF8 came out, I loved the story beyond words. Sadly, the magic system was *SO BAD* I almost didn't finish the game. (They gave up Materia for *THIS*!) I always wanted to re-tell the FF8 story end-to-end but mainking the magic system a side-thing. The plan was to make a 3d real time movie created from of the FF8 data. I helped Qhimm decrypt the FF8 models and tought how to do data visualazation with a few tools I created. Sadly, I have long lost my copy of FF8 PC and the PSX version has a horrably hidden filesystem.

The only thing I really do is read Japanese blogs and sometimes hear a whisper or two from some Squaresoft developers. I also had some contacts from Square-USA in Hawaii that poked me with a clue stick sometimes.

If anything, the only thing I do is come up with wild theroies or play the PSX version of FF7 VERY SLOWLY with the VRAM showing and watch how the system handles data. (I run in software mode at 1280x1024 from a save state). It's enough to get a frame-by frame play.

Another sad thing is my tools have to be re-created. I magrated to Linux a while ago and don't have my hacker's toolbox anymore. Not only that, the PSX disk will not mount proper under linux because it's written in mode 2, I also can't seem to rip the data correctly as Mode 2 data has larger sectors than Mode 1 (ISO-9660) causing the last 256 bytes of each sector to get eaten.

Also the only real contobutions I've ever done is made the baby steps into decoding the .a files waaaay back then. (Mirex then filled in my neophyte work I was doing and did all the heavy lifting) and decoded the FF8 models, but that was because I realized that the models were using quads, not triangles. It was Qhimm that told me that it was using PSX GPU Packet headers to orginaze the data. Something *I* should of reconized as I wrote the PSX doc... (Which makes sense, you can "preload" the data packets and and stream them to the GPU via DMA quickly as opposed to creating every packet on the fly and placeing them into an Ordering Table.)

Another dream is to re-create the FF7 engine and have it run on modern platforms. In a perfect world I would adore the ability to use data from either the PSX or the PC version. However, I bearly know C and use a graphics lib called "allegro" which can't do accelerated graphics. I can bearly open a file and read it into a struct. I can't do OO programming at all because I have difficulty with relational data. I'm also an innumerate and can't add numbers above 15. (I'm not joking!)

The only thing I'm really good is taking programs, blowing them apart, and looking at the fagments left behind. I have a slight (SLIGHT!) intuitive edge, however my therories are often quite wrong. Most of the time people think I know what I'm talking about and try my theroy, only to find I'm full of crap ^_^ and then work out on thier own how things really work...

For example ^_^

I once spoke with the Japanese fella who wrote the FF7 model viewer, he got the data from a friend who worked for square. When I asked him what the file format was, he told me, but it was in such convoluted Japanese I could bearly understand him. He said it was set up in "Data Pools" when one pool refered to another. I saved the explanation so I could translate it later, and never found it again.

I posted here that the models are made from "Data Pools" and for some reason, someone knew what I was talking about and was able to make headway into the .p format.

Where was I?

Oh, yea.

Anyway, if you want me to accumulate everything I have discovered or read or have blown up into one huge doc for refrence, I'll do it. "Everything you ever wanted to know about the FInal Fantasy 7 Engine, but were afraid to ask" ^_^ It wll be an inresting place to put my wild theroys and so you guys can can prove me wrong and tell me I'm full of it.

I'll accumulate what I can into an outline. I would like permission from the various hackers to be able to put thier data into my doc. I'll give proper credit.

If anything, we will have a base to which someone else can port the silly thing to modern platforms.

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Halkun is back! Prepair to be r0xored.
« Reply #24 on: 2004-06-16 06:26:11 »
Quote from: Darkdevil
Could "supernova" be using the scripter from "cure", but simply using parts from other magics/summons/attacks?


If I can get my vram viewer to work again, I believe there is a generic set of textures for Battle. (The s_effect textures). These are four-bit textures that have such things as slash animations, generic explosions, and various "sparklies" that spells and attacks use. It also conatins the limit break aura texture, enemy skill aura texture, and magic aura texture.

As soon as I figure out how to get my vram viewer to work again I would like to see if these are cached. Because they are only four-bit textures, they don't take up very much room at all and are probably never cached out. It would make the access time faster as only the unique textures for the more complex spells will ever need to be paged in.