Tonberry: Enhanced v2.04 by JeMaCheHi (http://forums.qhimm.com/index.php?action=profile;u=13631) and mavirick (http://forums.qhimm.com/index.php?action=profile;u=4268)External Texture Support for Final Fantasy VIII*Beta version, please let me know if there is something preventing you from using it(https://googledrive.com/host/0ByMkI_Nb8OmJQ3FEcTkxYkFaUDQ/tonberry.png) (https://googledrive.com/host/0ByMkI_Nb8OmJQ3FEcTkxYkFaUDQ/greenarrow.png) (https://googledrive.com/host/0ByMkI_Nb8OmJQ3FEcTkxYkFaUDQ/FF8_Tonberry.png)

Hello! (I'll borrow Omzy's header, hope you don't mind bro :D )

Broken cache fixed!I've been working Mavirick and I have been working on an enhanced version of Tonberry, as many of you would know from its original thread. You should check Omzy's original post (http://forums.qhimm.com/index.php?topic=15291.msg213836#msg213836) to learn about its functioning.

What's new?:

2.04

Persistent textures - modders now have the ability to designate textures as "persistent," meaning they will never be removed from the cache. This feature should be used primarily for the core textures, such as those replaced by SeeDReborn.

To mark a persistent texture, simply precede the name of the texture with a bang/exclamation mark (!) in the relevant hashmap or objmap .csv. For example:

!sysfld00_13,8637763346649579509

Please be aware that filling the cache with persistent textures will lock it in place and all subsequent textures will fail to be replaced, so use this feature with discretion.

Significant performance improvements - although dampened in part by the increased complexity of the persistent textures, Tonberry should be running faster than ever due to some major cache optimizations and an improvement to the way we handle the core (SeeDReborn) textures.

No hard limits on cache_size - the cache size no longer has a hard minimum size of 100. You can now set it to 0 to disable the cache and texture replacements altogether, although Tonberry will still be touching each in-game texture and checking for replacements (that never exist). This feature should be entirely ignored by average players but could be helpful for modders. Note that you can also set your cache_size too high and cause memory overflow exceptions! If you do not have LargeAddressAware enabled for your FF8 executable, your cache_size should be no larger than 250.

Actually disabled textures - before, textures that were disabled with a star/asterisk (*) were not handled any differently; Tonberry would simply fail to load the replacement texture when it looked for a .png file beginning with the asterisk character. Now these textures are actually excluded from the internal hashmap, which should yield a slight increase in performance and keep these textures out of your \tonberry\debug\noreplace folder. If for some reason you want these textures to show up in your debug\noreplace folder, simply change the asterisk to any other character--just so long as the texture name in the .csv does not match any file in your \textures folder.

2.03:

2.02 broke collision resolution--textures from the collisions.csv hashmap were not properly stored in the cache, which caused bad replacements and glitching textures especially on loading screens and in menus; this issue is resolved

2.02:

We fixed the little issue with debug folders. Now unsupported textures will be on "unsupported" folder.

Even more code optimizations!! We love code optimizations ;)

2.01:

Caching system fixed (now it really works, I swear it!)

More code optimizations (as usual ;) )

2.0:

Completely redone texture caching system

New option added to prefs.txt(cache_size) to set the maximum cache size

New option added to prefs.txt(texture_dir) to change textures directory

Lots of code optimizations

1.61:

Better objmap organization

Source code tweaks. Hashcode searching should go a little faster now

New option added to prefs.txt(debug_mode) and comments

1.6:

Better hashmap organization

Some compilation tweaks which should make Tonberry run smoother

For now there's no much done, actually I didn't want to release anything until I had something more, but Mcindus convinced me to do it :-[ . Due to recent mods have been more and more numerous, I thought this simple update will make our lifes easier when it comes to modify your hash1map.csv file.Now we have redone the whole caching of textures, this is gonna run with no sweat. Most of you will be able to run animated textures smoothly. We've added the possibility to change the path where the "textures" folder is stored, so you can place it on an SSD drive for even more speed. You can also tweak the cache size to fit your needs. Just refer to the prefs.txt file on "tonberry" folder for more info. Next step: new hashing algorithm, and potentially zero collisions.

We now have two new set of folders: { [your FF8 directory]/tonberry/hashmap and [your FF8 directory]/tonberry/hashmap/disabled }and { [your FF8 directory]/tonberry/objmap and [your FF8 directory]/tonberry/objmap/disabled }

In that "hashmap" folder you can put a set of *.csv files, with hashes that previously was at hash1map.csv

In that "objmap" folder you can put a set of *.csv file, with the previously set at objmap.csv

You should create a different .csv file for each mod hashes. You can name them as you like, but make sure they have *.csv extesion

Which advantages provide us this new directory system?

We now can release mods directly with its .csv file, just ready for copy-paste and make it work. Plug and play!

We can obviously split the "hash1map.csv" file into smaller ones.

We won't have to deal with the old massive "hash1map.csv" file, we won't have to look for duplicated hashes... etc.

We can disable certain mods by just by moving its csv file to the "disabled" folder.

**EDIT 2/20/2015**The hashmaps to SeeD Reborn and Tripod have been updated! These updates should fix any current missing textures issue!Spanish and French SeeD Reborn versions added!Spanish and German Tripod versions added!*****************

To-do list:

Improving the hashing algorithm to be faster

Reducing collisions to zero (or nearly zero) with a new hashing algorithm

Redesigning the texture caching system to greatly speedup the whole system

Take a new approach in handling native game's textures so we can separately use 128x128 texture objects

To provide a better debug system, instead dumping the textures by random numbers.

Known issues:

The game crashes when using Squall's limit breaks around some enemies (especially Tonberry in the Centra Ruins) while both RebirthFlame and LunarCry are enabled. Fixed...? I have not been able to replicate this crash since using 2.04. While I never isolated the cause of the crash in earlier versions, I believe 2.04 to have fixed the problem. If this is not the case, please let me know.

If the cache has been full and you've been playing for some time without seeing any text (dialog, menus, etc), the cache will dispose of the high resolution font textures and you will start to see text with mixed high-res/low-res characters. Fixed! The persistent textures feature should allow these textures to be kept in the cache indefinitely (see "What's new?").

Some users are experiencing random crashes when using Tonberry with Project Eden. If you are having this or any other issue please post here with details so I can look into it. Until more is known about the crash, my best advice would be to save frequently. Fixed! This exception was caused by memory overflow errors; make sure your cache_size in \tonberry\prefs.txt is 250 or less.

The overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration. (http://forums.qhimm.com/index.php?topic=15988.0;topicseen)

If someone is having trouble with it, please post it here and we will try to resolve it.

Thanks to Mcindus for helping me with the testing and...Thanks Mavirick for your interest and helping with the new hashing algorithm joining the development!Thank you Omzy for making original Tonberry, changing FF8 graphical modding forever

*For future modders who are hashing textures, please keep or upload a copy of the debug output textures themselves. If the hash algorithms change, this hashing will have to be re-done and it will be much easier if we have all of the original dumps.*

I'm so glad you posted this! I know that everyone really wants a new release with a better hashing system, but until that work is completed, we really need to get people using this!Also - I can't imagine not using the new folder hierarchy. It makes the hashing and modding process so much cleaner and stops us from having to keep re-writing over our old hash1map.csv file - especially if we are heavily modding the game and have custom hashmaps.

In honor of this release, I am going to post the hashmap files for all of the mods currently available. I will be updating this list as I go!

TURN OFF THE STEAM OVERLAY TO PREVENT CRASHES!!

Hashmaps:Put these in (/steamapps/common/FINAL FANTASY VIII/tonberry/hashmap)

*For future modders who are hashing textures, please keep or upload a copy of the debug output textures themselves. If the hash algorithms change, this hashing will have to be re-done and it will be much easier if we have all of the original dumps.*

Nice to see things moving! For those of us who have Tonberry and other mods installed, should we just uninstall them and reinstall this?

And speaking of csv files, it should be relatively easy to add the correct codes and make a new file?

You doesn't have to uninstall any mod. Just overwrite the old Tonberry installation. Then split your current hash1map.csv into several, smaller ones and put them in the "hashmap" folder. Or you can also download Mcindus' .csv files:

Do you have to install Tonberry v1.5 first to get the collisions and hash2map and objmap to work properly? I'm just wondering if this is stand-alone, or dependent on the last release.

I didn't do anything with the hashing system. We still have all the same hashes. That means that you can use Omzy's ones (maybe I should post them in the first post, thanks Mcindus). But you don't have to install Tonberry 1.5 first. Just install Tonberry 1.6 and then copy the collisions, hash2map and objmap.

I didn't do anything with the hashing system. We still have all the same hashes. That means that you can use Omzy's ones (maybe I should post them in the first post, thanks Mcindus). But you don't have to install Tonberry 1.5 first. Just install Tonberry 1.6 and then copy the collisions, hash2map and objmap.

For some reason, the hashcodes that have special exceptions seem to be messing with how Tonberry works with this new file structure. I rearranged the hashes for SeeD Reborn and Tripod and I think these should work better and cause less glitches in missing textures. Check my post with the links for updates!

For some reason, the hashcodes that have special exceptions seem to be messing with how Tonberry works with this new file structure. I rearranged the hashes for SeeD Reborn and Tripod and I think these should work better and cause less glitches in missing textures. Check my post with the links for updates!

Hahaha, today is 19th, not 13 bro. Tell me what hashcodes are giving you trouble and we'll se what can we do.

And about hashing system, for now I've tried three more algorithms, everyone of them being almost equally inefficient as Omzy's original one, despite of being clearly faster (I even applied loop unrolling techniques, redesigned the algorithm to fuse several looping functions...). I'm starting to think that the real bottleneck is the UnlockRect function. That function is the one that actually replaces the original game's texture with our modified one. I'm running out of time, I have to start a new work and won't have time for this for a while.

If anyone can take a peek to the function (look at Omzy's thread, there's the src) and think with me, just PM me or post it here and we'll talk about it more carefully.

For some reason, the hashcodes that have special exceptions seem to be messing with how Tonberry works with this new file structure. I rearranged the hashes for SeeD Reborn and Tripod and I think these should work better and cause less glitches in missing textures. Check my post with the links for updates!

thank you mcindus, card problem gone but after tonberry 1.6 now I've this sort of problem

That seems to be some kind of collision between textures... I need to work on that too. Do me a favor please: put all your hashes in a single file ( into the hashmap folder, but paste them in a single file, call it as you wish ), and then move all the other files to the "disabled" folder. Test if the problem still remains and report it here.

That seems to be some kind of collision between textures... I need to work on that too. Do me a favor please: put all your hashes in a single file ( into the hashmap folder, but paste them in a single file, call it as you wish ), and then move all the other files to the "disabled" folder. Test if the problem still remains and report it here.

in addition to collision.csv, objfile.csv and hash2map.csv coming from tonberry hashmap v1.3, I'vehorizonPackseedRebornTripodProjectEden

Do you want me to merge these 4 files in a single one? if so in what order?

Anyone adding hashes to their own files should check if the hashcode has been used already (which would cause a collision). The way I do this is compile all of the mods hashes into one "masterhashmap.csv" file that I only use as a test file. I then search my code against the other codes in the master hash file before making them official.

This might seem tedious, and it is. This is just one of the reasons why we need a new hashing algorithm so badly. I have to go back and do this to a few of my own files, as I had forgotten to do so about halfway through my summons and horizonpack mods.

Tripod, SeeD Reborn etc. seem to work now with Tonberry Enhanced 1.6 and your new hashmaps! No more 2/3 backgounds or anything.

I put all of them into the "C:\Final Fantasy VIII\tonberry\hashmap" folder and the old "collisions.csv", "hash1map.csv", "hash2map.csv" and "objmap.csv" files from "Hashmap 1.3", but replaced the "objmap.csv" with the one needed for the Character models from FatedCourage: http://forums.qhimm.com/index.php?topic=15668.msg223218#msg223218 and your GF codes with the upscaled GF textures from rufoos: http://forums.qhimm.com/index.php?topic=15668.msg223269#msg223269

I pasted the GF hashcodes into the "objmap.csv", is that right? Because there are also the character codes.

Tripod, SeeD Reborn etc. seem to work now with Tonberry Enhanced 1.6 and your new hashmaps! No more 2/3 backgounds or anything.

I put all of them into the "C:\Final Fantasy VIII\tonberry\hashmap" folder and the old "collisions.csv", "hash1map.csv", "hash2map.csv" and "objmap.csv" files from "Hashmap 1.3", but replaced the "objmap.csv" with the one needed for the Character models from FatedCourage: http://forums.qhimm.com/index.php?topic=15668.msg223218#msg223218 and your GF codes with the upscaled GF textures from rufoos: http://forums.qhimm.com/index.php?topic=15668.msg223269#msg223269

I pasted the GF hashcodes into the "objmap.csv", is that right? Because there are also the character codes.

I'm glad everything is working for you!

No the GF codes are their own thing - actually... let me release that hashmap right here. It's for a future mod, but the codes are the same. New update for summons hashmaps in my main hashmap post!

I can't find the new codes for the GF or do you mean the post where you have initially posted them? :D Thanks for your effort, I'm a bit confused how to even find them in any way or so.

BTW, the "Tripod_GR_hm.csv" should be named "Tripod_DE_hm.csv". DE should be the international abbreviation for German. Like "ES" is for Spanish (from Espaniol). DE comes from "Deutsch".

Oh and can it be, that Tripod doesn't effect the in-game menu cards? I mean by pressing Triangle (Y for Xbox) and go to "Cards"?

Thanks! I fixed it to DE in google drive. The in-game cards are actually part of SeeD Reborn. Could you send me the debug information for those menu pages when/if you get a chance? Also - I got caught up in updating my other mod pages and forgot to post the GF's - they are there now! Enjoy!

Anyone adding hashes to their own files should check if the hashcode has been used already (which would cause a collision). The way I do this is compile all of the mods hashes into one "masterhashmap.csv" file that I only use as a test file. I then search my code against the other codes in the master hash file before making them official.

This might seem tedious, and it is. This is just one of the reasons why we need a new hashing algorithm so badly. I have to go back and do this to a few of my own files, as I had forgotten to do so about halfway through my summons and horizonpack mods.

I'm still working on the hashing algorithm, plus on the performance enhancement. Just need more time, it's being hard to combine this project with my duties.

Hello JeMaHeChi,Could you tell me what do you want to improve in the hashing algorithm? The main problem is the memory consumption in worldmap exploration. I think the problem is that there are a lot of tiny textures that are loaded from the same big texture. So each time a new portion of the worldmap appears on screen , the big texture is loaded. So the hashing algorithm is run several times when the camera moves. This is not the case with field textures or character textures because they are always on camera.

About the collisions. It is only an assumption but i think sometimes 2 images have the same hashcodes because they are almost the same texture, only slightely blurred ( for depth of field animation). So it may happen that the comparison between pixels give the same results for a blurred texture:

Imagine a white texture with a black circle in the center. Even if i blur the texture the center of the black circle would still be darker than the borders. So if i run the hashing algorithm it would give the same result. This error won't happen if the compared pixels are close enough.

You necessarily need to run a second algorithm that reads intermediate pixels . That's the reason of hash2map algorithm.

Could you send me the debug information for those menu pages when/if you get a chance?

Thanks Mcindus! If you tell how to do that, it won't be a problem for me. But if we still talking about the "in-menu" cards, it happens with the English version (I think also with any other, haven't tried). I mean they don't have the nice frames around the images. Seems to be the vanilla ones only. But playing a card game is okay, so all frames are new/nice etc. =)

For anyone who has problems, this should be the *.csv files package you need for tonberry 1.6 (if I'm not wrong): http://www34.zippyshare.com/v/YjKm3zpD/file.htmlBut replace them as soon as Mcindus or FatedCourage update anything.

Could you tell me what do you want to improve in the hashing algorithm? The main problem is the memory consumption in worldmap exploration. I think the problem is that there are a lot of tiny textures that are loaded from the same big texture. So each time a new portion of the worldmap appears on screen , the big texture is loaded. So the hashing algorithm is run several times when the camera moves. This is not the case with field textures or character textures because they are always on camera.

About the collisions. It is only an assumption but i think sometimes 2 images have the same hashcodes because they are almost the same texture, only slightely blurred ( for depth of field animation). So it may happen that the comparison between pixels give the same results for a blurred texture:

Imagine a white texture with a black circle in the center. Even if i blur the texture the center of the black circle would still be darker than the borders. So if i run the hashing algorithm it would give the same result. This error won't happen if the compared pixels are close enough.

You necessarily need to run a second algorithm that reads intermediate pixels . That's the reason of hash2map algorithm.

You hit the nail right on the head with this post. When I built Tonberry, I did not take any time to consider these inefficiencies regarding animations/world map. I also did not spend much time thinking about the best way to select pixels for the hashing algorithms and my lazy solution was to just create the hash2map algorithm by hand-selecting pixels I thought would help distinguish. The second algorithm is only run when the first one fails (has a collision), of course. There must be a better way to do this, or at least a better way to select pixels--I would be rather surprised if what I came up with so quickly was really the best possible solution.

Edit: A potentially 'smarter' solution would be to take every texture in memory dumps (as complete a collection of unique textures as one can amass through an entire complete playthrough speedrun) and run algorithms on them to build a histogram of all of the differences between pixels. This approach could yield the perfect minimal set of pixels to check that would guarantee a collision-free set of codes. The computation and knowledge required to do this would be moderate to advanced, I think, but not beyond the realm of these forums. The eventual technique could also be documented so that it could be extended to FF7 and FF9.

Hello JeMaHeChi,Could you tell me what do you want to improve in the hashing algorithm? The main problem is the memory consumption in worldmap exploration. I think the problem is that there are a lot of tiny textures that are loaded from the same big texture. So each time a new portion of the worldmap appears on screen , the big texture is loaded. So the hashing algorithm is run several times when the camera moves. This is not the case with field textures or character textures because they are always on camera.

About the collisions. It is only an assumption but i think sometimes 2 images have the same hashcodes because they are almost the same texture, only slightely blurred ( for depth of field animation). So it may happen that the comparison between pixels give the same results for a blurred texture:

Imagine a white texture with a black circle in the center. Even if i blur the texture the center of the black circle would still be darker than the borders. So if i run the hashing algorithm it would give the same result. This error won't happen if the compared pixels are close enough.

You necessarily need to run a second algorithm that reads intermediate pixels . That's the reason of hash2map algorithm.

The main problem about the hashing algorithm is that it doesn't provide enough "resolution" on the hashes. I mean: it parses some pixels, makes some operations with them, and then it produces the hashcode. The problem is that in some cases, the pixels it analyse are almost the same, but the textures are different ones. That's the case of the collisions, so Omzy made a new Hash_Algorithm which parsed a completely different set of pixels. A better solution would be to make a new one with a higher resolution, parsing more pixels, but this would mean to increase the computation charge on a system which is already inefficient.

On the other hand, we have a huge bottleneck somewhere and I can't identify it. I suspect the texture cache is a big one, and I'm currently working on this, but didn't achieve much on this.

Another solution (for the whole system) would be to take a multithreaded approach, but since FF8 can't use multithread, don't think that is a really good solution...

Currently the hash algorithm checks a pixel's color against the next pixel in the series and records a binary value for whether the next color is a higher RGB value or not. This eventual binary string of pixel comparisons is converted to a decimal number and is the final hash code. There is no rule anywhere that says this is how the hash code has to be built.

Some food for thought on the matter (from my gf who is into image processing):

Quote

Method: Find 100 or so pixel locations that generate a unique hashcode for ~10,000 images.

Perform transforms on images, then compare transforms to place images into subsets. Repeat until there are maybe no more than 100 images per subset...I don't know, might need more or less, have to find out when you do it. OpenCV is probably the best codebase to use for that. References: http://reference.wolfram.com/language/guide/MathematicalMorphology.htmlhttp://www.seas.upenn.edu/~bensapp/opencvdocs/ref/opencvref_cv.htm

Extract from each subset the set of pixels that differentiate each image from another. Then compare those sets of pixels from each other subset and extract the ones that are consistent in a large percentage of the subsets

boom, you have your essential pixels for the hash code

So you could separate images based on the overall average color, for example, and make sure you have equal sized subsets. Then you chart the pixels in each subset that are different amongst most images in the set and those become your pixels.

An alternative approach I thought of would be to take the entire database, for each pixel in each image, record the color of the pixel so you can build a frequency chart for each pixel (histogram). You could identify which pixels have the biggest spread (flattest bell curve) and then use those pixels. This would be easy to write an algorithm for and may yield good results. If there were still collisions, a second step could be used.

Anyone adding hashes to their own files should check if the hashcode has been used already (which would cause a collision). The way I do this is compile all of the mods hashes into one "masterhashmap.csv" file that I only use as a test file. I then search my code against the other codes in the master hash file before making them official.

This might seem tedious, and it is. This is just one of the reasons why we need a new hashing algorithm so badly. I have to go back and do this to a few of my own files, as I had forgotten to do so about halfway through my summons and horizonpack mods.

I threw together a python script to find hash collisions in the .csv hashmaps. It should be placed inside \FINAL FANTASY VIII\tonberry\ and run from the cmd line.

optional arguments: -h, --help show this help message and exit --hash n [n ...] look for each hash n in the .csv files

If no hash is given then check_collisions.py will search only for collisionsin the .csv filescheck_collisions.py will ignore the collisions.csv and any .csv's in \hashmap\disabled. If no argument is given it looks for existing collisions, otherwise it will look for whatever hashes you provide it (separated by spaces).

Here's what I get when I run it with the current version of Mcindus' mod .csv's (excluding the G.F. Summons hashmap) and FatedCourage's character hashmaps:

Currently the hash algorithm checks a pixel's color against the next pixel in the series and records a binary value for whether the next color is a higher RGB value or not. This eventual binary string of pixel comparisons is converted to a decimal number and is the final hash code. There is no rule anywhere that says this is how the hash code has to be built.

Some food for thought on the matter (from my gf who is into image processing):So you could separate images based on the overall average color, for example, and make sure you have equal sized subsets. Then you chart the pixels in each subset that are different amongst most images in the set and those become your pixels.

An alternative approach I thought of would be to take the entire database, for each pixel in each image, record the color of the pixel so you can build a frequency chart for each pixel (histogram). You could identify which pixels have the biggest spread (flattest bell curve) and then use those pixels. This would be easy to write an algorithm for and may yield good results. If there were still collisions, a second step could be used.

omzy could u pls point me where is located the hashing algorithm in tonberry src files?

I only wrote code in a handful of files. For the D3D9CallbackSC2 I wrote d3d9Callback.cpp/h and GlobalContext.cpp/h. ExtraCode was just unused code. For the D3D9Interceptor, I wrote d3d9Wrapper.cpp/h, Globals.cpp/h. Most all that should be needed to be modified would be in GlobalContext.cpp, I think. There you will find the hash algorithms and the logic for replacing images. It did take me a long time to understand how the directx code works, but if someone simply wants to change the way hashing works they shouldn't need to know that anyways. I think you have a good idea for bundling hash files with their mods--that would make things easier to work with and to update. The biggest thing that is needed, however, is to write new smarter hash algorithms that don't suffer from collisions. This may fix many problems and if more research is done, may decrease problems with animation lag. To compile the code you'll need Microsoft Visual Studio C++ 2010 Express (which is free). I believe you can just open the vcxproj file and then build the DLL. You might have to mess with some configuration, but hopefully it is already configured with the libraries and paths. I remember it being a pain in the ass to do the setup but you might not have to do all that since I sent out the vcxproj file.

You may need to modify some path variables in build config to match your local directories.

Thanks Mcindus! If you tell how to do that, it won't be a problem for me. But if we still talking about the "in-menu" cards, it happens with the English version (I think also with any other, haven't tried). I mean they don't have the nice frames around the images. Seems to be the vanilla ones only. But playing a card game is okay, so all frames are new/nice etc. =)

For anyone who has problems, this should be the *.csv files package you need for tonberry 1.6 (if I'm not wrong): http://www34.zippyshare.com/v/YjKm3zpD/file.htmlBut replace them as soon as Mcindus or FatedCourage update anything.

Just a few corrections... you actually don't need the hash1map.csv file if you're using the character hashmaps. This is probably causing some collisions. I deleted my hash1map.csv file because all of the hashcodes are already in the hashmap folder if you use the codes we've provided in the .csv'sProjectEden hashcodes are Omzy's - I just made a separate file for them. ;)Also - DO NOT USE more than one language pack.. ONLY use the pack that is for your language - otherwise, there will be excess collisions.

Thanks for the info, was a bit confused with all those files, so just used them all or as given in descriptions, like from FatedCourage's package.I used the "from ..." to show from who to get the file, if you doesn't want to use the Zippyshare upload.

Until the mythical hashing algorithm is found, why not just allow modders to add their own entries to hash2map.csv as well? It would be trivial to separate the csv's in \hashmap\ by suffix, let's say _hm and _hm2, and everyone has access to both hashing algorithms, right? So just include both hashes for every image you modify, build collisions.csv on the fly, and there won't even be problems with future collisions (unless of course both algorithms produce collisions on the same files).

Honestly, I'm not convinced that we will be able to find a perfect hashing algorithm without sacrificing efficiency, there's just too many super-similar textures in menus, loading screens, etc. Certainly we can find the set of pixels with the greatest variance throughout the entire dataset of images, but even then a second round of hashing will probably be necessary for at least a few images. As long as we can keep the quickly-reloaded images (like the worldmap textures, apparently) in their own bucket we shouldn't have too much of a problem. Or am I missing something?

The new caching system that we've just released with Tonberry 2.0 is an absolutely massive improvement. The old version of the cache... more often than not, it wasn't much of a cache at all.

This new setup should allow those of you with RAM to spare to load most (if not all) of the modded textures into memory, from which they can be accessed and loaded into the game seamlessly and without any noticeable lag. Make sure you check out the new options in prefs.txt to take full advantage of this feature!

I am getting really close to completing my new hashing algorithm, which will allow modders access to the full expanse of in-game textures and prevent all the collision-related glitches we've been seeing (especially with character/enemy textures). I am happy to share that my algorithm has reduced the number of possible collisions amongst all textures in the game from >50% to, at my last measure, an all-but-negligible 2.59% ;D

We would love to get players using this new version as soon as possible so that we can hear your feedback--it's what keeps us going! Also, I am looking for players who are willing to help me collect a more robust texture set to speed up the upcoming transition from the original Tonberry hash algorithm to my new and improved version. If you're interested, PM me for details.

the 1.61 was very cool and the 2.0 looks like very promising, anyway it seems like there some issue i just replace dll from 1.61 to 2.0 and now world texture map is no more apply on HD, and some precalc scene is not here too.

I've been using Tonberry 2.0. It seems that now my character textures seem to blink in and out(new to old). I've debuged and the codes are the same that I have and I've messed with the prefs.txt to see if it would help, but doesn't. Not exactly sure what is causing this. It also kind of messes with SeeD Reborn on my end as well. But things are considerably faster, though.

the 1.61 was very cool and the 2.0 looks like very promising, anyway it seems like there some issue i just replace dll from 1.61 to 2.0 and now world texture map is no more apply on HD, and some precalc scene is not here too.

I've been using Tonberry 2.0. It seems that now my character textures seem to blink in and out(new to old). I've debuged and the codes are the same that I have and I've messed with the prefs.txt to see if it would help, but doesn't. Not exactly sure what is causing this. It also kind of messes with SeeD Reborn on my end as well. But things are considerably faster, though.

Thank you guys for your feedback. As commented on the main post, there will be some issues with SeeD Reborn HD textures and some other ones. This is an inherent problem to Omzy's algorithm and we're working on a quick workaround until we fully get the new hashing. The main problem is that Omzy used the texturenames for caching and all, but we changed it and now we index our cache elements by their hashcode, which is way faster. This obviously gives us some problems (I fixed some of them, like most SeeD Reborn collisions, though not all of 'em)

This is why we don't deleted the previous versions: If you're having so much glitches that the game became unplayable, just switch to 1.61. But, if you're a modder and want to start working on animations, you'll appreciate this speedup.

I'm thinking about designing a log system so yo guys can send me logs and we can figure out what exactly is crashing here... As Mav said, now I'm gettin busier and will have to work on this with less intensity :)

From here, when you have a crash with some texture (flashing, not appearing, being replaced with an incorrect one...) please try to post which texture is giving you the problem, and the cache_size you're using.

Sorry for any inconvenience people, we missed a little fact which had a big impact on the final software ^^Mav will work on it and I'll join him probably on the weekend, you'd better use 1.61 in the meantime. Thanks for your feedback as always, we wouldn't have detected the bug without it ;)

I write screenshot support for tonberry mod.If you press the print screen button in the game directory "sсreenshot" folder appears with screenshot of the game.Work only in window game mode. :(DOWNLOAD (https://yadi.sk/d/pS4EDrprfFL5z)Installation:Owerwrite d3d9.dll with my files in game folder.(After installing tonberry)

And...(http://i60.fastpic.ru/thumb/2015/0314/08/a49e55ff1d909f8b7d1173bf50199708.jpeg) (http://fastpic.ru/view/60/2015/0314/a49e55ff1d909f8b7d1173bf50199708.jpg.html)(http://i60.fastpic.ru/thumb/2015/0314/59/9a604cef4e99a048ed1894e041935359.jpeg) (http://fastpic.ru/view/60/2015/0314/9a604cef4e99a048ed1894e041935359.png.html)(http://i64.fastpic.ru/thumb/2015/0314/b4/a0b6a161ac48954b4d6519d88f3c78b4.jpeg) (http://fastpic.ru/view/64/2015/0314/a0b6a161ac48954b4d6519d88f3c78b4.jpg.html)With tonberry can not pass episode in space. This is very big BUG.(No spacesuit in the picture)

SweetFX created a Steam Overlay 'hack' that enables it to be used simultaneously with the Steam Overlay... maybe one day we can figure out how this can be done with Tonberry. Until then, sorry you can't broadcast!

2.0.1. is still glitchy and crashes with the Steam overlay. Works fine without it.

The Steam Overlay is kind of important to me since I need it in order to broadcast the game.

Sorry about that Devina, but for now Steam Overlay is not a priority. Tonberry has never worked with it, and won't do for now since we're focused on more critical features like smoothness, eliminating collisions and remake the hashing algorithm. However, thanks for pointing it out, I'll put it on the "known issues" section so everyone know it before downloading.

To everyone else, we still want your comments, opinions and questions! :)

@[email protected] it seems the debug folder structure was broken by this latest release. Everything is working fine, but when debug_mode=yes the replaced textures that are already on the cache will end up in the tonberry\debug\ directory instead of tonberry\debug\replaced\

It was a simple fix but, again, we'll have to wait until JeMa can get my code and upload a new version.

If you are playing with debug_mode=no then this does not apply to you.

This issue has been resolved. Please use version 2.02 for the best Tonberry experience yet.

@[email protected] it seems the debug folder structure was broken by this latest release. Everything is working fine, but when debug_mode=yes the replaced textures that are already on the cache will end up in the tonberry\debug\ directory instead of tonberry\debug\replaced\

It was a simple fix but, again, we'll have to wait until JeMa can get my code and upload a new version.

If you are playing with debug_mode=no then this does not apply to you.

I think this was still happening with the 2.0 version when I tried it. Just didn't bring it up because I thought it might've been a normal thing. :P

Why don't you use a Github or svn to publish your code, maybe we could help ;) ?

We started using a Github but the trouble is a) it's only the files we've modified, the whole D3D9Callback project is large and complicated and the compiler settings are a huge pain and b) JeMa owns this thread so I can't modify the first post. I could compile and upload a new D3D9Callback.dll for you guys but that throws a wrench in our whole version scheme, and if people have problems or feedback we don't know which version they're using... I guess I could upload a temporary fix and then remove it whenever JeMa can modify the first post...

Good news folks - the new hash algorithm should may help fix the Steam Overlay issue.

The problem is that the current hashing algorithm detects matches in some of the overlay textures. If you have "debug_mode=yes" and try to open the overlay, you'll notice some Steam Overlay images end up in your \debug\replaced\ folder. I think this is what causes the ensuing crash.

My new algorithm will avoid these matches, so could help avoid the crash. This will be something I keep in mind as I work towards a release of the new hashing method.

Erm... all 2.02 changed was the way we saved images to the debug folder. It shouldn't have touched image caching or replacement.

This looks like a classic hash collision. Are you sure it wasn't happening in earlier versions, or in 2.01?

Never happened on earlier versions(1.61 and back). Those places were always more pixelated, though. I use this spot quite frequently to test textures while gathering codes. It could be something on my end. Never know, really. I only took a screenshot. But what's really happening near the fountain is that it's switching between multiple textures where there is suppose to be animation for the fountain.

Never happened on earlier versions(1.61 and back). Those places were always more pixelated, though. I use this spot quite frequently to test textures while gathering codes. It could be something on my end. Never know, really. I only took a screenshot. But what's really happening near the fountain is that it's switching between multiple textures where there is suppose to be animation for the fountain.

Never happened on earlier versions(1.61 and back). Those places were always more pixelated, though. I use this spot quite frequently to test textures while gathering codes. It could be something on my end. Never know, really. I only took a screenshot. But what's really happening near the fountain is that it's switching between multiple textures where there is suppose to be animation for the fountain.

If it used to be pixelated there, this might be a good omen

Yep. Looks to me like the background textures are working in an area where they weren't previously, but you're getting collisions on the fountain texture and the collisions map does not or cannot resolve it. Problems like these won't be fixed until the new hash algorithm is complete.

Now... As for 2.02. It seems I've ran into this problem. Surprisingly, this happened in the 2.0 version as well.(http://i.imgur.com/o7gYdYZ.jpg)It doesn't appear to happen in the 2.01 version, though.

That's a classic collision FatedCourage. If you say it worked on 2.01 and it doesn't on 2.02, there's no other explanation. All I changed on 2.02 was the naming for the debug folder and made an enumerated type for the type of mached hash. Nothing to do with that. Also, I've found out that some collisions will happen 100% of the time, and some others are more probabilistic since they depends on where are they placed on memory. Anyway, you all will have to wait until we finish the new hashing to see most collisions solved :)

That's a classic collision FatedCourage. If you say it worked on 2.01 and it doesn't on 2.02, there's no other explanation. All I changed on 2.02 was the naming for the debug folder and made an enumerated type for the type of mached hash. Nothing to do with that. Also, I've found out that some collisions will happen 100% of the time, and some others are more probabilistic since they depends on where are they placed on memory. Anyway, you all will have to wait until we finish the new hashing to see most collisions solved :)

I have no problem with this. Didn't want to gloss over anything like I did last time. And if textures that didn't work before are starting to work now, then that's a good sign. It just motivates me more to continue collecting codes/bitmaps for this. :D

I have no problem with this. Didn't want to gloss over anything like I did last time. And if textures that didn't work before are starting to work now, then that's a good sign. It just motivates me more to continue collecting codes/bitmaps for this. :D

Yeah, it's a good sign indeed :D. Don't forget to keep all the debug textures and sending them to Mavirick or me!

Actually, now that I remember, if I detected that there was no match or an unresolvable collision, I ignored it and let d3d keep the original texture there. So if there are now colliding textures in previously pixelated spots, it might mean that 'ignore' was turned off and it is just placing the last thing in memory there. Again, sorry if I overlook stuff, it has been a while since I looked at the code.

Mavirick, as a continuation from what I have been PMing you and Mcindus, how do I use the Debug Mode in Tonberry so I can find what is randomly crashing my games? I feel like a proper write up of the Debug Mode should be included in the original post.

Actually, now that I remember, if I detected that there was no match or an unresolvable collision, I ignored it and let d3d keep the original texture there. So if there are now colliding textures in previously pixelated spots, it might mean that 'ignore' was turned off and it is just placing the last thing in memory there. Again, sorry if I overlook stuff, it has been a while since I looked at the code.

As far as I know this wasn't changed, but my work was really focused on the cache. I know the logic for replacing textures had to be changed to some degree but Jema is dealing with some personal business that is keeping him away; I will take a look when I get the chance.

Mavirick, as a continuation from what I have been PMing you and Mcindus, how do I use the Debug Mode in Tonberry so I can find what is randomly crashing my games? I feel like a proper write up of the Debug Mode should be included in the original post.

I don't own the thread so I can't modify the first post, but to turn debug mode on, simply set debug_mode=yes in FFVIII\tonberry\prefs.txt. All debug folders then need to have the zero removed, so \tonberry\debug0 becomes \tonberry\debug, \tonberry\debug\replaced0 becomes \tonberry\debug\replaced, etc.

Edit: You guys were right--it looks like our new cache broke collision resolution. I believe I've found the problem and I've made a quick fix but it will need more testing before I release it. If you are experiencing a crash or texture problem that you can easily replicate and would like to help, send me a PM and I can provide the new d3d9Callback.dll for you to try. Otherwise hold tight and I'll get it released as soon as I can.

Edit: You guys were right--it looks like our new cache broke collision resolution. I believe I've found the problem and I've made a quick fix but it will need more testing before I release it. If you are experiencing a crash or texture problem that you can easily replicate and would like to help, send me a PM and I can provide the new d3d9Callback.dll for you to try. Otherwise hold tight and I'll get it released as soon as I can.

Hi sorry total modding newbie here,

my game keeps crashing right as you reach the dollet solder and face the anacondor. Ive pretty much eliminated all my mods but tonberry. is this something that d3d9Callback.dll would fix once the details are worked out?

my game keeps crashing right as you reach the dollet solder and face the anacondor. Ive pretty much eliminated all my mods but tonberry. is this something that d3d9Callback.dll would fix once the details are worked out?

It's hard to say--I certainly hope so. I haven't heard of anyone else having this glitch and this next fix should restore Tonberry to 1.61 efficacy, so it's very possible that you're experiencing a collision issue that will be resolved by the new version. The other possibility is that you're getting an achievement or Steam notification--folks, the overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration. (http://forums.qhimm.com/index.php?topic=15988.0;topicseen)

I have the new d3d9Callback.dll all packed up and ready to go, but am waiting on some feedback and a bit more testing before I release it, hopefully tomorrow. I hate the fact that we've released so many broken versions, but we're close!

TES, it's probably the Steam Overlay, it seems that a lot of people still miss this one, but it MUST be turned off unless you are using GeDoSaTo and Mcindus' FF8 loadout. If that still doesn't fix the problem it may be the way Project Eden (if you have it installed) and Tonberry v2.02 interact w/ each other. I am one of the people that Mav is referring to on feedback, I will try out his new Callback.dll and see if it fixes my random crashing w/ Project Eden and Tonberry v2.02.

First off, I just want to say thank you for this excellent project. I only recently got FF8 on PC and decided to try modding it. It's so cool to be able to play this old game "remastered" by the community.

My only problem is crashing every so often when I hit a load screen (screen going black when entering a new area/screen). All steam overlays are off. The annoying thing is I can't reproduce the crash. It will crash on a loading screen and then when I restart, that loading screen is fine, no crash. It seems to be completely random. In the error report it shows d3d9Callback.dll as the problem so maybe your next release will fix it. I've just been pushing through and saving a million times to try to counter it :| I may try removing Project Eden and seeing if that's the problem.

Also, when I add those 2 collision files, Collision and Hash2Map, this happens: http://i.imgur.com/LXHo2QY.jpg (http://i.imgur.com/LXHo2QY.jpg). :-o Maybe I'm doing something wrong. It's no big deal, I just removed them for now.

Thanks again for this excellent tool, looking forward to more in the future! :)

