So where do i get started?

[Aali]

after reading through pretty much everything in this forum, i've decided to take a shot at helping this project

from what i've gathered, attention is focused on the script system at the moment, and since thats whats calling all the other modules of the game, its probably a good place to start

i have not looked at the code yet, but i assume its still not anywhere close to a useable engine, capable of actually doing anything 'useful'

basically what i want to know is what you have in mind for the different parts of the engine, and more importantly, what we need to get going to make the thing somewhat playable (its easier to improve on something you already have, than to aim for perfection at the very beginning)

as for me, i have prior experience with cross-platform game development in c/c++, i own both pc and ps versions of ff7 (english)
i have been poking around in the data files and main .exe of the pc version, but thats as far as my ff7-hacking goes

_if_ this hasn't been done already, i would love to get working on decoding (and rendering) the field background images

 

[Synergy Blades]

its easier to improve on something you already have, than to aim for perfection at the very beginning

I disagree. If you've worked on large projects before you'll probably know that if you don't plan fully and correctly at the start, you will end up doing about 70% of the project before you realise it just ain't gonna work, and how you'd wished you'd planned fully at the start before diving in. Yes, it probably will take a lot of time but the people on this project have stated it isn't going to be usable for quite some time (think years).

So I reckon your suggestion about looking at background code is best. Have a look at Fice's website which (as far as I can remember) includes background rendering code in Delphi. Take that as a base for whatever language you use.

Some suggestions - why certain backgrounds render garbled (try Cosmo - anfrst_1 to anfrst_4, for example; it looks vaguely recognisable, so are we missing a certain structure in the background image section); figure out how background animations work.

 

[Aali]

well yeah, of course, there are some 'traps' you dont want to fall into
i'm not saying you should just hack up whatever to make it work (kind-of), you still have to make sane decisions
what i really meant is that no single part should have to wait because something else isn't perfect implementation-wise

too bad i'm not familiar with delphi, but yeah, i'll look into that, shouldn't be too hard to figure it out
is that just the pc version though or do they use the same format? i guess it should be similar either way
background animations, will do  :wink:

 

[halkun]

I'm at school, I have about two weeks left....

Your best bet is to go through the code. Akari has done a good job setting up the modules and have entry points for a lot of them.

The PC and PSX data, though related, are defferent. Your best bet is to pick though the PSX version with an emulator and memory dumps. (See my recent fieldscript posts)

We should be decrypting the fieldscript as best as we can and getting that documented. That's the core of the system that most everything else is based off of.

 

[Cyberman]

Having been strangely silent ( for me that is LOL) I thought I would add a few things.
This does require a great  deal of patience so if you want to start you have a bit of catching up to do.
Halkun's advice is very sound, pick through the PS1 data if you have it.  There are some discussions of this in the tech forum from a while back abuse search in it as much as possible.
The field script data is pretty important, in fact without it the rest of the data information is fairly useless apart from making nice eye candy.
The real current difficulty with the field script is defining pneumonics for the codes and a nice way of presenting parameters for them.
Essentially the field script is a form of byte code like a processors opcodes.  So it's kind of like making a disassembler.  This is a bit more difficult to interpret since the opcodes themselves are sort of unknown in terms of all the information reguarding them. Qhimm has been extremely helpful in that reguard.
The field background data for the PS1 I've been toying with, it's kind of difficult to figure out for me thus far and I kept loosing my source code to NTFS getting corrupted.  Borde has done some work with the PC data, (see tech forum).

Now some boring stuff.
The backgrounds have a few limits, the number of tiles, and palletes are fixed (50 palettes although it won't crash with 51 it's likely a bug not a feature). They are collection of tiles with palettes that are pasted to the display.  The data is mostly the same as what the PS1 data set is.  Only stored differently. Because it was originally a PS1 game FF7 for the PC has PS1 limitations (likely per contract with Square for the port).  So all the backgrounds are identical to the PS1 version.   The big difference is the structures used for swaping the data to the display.  There are several types of data used.  Also it's technically not background image data but scene data.  There are several layers like those used for drawn animation.  The background is one set of tiles.  Static objects that can be walked around and in front of are another.  Animated objects are the last set.  For the PS1 the tile data is stored in files with the MIM extension.  The field location information (including the background arrangement) is stored in files with the DAT extension.  BSX files aren't of interest for the field scene unless you wish to talk NPC and 3d object models (train graveyard in midgard for an example of moveable 3d objects).
A lot of this is discussed in the tech forum though.  I'm not positive but I think a lot of the PC data is in the wiki.

Cyb

 

[Aali]

so yeah, i had a look at the code, and to put it simply, i was expecting to see alot more *working* opcodes
i see now why you're focusing on that

but, i have the PS1 data, emulators and everything so i should be able to help you with that
just need to read up on how the PS1 works, and how to make my emulator spew out all the nitty gritty details 

oh, and, i was toying around with the PC field background data, i managed to get nearly all of them to look perfect (minus special effects, since "we", the wiki and i, have no idea how that works)
there's one thing thats bugging me though, some (most, but not all) of them expect black (0x0000, after palette filtering) to be replaced with color 0 in the palette, and there doesn't seem to be any sort of flag or anything to indicate if this behavior is required

following that rule makes some backgrounds look good, but draws non-black pixels that should be black in others, not doing it breaks the ones that expect this but make the others look fine

i think i'll leave it at that and wait 'til some smart kid figures it all out 

 

[Cyberman]

0x0000 is not what you think. It's not black. This is because they are using a PS1 palette not a PC palette.
0x0000 is not black it's transparent. 0x8000 IS black.
This is because of how the PS1 handless the transparency flag apparently. (sigh)
A:1|B:5|G:5|R:5
A:1 is the transparency flag.  For anything BUT 0x0000 in BGR it indicates transparency.  For black it indicates black
So if you see 0x0000 it's actually completely transparent.

Minor bit of weirdom to say the least.  This is what I've been told and have interpreted it as.

There was also a discusion on color translation in here, I suggest you find that too get a long winded discussion for it.

Cyb

 

[Aali]

well, problem still stands, some backgrounds assume color 0 is transparent, others assume its a real color and there doesnt seem to be any kind of flag to tell you what they want

let me get you some screenshots..

first method, ignoring color 0 in layer 2 only:

second method, ignoring color 0 in both layer 1 and 2:

fixing one produces artifacts in the other and vice versa..
i dont know why they would have two different standards for this in the first place, but it seems kind-of weird

 

[Cyberman]

Did you check what palette was being accessed? I can't remember off hand but some scene objects palette information is treated differently.

Cyb

 

[Aali]

palettes 1 and 4 respectively, giving special treatment to either of them does not solve the problem
i suspect the unknown bytes in the section header (where width, height, etc is stored) may have something to do with it
i have not seen any obvious patterns though