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
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:

I thought Aali said this was not possible??  :o looks like you proved him wrong many thanks for this epicness Omzy now let ff8 modding begin :evil:

For the record, and this is something I have already discussed with Omzy in the thread that led up to this project, this kind of hash based identification of textures is something I have experimented with in the past but did not, and still do not, want to support & develop because of the many unknowns and the hackish nature of it. The fact that Omzy has taken it upon himself to do so is great news for everyone involved, including me ::)

If I were to implement modpath/replaceable textures for FF8 the first step would be to rewrite parts of or maybe the entire GPU emulation. Not because it is flawed in any way (although it isn't very efficient) but because then I could start rewriting all the rendering code to use explicit textures instead of just VRAM coordinates.

It would be a massive undertaking. Good luck ::)

PSX textures are always 256x256 and on a real GPU there would be no reduction in performance if you were to access them on 128 pixel boundaries. From your point of view (I am assuming you're getting this from PIX) you will only see which textures need to be constructed to emulate the GPU commands from the game. There is no "good" reason for the duplication you're seeing other than that its necessary to properly emulate the GPU. This is one of the big issues with replacing textures in FF8, field backgrounds are used as if they were 128x256 but when they're uploaded to a texture the next 128x256 pixels from the VRAM will be uploaded with it because that's just how the GPU works.

I have already used such a hash method in the past to debug the driver (so that I can set breakpoints when a particular texture shows up or compare output from the texture conversion process) but it is not workable in real-time.

Textures are usually 256 * 256, either 8- or 16-bit. Add 16 different palettes of 256 32-bit colors each and you've got 70-150kb of data to hash every time the game tries to upload a texture. Now add to the mix the fact that palettes are not static, the game (and especially field files) often writes directly to the palette causing the whole texture to be reloaded (and depending on how the palette is modified you could get a million or so different hashes just for that one texture). In FF7 that is still kind-of manageable, textures aren't reloaded all that often and you can disable these palette writes without completely ruining the game (you'll just make all the field scenes feel static and dead).

off course, FF8 is a lot more liberal with these things. Every time the game touches the emulated VRAM it'll reload some texture, sometimes more than one, this process alone is enough to make the game run slow on a modern machine, I've already had to implement a bunch of checks just to make sure it doesn't try to reload the same textures every single frame. Now, as if that wasn't enough, both palettes and textures are not even guaranteed to be in a consistent form, you'll sometimes get a texture uploaded that just contains random garbage, wasting time and hash space.

Even if such an approach is theoretically possible it would be nothing but hacks upon hacks upon further hacks. It would be a nightmare to support.

In FF7 I have basically rewritten the function that loads .tex files so that it stores the filename in a place where I can retrieve it once the game tries to upload it to a texture.

Since field files are not in .tex format I have rewritten another function that gets called when the game loads field files so that I can construct a meaningful filename and place it where the texture loader will find it. So far no problem.

However, in FF8 there are many many different texture formats each with their own loaders scattered all over the place usually with several levels of indirection (several textures inside multi-part files sometimes inside other multi-part files ???) and so very hard to replace with something that can construct a meaningful filename. Now even if we could tackle this issue these routines are just loading data into the emulated GPU VRAM, there's not even necessarily a 1:1 mapping from file to texture at this point. When drawing a scene, the emulated GPU uses a set of predefined textures which each represent a certain area of the VRAM and a certain palette (using some kind of cache system with 16? or so different textures so they're not each fixed to a certain area but get swapped around) so even if we had useful filenames at this point it would be extremely difficult to map them to these textures. For a while I was experimenting with keeping a map of VRAM areas to filenames and figuring out on the fly which area the game was trying to draw from but this turned out to be completely unfeasible and never really worked for anything but the credits screens.

Pages: [1] 2 3 ... 48