Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Aali

Pages: [1] 2 3 ... 48
Huh. That is an actual, working? full decompile of FF9. Its something we talked about doing for FF7 but someone actually did it. I'm not sure what this will do for us exactly but it sure is pretty impressive.

Each tile (except for the first layer) has a given Z coordinate, it's all in the field file format. I would also like to point out that since the PC version uses Z-buffering, it does not have to do any of this manually and characters are simply drawn before all the tiles are drawn.

Download link is down right now, don't know exactly when it will be back up, feel free to post an alternative DL.

It seems more likely the high-res textures were cut out due to performance issues. The worldmap module in FF8 is extremely inefficient and I doubt it ran very well even on mid-range hardware at the time it was released.

The high-res textures are only used in the Steam version. The original PC version will never use them.

DLPB, NFITC1, myself and I'm sure a bunch of other people have tons of information that isn't feasible to share on the wiki, if you ask specific questions about the structure or functionality here or in the IRC we might be able to help. Just make sure to do your homework first.

You may want to read this document:

It's reasonable to assume that the file format is pretty much a 1:1 mapping of whats sent to the GPU.

Per DLPB's request, I'm filing a bug report for 1.2.1.   Upon attempting to compile a heavily modified battle.lgp that will be 1.04Gb or larger, it throws the error "the volume for a file has been externally altered so that the opened file is no longer valid".  However, using a compiled version of Aali's code from will compile it just fine (though in instances like barret's attack, his shells will no longer appear. and there are a few other texture errors).   Your version has fixed whatever that problem is, it just won't compile it if it's too big it seems.

Also tried compiling the 1.04Gb battle.lgps using Aali's code and using 1.2.1 to then dump that.  It errors saying battle.lgp cannot be found

I would like to see that broken LGP you produced with my tool. If you could come up with a set of source files that produce a broken LGP file with my tool and a working one with ulgp that would be even better.

It's a combination of walkmesh flags and script handlers, see

The trigger for these events would be type 2 "Mesh Functions" but if you want to move them within the same mesh you'd only have to adjust the walkmesh.

TL;DNU; it's a lot of work and you're on your own.

For the record, worldmap can read and write anything in the savemap beyond 0x0BA4. See

That log doesn't say anything about missing textures so I don't know where you got that from but those error messages are certainly not normal. It looks like it might be a bug in the driver, you should be able to work around it by manually creating the path its asking for. (create the directory c:/games/Final Fantasy VIII/mods/mods/cache/data/eng/menu/hires)

Q-Gears / Re: Current state.
« on: 2014-08-05 19:44:32 »
I am, that's just the opcodes though, I will be adding more on how the script is organized and executed and once that's done link it into the main FF7 page. There are still a large number of unknowns though and it seems like quite a bit of stuff you'd need to get the WM working is either hardcoded or contained in other files.

Code: [Select]
FrameLimiter ( byte fps )
   Entrytime = timegettime
   while( true )
      if ( ( 1000 / fps ) >= ( timegettime - Entrytime ) ) break;

n'est-ce pas?

This is the kind of shoddy code that gets us inconsistent framerates in FF7 in the first place. You have to take into account the time it takes to process/render the frame, you can't just wait a predetermined amount of time after each frame.

here is my upscaled version of bugin1b.  The file bugin1b_0_00000516.png is there but if you try to import it into palmer 0.8b or earlier versions Palmer just ignores that file and says its missing.  Again the only reason I can guess is because the file size is sub 2 kb.

That file is an 8-bit paletted PNG. Palmer only supports truecolor images, 24- or 32-bit. Error reporting could be better in this case..

Now what about that crash?

Please provide details on how to reproduce any problems you've found in 0.8b.

I guess I need to search for my test shadow field model and make some tests to see if I understand what you say right...

Maybe I got you wrong but this is the result of my tests:

I have tried to replace the shadow texture with its external counter part, but no matter which setting I use it doesn't use the correct alpha blending:

