[FF7] Intended FFVII Editor - Aeris (2007-01-23)

  • Thread starter Thread starter The SaiNt
  • Start date Start date
Status
Not open for further replies.
T

The SaiNt

Guest
Well it isn't actually an editor at the moment, just really a test of some field background loading code.
Just needed some people to test it to tell me what other problems there are with the field background code.
It should fix several problems that exist in most if not all the other field background loading projects (since they're all based on Qhimm's code) out there.
If things works out fine, I'll release some documentation so everyone else can implement it.

http://forums.qhimm.com/The_SaiNt/Aeris.rar
 
Last edited:
Nifty; haven't had a chance to check it out yet, but it sounds like a perfect complement to Meteor, since I could make it as a plugin.

[Edit]Hmm, can't get the archive to open in Linux, will try it again when I get home (Windows). Did you figure out how a character is able to walk both in front and behind a portion of background, depending on their z-coordinate? I had tested out one of the unknowns which I thought was a sort of "z-axis" for the background, but couldn't find a specific pattern to it.

[Edit2].NET? I need to get the latest version of the framework apparently...
 
Last edited:
I'm more intrested in wondering if you were able to get the color palettes fixed so that there were no "drop outs" in color and also if the "spanning" field files (ztruck) have been fixed.
 
You'll need .NET 2.0 runtime to get it running.
Also, the Upper / Lower Plain checkboxes have been disabled on purpose, since I'm still in the midst of debugging them.
 
You'll need .NET 2.0 runtime to get it running.
Click to expand...
That excludes me, It's amusing that Microsoft would make a cross-platfrom bytecode system, and then not make is cross-platfrom

And mono doesn't cut it. C#, as microsoft sees it, requires windows.forms. Which ties it to win32 anyway.
 
Apart from the memory usage, which sent my laptop into overdrive  :lol: It looks fairly good in terms of getting the scrambled backgrounds out that were unreadable before. Still on the proverbial to-do list then are:


  • The odd colours (ancnt1 black areas, uutai1 clouds, etc)
  • Lighting, or rather, transparent coloured patches (Wall Market, Aeris' house, etc)
  • Transparent areas, other special effects (Chocobo Races, etc)
 
It would help if you could point out which ones you were refering to exactly.
 
Any. The ones I highlighted are just examples of what specific things the format is missing from either Qhimm's code or yours (generally, what we still don't know). If you like I'll photoshop a few examples and post them here in a bit.
 
Fixed the black areas and uploaded a new version.
Do make your screenshot based on the one I just uploaded.
 
I did try; after about two minutes getting ancnt1 to appear, which looks great now without the black areas, I tried another, and about ten minutes later and 375MB+ memory usage I had to restart.  :oops:

Anyways, not having a save game to hand I've just photoshopped a few of the backgrounds to illustrate what's left. Note that these were what I noticed on the previous version so I don't know if the new version has these or not:

chocobo_races.jpg


The semi-transparent blue 'crystal' foreground piece is missing from the central area.

wall_market.jpg


Try this out ingame and see the glowing effects all over Wall Market; I just felt the area on the left was most prominent. They're transparent foreground bits, simulating lighting. I know these are made using palette opcodes in the script, and as a result I think they need to be set up in the foreground sprites so that you can manipulate the colours correctly via scripting. Any insight would be really useful.

[Edit] I did actually make a mod to the background generation code that outlined any 16x16 tiles using the "unknown_sfx" as per fice's documentation, and I'm fairly sure these are the ones that set the "light" areas (since, for example, on Aeris' house, the rays of light coming in from the top left where outlined in the same shape they are in the game for the lighting areas). Still not having peeked into the palette manipulation opcodes as yet, I'm not sure whether the numbers for unknown_sfx correlate with those used by the opcodes.
 
Last edited:
Still have pixel drop-outs. Palette index 0 isn't being used correctly (still)

According to cyb, palette index 0 sometimes means black, and sometimes mean a color. However, how the field file decides which is which is random. Is it set with a ???PAL command in fieldscript? Is it a data element we are missing?
 
lol, I'll have to take a look at this memory problem on your machine, I have no such problem on my PC.

[Edit]I just made some changes to make it clean up more so it won't use so much memory, hopefully this fixes your problems
[Edit 2]Now all fields shouldn't have any pixel drop-outs. I can assure you that palette index 0 is always transparent, it's not random ;)
I'll probably work on the lighting thingy when I get the time, but don't hold your breath cause I don't really have too much free time to work on this.
 
Last edited:
Added support for the lighting & transparent stuff. Also moving this thread out to the public area since I believe it's ready for public testing. Mouse scroll zooms in and out, left mouse drag to move around.
 
Nifty; haven't had a chance to check it out yet, but it sounds like a perfect complement to Meteor, since I could make it as a plugin.
Click to expand...
I think I know which variable represents the z value, but obviously in the state of the current viewer, I haven't had a chance to test that value yet.
 
Nice one The SaiNt!

Here is a quick list of problems

bugin1a - crash
hyou2 - display problem
junpb.tut - crash
junair - wierd overlay
las4_3 - crash
las4_3 - crash
maplist - crash
mds7pb.tut - crash
nivl_b12 - shows the last chunk on the left side
nivgate3 - weird display
nivgate2 - weird display
nivl_b1 - shows the last chunk on the left side
nivl_e2 - weird display
ship_1 - shows the first chunk at the end and there is a green spot even with the cover
trnad_3 - crash
trnad_1 - weird display

I think you should add a sort of check for non field files and that should solve the crash in *.tut and maplist. All the other problems look common. The crash on certain files and the video weirdness. I think that when you solve those two problems all the others will go right in their place.
 
Thanks for that, I've fixed most of the issues now.
I'll upload a new version after I complete the extra features I'm implementing for the next version.
 
Uhhhh... extra features....  :-D

If i can be curious, what kind of features?
 
You get to see the new features now ;)
A few controls you should be aware of though.
Shift + Drag moves the top layer (try bwhlin and you'll know what I mean.
Normal drag scrolls the screen.
Mousewheel zooms the image.
Also the Upper / Lower Plains hardly appear in the right positions. This is because they are implemented via the scripts and obviously I haven't implemented them yet.
I'll let you test the rest and figure out the rest of the controls yourself.
 
Nice! I think the ability to move the layer is really useful.

Btw, i was checking all the levels again and:
colne_1 - missing tiles
colne_5 - missing tiles
hyou2 - still looks weird. The trees have like a blue stroke around them
junonl2 - the upper plain is transparent. I don't know if it's correct
junele2 - cover totally black?
junonr2 - same as junonl2
las4_2 - like hyou2
losin1 - missing tiles
mkt_s3 - missing tiles
nivinn_1 - missing tiles
nivinn_3 - missing tiles

Everything else looks perfect.

I can't wait to see what this program is going to be capable off. Oh one question... i don't know how hard it would be to export the BG layers and re import them. You think it's doable in an easy way? If not, forget my stupid question :P
 
Status
Not open for further replies.
Back
Top