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 4 5 6 7 ... 48
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".

FF7 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

FF7 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).

Of 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.

I would like to point out that actually replacing the textures is the easy part (in fact it is trivial), the problem is figuring out what to replace and what to replace it with.

How about making the installer to use an external package? It would be better this way, because the installer would work with any newer version without the need of updating the program.

That would be a great solution, if the installer just prompted for the zip file when you launch it I would have no problem with that. Linking to the release thread from the program is also acceptable, direct linking to the download is not.

I get a lot of PMs and I hardly ever answer because most of them are utter crap. Yours was quite rude and not anywhere close to asking for permission.

You do not have permission to redistribute the driver in this manner. I'm not going to ask you to take it down but you really should have asked first.

For the record that crash has absolutely nothing to do with integrated graphics, intel or otherwise. Its a bug in 0.7.11b that was mostly fixed in 0.8b, it won't crash anymore but you can run into graphics corruption issues. Let me just re-state again; it does not matter what graphics card you have, the only thing that matters is the size and number of textures you have loaded since you started the game.

Troubleshooting / Re: FFVIII Wmsetus-Wmset.obj
« on: 2014-04-05 17:44:00 »
FF8 .obj files are usually divided into a number of sections, you should read the first 4 bytes to figure out how many there are. Then each 4 byte value after that is an offset into the file where you will find the start of that section. If you were to extract all the data in between those offsets you will get a bunch of different files, wmset.obj has 48 different sections. Some of those sections contain more data in the same format, section 38 for example holds a bunch of .tim textures for the worldmap itself. Good luck digging through it all! ::)

Graphical / Re: FF8 Triple Triad HD Project
« on: 2014-03-16 03:58:46 »
FF8PC emulates the playstation GPU for most parts of the game. Thats bad news for several reasons but just to name a few it means the game has limited memory available for textures, doesn't use relative UV coordinates and does not readily accept textures in any other size or format than it was designed to. I don't think you'll have much luck, unfortunately.

Is it possible to trigger this overflow by any other (easier) means than the death penalty glitch? I figure if you spend that much time grinding you can have your instakill attack :P

And of course, even if you were to fix that particular check you could still overflow it to 0 and do no damage whatsoever instead.

The old game has movies in TrueMotion2.0 format.
Aalis driver should be able to play this, but I have not tested.
If it does not work, you can install the K-Lite pack 10.3, this works for me.

Can we please stop telling people to install some codec pack? It has never made any difference whatsoever to the drivers ability to play anything and it never will.

Hello everyone!

I have a problem running FF8 with the custom driver (the most updated one of course, 0.8.1b). FF7 works fine with mods, no problems. However, FF8 seems to fail no matter what fix I give to the game.

The error message it gives is "Failed to load custom driver."
It doesn't crash, it just doesn't initialize the game
Note that I tried even without mods, it always gives the same error.
As you can see I deleted the popup thingy so I don't know what to do now.

If you think there is an obvious derp of an error in my part, please tell me what it is.
If the problem still persists, I will post the problem in the troubleshoot board along with my system specs, mods, and everything I did to make the game work.

I tried every possible fix, search through the entire forum, spoke with people, still same error.

That error message means the loader for FF8 wasn't able to load the "ff7_opengl.fgd" file. That should never happen if you've installed it correctly. Make sure virtual store/UAC/antivirus/whatever isn't screwing you over and try again.

Again to Aali:

I just noticed that your last two registry keys may be wrong.
There is for me no key [HKEY_CURRENT_USER\VirtualStore\...]
With me                       [HKEY_CURRENT_USER\SOFTWARE\Classes\VirtualStore\...] is correct.

Thanks, it seems you are correct, I couldn't test it myself since I don't use the utter piece of garbage that is VirtualStore :roll:

To be fair, it is not included in the Steam version.

I don't support the steam version out of the box anyway, it would have to be included in the converter.

This is exactly my problem.
With the original FF7Config 1998 you can not set Aalis driver. With the FF7Config of Aali I get this message (paraphrased): The specified procedure could not be found

That is working as intended. You are supposed to use the original FF7Config to set your other settings, then apply the .reg file to install the driver.

Dear Aali,

You have the file "FF7Config.exe" omitted from your driver 0.8 and instead inserted a .reg file.
Unfortunately, I do not know any other way to determine the value for the registrykeys "DD_GUID" (seems to be 00...) and "Sound_GUID".
With your old (0.7.11) "FF7Config.exe" the self-test does not work anymore.
Do you know a way to determine the values without "FF7Config.exe" or can you create a new "FF7Config.exe"?

What. FF7Config.exe is included in a normal install of FF7.. (I did forget to re-add that step to the install instructions though, that's taken care of now)

I have a HD 6870 with 1GB RAM.
I have also installed FeliX Leonhart's World-map Enhancement (
With the "use_pbo = off" and "compress_textures = on", the game requires at first start about 27 seconds before a picture appears.
On the second start, it is about 15 seconds.
With "compress_textures = off" are required only 5 seconds.
Under what circumstances it makes sense to use the option "compress_textures = on"?

Define "start", worldmap textures aren't loaded until you are actually on the worldmap. If texture compression is indeed slower for you just leave it off, it should be faster in theory and it is a lot faster on my setup but in the end it depends on your graphics driver being able to handle compressed textures efficiently.

Unfortunately due to the way it works right now you probably cannot even delay the issue by making your cache bigger. The specifics of exactly where the cache resides is technically up to your OpenGL implementation but it's safe to assume that it does count towards the 32-bit address space limit. (Which is why setting it any higher than 1GB is regardless a terrible idea)

Pages: 1 [2] 3 4 5 6 7 ... 48