Messages

176

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-12 01:29:39 »

Those gaping holes infer that the surface has the inverse normal it should have hmm you may have mostly triangles and those might be quads? This may indicate you are not traversing those particular vertexes in the correct order. The right foot looks slightly incorrect. It's better looking than my spaghetti was to be honest.

I found my old source code but it looks like the DFM file (form layout description language) got hosed. It seemed to do quite a bit it appears to have used GLPanel which... isn't on the net anymore

I remember I was moving to GLScene. However GLScene is vehemently Delphine in nature as well as not very well supported by BCB. I can't build the components essentially. (Puzzle).

Well anyhow it appears to be a similiar panel to what NeHe assistants used in the BCB examples. So I'll see what I can do with those variants.

The biggest problem is I am missing half the descriptor for my form.

Erstwhile as I said it looks like you have missordered some of the vertexs and that might be what is causing the 'holes' the rotation issues might be directly related although I doubt it. The foot appears to have been rotated the oposite direction. My mistake was not taking the vertex pool seriously enough. Maybe I can fiddle with the old FF8 model traversing code.


Cyb

177

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-10 19:31:53 »

So what you're saying, is that once I have a potential vertex pool, I start plotting two of the coords per vertex in paint... If it starts to look like a model shape, I probably have the right stuff. If not I may be looking at something else entirely...

Is that what you're describing?

