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 ... 48
Cool! Glad to see this is coming along :)

You're such a doof Dan ::) The encoding of that particular file has been flipped up, if you look at the original on github you can tell what's supposed to happen there.

If it wasn't obvious to anyone, I've been 'done' for a while now. I read the odd post in this forum if it catches my eye but thats about it ???

I am most definitely still around and I would not like to see that code being released into the wild nor do I believe there is any license or other information included in that code that would give you the right to do such a thing. The source code has not been released because of potential copyright issues that would require essential parts of the driver to be rewritten. Should I be able to resolve these issues however, the full source code would be released under a suitable open source license. If anyone is interested and feels that they would be able to contribute to the rewriting of said parts, I invite this person to contact me via PM.

Actually the game keeps track of which "directory" it is in and uses this to find the files, name + directory goes into the LGP parser but the directory is only used if there is a conflict. However, with FF7PC being a fairly shoddy port this system is not used in any sort of consistent way. The battle module has its own encoder/decoder for converting PSX filenames into the cryptic 4-letter sequences from the PC version but I guess they couldn't be bothered with that for the magic effects so they were left as-is. At the same time, some modules use the mangled PC names straight up, completely doing away with the PSX names. In short, it is definitely possible to sort out the magic effects into separate directories but it will probably need a bunch of manual work to sort out the odd file where the directory happens to be incorrect.

Either way, the crucial piece of metadata that ties these files together is hardcoded in the .exe, magic effects (which are hardcoded) explicitly load their own models and textures as they execute.

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.

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