Umbra, sounds like you are having the same issue I do w/ Project Eden. I will have you know, Mavirick's new Callback file DOES fix all the conflicts w/ collisions.csv (including the one in your link, I had the exact same issue). However, it does NOT cure the random crashing while running Project Eden. I used to run a modified collisions.csv file, but am now able to run on the stock one that is linked in the original posting.

I currently have every one of the latest mods installed from this website, EXCEPT for Project Eden (which is a drag).

Okay, I've decided to go ahead and release v2.03. I don't own the thread so I can't update the main post, but you can get it using the link above. This includes all necessary .dll's, an empty debug directory structure, and the minimum necessary hashmap .csv's. To find hashmaps for individual mods, see Mcindus' post on the first page (first comment).

What's new?:2.03:

2.02 broke collision resolution--textures from the collisions.csv hashmap were not properly stored in the cache, which caused bad replacements and glitching textures especially on loading screens and in menus; this issue is resolved

Known issues:

Some users are experiencing random crashes when using Tonberry with Project Eden. If you are having this or any other issue please post here with details so I can look into it. Until more is known about the crash, my best advice would be to save frequently.

The overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration. (http://forums.qhimm.com/index.php?topic=15988.0;topicseen)

I've installed tonberry and I'm using SeedReborn (german), Tripod (german), Horizon, project eden, lunar cry and the Controller Buttons Pack (X360)Since i've installed the mods i get the "Unknown exceotion occured" message irregulary and my game crashes. And yes, I already have disabled the Steam overlay.

Do you have an idea, what could be wrong?

Thanks for your Help and keep up the good qork :)