As you can see I need to change the status for the shadow part to average to get alpha blending to work, but that's not as I had planed that it should look like. I wasn't sure if I replaced the shadow texture right, so I painted an big red A on it. Well I had done it right...

Here is the same with the driver built before and that's what I expected the shadow should look like. Though I still need to set the blending for the part to average:

That is quite strange and not how I intended it to work. Could you send me the files you used to test this? And just to be sure, can you check that fancy_transparency is on? I don't see why anyone would turn it off but that would disable the alpha blending.

The problem is that the engine abuses and misuses the average blending mode. It should never have been used for "real" alpha blending, there should have been a separate mode for that. As a result the change I did in 0.8b improves some things and completely breaks others. It's not an issue for modpath textures and never was, those always use alpha blending so all you have to do is turn off the PSX blending modes to get proper blending without the average effect.

Since the PSX does not have alpha blending it's safe to assume that any alpha blending used in the PC port is some kind of hack to make up for the lack of subtractive blending.

IIRC the shadows on PC are just a vertex colored triangle fan, there's no texture.

The shadows (and probably other effects) in battle were changed pretty drastically for the PC version because graphics cards at the time didn't support subtractive blending. While it's technically possible, there's no easy way to bring back the PSX shadows.

Dynamic shadows is not happening until we get q-gears running though, the graphics engine would need to be pretty much rewritten with that in mind to make it work. And even then every single battle scene would probably have to be remodeled to make it look okay.

General discussion / Re: Black Border Errors
« on: 2014-07-18 00:53:55 »
It's a side effect of the way FF7 handles that kind of effect. It's really a minor thing and would require a bit of an ugly hack to fix so I haven't got around to it.

It doesn't happen in the steam version because the steam version is always rendering the game to a texture before rendering it on screen.

So would you have to write the shaders by hand or is it theoretically possible to procedurally generate them based on the code in the field scripts?  Either way it seems like a lot of work.  Also, if current hardware doesn't support paletted textures how do the originals show up correctly in game.  Just trying to wrap my head around this.

Writing the shaders by hand would be insanity, generating them from the field script or perhaps analyzing the palettes themselves is the only practical way of doing it. Original textures are converted to plain BGRA textures on the fly. That's already kind of slow but acceptable on modern PCs, a 4x resize however would require 16x the amount of CPU power and GPU bandwidth.

The old "timer" uses this mechanism:

Under Windows platforms, Microsoft strongly discourages using the TSC for high-resolution timing for exactly these reasons, providing instead the Windows APIs QueryPerformanceCounter and QueryPerformanceFrequency

Which is exactly what the new timer does.

I've never had a problem with FPS being wonky but DLPB has discovered a strange piece of code that might cause field FPS to be slightly higher than normal and the issue is machine-dependent. I will be looking into it.

Those animations rely on the field script being able to modify the palette in real-time (changing the actual colors in the palette, not just switching between different palettes). Obviously that cannot work with your upscaled images since there is no palette to speak of. In theory it would be possible to create upscaled images that use the original palettes but that would kind-of defeat the point not to mention be difficult to implement and since there's no hardware from this millenium that supports paletted textures it would run incredibly slow even if you could make it work.

I have been thinking long and hard on this one, I figure the best bet would be to somehow analyze the field script to figure out what effect it is trying to accomplish and implement it with a shader. That is unfortunately only slightly more feasible than the above "solution".

Tools / Re: Palmer - Field background editor
« on: 2014-07-15 22:38:37 »
There we go, that should do it.

 - Fixed crash on export for some (broken) field files

Tools / Re: Palmer - Field background editor
« on: 2014-07-15 19:20:57 »
Bah, that one issue has been causing so many problems.. As far as I can tell those files are just broken, using palettes that don't exist. I'll post an updated version as soon as I get around to making one.

Those "numbers" are just scancodes, a complete list can be found here:

Pages: [1] 2 3 ... 48