76
Support / Re: [FF7] More than 750 sound effects?
« on: 2014-07-04 14:23:31 »
Uhhh nooo.... @.@ there is no edit in the post above you

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.
Morning all.
I knocked up a proof of concept tool for the original FF7Voice project, although I don't think it was my tool they went on to use for their work; it shouldn't be difficult to get something working again, if people are interested.
I only have the 2012 version to hand (I still have the original 1998 CDs - but none of my PCs have optical drives!) so I'd have to get it working on that version first, but I'm fairly sure the differences between the two aren't gigantic, right?
Cheers.
Oh , sorry, I got lazy. Thought this was a ff7 question. On FF8, I agree with Covarr. Although I like that ff8 movies are now outside package in Steam.
So - currently we have a workaround for the achievement crashes - just disable the Steam overlay in settings.
Now unfortunately, the memory allocation causes crashes at a certain point (after the app reaches 1.6 gigs of RAM use) and it's causing everyone to have to save the game and then quit/restart the .exe file every hour or so.
Is there a way to fix the memory issue easily? I hope its not a huge hassle for Omzy.
Only 2 major bugs and one already has a solution. Great work!
Thanks Kaldarasha. I've never done any modeling work. I'm very versatile in Photoshop and illustrator but I've never done 3d. Does Adobe have a program like blender
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.
Hi all,
I just started playing the Steam version of FF8 and the characters and objects look nice and crisp but the backgrounds are so pixelated that it makes me die a little on the inside. When I had that feeling playing FF7, I resized them myself with long-handed photoshop algorithms, but I could conveniently rely on Aali's driver doing the import nice and clean.
However, with FF8, according to Aali (in response to Mcindus' Triple Triad HD project),
My problem is that I'm so obsessive that I can't take no as an answer. I know that if I take the game apart myself binary bit by bit, I can build it again, theoretically, so that it will work however I want it to, given an infinitum of time. My question for those who have the knowledge of game engines, gpu architecture, executables, drivers, etc, what is the path of least resistance to allowing this game to accept larger textures? This may include some reverse engineering, recompiling executables, creating DLL's, etc.
Please use this topic as a place to sound off and throw your ideas around.
My hope is that when I have time on my hands in about a year, this question will be answered, or at least someone can provide me with the right direction to learn the things necessary to complete this task. I really believe it is a step-by-step endeavor, but right now the steps are not clear to me.