(And on the subject of busy life stuff... that I can fully understand... it isn't easy being a fulltime student with a part time job and no method of self-transport...)


However, I should note that I'm not simply working on FF8... I'm on FF9, both .hack series' and a number of other games on and off at any given moment, as well as being a 3D modeler for my own games... If I devoted all my time to one format... I'd probably be able to crack it at some point(or have a severe mental break).

However, my previous statement was referring mainly to the fact that I still can't get my headers to read properly even when they are fully documented...

When I read a header that tells me a file should start or end at a certain point in the data... I look at that part and it's either well after the end of the file or it is in some random spot after the file has already started... so instead I look at a relative point to the beginning, or end of that header, or the main header, or the end of the previous file, etc... but for some reason, even though I know the documentation is good, the headers don't seem to point me to where they should... (meaning I'm somehow reading them wrong...)



In any case... none of this helps the FF8 formats so I guess I'll stop.

I'm now curious when I get time I'll dig through what's left of my FF8 experimentation.  I have to remember the media data as well. FF7 was much easier to deal with than FF8 and FF9 in that regards. In the mean time it will be a bit of time before I can have some useful data from my mad ramblings eons ago.

As for your interpretation of the headers, I believe if you can find the data on for example 15 different models, then compare the header information with regard to the information to the location of the data in the model section that will help. That's basically what I've always had to do. It's how I discovered that the model file in FF7 is actually a large number of files with character files having 16 weapon files (including blank ones) and the weapons were treated as part of the character's skeleton in animations.

If you plot the 3d data as you decribe you can get an idea. It also works with the UV data for the 3d data as well. That will get a few textures on your models. Also be aware of the way the PS1 renders quads and triangles. They are not obvious. In fact I suggest you read halkun's 'everything you wanted to know' document he wrote in regards to the organization of the GPU data. Follow carefully the use of the coordinates in the polygon. The PS1 renders the quads as 2 triangles. This is how I got them to work in data FF7 with quite good results. The same will go with the data likely in FF8. If you think about 2 triangles being rendered to make a quad. 2 points are adjacent. That's the big clue on how they rendered the data.  You will have your polys look like bow ties if you don't realize this.

UV data has coordinates in a bit map (texture).  If you take a blank bit map and draw the UV coordinates on it while traversing the associated polygons you can plot the triangles and polys on the bitmap as they are rendered.  This also helps when you have your quad coordinates not in order.

Cyb

178

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-09 15:50:52 »

Oh how I wish I had he skill at spotting the relevant patterns for data structures like you guys have... Even with well documented headers I can't seem to make my bytes fit right... nonetheless find a vertex pool...

but regardless, I'm glad to see I'm not the only one still interested in getting a good look at 8's graphics.

For me it's sort of like this, "I'm working on an LED luminary, how far is that half bridge from the OSMC 4.1XX, ok I have this AT91SAM7S dev kit is the JTAG drivers installed, I need to install YAGARTO to develope for the micro why is ECLIPSE CDT wiping out the ZYLIN CDT used with YAGARTO, we have 30cm of snow in the drive way. Ok which to do first" sadly that's just today. That didn't include eating getting up and the myriad of other things I think of in a single day etc.

I would spend more time on this stuff if I had more time I guess is the best way of looking at it.

The best way to look at graphics data is that it IS data. Data must be arranged in a uniform manner. Data must have certain information in it for it to function.  What does FF8 do? It has polygons textures, and a skeletal system. We know this by observing the game output.  So it must have UV data to map the texture. It must have a texture. It must have a list of vertex information. It must have a polygon list.  I believe FF8 used all quads I can't be positive because it's been almost 3 years and 9 months since I looked at it. Unlike FF7 it's all the same data type.  FF7 had a rather complex setup where it drew quads triangles and then textures. FF8 just does textures. Of course the reason why FF7 looks quite good still is because of the complex method of rendering.You are a bit further along than I was I was about where you were at the post on 2009-10-09 14:31:2.

Side ramblings, I have more FF9 data now. I suppose I should finish gathering the FF8 data as well. I need several hundred saves with detailed notes on them basically to verify what bit does what and when. One LONG boring play through.

I may put up a detailed CRC explanation as well (hmmm).

Erstwhile with the FF8 data I suggest taking a bit map and drawing on it while you render, the polygon data or while you traverse it.  This technique allowed me to find and understand  the UV data in FF7. IE you feed the UV coordinate data into a vector drawing routine and plot the UV drawing out on a bitmap. IF it looks right then you are probably correct in analysizing the data. Do note they do mirror the data. If you wish to get fancy you can also include numbering for each polygon drawn as well. I started doing that just to know what was done when. (I was nuts I admit).

IF you detail all of this better than I can remember good, if you have the time put it in the wiki (LOL) maybe Qgears will get FF8 functionality sooner than later.

Cyb

179

Scripting and Reverse Engineering / Re: FF8 Models, How did Qhimm rip them?

« on: 2010-01-07 22:34:58 »

In case anyone's wondering, I messed with my script too much and didn't keep backups, so I can't reproduce those results from before. 
I've attempted to recreate it, but I don't know how close I've gotten. I've fixed the misplacement of vertices though.

Current results:

However, the first method can only do one frame from one animation.


(I don't know much about 3D.)

The polygon placement looks about right actually. I believe that the models might have been permanently lit though.  The UV data should also be with the polygons as I remember something like that it was straight forward poylgon data from the PS1 GPU system.

Cyb

180

Scripting and Reverse Engineering / Re: Scripting question

« on: 2009-12-07 21:22:54 »

I don't see how that would make me not like sleep considering that halkun's experiment sort of makes it a lot more possible on a much shorter time-frame, all you really need to be able to do is trace and upgrade the models one area at a time much like with the characters.

As a rule environments have a lot less detail involved over character models and less detail = less time spent however we would need a texture artist to do it properly.

think about it we could place our own mark in midgar, put boxes places they weren't making the game more modding friendly/higher detail

There are ways of doing this, however unless you have the expertise first you will have no idea how to do it.  As QGears is open source you should be able to experiment with adding background information to the FF7 exported data used by the QGears engine. However it is not possible to do with the original data.  Examine the battle scenes in FF7 that's the closest thing to background support you can have in the game. The original engine would require modification to add 3d scenes.  It's not impossible it's just impractical.

Then comes to the problem of creating 3d content based on the scene used.  You can use the walk mesh as a guide. However generating correct depth information is the issue.

I don't believe there is any EASY way to do it.  If your heart is set on this, I suggest experimenting with a small scene. If you don't know much about 3d and Qgears I suggest you study a bit about 3d information (modeling inclusive) on gamedev.net and spend some time learning what is going on with FF7 and how the engine works. If you understand how things work it becomes much clearer how to make what you want reality.

Cyb

181

Q-Gears / Re: To Clear up some things.

« on: 2009-12-07 21:15:33 »

Really? Hmmm it was a lot harder for me to find the models et al than 7 and 9 .. at least 9 had a nifty index system that was .. obvious

Oh well such is life.

Cyb

It's maybe easier to find without reversing, but when you reverse all the code - FFIX is much harder. Scripting system in FFIX is a bit different and resource system is very big and annoying. FFVII, Xenogears - much easier.

ps: I start with reversing of graphical pipeline. Trace and reverse all data that formed into render packets.

That's a good route for my current PSX project actually. It's a bit too long to explain right now.  In any case I had never thought of that approach. I have always beat on the data itself not investigated what was being done with it. (LOL)

Cyb

182

Scripting and Reverse Engineering / Re: Scripting question

« on: 2009-12-06 18:34:58 »

next question would it be possible to rotate the camera in th field like on the world map

Rooms have fixed camera views there are multiple camera views in some rooms but that is because the room scrolls and the fixed background is done such that either perspective will look fine.  An example is Coasta Del Sol If you walk from one side to another the screen pans and so does the camera, the actual background is fixed the camera pans depending on which section of the background is being viewed.  There is no point in doing anything else because the only things that are 3d are actors in the screen. This would be save points treasure chests and things that are walking about.  You can't see the rooms in any other angle because they are permanently rendered (hand drawn actually).

Cyb

183

Q-Gears / Re: To Clear up some things.

« on: 2009-12-06 18:19:42 »

Really? Hmmm it was a lot harder for me to find the models et al than 7 and 9 .. at least 9 had a nifty index system that was .. obvious

Oh well such is life.

Cyb

184

Q-Gears / Re: To Clear up some things.

« on: 2009-12-04 00:17:45 »

I will not work on FFVIII, only FFVII, Xenogears and FFIX. If anyone have courage to face up FFVIII - welcome.

Please excuse my ignorance, but what exactly is the difference between them?

FF8 is a bit trickier than the others. There isn't as much information also. I remember poking around with it some. I suppose I should get back to playing with some of this. It will be after I have ported PCSX 1.9df to the beagle board however. That should take a week or two as I am a bit backed up. I've started actually taking vacation .. so maybe I'll get around too it sooner?  I still haven't started any of my AT91SAM7S projects (I have all the dev stuff too) heh. Lots of projects just not enough time I guess.

Bottom line though FF8 data requires a bit more work (on the PSX variant) Qhimm has done a lot of deciphering along with numerous others (back in the days). Not as much people play with Ff8 I guess. I have some save data yet to finish with (the bit data for each thing you do in the game is but one of many).


Cyb

185

Scripting and Reverse Engineering / Re: FIELD.BIN (exploration) thread

« on: 2009-12-01 22:31:30 »

I believe I read through field.Bin before (as noted I started the thread eons ago) and found several tables in it. 

I suspect that the LBA table for the real file db is in there and I believe I found corelation to the files on the disk. I just had a system crash and it wiped all my work out is all. Have to love SIS motherboards (that's what killed my data a bad ATA interface on the board). This is the same machine with a different mother board works just fine without it

Anyhow judging that the engine uses a series of numbers internally for field files it has to use something to translate that information into a physical location.  I would hazard to guess that would FIELD.BIN for the rooms (which is the majority of the game content apart from movies). Battle scenes and characters have very little in the way of scripting.  The majority of the script is in the \FIELD directory.  That being said everything therefore must have an index for the script system FIELD.BIN seemed (or is?) the most likely candidate for the table for that.

Cyb

186

Scripting and Reverse Engineering / Re: field backgrounds Zone2 sprites Z coordinate

« on: 2009-10-24 20:35:18 »

I've been looking for a time about those files and trying to display them. But i was wondering about the Z texture coordinate, that has to determine the order of painting algorithm over the model. I know that Z has a 4 byte size but it's not a floating point value because it's representation it's too small to simple be it. I was wondering if it could be possible that Z coordinate along with X and Y where on a fixed point like angles in battle movement and need to be divided by 4096.

Thanks.

Good question however there are quite a few Final Fantasy Game/Square soft games etc. So what particular ... game file type etc. are you speaking about?

Cyb

187

Scripting and Reverse Engineering / Re: [FF8] .STR movie format variation

« on: 2009-10-23 23:12:20 »

I know that there is distortion, but it's acceptable for the people, I think
I thought about English & Polish words together, but it was too many things on the screen and the movie was less "clarity".

IT would have made your job easier if they used text overlays instead, which is/was practical at the time. I'm curious why they didn't. It doesn't make much sense to create a bunch of custom video's for each language. Then again that was the era of BFI (Brute Force and Ignorant).  FFIX although pretty suffered from the same issue.  I suppose the real problem would have been the fact the overlay generation system might have taken more time than doing all the sequencing and typesetting.  Also the video may have been relegated to a team that was for the video. Overlay generation would have been a different group. IE less work (Time) for them. Money allocation issues I guess.

Cyb

188

Scripting and Reverse Engineering / Re: [FF8] .STR movie format variation

« on: 2009-10-22 00:42:00 »

I know what is Type 1 and Type 2, but thanks

Movies are stored inside IMG file on the disc. I translated what I want, you can see effect here:
http://www.youtube.com/watch?v=-9oss6rX4y4

When I'll finish conversion of Polish translation into PSX, I'll add explanation into Translation minitutorial.

Img files are just packages of data. Ertswhile, not too bad, you can see the distortion of the original symbols in the video but it's not enough that I would actually care if I were playing the game. I think most people would be interested in the reinsertion of the video.  I'm glad you know about Type 1 and 2 sector data, because I've seen only a few who actually paid attention to that.

Cyb

189

Scripting and Reverse Engineering / Re: About savemap in FFIX

« on: 2009-10-16 03:51:27 »

Oh and the name size is not 8 it's 10 symbols

Hmm, ye kinda seems so. In the japanese version (which is the only one I found right now), there's even 2 names stored for afew characters. Like Zidane have both "ジタン" and "？" stored within these 10 bytes, Garnet have both "ガーネット" and "ダガー" etc. Can remember that in the english version (besides, it kinda shouldn't be possible to store both anyway!). I also though it was 8 because Salamader wouldn't fit, hence he's called Amarant, oh well.

I'll see if I can dig out some savegames, I usually don't use more then 1 slot though.
What's the 2nd MAX HP/MP for anyway?

Ugh that took me forever to find out. Max HP/MP with enhancements. IE +10hp mods for stone settings.  They have some limit they set (calculate?)
I've got more data as well.

Cyb

190

Scripting and Reverse Engineering / Re: [FF8] .STR movie format variation

« on: 2009-10-16 01:24:47 »

The files are Type 2 media data your sector sizes are therefore wrong. They are BIGGER than 2048 bytes. The video simply doesn't use the remaining bytes of the sector the audio DOES however.
You need to read the HEADER information for each sector (and you must read an iso file don't waste your time with windows reading the files off the CD it will hose them) to decipher the data correctly. If you only plan to modify the video it shouldn't be too bad.  I believe the video encoder that Sony had available 10 years ago is still floating around. You need to be sure the video for input to the encoder is the correct format (resolution is just half the battle it has to be able to read the data).  It's been over 10 years since I've played with this stuff.  Basically you need to run the encoder to make the proper block data for the video sectors. Then stuff the chunks of video data into the video sectors (only) you can't do this in a contiguous manner you need to break it up frame chunk by frame chunk like the original frames were. I believe 15fps at 2 speed was the data rate for the audio and video. This information was interleaved. That is why you need the sector headers since that information controls what sector is what (audio or video).

Unfortunately it looks like Pixel let his website go poof. He was a doctoral candidate in France hopefully nothing bad happened.
he had some great explanations of the ISO9660 format etc. I downloaded those. He also had a very handy scriptable tool for managing CD-ROM data of Type1 and Type 2.

STR data is type 2 data (even when the audio isn't with it). It's extremely important you read a ISO created from your original media for FF8 instead of trying to use regular tools.
Hopefully you can do some coding and learn how the Type 2 file format works and the video data on the PS1 disks work.

Good fortune!

Cyb

191

Scripting and Reverse Engineering / Re: About savemap in FFIX

« on: 2009-10-09 21:19:51 »

It's been 5 years since I worked on that. Hmmm I'll have to see what I had done.

Cyb

After clearing debris in my computer (gah this thing is full of 10 years worth of stuff and my linux box is worse 15 years!)
(cough)
Anyhow seems some of the information is a little different I have.
Listed under support I have ability learned, however Support may make more sense, namely because the bit fields simply do not match what has enough learning points.  At the same time, each character has a set of unique skills and common skills that can be learned. Vivi can learn magic where as Dagger/Garnet and what's her name can learn summons. However all of them can learn things like bug killer etc. I have 64 I suppose to match the number of bits in the 'support' thing  so I have fewer unknown space. As yet I have seen nothing in the first 16 columns.  Does anyone have a complete set of saves from begining to end of game is MCR format? (ePSXe) I just don't feel like playing through 40 hours of game to get a large amount of data suddenly.  

I remember the same problem with FF8 I got about 6 hours into it and ... hmmm

Oh and the name size is not 8 it's 10 symbols
at 0x002C WORD 2nd HP max
0x002E WORD 2nd MP max
0x0038 is the status byte for the character as some status changes do not end after combat (Darkness for example) not sure about petrification also... anyhow.

Cyb

192

Scripting and Reverse Engineering / Re: About savemap in FFIX

« on: 2009-10-02 23:15:37 »

He's looking for the save data structure information.

Cyb

193

Q-Gears / Re: Project State

« on: 2009-09-10 00:37:13 »

There is no PC version for 9 10 or 12.

Erstwhile check the Qgears sourceforge page. It's mostly there.
I believe CodeBlocks is the IDE for developement by Akari. There is a script engine being used don't remember what it was.

I haven't even looked at it in over a year. Working on other things these days.

Cyb

194

Scripting and Reverse Engineering / Re: Figuring out the field files

« on: 2009-09-01 23:14:30 »

There is some sort of "build" file dumped in the FIELD section of the PSX disks. This has a lot of data but I don't believe it's used by the game at all. I'm trying to remember it's name. Oh well if it's not a DAT MIM or BSX  (something like that) that's likely to be close to what that file is. It's been a long time since I messed with the data BCX are characters (heh look at the names) I believe it's FIELD.BIN not positive though as I said it's been a while.

Cyb

195

Troubleshooting / Custom graphics driver for FF7/FF8 [v.1-.7.6]

« on: 2009-08-29 22:07:18 »

Cyb! Welcome! Where have YOU been?

Working on the OSMC 4? (Open Source Motor Controller) It's in yahoo groups.
Since I'm an engineer by job, training, and by blood (4th generation) it's something I do
Programming is something I do as well.

Aali your PC DLL is probably going to make those old programs (FF7 FF8 PC) go a lot longer.

Cyb

196

Troubleshooting / Custom graphics driver for FF7/FF8 [v.1-.7.6]

« on: 2009-08-27 22:06:38 »

The rumors of my vacation have been greatly exaggerated.

I moved to a new city, had ISP problems and went to uni, in that order.

But more importantly you didn't go into net withdrawl LOL

Vacation right now sounds nice ... really really nice.

Cyb

197

Troubleshooting / Re: Swap/insert FFX models/textures

« on: 2009-08-27 22:04:54 »

I have seen some tools to extract the models and textures from FFX. But this doesn't help me much, because what I want to do is change the appearance of one thing into another. So, I need to replace the model/texture of one FFX object with another. This should be very easy, but I don't see any tool to help me. Does such a thing exist?

If you don't know how the models are put together, the format of the data, then how can this be "very easy"? Perhaps you should find information available and DIY?

Cyb

198

Troubleshooting / Custom graphics driver for FF7/FF8 [v.1-.7.6]

« on: 2009-08-21 02:01:42 »

Nevermind that, the next version of the driver will only ever load external textures once.

Right now it'll reload the texture every time FF7 reloads the original texture, and that's pretty often.

And how much memory will you consume as a consequence? Remember the more memory you consume without releasing it the more likely you'll have:
1 a memory leakage issue
2 a slower program due to swapping because other programs running need memory.

Microsoft assumes that RAM is theres (not a joke it's a fact) and they do use a HUGE chunk of it even if it doesn't look like it.  This means you'll always have SWAPPED out memory.
Any time you have large chunks of allocated memory you will get slower hard disk performance. This is because of SWAPPING caused by loading more data into memory. It seems part of there allocation scheme for memory involves swapping data out immediately (to keep more room for ... something).

Anyhow.. windows is ill behaved with large memory allocations.  Hence I recommend you consider a texture caching scheme before you make it difficult to implement.

Genius is the art of planning ahead.

Cyb

199

Scripting and Reverse Engineering / Re: [Xenogears] Level transforms/animations/skeleton?

« on: 2009-08-16 22:44:09 »

It's always appreciated when people share Micky LOL

I haven't really done anything with FF7/8/9 in 2 years scarey huh?
However I may have some time to tinker.
I have WAY too many games... SIGH.

Cyb

200

Scripting and Reverse Engineering / Re: FF7 PSX Field Scipt Opcodes

« on: 2009-08-15 00:48:54 »

Hi, I'm trying to figure out how to kill the background music for battles, and disable the victory music at completion. Opcode F6 selects the music, and it looks like i can disable the victory music with opcode 22. Do I need to uncompress and modify a /field/*.dat file? If so, what editor do I need? I can only seem to find PC editors... I've searched all over the place. I don't know where to start looking. If anyone can point me in the correct direction, I'd greatly appreciate it.

I believe all battles have there own script in fact they all do. Some a very short. Some battles do not have the same background music (if you have noticed).  So my guess is the place to look is in the BATTLE area not the field scripts.  Area has specific battles for it as well as world map has specific random battles.
Battle I think has it's own script engine as well. I suggest you look again at the WIKI.

Cyb