I have not experienced this crash myself, so it is proving difficult to debug. It sounds on the surface like a caching problem (trying to access NULL textures) but it seems others have isolated it to Project Eden which is full of colliding textures, so I'm not so sure. I will be targeting this issue and hopefully will have resolved it soon. In the meantime, disabling Project Eden may help reduce the frequency of crashes.

I have not experienced this crash myself, so it is proving difficult to debug. It sounds on the surface like a caching problem (trying to access NULL textures) but it seems others have isolated it to Project Eden which is full of colliding textures, so I'm not so sure. I will be targeting this issue and hopefully will have resolved it soon. In the meantime, disabling Project Eden may help reduce the frequency of crashes.

At this point i can't tell if it has worked, but since I have disabled Project Eden i haven't had any new crashes. Seems like Eden was the Problem. Thank you very much

It's hard to say--I certainly hope so. I haven't heard of anyone else having this glitch and this next fix should restore Tonberry to 1.61 efficacy, so it's very possible that you're experiencing a collision issue that will be resolved by the new version. The other possibility is that you're getting an achievement or Steam notification--folks, the overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration. (http://forums.qhimm.com/index.php?topic=15988.0;topicseen)

I have the new d3d9Callback.dll all packed up and ready to go, but am waiting on some feedback and a bit more testing before I release it, hopefully tomorrow. I hate the fact that we've released so many broken versions, but we're close!

negative i had the overlay disabled and was still receiving that error. though i am going to try this new release and try it without project eden. will update with how well it works

Update: did not work, still crashed.... basically it let me play long enough to do all the chocobo forests, then on my way out the sanctuary it crashed with the "Unknown exception" error

I have been unsuccessful in replicating the crash you guys are experiencing so I am releasing this ALPHA version of 2.04 with verbose debug logging enabled. This is not an official, supported release of Tonberry and should only be used by those who are experiencing the crash and would like to help out with the debugging process. I found a few possible sources of unhandled exceptions that have now been cleared up and also made what I believe are some pretty substantial speed improvements, especially in the realm of area transitions and black loading screens. It's possible that these were causing the random crash but I have no way to be sure without your help.

Instructions:

Download TonberryEnhanced2.04_ALPHA here (http://goo.gl/vfIHV3)

Extract the new d3d9Callback.dll and copy/paste it into your \FFVIII root folder.

There must be a valid \FFVIII\tonberry\debug directory; if your debug folder is named "debug0" you must rename it to "debug" before proceeding.

Enable any mods you like. For those of you who have had success disabling ProjectEden, re-enable it. If there are specific textures within PE that are causing this exception, I want to know.

This is optional, but I suggest you set debug_mode=no in \FFVIII\tonberry\prefs.txt; the logging I've enabled will already slow things down and if it takes a long time playing before the crash the texture writing will only make things even slower.

Play. Save often. Wait for the crash.

After the game crashes, navigate to \FFVIII\tonberry\debug. There should be two new files there: "global_context.log" and "texture_cache.log". Send these two files to me, either via PM or to mavirickstone_at_gmail_dot_com.

Note that, depending on how long you've played before the crash, these files could be quite large (although nothing like the debug texture folders). They're just text but they're logging every single texture modification and every operation in the texture cache. You are welcome to take a look, but without a thorough understanding of how Tonberry works it likely won't make much sense.

If this is successful, I will start releasing unsupported alpha versions for those of you who are generous enough to help out. Hopefully that will speed up development as we approach the new hashing system and an even more beautiful FFVIII.

Again, this is not an official, supported release of Tonberry and should be ignored by anyone who is not experiencing the crash.

I have not experienced this crash myself, so it is proving difficult to debug. It sounds on the surface like a caching problem (trying to access NULL textures) but it seems others have isolated it to Project Eden which is full of colliding textures, so I'm not so sure. I will be targeting this issue and hopefully will have resolved it soon. In the meantime, disabling Project Eden may help reduce the frequency of crashes.

Set your cache_size=250 or less in \tonberry\prefs.txt. I believe the problem is that the cache is growing too large.

I managed to reproduce the crash today, and the debugging I've been able to do is making it look like the FF8_EN.exe process is trying to use greater than the ~1.75GB of memory allowed to 32-bit processes. It seems the simulated PSX GPU is using more non-GPU memory than I realized... and I may have added a zero when I was doing my memory calculations to determine optimal cache size. :o

But on the bright side, debugging this thing has led to all sorts of optimizations that should make things faster once we get the crash sorted out. I'll know more in the next few days, but our solution may be as simple as keeping the cache size between 100-250 (which seems to be about 20 gameplay minutes worth of textures).

Thanks for the tip Mcindus. I am going to revert back to the v2.03 Callback and drop my cache size down in Prefs tonight to see if that works. To me it sounds like a logical problem why only Project Eden appears to crash the game w/ Tonberry. The texture sizes of the pre-rendered backgrounds are probably the largest sized (memory-wise) textures in the game.

To me it sounds like a logical problem why only Project Eden appears to crash the game w/ Tonberry. The texture sizes of the pre-rendered backgrounds are probably the largest sized (memory-wise) textures in the game.

It's not so much that the backgrounds are larger as much as that there are so many of them. There are more than 6,500 replacement textures from Project Eden, and this means more textures in the cache at a faster rate. The game itself doesn't use that many unique texture objects--it recycles them frequently--so we're often removing items from the cache, but the more textures we replace, the faster it fills up. Disabling Project Eden has not worked for everyone and I suspect it ultimately only slows down the time it takes before the crash rather than fixing it.

I'm only sorry I didn't realize this sooner. JeMa's and my debug efforts were focused on small caches because we assumed the problems would arise when the cache filled up, so I was often debugging with a cache_size of 100. It wasn't until I opened up the cache_size and played for 20+ minutes in a transition and texture-intensive area that I experienced the crash myself.

If anyone has used a cache_size of 250 or less and experienced problems, please let me know.

Set your cache_size=250 or less in \tonberry\prefs.txt. I believe the problem is that the cache is growing too large.

I managed to reproduce the crash today, and the debugging I've been able to do is making it look like the FF8_EN.exe process is trying to use greater than the ~1.75GB of memory allowed to 32-bit processes. It seems the simulated PSX GPU is using more non-GPU memory than I realized... and I may have added a zero when I was doing my memory calculations to determine optimal cache size. :o

But on the bright side, debugging this thing has led to all sorts of optimizations that should make things faster once we get the crash sorted out. I'll know more in the next few days, but our solution may be as simple as keeping the cache size between 100-250 (which seems to be about 20 gameplay minutes worth of textures).

I set down the value and it worked at first. then i installed rebirth Flame and it started crashing again. Not just with the Fated circle but also with Blast zone. I will try again with disabled Rebirth Flame and the low cache value and report if something happens.

Edit: Nope, still crashes with Squall's limit breaks. Rebirth Flame is disabled and cache-size is 100. I also upgraded to tonberry 2.03

Do the backgrounds use the same cache as the rest of the textures? If so would be there any benefits if they have their own cache?

No. The problem is not a full cache--the data structure we've created could hold millions of textures if we had the RAM for it. The problem is that 32-bit processes are only allowed 2GB of memory, and after necessary OS components that ends up being less, something like 1.75GB. The FFVIII process (FF8_EN.exe) is necessarily 32-bit and the d3d9Callback.dll library we've created is attached to that process at startup, so we're limited to that 1.75GB minus whatever the game is already using. I haven't had an opportunity to properly profile FF8_EN.exe to see the most memory it uses without Tonberry and I'm not sure there's any way of determining that maximum for sure, but when I set my cache_size=300 it finally crashed after a long while and at =280 it seemed to reach a steady state, so I think <=250 should be safe, assuming we have at least 2GB of RAM to work with.

Eventually it's possible that I could add in some logic to dynamically determine the usage of the process and adjust the cache_size accordingly but that could prove pretty CPU-intensive. I will also be looking into the possibility of running d3d9Callback.dll in a separate process (which would give us a full 1.75GB of cache space on 32-bit systems and basically as much RAM as you can spare on a 64-bit system) but it doesn't seem likely since it has to hook into FF8_EN.exe.

I set down the value and it worked at first. then i installed rebirth Flame and it started crashing again. Not just with the Fated circle but also with Blast zone. I will try again with disabled Rebirth Flame and the low cache value and report if something happens.

I am not convinced that these crashes are related to the memory overflow exception we've been talking about. The fact that you're seeing the crash specifically during certain moves and animations is evidence that this is something texture or hash related. I vaguely remember some others discussing a problem with certain limit breaks in conjunction with the new character textures, I'll see if I can find it.

enabling Large Address Aware on FF8_en.exe would allow you to access up to 4GB of RAM for a 32bit process. It would be an extra step for the users, But it could greatly reduce the amount of crashes.

http://www.ntcore.com/4gb_patch.php link to the patch if you wanted to have a look

Neat, I didn't realize you could enable Large Address Aware without compiling the executable yourself. Still, this is not guaranteed to work; depending on what kind of pointer arithmetic FF8_EN.exe is doing--the fact that the port is emulating PSX processes worries me--this could break the game even without Tonberry running. Have you (or anyone else) tried patching FF8_EN.exe? I will try later when I get a chance.

Note that this is most helpful for people running a 64-bit version of Windows; 32-bit systems would be still be stuck with the hard limit of 2GB unless they modified Windows settings to allow a maximum of 3GB. Still, setting the cache_size to 100-250 should prevent the memory-related crashes and honestly the performance hit is pretty small. The cache is most essential for the 100 or so textures that the game is re-using extremely frequently, e.g. menus, text, characters, and worldmap textures.

Edit: I enabled the /LARGEADDRESSAWARE header for my FF8_EN.exe and it seemed to start up without issue. I'm accessing my PC remotely so I can't properly stress test this, but this could potentially allow 64-bit users to up their cache_size to as much as ~700 and 32-bit users to as much as ~450. Either way, everyone should be lowering their cache_size from the default 1000 to 250 or less until we're sure. I will be putting a hard limit on the cache_size and changing the prefs.txt default with the release of 2.04.

All right, I've successfully filled up the cache to 4GB using a LargeAddressAware FF8_EN.exe. At cache_size=700 I had no trouble, so I upped it to 800 (manually in the VS debugger), still no trouble, then to 900 and it crashed when the memory overflowed. I think 700 will probably be a good size for 64-bit users to max out their RAM usage while avoiding a crash. Obviously, you have to have at least 4GB of RAM to do this. And if you're wondering why my initial guess for a proper cache_size was so far off (2000+ :o) your guess is as good as mine, but I'm thinking I must have dropped a zero when I first did the math. Replacement textures are generally 1024x1024 pixels and each pixel is 4 bytes for a total of 1024x1024x4 = 4MB per image, plus a little bit of overhead for the cache logic. For 2GB of RAM that comes out to 512 images, but of course we have to allow for FF8's memory usage which is why we drop to 250. For the additional 1-2GB enabled by LargeAddressAware, we can safely add 200 and 500 images to the maximum cache size since the additional RAM will not be used by FF8 itself.

Still, please be aware that I don't think this large of a cache is necessary. You should be able to enjoy Tonberry at smooth speeds with a cache_size less than 250--at a size of 700 we're replacing textures the game loaded 20 minutes earlier. Many of these old textures in the cache are going to be backgrounds and character textures from an area you've long since departed and the speed gains from keeping these textures in RAM are going to be minimal.

Last thing, this is a known issue I will be working on: if the cache has been full and you've been playing for some time without seeing any text (dialog, menus, etc), the cache will dispose of the high resolution font textures and you will start to see text with mixed high-res/low-res characters. This is because, unintuitively, the process that loads the textures is called very rarely for the most common textures, and if they're not actually seen in game they will fall to the back of the cache and eventually be removed. I will be working on a way to keep the most essential textures in the cache no matter what.

Last thing, this is a known issue I will be working on: if the cache has been full and you've been playing for some time without seeing any text (dialog, menus, etc), the cache will dispose of the high resolution font textures and you will start to see text with mixed high-res/low-res characters. This is because, unintuitively, the process that loads the textures is called very rarely for the most common textures, and if they're not actually seen in game they will fall to the back of the cache and eventually be removed. I will be working on a way to keep the most essential textures in the cache no matter what.

That's because it's using the PSX's cache management system. The menu module's graphics that have the font/menu stuff are loaded into VRAM perminatly and never swapped out. Things like backgrounds and battle scenes are overwritten at a drop of a hat, (Most often during a module swap)

That's because it's using the PSX's cache management system. The menu module's graphics that have the font/menu stuff are loaded into VRAM perminatly and never swapped out. Things like backgrounds and battle scenes are overwritten at a drop of a hat, (Most often during a module swap)

Precisely. I want to expose this capability to modders and players such that hashmaps have an option for designating textures that should be kept in the cache at all times. This should be quite possible using the current cache setup, I've just got to add a persistent portion that will not be involved in a few cache operations.

New crash details. As I already mentioned, my game crashes while using Squall's Limit Breaks. But as I now found out, it only crashes while using Squall's Limit Breaks against Tonberries in the Centara Ruins while trying to get the GF Tonberry. Anywhere else, his Limit Breaksare no problem.I hope it's a good clue for you guys.

New crash details. As I already mentioned, my game crashes while using Squall's Limit Breaks. But as I now found out, it only crashes while using Squall's Limit Breaks against Tonberries in the Centara Ruins while trying to get the GF Tonberry. Anywhere else, his Limit Breaksare no problem.I hope it's a good clue for you guys.

Mcindus brought this up before. But it's probably the battler codes, Squall's most likely, from Rebirth Flame colliding with the Lunar Cry mod if you're using that. You can either disable one of the mods to see, or disable the Tonberry upscale code and or Squall's to see if that fixes the crashes.

New crash details. As I already mentioned, my game crashes while using Squall's Limit Breaks. But as I now found out, it only crashes while using Squall's Limit Breaks against Tonberries in the Centara Ruins while trying to get the GF Tonberry. Anywhere else, his Limit Breaksare no problem.I hope it's a good clue for you guys.

This is super helpful. As FatedCourage said, this is a known issue, but colliding textures should not be causing the game to crash--they should just look weird in game. I've recently been successful in attaching the Visual Studio debugger to the FF8 process (which is made unnecessarily difficult by that damned launcher...) so I will try to replicate this crash and figure out what's causing it.

This is super helpful. As FatedCourage said, this is a known issue, but colliding textures should not be causing the game to crash--they should just look weird in game. I've recently been successful in attaching the Visual Studio debugger to the FF8 process (which is made unnecessarily difficult by that damned launcher...) so I will try to replicate this crash and figure out what's causing it.

It was said before that because Tonberry had special animations, it would cause a bit of a problem. I personally turned Lunar Cry off for that side quest and turned it on again only after getting Tonberry King. This was before I limited the cache size to 350 (and before Tonberry 2.03), which, by the way, has eliminated my crash problems for the time being.

Use OllyDbg or Cheat Engine debugger to show debug window, as those two allow you to attach to running process instead of running with debugger.

You can attach the VS debugger to a process as well, it was just cumbersome because the options VS gives you make it seem like you have to start the actual process from within VS, which is impossible because FF8_EN.exe must be launched from FF8_Launcher.exe. What I ended up doing was creating a message dialog from within d3d9Callback.dll that halts the process before Tonberry is loaded, then attaching the VS debugger to FF8_EN.exe through the Windows task manager before closing the dialog and continuing.

In any case, I have been unsuccessful in replicating the Tonberry/Squall limit break collision crash. I've probably used Squall's limit breaks in the Centra Ruins against a Tonberry 20-30 times without issue. Is it possible that a) it only occurs before you've gotten the Tonberry GF or b) it only happens with the Lion Heart finishing move? Because the save I was playing on had already defeated Tonberry King and did not yet have Lion Heart, so the only finishing moves that were being used were Rough Divide and Blasting Zone (I'm assuming Fated Circle is not used when there's only one opponent because I never saw it in those 20+ Renzokukens vs. a lone Tonberry).

In any case, I have been unsuccessful in replicating the Tonberry/Squall limit break collision crash. I've probably used Squall's limit breaks in the Centra Ruins against a Tonberry 20-30 times without issue. Is it possible that a) it only occurs before you've gotten the Tonberry GF or b) it only happens with the Lion Heart finishing move? Because the save I was playing on had already defeated Tonberry King and did not yet have Lion Heart, so the only finishing moves that were being used were Rough Divide and Blasting Zone (I'm assuming Fated Circle is not used when there's only one opponent because I never saw it in those 20+ Renzokukens vs. a lone Tonberry).

I've went and fought against the Tonberry and every Limit Break I use(Lion Heart, Blasting Zone, Fated Circle) does indeed cause a crash. It's like when those Grendels use Breath and causes my game to crash.

I've went and fought against the Tonberry and every Limit Break I use(Lion Heart, Blasting Zone, Fated Circle) does indeed cause a crash. It's like when those Grendels use Breath and causes my game to crash.

Okay well I've also been using this opportunity to test out the new persistent section of the cache and the optimizations I've made along the way, so maybe this means the other changes fixed this bug without my realizing it. 2.04 should be released by tonight or tomorrow :)

Edit: I did manage to replicate the crash using 2.03, so I believe 2.04 should fix this issue. Unfortunately I'm not quite ready to release 2.04 yet--still a few kinks to iron out--but it should be out soon. Stay tuned.

Edit2: It seems I accidentally included the objmap.csv from FatedCourage's early version of Rebirth Flame in the 2.03 release. I'm sorry I didn't catch this before, but this file will cause problems for character textures if used in conjunction with Rebirth Flame.

If you have a file called 'objmap.csv' in your \tonberry\objmap directory, it should be deleted!

I'm excited to release Tonberry Enhanced v2.04, which should hopefully clear up the issues people have been having with 2.03 and earlier versions. This includes all necessary .dll's, an empty debug directory structure, and the minimum necessary hashmap .csv's. To find hashmaps for individual mods, see Mcindus' post on the first page (first comment).

What's new?:2.04:

Persistent textures - modders now have the ability to designate textures as "persistent," meaning they will never be removed from the cache. This feature should be used primarily for the core textures, such as those replaced by SeeDReborn.

To mark a persistent texture, simply precede the name of the texture with a bang/exclamation mark (!) in the relevant hashmap or objmap .csv. For example:

!sysfld00_13,8637763346649579509

Please be aware that filling the cache with persistent textures will lock it in place and all subsequent textures will fail to be replaced, so use this feature with discretion.

Significant performance improvements - although dampened in part by the increased complexity of the persistent textures, Tonberry should be running faster than ever due to some major cache optimizations and an improvement to the way we handle the core (SeeDReborn) textures.

No hard limits on cache_size - the cache size no longer has a hard minimum size of 100. You can now set it to 0 to disable the cache and texture replacements altogether, although Tonberry will still be touching each in-game texture and checking for replacements (that never exist). This feature should be entirely ignored by average players but could be helpful for modders. Note that you can also set your cache_size too high and cause memory overflow exceptions! If you do not have LargeAddressAware enabled for your FF8 executable, your cache_size should be no larger than 250.

Actually disabled textures - before, textures that were disabled with a star/asterisk (*) were not handled any differently; Tonberry would simply fail to load the replacement texture when it looked for a .png file beginning with the asterisk character. Now these textures are actually excluded from the internal hashmap, which should yield a slight increase in performance and keep these textures out of your \tonberry\debug\noreplace folder. If for some reason you want these textures to show up in your debug\noreplace folder, simply change the asterisk to any other character--just so long as the texture name in the .csv does not match any file in your \textures folder.

Known issues:

The game crashes when using Squall's limit breaks around some enemies (especially Tonberry in the Centra Ruins) while both RebirthFlame and LunarCry are enabled. Fixed...? I have not been able to replicate this crash since using 2.04. While I never isolated the cause of the crash in earlier versions, I believe 2.04 to have fixed the problem. If this is not the case, please let me know.

If the cache has been full and you've been playing for some time without seeing any text (dialog, menus, etc), the cache will dispose of the high resolution font textures and you will start to see text with mixed high-res/low-res characters. Fixed! The persistent textures feature should allow these textures to be kept in the cache indefinitely (see "What's new?").

Some users are experiencing random crashes when using Tonberry with Project Eden. If you are having this or any other issue please post here with details so I can look into it. Until more is known about the crash, my best advice would be to save frequently. Fixed! This exception was caused by memory overflow errors; make sure your cache_size in \tonberry\prefs.txt is 250 or less.

The overlay is still not supported by Tonberry and should be either disabled or circumvented using Mcindus' GeDoSaTo configuration. (http://forums.qhimm.com/index.php?topic=15988.0;topicseen)

While Mcindus and other modders should weigh in on exactly which textures should be persistent, in the meantime this is the SeeDReborn_hm.csv I've been using to test the persistent portion:

i acutally dont know where to put this, maybe ask the general question here will help me out, but my game seems to go to 2 fps when blur animations are played (eden summon and wishing star for rinoa is the main thing for me) and ive been trying to find a fix but the only thing that people say is putting it to original graphical mode (which i think blocks all the mods?) and it works and is fine, anyone have anywhere i can start to try to fix this?

(notice someone was saying it might be specs on the computer, so ill list the main components)AMD FX 8320Nvidia GTX 67016gb 1333mghz ram

i acutally dont know where to put this, maybe ask the general question here will help me out, but my game seems to go to 2 fps when blur animations are played (eden summon and wishing star for rinoa is the main thing for me) and ive been trying to find a fix but the only thing that people say is putting it to original graphical mode (which i think blocks all the mods?) and it works and is fine, anyone have anywhere i can start to try to fix this?

(notice someone was saying it might be specs on the computer, so ill list the main components)AMD FX 8320Nvidia GTX 67016gb 1333mghz ram

Doubt it's the specs. Your computer shouldn't have any trouble playing the game. I have lag at those moments and I have an AMD FX 8370, GTX 970, and 32GB of ram. It's no Intel rig, but it's great for most everything. I've noticed it only lags depending on the resolution you set. For example, when I set it to 1600x900 there is no lag for summons like Eden or Gilgamesh. Or for Wishing Star. And no lag in the final battle. But once I set it to 1920x1080 it's obviously there. And if I use GeDoSaTo to go even higher...well let's just say that it's a slideshow. :P Not sure if others experience it much or not. I don't see it discussed often. Just seems like it has something to do with the game itself.

Doubt it's the specs. Your computer shouldn't have any trouble playing the game. I have lag at those moments and I have an AMD FX 8370, GTX 970, and 32GB of ram. It's no Intel rig, but it's great for most everything. I've noticed it only lags depending on the resolution you set. For example, when I set it to 1600x900 there is no lag for summons like Eden or Gilgamesh. Or for Wishing Star. And no lag in the final battle. But once I set it to 1920x1080 it's obviously there. And if I use GeDoSaTo to go even higher...well let's just say that it's a slideshow. :P Not sure if others experience it much or not. I don't see it discussed often. Just seems like it has something to do with the game itself.

The game's internal renderer is locked to 720p. You can set the output higher but the game doesn't benefit from the extra pixels. However I can't test if the game's internal is able to render 1080p too, if so then it might explain why there is a sudden performance decrease.

I've noticed it only lags depending on the resolution you set..... But once I set it to 1920x1080 it's obviously there.

Now that's an interesting observation. I'm using a 1920x1080p and I noted animation lag early in Tonberry's development, but assumed it was something I wasn't understanding about FF8's DirectX. If it doesn't occur at all at resolutions below that, it is certainly a hint towards a solution.

Now that's an interesting observation. I'm using a 1920x1080p and I noted animation lag early in Tonberry's development, but assumed it was something I wasn't understanding about FF8's DirectX. If it doesn't occur at all at resolutions below that, it is certainly a hint towards a solution.

Well, from what I've tested, the game seems to start lagging at those moments(for me) after setting the resolution on anything higher than 1600x900p. Anything at, or below, 1600x900p and the game runs fine. If this is of any use, then I'm glad.

i did a search and found out that some think its just the blur effects (of course this was steam community that i seen it on) and also said that lower the resolution the less frame loss they have so i wonder if its something to do with the game not able to render those blur effects above a certain resolution? (overload on the program itself or something along those lines?)

the only thing i can give is what i experience i dont know how to do any debugging like you guys can do unfortunately XD is there a general debug tool i can run with FF8 to try to get more information for you guys about this?

ok i cannot for the life of me get ANY of the textures to show up in gamei downloaded Tonberry 2.04, extracted in to my FF8 folder (it's on a separate HDD than my OS it's D:\SteamLibrary\steamapps\common\FINAL FANTASY VIII\that's where i have the texture folder yet i go to balamb and it's still vanillai have the hash map files all placed righti edited my prefs to my ff8 folderi did everything step by step and it just. won't. work.NONE of the Textures i downloaded work it seemsi'm running windows 8.1 x64, AMD r9 290 w/4gb vram, 16 gb rami don't understand why the textures won't work.help please

did you make sure that old graphics is UNchecked in options? that might be it, other then that what i can think of looking at the instructions is just make sure the pref.txt in your tonberry folder is pointed to the right drive letter.........

yep original GFX is unticked and my prefs is indeed pointed to my D driveam i missing a program ? cause i don't see how tonberry by itself could affect the ff8 texturesi'm pretty sure i downloaded all the tools i need...

Edit: its just a drag & drop operation right?Tonberry goes into my FF8 root folder along with the texture folderthen i modify prefs to mirror this D:\SteamLibrary\steamapps\common\FINAL FANTASY VIII (that's where i have my FF8 installed)then i add the new textures to the texture folderthen add hash maps to the hash folder and the objmaps in the obj folderand that's it right? i should be good?or am i missing a step or 5? -_-

yep original GFX is unticked and my prefs is indeed pointed to my D driveam i missing a program ? cause i don't see how tonberry by itself could affect the ff8 texturesi'm pretty sure i downloaded all the tools i need...

You said your OS is on a different drive, right? I'm pretty sure your prefs need to be set to the drive the OS is on. Doesn't matter where you have FF8 installed.

I saw your edit from before. It is pretty much drag and drop. I don't think you needed to edit anything in your prefs. Pretty sure it all should've worked without touching it. The only thing I myself have edited in the prefs is the cache size to suit my needs. It should be fine untouched.

Edit: What I'm saying is, just replace the prefs with a fresh one. You did indeed do all the steps right. Except for editing the prefs. I don't think you needed to do that.

Hi Skillster, I'm sorry you're having trouble. Is FFVIII totally failing to launch, or is it just Tonberry that's not working?

Is your Windows installed on the E drive? If so (or if it's anything other than C) you need to set drive_letter to the appropriate value in \FINAL FANTASY VIII\tonberry\prefs.txt.

Have you put the Tripod textures in \FINAL FANTASY VIII\textures\?

Hi there. Yes if you try launching from steam it doesn't even bring up a window/dialogbox/error sound :)If you try launching from the FF8 folder itself (ff8en or ff8 launcher) you get the error that MSVCP120.dll is missing - however if I try to run the runtime you included it tells me there is a newer version installed anyway.Tripod textures are in E:\GAMES\Steam\steamapps\common\FINAL FANTASY VIII\texturesWindows is on C:\Any ideas? Roses and Wine worked fine on a vanilla install of FF8 Steam.

Any chance for a difficulty mod?the mods you have done are excellent, But this game is just too easy// If they had done a training center like the FFX monster arena, where you could get all the additional monsters/boss'sThat would've just been amazingHopefully if a hard mod comes along, it's so hard that it takes me 500 hours to complete the game

It's not a correct thread nor forum section for this. Please, use IFRIT, that you can find in tools section and read scenes.out specification at wiki and make one yourself. Today it's not that hard, you just follow instructions and read documentation.

Got a problem with this mod that causes me unable to play the game in full screen. I have tonberry installed with mods and they work (seed reborn etc so easy to check). But when I start the game in full screen setting from the settings it will crash with a 'an unknown exception has occurred.' I have tried all setting combinations, steam cloud/overlay on and off and every resolution with and without mods but it keeps crashing on full screen. Related to that setting option only. Also noticed this did not happen with 1.5 but did crash from 1.6 and onwards. Any help on fixing this? Without tonberry it won't crash in full screen so it is related to this. I have no idea how to go with this.

Got a problem with this mod that causes me unable to play the game in full screen. I have tonberry installed with mods and they work (seed reborn etc so easy to check). But when I start the game in full screen setting from the settings it will crash with a 'an unknown exception has occurred.' I have tried all setting combinations, steam cloud/overlay on and off and every resolution with and without mods but it keeps crashing on full screen. Related to that setting option only. Also noticed this did not happen with 1.5 but did crash from 1.6 and onwards. Any help on fixing this? Without tonberry it won't crash in full screen so it is related to this. I have no idea how to go with this.

Kind Regards

Fullscreen works fine for me, and I'm assuming there are lots of other fullscreen players. What do you mean when you say "with and without mods?" Is it crashing as soon as you start up or only after a while of playing? I'm not sure what fullscreen would change that would cause Tonberry to crash, but if you're getting "unknown exception" then that does sound like it's coming from d3d9Callback.dll.

Fullscreen works fine for me, and I'm assuming there are lots of other fullscreen players. What do you mean when you say "with and without mods?" Is it crashing as soon as you start up or only after a while of playing? I'm not sure what fullscreen would change that would cause Tonberry to crash, but if you're getting "unknown exception" then that does sound like it's coming from d3d9Callback.dll.

I figured it would work fine for other players indeed. And yes I do mean crash right away at start. DId it with blank tonberry and tonberry with mods (e.g. seed reborn) and even with debug on in tonberry and renaming directories to match I get 0 output.

When I start the game in full screen and press play I get a black screen quarter of the screen and 0.1 second later in full screen and it stays black, nothing happens, it has crashed instantly and the popup is hidden behind it to which you need to alt tab. When you press 'ok' on that popup with 'unknown exception' you can get the windows crash that asks to close it etc which also has 0 information. And this happens only in full screen regardless of anything else as long as tonberry is there. In windowed mode it runs just fine with everything working..

I figured it would work fine for other players indeed. And yes I do mean crash right away at start. DId it with blank tonberry and tonberry with mods (e.g. seed reborn) and even with debug on in tonberry and renaming directories to match I get 0 output.

When I start the game in full screen and press play I get a black screen quarter of the screen and 0.1 second later in full screen and it stays black, nothing happens, it has crashed instantly and the popup is hidden behind it to which you need to alt tab. When you press 'ok' on that popup with 'unknown exception' you can get the windows crash that asks to close it etc which also has 0 information. And this happens only in full screen regardless of anything else as long as tonberry is there. In windowed mode it runs just fine with everything working..

I'm not really sure what to tell you besides to try completely removing Tonberry and starting over. Make sure you're using v2.04, that the Steam overlay is disabled, and that at the very least both collisions.csv and hash2map.csv are in FFVIII\tonberry\, even if you have no texture packs enabled. If you continue to have issues I will send you a modified version that will log startup events from within Tonberry so I can see where and why this is happening.

Sorry for the late reply. No matter what I try it keeps crashing. Also I use the collisions and hash2map.cvs files in the 2.04 zip but no matter what I try it keeps crashing when on full screen. If you can sent me the adjusted dll file that would be great so I also can see what is going on.

Hello everyone I am trying to install mods to play FF8 with, however I got several warnings of virus and medium threat after downloading Tonberry Enhanced 2.04. I was wondering if there should be any concerns? Also I don't understand if I should download this version 2.04 or the older versions such as 1.5 to run modded FF8.

I've modded skyrim plenty of times but this is my first time modding FF8 and I am very confused, any help is greatly appreciated!

Hello everyone I am trying to install mods to play FF8 with, however I got several warnings of virus and medium threat after downloading Tonberry Enhanced 2.04. I was wondering if there should be any concerns? Also I don't understand if I should download this version 2.04 or the older versions such as 1.5 to run modded FF8.

I've modded skyrim plenty of times but this is my first time modding FF8 and I am very confused, any help is greatly appreciated!

You should have no concern with viruses. If AV programs are flagging Tonberry files as dangerous, my guess would be it's because of the D3D9 injector, which simply intercepts calls to your graphics card and replaces textures with the modded files.

Don't worry about earlier versions--everything you need should be included in the Tonberry 2.04 download.

Mavirick, would it possible to have a Tonberry texture support for FFVII steam version since the game works in a similar way ? How much work would it take ?

Yes, I believe so. The FFVII Steam release uses DirectX 9 so I think you could use the exact same D3D9Callback.dll. There is some question as to whether the textures are the same size and are handled the same way (they are written to the GPU upside down in Tonberry, don't ask me why), but assuming they are mostly similar to FFVIII then the same process could be used: use Tonberry debug mode to find in-game textures, upscale them or repaint them, use hash of in-game texture to replace with new texture. I don't own the Steam version of FFVII, but if someone wanted to try Tonberry 2.04 with it I'd be interested in their findings. You'd want to empty \textures, tonberry\hashmap, and tonberry\objmap, set debug_mode=yes in tonberry\prefs.txt, and create a proper tonberry\debug folder structure for saving images.

The biggest problem would be the hashing algorithm, which Omzy wrote and then reinforced by a set of handchosen pixels that seemed to reduce collisions to an acceptable level. This algorithm would probably not work very well with FFVII and its entirely separate set of textures, which would mean tons of collisions and general misery for modders. In a perfect world, you'd want to do what the eventual plan for FFVIII is:

Use Tonberry with debug mode on to collect a large majority of in-game textures. The more textures the better--the best way to do this would be to crowdsource it, assigning people different areas to run around and then send all the collected textures to one person. One diligent speedrunner could also collect most of them in a reasonable amount of time, assuming he had the harddrive space (likely 100+GB of images), and if I've learned anything from qhimm it's that you should never underestimate the patience of a determined modder (I'm looking at you, FatedCourage :P).

Run some analysis on the set of in-game textures to find an ideal set of pixels for hashing. I've developed a process that I think does an excellent job of this, and was able to reduce collisions among the FFVIII textures I'd collected to ~2% (versus the 20+% in the current hash algo). However, the new hash algorithm was never completed/implemented for a variety of reasons, not the least of which was the release of The Witcher 3 ::)

Use pixels from analysis to create an (almost-)optimal hashing algorithm that can replace every texture in the game with whatever modders want without any significant collisions. Use the existing Tonberry structure with hashmaps and a directory for replacement textures.

Release the collection of in-game textures with their hashes (or an app for generating the hashes, like BerryMapper) and let modders go to town.

Release an updated Tonberry that uses the new hashing algorithm.

There are several other improvements in development (if a somewhat delayed development) for Tonberry, including logic that can search for 1-4 objects in all four corners of a texture so that modders like FatedCourage don't have to trawl the game for every possible combination of character textures to include in the hashmap. The important thing, I think, is that the replacement strategy that Omzy came up with and the texture cache that JeMa and I developed are both iron tight. They can and should be used for other games.

I am having trouble following the installation instructions. I think I got Tonberry in place but I don't understand how to add the mods. Feels like I missed the first half of a conversation, or something. Is there a more detailed tutorial somewhere?

I am having trouble following the installation instructions. I think I got Tonberry in place but I don't understand how to add the mods. Feels like I missed the first half of a conversation, or something. Is there a more detailed tutorial somewhere?

Most of the mod threads usually tell you what you need to do to make them work. If you use the Rebirth Flame mod, I put instructions on the first page saying where you need to put everything to make it work. And I'll link that page here. http://forums.qhimm.com/index.php?topic=16022.0 And Mcindus and others also put instructions on theirs as well.

I don't own the Steam version of FFVII, but if someone wanted to try Tonberry 2.04 with it I'd be interested in their findings.

I tried it for you. It does pull textures like the backgrounds, text, battle effects and icons, and also character portraits. Doesn't pull any textures from the character models in or outside of battle though. It does give me their creepy little eyes, though.

(http://i.imgur.com/Otm7VPJ.jpg)

Quote

One diligent speedrunner could also collect most of them in a reasonable amount of time, assuming he had the harddrive space (likely 100+GB of images), and if I've learned anything from qhimm it's that you should never underestimate the patience of a determined modder (I'm looking at you, FatedCourage :P)

That actually sounds very plausible. Though, I'd be uploading for days. And I'd feel sorry for the person having to sift through all that. Er... I'm a very determined person when it comes to anything I take part in. Perhaps too much at times. ...I also lead a very boring life. 8-)

I tried it for you. It does pull textures like the backgrounds, text, battle effects and icons, and also character portraits. Doesn't pull any textures from the character models in or outside of battle though. It does give me their creepy little eyes, though.

Hm, that's interesting that you don't get character models... Doesn't seem right to me. I don't know why they would work any other way. It's also kind of a deal-breaker if there's no way around it. Did you have all the debug directories working? They could be an unsupported size or something.

That actually sounds very plausible. Though, I'd be uploading for days. And I'd feel sorry for the person having to sift through all that. Er... I'm a very determined person when it comes to anything I take part in. Perhaps too much at times. ...I also lead a very boring life. 8-)

There wouldn't have to be any sifting, necessarily, just some code to remove any duplicates from the set and then pixel analysis on what's left over. And as far as your determination goes, I'm certain I'm not alone in saying that we're thankful for it around here ;)

Hm, that's interesting that you don't get character models... Doesn't seem right to me. I don't know why they would work any other way. It's also kind of a deal-breaker if there's no way around it. Did you have all the debug directories working? They could be an unsupported size or something.

I tried a few times and got nothing. Hard to say... Yeah. I opened them all up. Unsupported got FMV shots, and nomatch2 had more eyes in it. But no character or enemy textures in any.

Quote

There wouldn't have to be any sifting, necessarily, just some code to remove any duplicates from the set and then pixel analysis on what's left over. And as far as your determination goes, I'm certain I'm not alone in saying that we're thankful for it around here ;)

I tried a few times and got nothing. Hard to say... Yeah. I opened them all up. Unsupported got FMV shots, and nomatch2 had more eyes in it. But no character or enemy textures in any.

Hm... is it possible that there aren't any character textures? I haven't played in a long while, but just looking back at screenshots it appears almost as if the characters are just polygons filled with solid colors. Lighting and shaders gives it the gradient look, but I'm not seeing any actual textures:

Hm... is it possible that there aren't any character textures? I haven't played in a long while, but just looking back at screenshots it appears almost as if the characters are just polygons filled with solid colors. Lighting and shaders gives it the gradient look, but I'm not seeing any actual textures:

I'm not entirely sure that using solid colors instead of wrapped textures would change the way Tonberry works, but it's a possible explanation.

That was my initial thought also. When I saw how people were making the models and such, I questioned whether or not it's just colored polygons as well. So you might be right. Still, Tonberry does/eventually can work to a certain degree on most other things. And I guess it's up to others whether they see potential in any of it or not. Also, since I don't have a save near the world map, I can't test anything there.

It's all polygons yes, the only textures for field and battles models are eyes, mouth, Barret's tatoo, Cloud's belt and such. You can change/replace them using Kimera.

So am I correct in assuming Kimera cannot replace backgrounds and menu textures?

The only issue I foresee is using custom textures through previous mods in conjunction with Tonberry: if Tonberry is using a hashing algorithm based on FFVII vanilla textures but then gamers start throwing different combinations of modded textures at it, modders will not be able to predict and reproduce (and thereby try to circumvent) collisions. Someone's custom texture could very well hash to the same thing as a vanilla texture, which would cause Tonberry to try to replace it and things would start getting weird. Ideally, you'd use Tonberry for everything or not at all--additional textures won't slow it down significantly.

Obviously this is all further down the line, just something to think about. If Tonberry is to be used with FFVII, its addition to the game needs to be worth the slowdown (which admittedly should be very minor for modern computers) and the effort required to adapt existing texture mods to use it.

EDIT: As an additional and probably far-fetched thought, it's possible that the D3D9Callback interceptor could be modified to catch FFVII's calls to fill in polygons. If those could be replaced with calls to apply a texture to the same polygon... well, that would be very interesting indeed.

As an additional and probably far-fetched thought, it's possible that the D3D9Callback interceptor could be modified to catch FFVII's calls to fill in polygons. If those could be replaced with calls to apply a texture to the same polygon... well, that would be very interesting indeed.

That won't work this way. Even if you replace a specific color with a specific texture you will run in tons of problems. As example battle models have gradients. How do you want to replace them?Texturing models is quite easy: giving the mesh a UV map and a texture and then place everything in back into the lgp (obviously it is more complicated in detail). I should mention that the directx9 renderer has a black texture bug which happens for no reasons.If Tonberry only looks for menu textures and backgrounds it would be enough.

Hey I am having some trouble with Carbuncle's texture. There is a description of the problem and a picture in the Lunar Cry thread here: http://forums.qhimm.com/index.php?topic=15977.msg229570#msg229570

I've downloaded Final Fantasy 8, and ran it vanilla no problem. I installed Tonberry and some mods and my Steam doesn't get past "Preparing to Launch Final Fantasy 8." I removed the mod and the game runs fine. I've also put back just Tonberry, and this is causing the game not to launch. When I say this, the launcher doesn't even come up.

I've installed the Visual C++ 2013 package.Direct X is up to date.I have a Nvidia 765m with fully updated drivers.My Intel Graphics driver is also fully updated.I have disabled steam overlay both for FF8 and globally just to make sure.

I have installed the mod properly to C:\Program Files (x86)\Steam\SteamApps\common\FINAL FANTASY VIII

in that folder is the tonberry folder, texture folder and all else that comes with the mod..

I've got collisions and hash2map in the tonberry folder.hashmaps in the hashmap folderobj files in objmap folderprefs file is untouched, but I confirmed that it is good.

This is my favorite childhood game D;. I appreciate the help guys

EDIT: I have removed ONLY the d3d9.dll so I could see if FF8 then launches... which it does; so hopefully that information helps out D;.

I've downloaded Final Fantasy 8, and ran it vanilla no problem. I installed Tonberry and some mods and my Steam doesn't get past "Preparing to Launch Final Fantasy 8." I removed the mod and the game runs fine. I've also put back just Tonberry, and this is causing the game not to launch. When I say this, the launcher doesn't even come up.

I've installed the Visual C++ 2013 package.Direct X is up to date.I have a Nvidia 765m with fully updated drivers.My Intel Graphics driver is also fully updated.I have disabled steam overlay both for FF8 and globally just to make sure.

I have installed the mod properly to C:\Program Files (x86)\Steam\SteamApps\common\FINAL FANTASY VIII

in that folder is the tonberry folder, texture folder and all else that comes with the mod..

I've got collisions and hash2map in the tonberry folder.hashmaps in the hashmap folderobj files in objmap folderprefs file is untouched, but I confirmed that it is good.

This is my favorite childhood game D;. I appreciate the help guys

EDIT: I have removed ONLY the d3d9.dll so I could see if FF8 then launches... which it does; so hopefully that information helps out D;.

Just do what me and skillster did. If you try to launch ff8 from the game directory itself it should tell you that you are missing msvcp120.dll. So I did a C drive search for those 2 files, copied and pasted them in when i found them in my LOL directory and its working now.

I just tried using Tonberry v2.04 and Berrymapper with FFVII steam version, the debug mode works great and I pulled off Cloud's avatar, the picture is now 4x the size (512x512px) *.png file and the texture path is "textures\cl\cloud\cloud_0.png".

I just tried using Tonberry v2.04 and Berrymapper with FFVII steam version, the debug mode works great and I pulled off Cloud's avatar, the picture is now 4x the size (512x512px) *.png file and the texture path is "textures\cl\cloud\cloud_0.png".

Are there by chance large areas of black in your 512x512 image you're hashing? If so, it's not looking at enough pixels and is trying to replace anything that uses a transparency mask (so you get a bunch of black boxes everywhere)

From what I remember, the objmap codes that you're showing are exactly that - ones that are trying to replace every instance of a 'black' or transparency texture. These I don't have a workaround for, but are what Omzy created the hash2map algorithm and collisions.csv exactly for these instances. It's why I can't make the intro scenes HD in FF8 - every block of text including the squaresoft logo is using that same objmap code you provided. Might even be the same hashcode too.

Omzy would know more about how to isolate the pixels and then what algo to run to get the longer codes.

It's really a shame, because this is the graphic I made for the new Tonberry for whenever we get an actual release with the new hash algorithms.(http://www.13tomidnight.com/FF8/intro_squarelogo_tonberry.png)

It's really a shame, because this is the graphic I made for the new Tonberry for whenever we get an actual release with the new hash algorithms.

I lost all my textures when I uninstalled/reinstalled the game :( They were in my tonberry directory and uninstalling the game wiped the whole directory instead of just deleting the game files. I tried to recover them but I guess the reinstall recycled the memory so they were all corrupt.

What I really need is the tonberry dump from an entire playthrough. It would be a ton of images and the playthrough would be frustrating cause debug mode slows things down, but the texture analysis algorithms are written and with a large enough texture set I could generate a near perfect hash. The only thing thing to solve would be hardcoding some pixels in for the animated textures like characters blinking. One solution might be a way to designate additional pixels to look at for certain textures, so that modders could fix collisions without having to generate a whole new hashing algorithm.

hello, i'm not sure if this is the right place to ask but i am having issue with 2 different mods sharing the same folder name in textures. the mods are project eden and seed reborn, both mods have a texture folder labeled gf and i am not sure how to proceed.

am i supposed to put extra folders in the texture folder to separate the textures of different mods? example [ \FF8\textures\Project_Eden\gf ] and [ \FF8\textures\SeeD_Reborn\gf ] instead of [ \FF8\textures\gf ] ? or maybe can merge all the folders inside both gf folders to the same gf folder?

I just tried using Tonberry v2.04 and Berrymapper with FFVII steam version, the debug mode works great and I pulled off Cloud's avatar, the picture is now 4x the size (512x512px) *.png file and the texture path is "textures\cl\cloud\cloud_0.png".

Sorry I never answered this 5way, I've been stretched thin on other projects for the past few months.

I'm pretty sure the problem you had with FF7 is the hashing function Tonberry uses (which is optimized for FF8) and especially the few hardcoded hashes used mostly for menu textures and the like. Many of the menu textures hash to the same thing and differ only by color (which Omzy's original hash function ignores) so there had to be special accommodations programmed directly into d3d9Callback.dll. It could also have to do with the texture size and resize code.

For the most part, if Tonberry can pull the texture into the debug folder then it can also replace it. If (and it's looking like the ball may get rolling again) we get a new hashing algorithm working in FF8 then we can look into applying the same process to FF7.

Thanks for the answer mavirick; yes, Tonberry does debug all kinds of textures so it was looking promising at first. Besides of the d3d9Callback.dll, does berrymapper needs to be optimized too for FFVII?

Thanks for the answer mavirick; yes, Tonberry does debug all kinds of textures so it was looking promising at first. Besides of the d3d9Callback.dll, does berrymapper needs to be optimized too for FFVII?

Basically, the method I've tested as a replacement for the hashing algorithm involves finding the set of the most "important" or "telling" pixels to differentiate between textures in the game, then packing their values into any good hashing algorithm. The one I've been using is Murmur2 because it's super fast and collision resistant, but really any hashing function will do.

You're basically trying to solve an optimization problem: maximize the speed of the hash (which is effectively the number of different pixels you use) while also minimizing the number of collisions (which show up as glitching textures in game). Obviously you could use every pixel and have zero collisions but it would be too slow, or use only one pixel and it would be very fast but have a ton of collisions. Theoretically, there is a perfect set of the minimum number of pixels needed to result in 0 collisions. This pixel set is based on the full texture set used by the game, and is--for all intents and purposes--impossible to find. But you can try to get close. Omzy hacked out a pretty good hashing process for FFVIII using some good ole' fashioned trial and error and that's the one we have today, but his process is virtually useless for other games (like FFVII).

TL;DRAll this is to say that yes, everything would have to change for FFVII--because the game uses a totally different texture set, Tonberry would need to hash a different pixel set. Berrymapper just uses the same hashing process as Tonberry to generate the hashes for the replaced and replacement textures. If the new hash function is completed it will come with a new Berrymapper as well. To make Tonberry game-independent, it would have to take the pixels used in the hash as an input (probably just a plaintext file), and the same goes for Berrymapper.

Hello Mavirick and JemaheChi,I've been away for a long time due to my new job; but i keep an eye on Qhimm. If you have any hints about your new hashing algorithm i would be happy to create a "test version" of Berrymapper to test the algorithm.Anyway, as we have a large number of hashed textures now ( characters, worldmap,GF,weapons, battlefields...) we can define already a close-to-perfect set of key pixels for your algorithm. We could even have different algorithm fit to each type of texture (one for characters, one for objects, one for worldmap).

Hello Mavirick and JemaheChi,I've been away for a long time due to my new job; but i keep an eye on Qhimm. If you have any hints about your new hashing algorithm i would be happy to create a "test version" of Berrymapper to test the algorithm.Anyway, as we have a large number of hashed textures now ( characters, worldmap,GF,weapons, battlefields...) we can define already a close-to-perfect set of key pixels for your algorithm. We could even have different algorithm fit to each type of texture (one for characters, one for objects, one for worldmap).

Thanks Shunsq, I appreciate the support :)

I had a preliminary version back in March and I used a thrown-together hashing tool to confirm that it would work. The issue was that the textures I had to work with (before I lost them all :oops:), even as many as there were, didn't come close to the full set.

Yeah, we have a large number of textures that have been used in different mods, but even if we had them all in one place it wouldn't be enough. The problem is that the textures we don't replace in any mods are as important--perhaps even more so--than the ones we do; without them we could unwittingly end up with tons of unforeseen collisions and then you'd start seeing the replacement textures all over the place, or they would end up behind the scenes in palette textures, masks, etc.

The reason the new hashing algorithm was never released was because I didn't want people to start using it before the pixel set was solid. Each time the hash algo changes in any way, all of the hashmap CSV's for every mod have to be changed. This means a lot of work for modders who have to keep up with each iteration and a lot of confusion for players who wonder why the hashmap for one mod works great while another causes problems. Maybe this decision was a mistake. Maybe, as I mentioned in my last comment, it would be possible to define the pixels used in the hash externally, such that modders and players could have more control over the set.

Fortunately, FatedCourage has done an incredible job collecting textures from a playthrough of the entire game, and as of today he's gotten all of them to me: a grand total of 293,848 textures collected through Tonberry's debug feature. Obviously a ton of these will be duplicates, but through the same analysis I did earlier this year we should be able to start making headway on a good pixel set. Stay tuned.

I had a preliminary version back in March and I used a thrown-together hashing tool to confirm that it would work. The issue was that the textures I had to work with (before I lost them all :oops:), even as many as there were, didn't come close to the full set.

Yeah, we have a large number of textures that have been used in different mods, but even if we had them all in one place it wouldn't be enough. The problem is that the textures we don't replace in any mods are as important--perhaps even more so--than the ones we do; without them we could unwittingly end up with tons of unforeseen collisions and then you'd start seeing the replacement textures all over the place, or they would end up behind the scenes in palette textures, masks, etc.

The reason the new hashing algorithm was never released was because I didn't want people to start using it before the pixel set was solid. Each time the hash algo changes in any way, all of the hashmap CSV's for every mod have to be changed. This means a lot of work for modders who have to keep up with each iteration and a lot of confusion for players who wonder why the hashmap for one mod works great while another causes problems. Maybe this decision was a mistake. Maybe, as I mentioned in my last comment, it would be possible to define the pixels used in the hash externally, such that modders and players could have more control over the set.

Fortunately, FatedCourage has done an incredible job collecting textures from a playthrough of the entire game, and as of today he's gotten all of them to me: a grand total of 293,848 textures collected through Tonberry's debug feature. Obviously a ton of these will be duplicates, but through the same analysis I did earlier this year we should be able to start making headway on a good pixel set. Stay tuned.

I had a preliminary version back in March and I used a thrown-together hashing tool to confirm that it would work. The issue was that the textures I had to work with (before I lost them all :oops:), even as many as there were, didn't come close to the full set.

Yeah, we have a large number of textures that have been used in different mods, but even if we had them all in one place it wouldn't be enough. The problem is that the textures we don't replace in any mods are as important--perhaps even more so--than the ones we do; without them we could unwittingly end up with tons of unforeseen collisions and then you'd start seeing the replacement textures all over the place, or they would end up behind the scenes in palette textures, masks, etc.

The reason the new hashing algorithm was never released was because I didn't want people to start using it before the pixel set was solid. Each time the hash algo changes in any way, all of the hashmap CSV's for every mod have to be changed. This means a lot of work for modders who have to keep up with each iteration and a lot of confusion for players who wonder why the hashmap for one mod works great while another causes problems. Maybe this decision was a mistake. Maybe, as I mentioned in my last comment, it would be possible to define the pixels used in the hash externally, such that modders and players could have more control over the set.

Fortunately, FatedCourage has done an incredible job collecting textures from a playthrough of the entire game, and as of today he's gotten all of them to me: a grand total of 293,848 textures collected through Tonberry's debug feature. Obviously a ton of these will be duplicates, but through the same analysis I did earlier this year we should be able to start making headway on a good pixel set. Stay tuned.

Glad to hear you're still working on this mav. I'm currently pretty busy on RL so I'd be a burden, more than a helpful hand on this. Actually, I was working on a full research about enemies AI that is at standby for now. But I still come here to read your progress guys(also take a peek at github so keep syncing your code :I) Keep it up everyone! :D

Hey all, I'm trying out this tool with a fresh new install of FF8 on my Mac. I'm running the game through Wine and it works just fine... for a while. After some time, usually traversing a few screens, definitely a few screens after playing Triple Triad, the next screen loads up with odd green textures. I'm able to replicate this fairly consistently from the first save in the game, at the Balamb Garden directory, then going to the Cafeteria, playing the lovestruck Trepie, then leaving the cafeteria back into the central ring. Upon entering all the water surfaces are overlaid with green textures.

Sometimes this effect can be negated by minimizing & maximizing the game. Half the time it freezes & crashes after a few seconds.

I'm attaching a report: http://www.chopapp.com/#sspmwbid (http://www.chopapp.com/#sspmwbid). I noticed it mention d3d9callback.dll, which was supplied by your tool. Any idea what could be going wrong?

In case you're unfamiliar with Wine, it has the ability to use its own inbuilt DLLs but also to commission native, external DLLs, provided that it's set up right. Am I maybe missing a crucial DLL, or is one of the DLLs maybe the wrong version?

Thanks for any help!

Edit: I forgot to mention the issue goes away after removing d3d9.dll. But then textures revert back to original.

Hey all, I'm trying out this tool with a fresh new install of FF8 on my Mac. I'm running the game through Wine and it works just fine... for a while. After some time, usually traversing a few screens, definitely a few screens after playing Triple Triad, the next screen loads up with odd green textures. I'm able to replicate this fairly consistently from the first save in the game, at the Balamb Garden directory, then going to the Cafeteria, playing the lovestruck Trepie, then leaving the cafeteria back into the central ring. Upon entering all the water surfaces are overlaid with green textures.

Sometimes this effect can be negated by minimizing & maximizing the game. Half the time it freezes & crashes after a few seconds.

I'm attaching a report: http://www.chopapp.com/#sspmwbid (http://www.chopapp.com/#sspmwbid). I noticed it mention d3d9callback.dll, which was supplied by your tool. Any idea what could be going wrong?

In case you're unfamiliar with Wine, it has the ability to use its own inbuilt DLLs but also to commission native, external DLLs, provided that it's set up right. Am I maybe missing a crucial DLL, or is one of the DLLs maybe the wrong version?

Thanks for any help!

Edit: I forgot to mention the issue goes away after removing d3d9.dll. But then textures revert back to original.

The green textures sound like a classic hash collision--Tonberry thinks the water textures should be replaced with those green textures. Freezing and crashing I'm not sure about, and the report you attached only confirms that it's Tonberry that's causing the problem. Does this only happen when you use Wine to load d3d9Callback.dll? I don't recall Wine causing issues but it's possible.

Has anyone else experienced this issue using Windows or is it isolated to OSX? Unfortunately, I don't have the time or the Macbook to properly support OSX. I can send you a debug build that will write some additional logs and may shed some light on the issue, but I cannot promise anything.

It specifically happens when I force Wine to use the d3d9.dll provided with Tonberry. Using the in-built DLL fixes the crashes but also disables Tonberry. I haven't tried running Tonberry without d3d9Callback.dll.

To make the symptoms more precise, in approximately half the cases upon entering a new screen the water turns green, some other textures are also messed up and upon exiting the screen the application crashes. If I minimize the application and then maximize again the problem goes away. Sometimes a similar thing happens while playing Triple Triad, some of the cards are overlaid with weird green/turquoise textures but minimizing/maximizing fixes it. In the other 50% cases the new screen goes mostly black with dark green patterns and what's presumably graphical artifacts from either the previous or the intended current screen. The game then immediately crashes.

Upon the advice from the pinned post to the steam community page for FF8, I just installed Tonberry 2.04 and added:SeeD Reborn v3.2Project Eden v1.0Tripod v1.1Rebirth Flame v1.1HorizonPack v2.1Lunar Cry v1.2

Although I followed the directions (as well as Mcindus's install video), I must have messed up somewhere. Since installing the mods, steam won't launch the game. Whenever I click "play", steam says the game is "running", followed by "syncing", and goes back to normal all within the span of <5 seconds. At no point does the launcher window open or even make an attempt to open, it just never shows any sign of anything going on other than the running/syncing message.

Has anyone else had this issue or has some suggestions on how to fix it? Thank you!

*UPDATE* I managed to figure it out. Somehow the MSVCP120.dll and MSVCR120.dll were deleted from the FF8 file.

The reason the new hashing algorithm was never released was because I didn't want people to start using it before the pixel set was solid. Each time the hash algo changes in any way, all of the hashmap CSV's for every mod have to be changed. This means a lot of work for modders who have to keep up with each iteration and a lot of confusion for players who wonder why the hashmap for one mod works great while another causes problems. Maybe this decision was a mistake. Maybe, as I mentioned in my last comment, it would be possible to define the pixels used in the hash externally, such that modders and players could have more control over the set.

Also - you had mentioned in the past that we may be able to enable multiple resolutions via Tonberry... For example - the enemy textures and worldmap textures don't need more than a 4x bump, but the character textures, battle backgrounds, and others would greatly benefit from being 8x! Any way for that feature to work? That way we don't have to have ALL 4x or ALL 8x...

Also - you had mentioned in the past that we may be able to enable multiple resolutions via Tonberry... For example - the enemy textures and worldmap textures don't need more than a 4x bump, but the character textures, battle backgrounds, and others would greatly benefit from being 8x! Any way for that feature to work? That way we don't have to have ALL 4x or ALL 8x...

I think so. The difficulty is that each D3D texture can hold two FF8 textures at once, so you run into problems with textures of different size. For example, let's say a D3D surface has an enemy texture that Tonberry finds and replaces with a 1024x1024 texture, but then also holds a character texture that has a 2048x2048 replacement. Do we go back and scale the enemy texture? This takes precious time and will be going on constantly.

What we may be able to do is give a max texture size in the settings, then always scale every texture to that size when replacing. As long as we know ahead of time that a 1024x1024 needs to fill a 2048x2048 space, we should be fine.

If it does become possible, perhaps certain bosses can benefit from this too? At least the bigger ones. Even Ulti has parts on her I'm sure it could improve.

Original:(http://i.imgur.com/vVI1nml.png)

Original w/Linear Filtering:(http://i.imgur.com/grhvTvV.jpg)

Waifu Upscale x4:(http://i.imgur.com/oDybjdW.png)

Waifu Upscale x4 w/Linear Filtering:(http://i.imgur.com/nOFdUyy.jpg)

While the upscale does a pretty good job, some parts still could use improvement. Unless there are better ways to cover it up? While Linear Filtering does a decent job of covering it up, I assume we're moving away from that. So that's why I'm curious.

Does this need to be installed over the old Tonberry 1.5, or in a totally clean installation? And we need old hasmap 1.3?

Because with this new Tonberry version, the xbox button mod, seems to not works.

I've always just been updating by dragging all the files of the newest version into my directory and choosing to let it replace the old ones. The files you need to keep are hash2map and collisions. You don't need hash1map at this point because you can download all the separate hashmaps you want to use on the first page of this thread.

If you already have SeeD Reborn installed, you should only have to drag the folder with the textures into the "texture" folder and it should replace the necessary files. But without SeeD Reborn(or at least it's hashmap), this mod won't work.

I'm running into an unknown exception error in the same spot, when Squall Selphie and Zell are boarding the ship to leave the Dollet mission. I have RaW, Tonberry 2.04, Apocalypse, Horizon, LunarCry, Project Eden, SeeDReborn and Tripod installed. From the Biggs/Wedge fight up to here I didn't run into any other errors. Has anyone ran into this before?

I recommend trying the "Verify Integrity Of Game Cache" option that Steam has. It has helped fix problems that other people have had that are also similar to yours. Sometimes games don't always download properly, so think of this as a way of repairing any files that might not be working correctly. Hopefully it'll work for you as well.

Thanks Mcindus! If you tell how to do that, it won't be a problem for me. But if we still talking about the "in-menu" cards, it happens with the English version (I think also with any other, haven't tried). I mean they don't have the nice frames around the images. Seems to be the vanilla ones only. But playing a card game is okay, so all frames are new/nice etc. =)

For anyone who has problems, this should be the *.csv files package you need for tonberry 1.6 (if I'm not wrong): http://www34.zippyshare.com/v/YjKm3zpD/file.htmlBut replace them as soon as Mcindus or FatedCourage update anything.

hello there i am a bit stuck with tonberry as soon as i copy it to the game directory, the game wont run does anyone have an idea why that might be, i did have tonberry working at one time but now i no longer can, any help would be appreciated, greatly.....

Yes it is thank you for your reply and the linear filtering is unticked , what i'm getting is, an unknown exception has occurred and i have had this working before i just don't know why it isn't now, i've been working really hard on this i've been doing my best to prevent asking for help but i'm really unsure what else to do.

yes a custom driver, i was told that works with FF8 to make the mods work

Ah... Okay, I see. Then you're trying to use Aali's driver. It's not needed to make the textures work in FF8 Steam and is probably causing you a lot of problems. All you need is Tonberry, the textures, and the hashmaps.

It still crashes just after i hit play game and if i press alt and tab there's a message box saying an unknown exception has occured, i wonder what it is i could be doing wrong, i've got the collisions.csv and the hash1map.csv and hash2map.csv in tonberry and objfile.csv, thats everything right?

If you're using 2.04, then all you need is collisions and hash2map. Hash1map is Project Eden, but that has it's own hashmap now so you don't need that one. Not sure what that objfile you have is. Also, make sure you turn off the Steam Overlay or your game will crash.

Brilliant thanks for the help, no extra csv would matter though if its there would it because i have the linear filtering unticked and it crashes straight away still, just keep hearing a sound and with that message box.

If turning off the Steam Overlay didn't fix it, then I'm not sure what's causing it. You can always try an older version and see if that makes a difference. I also see that you don't have a dedicated GPU so maybe your computer can't handle it?

hmm if that was the case you wouldn't of thought it would of worked before but ill try a different tonberry and see how i get on with that, thank you for all you tried to do mate i appreciate it you've been great.

This isn't my first time to use this FF8 MOD. I've done this before and it worked well. I just don't know what happen now and I tried to fix it before posting here. Well the problem is that, it's not working at all... there's no changes in graphics.

I'm using TonberryEnhanced2.04. Contents are changed except from the .dll files and the original contents of "tonberry" folder from TonberryEnhanced2.04

I added the hashmap files from http://forums.qhimm.com/index.php?topic=15945.msg223951#msg223951 (http://forums.qhimm.com/index.php?topic=15945.msg223951#msg223951) to D:\Program Files (x86)\Steam\steamapps\common\FINAL FANTASY VIII\TonberryEnhanced2.04\tonberry\hashmap I also replaced collisions.csv & hash2map.csv taken from the previous link.

PS: Of course I did not forget the main files which are the textures to be place on textures folder on TonberryEnhance2.04 Files are taken from http://steamcommunity.com/sharedfiles/filedetails/?id=391096600

I last tried this mod working on Windows 7. I'm on Windows 10 now.TIA, I hope you can help me. :3

This isn't my first time to use this FF8 MOD. I've done this before and it worked well. I just don't know what happen now and I tried to fix it before posting here. Well the problem is that, it's not working at all... there's no changes in graphics.

I'm using TonberryEnhanced2.04. Contents are changed except from the .dll files and the original contents of "tonberry" folder from TonberryEnhanced2.04

I added the hashmap files from http://forums.qhimm.com/index.php?topic=15945.msg223951#msg223951 (http://forums.qhimm.com/index.php?topic=15945.msg223951#msg223951) to D:\Program Files (x86)\Steam\steamapps\common\FINAL FANTASY VIII\TonberryEnhanced2.04\tonberry\hashmap I also replaced collisions.csv & hash2map.csv taken from the previous link.

PS: off course I did not forget the main files which are the textures to be place on textures folder on TonberryEnhance2.04 Files are taken from http://steamcommunity.com/sharedfiles/filedetails/?id=391096600

I last tried this mod working on Windows 7. I'm on Windows 10 now.TIA, I hope you can help me. :3

The OS won't affect Tonberry since I'm using Windows 10 and all is well. Were you using an older version of Tonberry at some point? If so, you also have to replace the .dll files with the new versions.

Another thing I noticed is that you put the folder "TonberryEnhanced2.04" in the game directory. What you're supposed to do is take the content out of that folder and put it in the directory instead. Not use the folder itself.

Thanks for the reply and for the correction where to put the tonberry contents.Unfortunately, game wont run with d3d9.dll in the directory. No crash thing, it just don't start at all. :|

No problem. Ah...that particular problem... Some people have that issue and most don't. Sadly, I don't know how to solve that. And I'm not sure if someone else has or not. You can always try an older version(go back about a version or two) and see if it gives you the same results.

Thanks for the reply and for the correction where to put the tonberry contents.Unfortunately, game wont run with d3d9.dll in the directory. No crash thing, it just don't start at all. :|

It seems to be an OS related problem, a lot of people is having this very same trouble too. It seems Windows 10 is having a lot of trouble with DirectX9, it seems Micro$oft is not giving much support for now... My best advice is to get back to W7...

The OS won't affect Tonberry since I'm using Windows 10 and all is well. Were you using an older version of Tonberry at some point? If so, you also have to replace the .dll files with the new versions.

Another thing I noticed is that you put the folder "TonberryEnhanced2.04" in the game directory. What you're supposed to do is take the content out of that folder and put it in the directory instead. Not use the folder itself.

Me? Home version. I upgraded from Windows 8.1. But people had these problems before Windows 10 as well... I also reinstalled the game after I upgraded. Maybe it is an OS problem like JeMa said. Maybe I'm just lucky.

I have a question, I just installed the latest version, and various mods (here's the folders of tonberry and textures) http://imgur.com/a/qKjvu

I have the correspondent files in textures and in objmap, and the game function properly. But the screen when I enter the game had some glitches. The Squaresoft logo only show the center part, and the black square which shows the controls before the "new game - continue" menu don't show anything. And in game the exit command (esc) only show the buttons, but no the words.

So, anyone know what could be? Overlay in steam is disabled. (here are the pictures of the problem) http://imgur.com/a/XFRGf

Having some issues. First time modding FF8. Using Steam version. Using everything here:

http://steamcommunity.com/sharedfiles/filedetails/?id=391096600

Except for the "Gameplay, Beta and Future" mods

Having two issues. It seems like the backgrounds aren't smoothed out at all. Hard to tell if the originals were just that much worse or if that mod isn't working.

The biggest issue, though, is that whenever I'm done with Quistis's tutorial and try to exit the screen to the World Map for the first time, the game hangs indefinitely. The World Map music plays but there is no transition. It hangs on the screen I was attempting to leave and just sits there with Squall stuck at the edge of the screen.

I have a question, I just installed the latest version, and various mods (here's the folders of tonberry and textures) http://imgur.com/a/qKjvu

I have the correspondent files in textures and in objmap, and the game function properly. But the screen when I enter the game had some glitches. The Squaresoft logo only show the center part, and the black square which shows the controls before the "new game - continue" menu don't show anything. And in game the exit command (esc) only show the buttons, but no the words.

So, anyone know what could be? Overlay in steam is disabled. (here are the pictures of the problem) http://imgur.com/a/XFRGf

Thank to all for the hard work!

Cheers!

Thanks for posting screenshots. For starters, delete hash1map. You don't need it since you have the Project Eden hashmap. Secondly, moved collisions and hash2map out of the hashmap folder. They should reside just inside the Tonberry folder. Thirdly, I think you also installed an old version of Rebirth Flame? So you need to delete Char_Textures_hm since you already have RebirthFlame_hm. Lastly, I'm not sure what that objfile is for... But that goes in the objmap folder. Not the hashmap folder.

Having some issues. First time modding FF8. Using Steam version. Using everything here:

http://steamcommunity.com/sharedfiles/filedetails/?id=391096600

Except for the "Gameplay, Beta and Future" mods

Having two issues. It seems like the backgrounds aren't smoothed out at all. Hard to tell if the originals were just that much worse or if that mod isn't working.

The biggest issue, though, is that whenever I'm done with Quistis's tutorial and try to exit the screen to the World Map for the first time, the game hangs indefinitely. The World Map music plays but there is no transition. It hangs on the screen I was attempting to leave and just sits there with Squall stuck at the edge of the screen.

Can anyone help me efficiently troubleshoot this?

A good way to see if the backgrounds are working is to put the ProjectEden_hm in the disabled folder, restart the game, and see if you can notice any differences. Plus, you can also use Linear Filtering if you want to get rid of more pixelation as well. I'm sure you also have the Steam Overlay disabled. You might be able to fix the hanging issue by using "Verify Integrity of Game Cache" that Steam has. You right click the game in your list and it'll be in the properties.

A good way to see if the backgrounds are working is to put the ProjectEden_hm in the disabled folder, restart the game, and see if you can notice any differences. Plus, you can also use Linear Filtering if you want to get rid of more pixelation as well. I'm sure you also have the Steam Overlay disabled. You might be able to fix the hanging issue by using "Verify Integrity of Game Cache" that Steam has. You right click the game in your list and it'll be in the properties.

Indeed Overlay is disabled. I verified the integrity of cache and it found 83 files missing but from looking at the date modified, it looks like it just replaced the music files that it had been using prior to installing RaW. Couldn't find anything else added. I have to go away for a week but next weekend I'll verify that it's still not working. I appreciate your reply.

Indeed Overlay is disabled. I verified the integrity of cache and it found 83 files missing but from looking at the date modified, it looks like it just replaced the music files that it had been using prior to installing RaW. Couldn't find anything else added. I have to go away for a week but next weekend I'll verify that it's still not working. I appreciate your reply.

Hm, I guess we'll see once you make it back. To my knowledge, there are more than 83 music tracks... I recommended this method because a few others had similar problems leaving to the world map and that seemed to resolve it for the most part. And no problem. :)

Hm, I guess we'll see once you make it back. To my knowledge, there are more than 83 music tracks... I recommended this method because a few others had similar problems leaving to the world map and that seemed to resolve it for the most part. And no problem. :)

Welp, fixed that bug it looks like BUT now RaW won't reinstall properly so I have no music and the world map textures look like they're also not applying. Balamb, for example, has a lot of missing textures and nothing seems sharper or redone. It almost feels like the mods just aren't even registering.

My computer does not like Tonberry Enhanced. I've done every trouble-shooting step I can think of to get things to work, and a few I was sure would NOT work, and no matter what I do the game ends up crashing with "unknown exception" errors. I made a post asking for help in the 'Graphical Mods' section, because at the time I wasn't ENTIRELY sure it was Tonberry, but now - well, I'm sure. It's definitely Tonberry. And I don't think it's a fixable issue, at least not by me with my current level of programming skills.

HOWEVER...

Pre-Enhanced Tonberry and my computer got along GREAT. I got up to disc two using it and the mods at that time, a little over a year ago, I believe. I actually stopped playing because there were so many great mods in progress and, darn it, I wanted to be using them. So I figured I'd wait awhile and go back to it when said mods were done. There is some irony there, alas. LOL. SO - to circle around my long-winded way to the point - exactly how complicated would it be to take the current hashmaps, and convert them BACK into one file for old Tonberry to read? Is it a matter of copy and pasting, i.e. something I can accomplish on my own? Or are we talking major re-writing of said hashmaps and I'd be better off just waiting another year until I can actually afford a new computer?

I´m having the unknow error too Q.,Q i have installed the game on my old pc with all the mods, and everything was great, now I have a month with a new pc (a better one ) but yesterday I install the game and it runs whithout problem, but when I put the tomberry in the folder (i try with the old tomberries various version and the new one enhanced and nothing always the same issue) its crash the game first say>unknow problem> then FF8_EN stop working

So, since I don't have programmer skills, I start to take out file one by one just like I do in the Sims for seeing what file is crashing the game its the d3d9 when I take this one out the game keep running but obviously the mods doesn´t work i'll search in google but didn't find a solution so I'm here...

6. (Optional) If your Windows installation is not on drive C, change your prefs.txt file 'drive_letter' from C to your drive letter. If you're using textures of different sizes, change 'resize_factor' in prefs.txt.

i´ll find something but Q.,Q isn´t working yet im running game on R drive not c so ill change as the tuto said the prefs.txt. soo the game now start but mods dosent work

My computer does not like Tonberry Enhanced. I've done every trouble-shooting step I can think of to get things to work, and a few I was sure would NOT work, and no matter what I do the game ends up crashing with "unknown exception" errors. I made a post asking for help in the 'Graphical Mods' section, because at the time I wasn't ENTIRELY sure it was Tonberry, but now - well, I'm sure. It's definitely Tonberry. And I don't think it's a fixable issue, at least not by me with my current level of programming skills.

HOWEVER...

Pre-Enhanced Tonberry and my computer got along GREAT. I got up to disc two using it and the mods at that time, a little over a year ago, I believe. I actually stopped playing because there were so many great mods in progress and, darn it, I wanted to be using them. So I figured I'd wait awhile and go back to it when said mods were done. There is some irony there, alas. LOL. SO - to circle around my long-winded way to the point - exactly how complicated would it be to take the current hashmaps, and convert them BACK into one file for old Tonberry to read? Is it a matter of copy and pasting, i.e. something I can accomplish on my own? Or are we talking major re-writing of said hashmaps and I'd be better off just waiting another year until I can actually afford a new computer?

I'm not sure how this may effect compatibility, but you can copy/paste all of the separate hashmaps into one file, call it hash1map.csv and replace the old hash1map.csv with this 'new' compiled one in your old Tonberry 1.5 file structure. You might not be able to use the objmaps but the hashmaps should work this way.

Also - I believe you're dealing with a directX9 incompatibility issue. There isn't just one way to fix this... however, see if you can try updating your graphics drivers -- or, playing FF8 in compatibility mode, as administrator, and even possibly confining it to the first processor through your task manager processes tab. Are you playing in windowed mode? Try fullscreen. Also - using GeDoSaTo might fix the issue.

So - tried GeDoSaTO, but it and Vista did not seem to like each other, as I got bizarre kernel32 errors as soon as I installed it. I was playing Full Screen the whole time, so I tried Windows just in case- that did not work, of course. I'd already tried administrator, so I gave Windows XP compatibility a shot but no - no luck there either. Graphics drivers were already up to date, and up to Directx11. I actually started downloading Directx9 to see if I could downgrade when trying your processor idea, because to be honest I just didn't see how THAT would do anything... how would giving it LESS processing power make it better? I'm honestly asking, because as you probably guessed from the happy START to this reply - that fixed it. I don't get HOW that fixed it, but as soon as I loaded it with just the one CPU enabled it was running faster and even looked clearer. Got up to the glitch point - and past the glitch point - and then an HOUR past the glitch point... well, I think it's safe to say that seems to have done it.

Thank you SO much - it's very much appreciated. And my computer appreciates not being thrown out of a window, as well. But - seriously... how the heck did THAT fix it? Inquiring minds would like to know. :)

Hi Mcindus, I've followed your instructions but none of the mods seem to be working except for Rebirth Flame v1.1

I'm running Windows 7, and using Tonberry 2.04, do you know what might be wrong? These are my main folders below:

http://imgur.com/oHcCRzk

http://imgur.com/71d9JKn

http://imgur.com/qAaCO3y

I've also updated the objmap folder, and hash2map and collisions files.

Edit: Found out the problem, apparently I needed to download the texture files as well, but that has created another issue. Of the different mods, what do I do when two separate mods have the same texture folder name? For example, both LunarCry_v1.2 and ProjectEden_v1.0 have a en texture folder so if I copy both of them to the FF8 texture folder, one of them is going to be overwritten.

Hi I'm new here, and thanks to all the people devoted to moding this game, it makes a whole lot change visually and acoustically. I suit up most of the mods and they are working great, but there is only a tiny little problem, which is characters do not Blink. Though I can see in texture files, the blink texture is right there, but neither in battle nor in 2D backgrouds, no blink at all. Actually this is not a big problem, cause there isn't so much close up shot in this game so that force you starring at their eyes and see the blink, but when you are using a magic, calling a G.F, or finishing the battle they usually close their eyes. the most obvious issue is for Quistis, when she stretches herself, she will close her eye, and this not happening in HD mods. Is there a way to fix it?

I know there have been a lot of questions about this, but I'm really stuck, I cannot get this version to work. The previous versions of Tonberry work, but the as soon as enhanced is installed nothing happens. The game runs in vanilla. I started with this, then read in this forum someone installed the pervious 1.5 version and it working, which happened with me, but there are many more mods out there depending on the enhanced version.

I believe I have tried most things on here. Now if I copy over everything except the hash1map file, and keep that, the mods continue to work. But the new ones don't.

I'll be active and upload screen of anything you need. But could someone please help me? I've been struggling to get this to work on my own.

Hi everyone fist time posting. Thank you very much for your hard work, I am having an installation problem...

I have "installed" (copy and pasted all the files in the right folder) for tonberry and other stuff (seed, eden and controller mapping), unfortunately nothing happen or changed, like it is not working at all.I have windows 7 ultimate (not original), and the only thing that I couldn't do of the installation of Tonberry was the "VC++ 2010 Redistributable (x86)" because it recognise a newer version.

Hi everyone fist time posting. Thank you very much for your hard work, I am having an installation problem...

I have "installed" (copy and pasted all the files in the right folder) for tonberry and other stuff (seed, eden and controller mapping), unfortunately nothing happen or changed, like it is not working at all.I have windows 7 ultimate (not original), and the only thing that I couldn't do of the installation of Tonberry was the "VC++ 2010 Redistributable (x86)" because it recognise a newer version.

What I need to do to debug the problem?

Taking a screenshot of how you have everything set up might be helpful. Make sure you aren't using any other injector like SweetFX. Or you could be one of the rare few where the newest version isn't working properly.

As long as you have your hashmaps where they need to be, no. So far everything else looks correct. You're using both Project Eden and SeeD Reborn, like you said. So the Title Screen hasn't changed at all? Or the text and menus?

Hello. My game works fine using the d3d9.dll file that comes with SweetFX Enhancement but it doesnt load any of the new textures and if I replace the file with the one on Tonberry: Enhanced (2.04) the game crashes at launch with an unknown exception. Are they supose tu be incomplatible? btw Im also using GeDoSaToTool.

Hello. My game works fine using the d3d9.dll file that comes with SweetFX Enhancement but it doesnt load any of the new textures and if I replace the file with the one on Tonberry: Enhanced (2.04) the game crashes at launch with an unknown exception. Are they supose tu be incomplatible? btw Im also using GeDoSaToTool.

The reason both cannot work together is because each use they're own d3d9.dll file. So really, you can only pick one or the other. But you can use GeDoSaTo to use SweetFX-like effects. Just be sure to set "interceptOnlySystemDlls" to "true" in the "Edit Settings" or FF8 will most likely crash.

As long as you have your hashmaps where they need to be, no. So far everything else looks correct. You're using both Project Eden and SeeD Reborn, like you said. So the Title Screen hasn't changed at all? Or the text and menus?

not at all, it is all as the vanilla pixellated. For this reason I checked and double checked the instructions. I would like to know how to debug the problem, I feel that the "newer" version of the installation file required is not working as it should by recognising the files but I have no idea how to check that.

not at all, it is all as the vanilla pixellated. For this reason I checked and double checked the instructions. I would like to know how to debug the problem, I feel that the "newer" version of the installation file required is not working as it should by recognising the files but I have no idea how to check that.

You'd have to get in touch with the creator/contributors of Tonberry to find a solution, probably. But they are all usually busy. You could always try v1.61 and see if that works.

The reason both cannot work together is because each use they're own d3d9.dll file. So really, you can only pick one or the other. But you can use GeDoSaTo to use SweetFX-like effects. Just be sure to set "interceptOnlySystemDlls" to "true" in the "Edit Settings" or FF8 will most likely crash.

Thanks a lot for the help. gedosato its working now along the new textures. ;D

I have a question, I just installed the latest version, and various mods (here's the folders of tonberry and textures) http://imgur.com/a/qKjvu

I have the correspondent files in textures and in objmap, and the game function properly. But the screen when I enter the game had some glitches. The Squaresoft logo only show the center part, and the black square which shows the controls before the "new game - continue" menu don't show anything. And in game the exit command (esc) only show the buttons, but no the words.

So, anyone know what could be? Overlay in steam is disabled. (here are the pictures of the problem) http://imgur.com/a/XFRGf

Thank to all for the hard work!

Cheers!

I have faced the same problem, also in fight on monsters the effect of a blindness isn't displayed. Removal of the collisions.csv file has helpedWhat this file is intended for?

I cant seem to get this tonberry thing right, I used to play this game when I was really young and would like to do so again.I bought it recently on Steam but the textures suck and it's ruining my trip down memory lane.I tied doing everything posted and watching youtube videos but i cant get it to work.

Hello, created an account so i could post and hopefully get some help.

I had Tonberry working before (think it was 1.5 or something, an early version anyway) and now i cant get it working at all after deciding to reinstall FF8.

I'm not quite sure what im doing wrong either as i think i have all the files in the right place.(http://Desktop/Tonberry.png)(http://Desktop/FF8.png)(http://Desktop/hash.png)(http://Desktop/obj.png)(http://Desktop/textures.png)(if none of these photos worked, you can try http://imgur.com/a/mTuNQ)

When i load the game, the start screen hasnt changed, character models lookk like theyve changed but unsure, backgrounds havent changed and neither have the text or cards. I'm bamboozled by this now.

Hello, created an account so i could post and hopefully get some help.

I had Tonberry working before (think it was 1.5 or something, an early version anyway) and now i cant get it working at all after deciding to reinstall FF8.

I'm not quite sure what im doing wrong either as i think i have all the files in the right place.(http://Desktop/Tonberry.png)(http://Desktop/FF8.png)(http://Desktop/hash.png)(http://Desktop/obj.png)(http://Desktop/textures.png)(if none of these photos worked, you can try http://imgur.com/a/mTuNQ)

When i load the game, the start screen hasnt changed, character models lookk like theyve changed but unsure, backgrounds havent changed and neither have the text or cards. I'm bamboozled by this now.

Looking at the pictures, it looks like you're missing the SeeD Reborn hashmap. As for everything else outside of SeeD Reborn, it looks like you don't have the textures for those specific mods you're wanting to use in the texture folder. Only their hashmaps. You also are saying something about character models? Not sure if you mean Rebirth Flame since I see neither the textures or hashmap for it in your pictures. And I'm also not sure what that objfile.csv is that's inside your Tonberry folder.

So i dont need the objfile.csv? Yeah i forgot to screenshot after i added in rebirth flame. So all im missing is textures and a hashmap? Im sure i downloaded everything from the links.I'll go have another try and see how i get on.

EDIT: So after somehow missing all the texture files and such, this is my folder structure for the texture and hash folders (obj folder still only has lunerCry only in it)http://imgur.com/a/mTuNQ

Loading the game now has updated GUI, start screen, cards, text and characters but i dont think the backgrounds are updated? am i missing anything else? (sorry for the constant questions :P

So i dont need the objfile.csv? Yeah i forgot to screenshot after i added in rebirth flame. So all im missing is textures and a hashmap? Im sure i downloaded everything from the links.I'll go have another try and see how i get on.

EDIT: So after somehow missing all the texture files and such, this is my folder structure for the texture and hash folders (obj folder still only has lunerCry only in it)http://imgur.com/a/mTuNQ

Loading the game now has updated GUI, start screen, cards, text and characters but i dont think the backgrounds are updated? am i missing anything else? (sorry for the constant questions :P

Everything looks to be in place now. I don't think you'll be needing the objfile.csv anymore. The backgrounds are upscaled, so it is working. Project Eden still needs some work, so you'll likely find a few issues like those black lines here and there.

I just downloaded this and Project Eden for testing purposes.(Since this replaces the classic tonberry I'm a bit confused about stuff (hashmaps) going in the \tonberry or \tonberry\hashmaps.

I put the Project Eden hashmap in this folder: D:\Steam\steamapps\common\FINAL FANTASY VIII\tonberry\hashmapAll the textures are in: D:\Steam\steamapps\common\FINAL FANTASY VIII\textures(Steam Overlay is disabled and it's a clean install)It doesn't matter if I choose a direct path in the prefs.ini either.

I just downloaded this and Project Eden for testing purposes.(Since this replaces the classic tonberry I'm a bit confused about stuff (hashmaps) going in the \tonberry or \tonberry\hashmaps.

I put the Project Eden hashmap in this folder: D:\Steam\steamapps\common\FINAL FANTASY VIII\tonberry\hashmapAll the textures are in: D:\Steam\steamapps\common\FINAL FANTASY VIII\textures(Steam Overlay is disabled and it's a clean install)It doesn't matter if I choose a direct path in the prefs.ini either.

But I get an CTD as soon as I start :((unknown error)

You got the file paths correct. When you open /textures/, do you see a bunch of two letter named folders?

Also, do you have the new Tonbery .dlls? They go in your FINAL FANTASY VIII folder.

I tried updating / downloading VC at the very start of the process but I got always the message, that there are newer version of it already on my system (Win 10). So there is no way to update either VC 2010 or VC 2015.Folderwise it looks like this atm:

Regarding the Tonberry-DLLs: Which one do I need? From Tonberry enhanced or from the "classic" Tonberry project?

You need only the .ddl's from the newest version of Tonberry.Can you screenshot your FINAL FANTASY VIII/ parent folder and your FINAL FANTASY VIII/textures folder?You don't need VC if you have a newer version, so you're good there. Try running FF8 in 'compatibility' mode. If that doesn't work, go into your TaskManager and assign FF8 to only use the first core of your PC. I've heard this works for Win10

Thanks for the tip - it worked with the DDLs of the original Tonberry :)

I know it's maybe not the correct topic but I don't want to open up some new one either.So: The game runs fine now "vanilla" but if I want to use GeDoSaTo (even with native 1920x1080) the game crashes. It crashes as well if I disable all post processing effects.Is there anything I can do? (Win 10)

Thanks for the tip - it worked with the DDLs of the original Tonberry :)

I know it's maybe not the correct topic but I don't want to open up some new one either.So: The game runs fine now "vanilla" but if I want to use GeDoSaTo (even with native 1920x1080) the game crashes. It crashes as well if I disable all post processing effects.Is there anything I can do? (Win 10)

Go into "Edit Settings" and set "interceptOnlySystemDlls" to true and that should hopefully fix the crashing problem with using GeDoSaTo.

This one worked as well and I can see the finish line already.But the post processing doesn't seem to work (enabled split screen for testing-purposes).Is there something else to consider?

Some texture.packs work very well like Project Eden or Horizon.But Rebirth Flame doesn't work :((doesn't matter which version or if the hashmap is either in \tonberry or \tonberry\hashmaps.This is strange.

This one worked as well and I can see the finish line already.But the post processing doesn't seem to work (enabled split screen for testing-purposes).Is there something else to consider?

Some texture.packs work very well like Project Eden or Horizon.But Rebirth Flame doesn't work :((doesn't matter which version or if the hashmap is either in \tonberry or \tonberry\hashmaps.This is strange.

That's good. :) The most I can say about the post processing is that you have a choice between two types. Each type has its own settings. And I assume you're going with the one Mcindus has set. So be sure to choose "Alt. Post Processing" settings to edit that one.

That is odd. It should work if the others do. You did take the "ch" folder out of whichever pack you chose and put that in the texture folder, yes?

As you can see background is Project Eden but the characters still look vanilla :( (http://www2.pic-upload.de/thumb/32098142/garden_entrance.jpg) (http://www.pic-upload.de/view-32098142/garden_entrance.jpg.html)The Horizon pack worked as well:(http://www2.pic-upload.de/thumb/32098145/worldmap.jpg) (http://www.pic-upload.de/view-32098145/worldmap.jpg.html)SeeD-Reborn aswell:(http://www2.pic-upload.de/thumb/32098143/menu.jpg) (http://www.pic-upload.de/view-32098143/menu.jpg.html)So I have no clue why the h*** Rebirth Flame doesn't work - textures are alll in the folders like the other projects that work and the hashmap is even in both folders (\tonberry or \tonberry\hashmaps)

As you maybe realized already: There's some bar still visible. This happens if I don't choose Fullscreen in the launcher. If I do, something more strange happens: Instead of a fullscreen-image, the game is displayed in a small window:

This is because you are using hash2map.csv and not the individual hashes with the new version of Tonberry. The old version of Tonberry can only do the mods up to a certain point because it doesn't have the ability to see the hash files individually. You should really replace those dlls with the new ones. The new Tonberry also has texture caching, etc. Much easier to manage.

There is a 'hackish' way to go about it, but it's not desirable and you would encounter a lot of errors.

Well... this whole Tonberry vs. Tonberry enhanced is getting confusing :oI'm still not into it actually. Do I need both? Is the "classic" one obsolete? (why is it still linked under "essential mods" then?)What folder structure is needed (\tonberry or \tonberry\hashmaps)? Which DLL's I need? :(I know this is a stupid question but this issue wasn't mentioned in your tutorial vid f.e.

So what do I need to do? Dump all DLL's from Tonberry enhanced and that's it?

Well... this whole Tonberry vs. Tonberry enhanced is getting confusing :oI'm still not into it actually. Do I need both? Is the "classic" one obsolete? (why is it still linked under "essential mods" then?)What folder structure is needed (\tonberry or \tonberry\hashmaps)? Which DLL's I need? :(I know this is a stupid question but this issue wasn't mentioned in your tutorial vid f.e.

So what do I need to do? Dump all DLL's from Tonberry enhanced and that's it?

PS: Did you manage to get CRT working with GeDoSaTo? PPS: Is there anything I can do about this frame / mini-window (when using fullscreen) when going for 3840?

Just go to the tonberry enhanced page and download the whole package. Delete the old version of tonberry (except for your textures folder - you can still use this one with the new tonberry). Then you must place the individual hash files (they normally end in "_hm.csv", like "SeeDReborn_hm.csv") and put those files (they come with the mods) into tonberry/hashmap. The old Tonberry is obsolete - and the 'essential mods' page isn't really 'essential' it's more 'all the mods' lol. Go with the MCINDUS mods guide via Steam for a more up to date mods package list.

CRT works just fine with GeDoSaTo. Is your monitor's resolution 1920x1080? That's the only way to use 3840 properly. Just double your resolution and plug it into gedosato. Also, make sure your monitors refresh rate is correct. This should fix your windowing, I believe. Make sure you select the new resolution in the FF8_Launcher settings before you launch the game.

I think I'm going to do a GeDoSaTo comparison via screenshots to show people what they can do with it. It's pretty massive.

Edit: I think I figured out my problem. It seems I missed out on some hashmaps. Reinstalling everything again just to make sure I didn't miss anything else.Thanks!!

Edit 2: Everything is working fine now!! Thanks for the guide and your hard work =D

Hi Mcindus,Thank you for your contribution!I have followed one of your guides but I don't think any changes have taken place on my FFVIII at all.I don't have any previous versions of Tonberry installed and I installed everything onto a fresh installation of FFVIII.Please take a look at my directories in the images below. Is there anything that I missed or doing wrong?Thanks!!

Thanks for your many tips FatedCourage and Mcindus - I finally made it work texture-wise (even with Project Hellfire) - windowing, etc. --> gone! :)

I still can'r get some small CRT-things to work (would do some small wonders graphic-wise I guess)I tried copying the settings from this https://sfx.thelazy.net/games/preset/1033/ into GeDoSaTo but it does nothing o.OOther stuff like small luma- and texture-sharpening works a tiny bit.

Could someone post a setting for the CRT-stuff?

PS: If I use the Addons and therefore a new Launcher, do I have to edit GeDoSaTo'S whitelist?

Thanks for your many tips FatedCourage and Mcindus - I finally made it work texture-wise (even with Project Hellfire) - windowing, etc. --> gone! :)

I still can'r get some small CRT-things to work (would do some small wonders graphic-wise I guess)I tried copying the settings from this https://sfx.thelazy.net/games/preset/1033/ into GeDoSaTo but it does nothing o.OOther stuff like small luma- and texture-sharpening works a tiny bit.

Could someone post a setting for the CRT-stuff?

PS: If I use the Addons and therefore a new Launcher, do I have to edit GeDoSaTo'S whitelist?

You have mostly everything correct -- delete 'collisions.csv' and 'hash2map.csv' because you don't need them anymore.

In order to use the CRT settings, you have to pick 'edit postprocessing' and enable it there, in gedosato. Also make sure you don't use a different postprocessing plugin like asmodean if you're using sweetFX.

You should look through the gedosato forum post and direct any more questions there.

Hi friends. Thanks for all your work upscaling my childhood - it really is looking great.

I am trying to run FFVIII and Tonberry using Wine on mac. I have got all the mods working, apart from Tripod and Hellfire (out of choice) which was a challenge in itself (trial and error with .dlls etc using winetricks) but unfortunately get a lot of unknown exceptions. I wonder if it is to do with the cache, as the game can run for a short amount of time before crashing. Do you have any suggestions as to other .dlls or areas that I can look to tweak in order to sort these problems? I understand that Mac is not really supported.

Would a legacy version help, as it does not leave textures in the cache?

EDIT: I have attempted to increase the video memory available on Wine using direct 3D registry keys, which has helped - I now get longer before the error. It also seems to help if I disable Project Eden, as I get longer play time before it crashes out. Without ProjEden I could get from Squall's dorm dressed in pre-Dollet uniform to the world map, where it would crash. Without ProjEden I can get as far as the Dollet beach.

Hi friends. Thanks for all your work upscaling my childhood - it really is looking great.

I am trying to run FFVIII and Tonberry using Wine on mac. I have got all the mods working, apart from Tripod and Hellfire (out of choice) which was a challenge in itself (trial and error with .dlls etc using winetricks) but unfortunately get a lot of unknown exceptions. I wonder if it is to do with the cache, as the game can run for a short amount of time before crashing. Do you have any suggestions as to other .dlls or areas that I can look to tweak in order to sort these problems? I understand that Mac is not really supported.

Would a legacy version help, as it does not leave textures in the cache?

EDIT: I have attempted to increase the video memory available on Wine using direct 3D registry keys, which has helped - I now get longer before the error. It also seems to help if I disable Project Eden, as I get longer play time before it crashes out. Without ProjEden I could get from Squall's dorm dressed in pre-Dollet uniform to the world map, where it would crash. Without ProjEden I can get as far as the Dollet beach.

Thanks

Try to make sure FF8 is only using the first processor core on your CPU -- also, try lowering the cache in Tonberry's prefs.txt file

Quick question - This (and other mods) state they are incompatable with the Steam overlay, but if I turn the Steam overlay off, my Steam Controller seems to stop working. I was wondering if anyone here knew of a way to fix this, or if it is simply a choice between using my Steam controller or nice updated textures...

Quick question - This (and other mods) state they are incompatable with the Steam overlay, but if I turn the Steam overlay off, my Steam Controller seems to stop working. I was wondering if anyone here knew of a way to fix this, or if it is simply a choice between using my Steam controller or nice updated textures...

If you use GeDoSaTo and customize your ini file to allow for the steam overlay to load in advance, then you might be able to use your controller with the mods.

Thanks to everyone who have worked on the various graphical mods. I've played FF8 Steam last year with various mods installed, and everything worked fine. But now I'm trying to reinstall the game with mods and I'm having some trouble getting it to work.

I've only installed the game and Tonberry only so far (v2.04). This is how my FF8Dir looks like:

(http://i.imgur.com/Xm2ZqP7.png)

Note that I've renamed "d3d9.dll" in the screenshot above.

Here is my tonberry dir:(http://i.imgur.com/s3m34S9.png)

The ff8/textures and hashmap folders are empty, since I've only installed Tonberry and no actual mods yet.

Here is my in-game ff8 config screen (I could only get the launcher and game to work if I rename the d3d9.dll):(http://i.imgur.com/BSOy761.png)

And finally, here is what happens if I try to run the game with "d3d9.dll" filename restored.

(http://i.imgur.com/j4LjMT9.png)

I've tried installing VC++ redist, .NET framework, DirectX, and they all seem to be up-to-date. I've also tried restarting windows and setting the exe to run as admin. My OS is Windows 10.

I've seen this issue with Windows 10 before... Try running FF8 from your first processor core only. Set that up by right clicking on the ff8 exe in your task manager and setting it to CPU 0. Shouldn't have to do this, but it might be a quick fix.

Also - check to see if your DirectX drivers are up to date. You might need to 'roll-back' your drivers. This seems to be a directx9 issue, mainly.

I've tried doing this, but the problem is, next time I run it, it goes back to "all processors", and I have no idea how to make it "stick". Since I have to rename the dll back, and then re-run the launcher, it will just go back to "all processors", and I get the same error (hence not being able to switch to single-core).

Thanks for the reply, Mcindus.I've tried doing this, but the problem is, next time I run it, it goes back to "all processors", and I have no idea how to make it "stick". Since I have to rename the dll back, and then re-run the launcher, it will just go back to "all processors", and I get the same error (hence not being able to switch to single-core).DirectX should be up-to-date already. I've run this installer:

https://www.microsoft.com/en-gb/download/details.aspx?id=35

and according to the installer, I have the latest or newer version installed. I'm not sure how to roll-back to an older version, nor which version I should try using.

It was set to 250, but after changing it to 100, I still got the same error.It was Jan 2016 according to my Steam achievement timestamp (I got the last achievement when I played most recently), so yes, I believe it was Windows 10.

It was a different system though (desktop). Right now I'm trying to run it on a laptop (don't have the desktop anymore).

Compatibility modes (win8 and win7) don't seem to solve it either.Oh, and I forgot to mention this in my original post: I've turned off the steam overlay and cloud saves.

Hello, sorry for my bad English. Thx for your Works.When I install Tonberry, the game does not start the LuncherVC ++ 2010 Redistributable is up-to-date.Steam Overlay is offMy OS is Win10

Renaming the d3d9.dll disables tonberry completely, which is why you shouldn't do that at all. Leave that file alone.

Make sure that you're modifying ff8_en.exe and NOT ff8_launcher.exe in the task manager.

Most likely, this is an issue with a 32 bit application and a 64 bit application conflicting.

Everything I read up on is saying it's a software issue with the DirectX9 dll's required for the game. The microsoft link you posted directly says it does NOT update key components of the directx9 -runtime- because it is a part of your Windows install. This issue pops up on other games that require d3d9.dll. To fix this, you need to make sure you have all of the Direct X runtimes (will not load with the web-based auto-launcher - download it from your windows updates).

If I were you guys, I would open up my windows updater and see if there's anything that is related to DirectX9 that you can install.

This is a stupid error on Microsoft's part - they should have included -everything-, and instead make certain fundamental drivers 'optional installs' and force some weird backward incompatibility issues because of it. Also - they placed a 'hard cap' on all 32-bit games so they can't use more than 4GB of VRAM in Win10 for some reason...

Also - update your graphics drivers for your GPU - even if it's the on-board one.

This could also be an issue with a poorly written 'monitoring' program that is conflicting with d3d9.dllHere's some more information:https://answers.microsoft.com/en-us/windows/forum/games_windows_10/windows-10-directx-9-appsgames-all-fail-with/23ef2a8a-3cd4-4df3-af20-e87e10e334dc?auth=1

Well this is awkward.Normally I would try to back my posts up with crash dumps or whatever theyre called, but the problem im currently having is sort of unique for me, usually I can figure it out simply reading the crash popup, but thing is, the problem im having is that the moment im starting FF8_launcher I get the seizure warning, but then nothing, the launcher dosnt popup at all.

Things ive tried:disable Tonberry. <works>

disable Tonberry by renaming D3D9 while starting the Launcher, but change the name back again before I start the game <works> first I thought this would do nothing, but it did change somethings, such as my font, its BOLD now, I cant remember which mod did that, but that specific part seems to work, but nothing else as far as im aware. (first time playing with mods, and steam, I cant tell what changed or not really)

Well this is awkward.Normally I would try to back my posts up with crash dumps or whatever theyre called, but the problem im currently having is sort of unique for me, usually I can figure it out simply reading the crash popup, but thing is, the problem im having is that the moment im starting FF8_launcher I get the seizure warning, but then nothing, the launcher dosnt popup at all.

Things ive tried:disable Tonberry. <works>

disable Tonberry by renaming D3D9 while starting the Launcher, but change the name back again before I start the game <works> first I thought this would do nothing, but it did change somethings, such as my font, its BOLD now, I cant remember which mod did that, but that specific part seems to work, but nothing else as far as im aware. (first time playing with mods, and steam, I cant tell what changed or not really)

changed all the hashmaps <Didnt work>

disabled all the mods, and simply only running Tonberry <Didnt work>

reinstalled essentials like VCR and DirectX <Didnt work>

Tried debug <Didnt work>

EDIT: Im running on OS windows 7. Ultimate if that matters.

You might have a weird monitoring program getting in the way of the D3D9.dll... try shutting everything off but steam.

Sounds like an issue with driver conflicts. Did you try all of the above instructions for the directx9 installs? the web installer doesn't install everything. What mods are you using?

You might have a weird monitoring program getting in the way of the D3D9.dll... try shutting everything off but steam.

Sounds like an issue with driver conflicts. Did you try all of the above instructions for the directx9 installs? the web installer doesn't install everything. What mods are you using?

Its not a problem with monitor programs, thats the first thing I check after something, anything really, fails to start, or load. My computer is completely up to date, so I should have the latest updates for Directx 9.And as for mods:

Basiclly all texture mods that was listed here https://steamcommunity.com/sharedfiles/filedetails/?id=391096600Except for World UV Texture Patch[forums.qhimm.com] by MaKiPL

EDIT: I do recall during installation of all the mods that some folders and files asked to be replaced/moved, I simply replaced them every time, cause I was told that all these mods should go together. Maybe Im wrong?

2nd EDIT: by running compatibility mode Windows XP service pack 2, I manage to load the launcher for 0.5 seconds before it disappears (completely serious here) if I time it correctly I can manage to press play game before the launcher disappears, and the game starts fine, I also know some mods, or all mods, are working since the font has changed to the bold one at the new game/ load save menu.I press load save, selects a save where I know im on the overworld(if that helps) the moment the load bar is finished after selecting the save I want, the game freezes.

Its not a problem with monitor programs, thats the first thing I check after something, anything really, fails to start, or load. My computer is completely up to date, so I should have the latest updates for Directx 9

Still sounds like it's a DirectX9 issue. Follow all of the links on this page regarding the issue... it's a common one. D3D9.dll is a 'developer' dll - and isn't part of any 'normal' installs since DX11 came out.

Also - try to run FF8 on a single core through the task manager. This might help.

Still sounds like it's a DirectX9 issue. Follow all of the links on this page regarding the issue... it's a common one. D3D9.dll is a 'developer' dll - and isn't part of any 'normal' installs since DX11 came out.

Also - try to run FF8 on a single core through the task manager. This might help.

Ah, alright, Yeah, ive been doing Directx problem solving for days with nothing to show for it, and to be honest I thought for sure that after I manage to actually launch the game that Directx wasnt the problem.

2nd EDIT: by running compatibility mode Windows XP service pack 2, I manage to load the launcher for 0.5 seconds before it disappears (completely serious here) if I time it correctly I can manage to press play game before the launcher disappears, and the game starts fine, I also know some mods, or all mods, are working since the font has changed to the bold one at the new game/ load save menu.I press load save, selects a save where I know im on the overworld(if that helps) the moment the load bar is finished after selecting the save I want, the game freezes.

I even manage to load a save thats NOT in the overworld and it works fine, its only the overworld save that seems to freeze. Granted I only have 2 saves, 1 overworld, 1 in deling city.

I remember i had the same issue on another game,dragon quest viii. It was because in the launcher i configured the game to be full screen.

Thanks mate, yeah Ive read that one aswell, even went so far as to make it a launch option in steam itself, didnt work im afraid, but I do know that others that had D3D9 problems have solved it that way.

Ok, I need help. For the life of me, I am unable to get anything to work. I have downloaded the texture packs of eden,seed,etc. placed them in the main game folder under textures. I have also downloaded and place tonberry in main game folder. I have put all the hashpack in the haskpack folder. I don't see any obj files. I am trying to introduce my wife into some of the older FF, but she is turned off by graphics. She got spoiled on the FFX remastered.

So I am also having the issue where direcX is being a jerk. Ive been working with McIndus via email and am posting here as a last resort. I have windows 10, my steam overlay is turned off. Geforece experience monitoring is turned off. I use windows defender.

I run the directX installer to no avail. I opened the june2010 file itself, and the infinst.exe wont run. right clicking on the various inf in that .cad result in at least one install trial that did "something" and the game still wont launch.

the Ultima launcher quickly brings up the seizure warning and the FF8_ULTRA_LAUNCHER.exe states: "FF8_Launcher.EXE opened successfully. Attempting to laod by Process Name (FF8_EN.EXE)... Still Waiting....Click "PLAY!""

however, once i hit ok on the seizure warning....big fat nothing.

McIndus and I believe it is an issue with the d3d9.dll, d3dcallback.dll, and zlib.dll.

It may be as simple as i cant install the DX properly cause im dumb? idk.

So, i think i will have to give up. I get the following error and tried the things on the next page. http://www.errorlive.com/exception-code-0xc0000005I got the launcher to start up with Method 3. however, the game then crashed. Im just gonna rest on this. im posting this incase it helps someone else.

Great collection of mods and I did purchase the Pandora mod pack. Playing through the game when I came across the part where squall is carrying Rinoa on the train tracks to Esthar their bodies disappear behind a block whenever they pass a light pole. I did a fresh install leaving out Project Eden and Rebirth Flame

I thought by chance that might fix what I saw plus some other odd glitches or blimps/misplaced lines in the background. I think using Edens textures with Angelwings hashmaps has some hiccups. Unfortunately, I didn't save anywhere around the train tracks so I'll have to track down a save at that point to see if this fixes it. I also notice that the characters blink their eyes with the original textures. I actually would like a character mod that upscales the current pixels much like Angelwings backgrounds. The characters are a little too plastic in Rebirth Flame if you know what I mean.

Otherwise great set of mods! I look forward to more and hopefully a Final Fantasy VIII remake before I die. One can hope.

For everyone who got the error (http://i.imgur.com/j4LjMT9.png) and with any exception code error (I guess).Download this dll files and put them into your FF8 directory: https://drive.google.com/open?id=1YU0k71W9xH7yWRhBR30VB097QDRhEoYbThis is an error for Windows 64 bit i guess, because i did run the game everything fine on Windows 32 bit, but then after I upgraded my OS to 64 bit, I got this error. And I noticed that when u installed the game, it directed to Program Files (x86) Folder, so after all i bet that x86 dlls might work. Windows 64 bit can run both software (x64 and x86) but the file itself still stayed as (x64 or x86) type file.

I fixed mine and now I can play everything fine with mods. I would be glad if this could help anyone who got the same error. :)

It came from here : https://support.microsoft.com/ja-jp/help/3179560/update-for-visual-c-2013-and-visual-c-redistributable-package(Microsoft Visual C++ 2013 x86)We can run FF8 with Tonberry on Windows 32 bit without any errors but, on Windows 64 bit, we have to put msvcp120.dll and msvcr120.dll (x86 ones) into your FF8 directory to run FF8 with Tonberry. If u dont play FF8 with Tonberry, then u dont have to put those dlls into your FF8, the game would run everything fine without any errors.

It came from here : https://support.microsoft.com/ja-jp/help/3179560/update-for-visual-c-2013-and-visual-c-redistributable-package(Microsoft Visual C++ 2013 x86)We can run FF8 with Tonberry on Windows 32 bit without any errors but, on Windows 64 bit, we have to put msvcp120.dll and msvcr120.dll (x86 ones) into your FF8 directory to run FF8 with Tonberry. If u dont play FF8 with Tonberry, then u dont have to put those dlls into your FF8, the game would run everything fine without any errors.

These are microsoft VC+ redist files - in which i mention that you need to update if you run into that specific issue on my MCINDUS Mods Guide via Steam, and it also states this is the original Tonberry thread. It is good to know however, that you need a newer version if you're using a 64 bit OS.

hello, i'm currently getting this problem at the main menu (after square enix's logo) . Can anyone help me fix it ? https://imgur.com/a/ijeWC

I think this is a problem with the collisions.csv and hash2map.csv either not working properly, or providing the wrong codes. To stop this from happening, try downloading the collisions.csv and hash2map.csv from the "Project Angelwing" thread and install it into your main Tonberry folder instead of the original ones. If that is already what you've done and you're encountering this error, try to re-download the collisions and hash2map from the Tonberry 2.04 download and put those -back- into your folder.

Hello, I have same issue. I've tried replacing those files, both redownloaded Tonberry files, and tried Project Angelwing files, but the issue remains for me. The game seems to works fine, and mods seem to work though. (Although I can't say if everything works, because I've only just started the game.) Weird. Would appreciate any help, because it keeps bugging me, I keep wondering if it will break something down the line.