Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - JeMaCheHi

Pages: 1 2 [3] 4 5 6 7 8 9
51
All of the character texture mods currently use the objmap.csv file for their locations.  I am using them in conjunction with a few hashmap codes for my enemy upscale and they seem to work great!  They seem to dominate, so if you use a texture that shares a hashcode with another one, Tonberry will populate both and show incorrect textures.  The reason a lot of people are seeing 'missing' textures is because the game is populating the art from the same hashmap, but possibly a different part of the image.  I'm still working on an effective fix without the need for a better hashing algo, and I'm making progress.

Since Tonberry internal implementation of the hashmap was made with a map structure, if you guys put two or more texturenames with the same hashcode, the map structure will keep just one of them. By definition, every key on a map (in our case, the hashcode) is unique. That's why a duplicated hashcode means losing one of the textures.

BTW Mcindus, I LOVED you changing the red 0 in battle hud with a skull. Hope you include it on the next SeeD release ;)

52
I posted a little update guys, check it out.

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

54
One MAJOR issue regarding hashcodes.

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.

BTW, glad you liked it, messiahgov!

55
Cool! Don't delete the debugging textures so we can rehash them in case Tonberry algorithm is remade...

56
in addition to collision.csv, objfile.csv and hash2map.csv coming from tonberry hashmap v1.3, I've
horizonPack
seedReborn
Tripod
ProjectEden

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

Yes, I want you to merge these 4 files. Don't care about the order, the program will reorder them internally.

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

https://drive.google.com/file/d/0B80OIcIggJEdZkZzZTZ0OHlpVms/view?usp=sharing

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.

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

59
Also, I did upload a few videos showing the textures in action. Just for people curious on how it looks.

https://www.youtube.com/watch?v=j9Pl5wIN1II
https://www.youtube.com/watch?v=zbggrdripv0

I plan to start working on this again soon now that I'm out of my funk.

Wow, great work. I think I fell in love with that Ultimecia <3

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

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

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

HorizonPack
Project Eden
SeeD Reborn
Tripod

It's the only change from the original Tonberry, everything else remains the same. You hasn't to change any texture file. You hasn't to uninstall any previous dlls, just overwrite everything :)

62
Thanks guys for your comments, I've updated the main post with the missing info.

63
Tonberry: Enhanced v2.04 by JeMaCheHi and mavirick
External Texture Support for Final Fantasy VIII
*Beta version, please let me know if there is something preventing you from using it


                   

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

Downloads:

Download v1.6
Download v1.61
Download v2.01
Download v2.02
Download v2.03 Link Dead
Download v2.04


This is how it works:
  • 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.
Installation:
It's fairly similar to Tonberry's previous versions
  • Install VC++ 2010 Redistributable (x86)
  • Extract TonberryEnhaced1.6.zip directly into your FF8 directory (I'll call it [FF8Folder] from here)
  • Copy all your hash files to [FF8Folder]/tonberry/hashmap folder
  • Copy all your obj hash files to [FF8Folder]/tonberry/objmap folder
  • Copy the rest of .csv files (collisions.csv and hash2map.csv) in "[FF8Folder]/tonberry" folder (Thanks Mcindus for pointing it out)
  • Download and copy the corresponding textures to [FF8Folder]/textures (on its propper directories, off course!)
  • Check the prefs.txt file for configuring your particular Tonberry instalation. You will find instructions on it!
Hashmap files collected by Mcindus:


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

HorizonPack
Project Eden
SeeD Reborn (English)
SeeD Reborn (Spanish)
SeeD Reborn (French)
SeeD Reborn (German)
Tripod (English)
Tripod (Spanish)
Tripod (German)

Other hashmaps:
Project Hellfire  G.F. Summons hashmap

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

An important note from Omzy:
*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.*

64
Hey guys, to add a bit more clarity, another message I sent JeMaCheHi might also be helpful:

Oh yes, that will be more than welcome, I forgot to paste that one too...  :-[
Well, hope someone help with the hashing :)

65
Hi everyone, I was PMing with Omzy about improving Tonberry and he asked me to tell you guys just in case you want to help or something. Here it goes:

While I think the directory enhancement is a good idea, the most necessary improvement lies in the hashing algorithm. That is the key to fixing all of the bugs. The way it stands Tonberry will always have bugs. You can understand this if you modify the hash algorithm to something simple like every sixteenth pixel, you will notice many more errors. If someone can sit and think hard about the best possible algorithm we will have a much better and successful Tonberry. Also if someone figures out how to avoid animation lag and incorporates that into the build. To see what directx calls are being made I used a program called PIX for Windows in case that helps.

Yes that will mean rehashing but it is as simple as running all the images through a script-- just make sure that the new algorithm is the final version so it doesn't have to be done again. If you haven't yet, refer to the pre-Tonberry thread in scripting and reverse engineering section from last year. I forgot the name of the thread but I started it.

Regarding release, I think it's a good idea to start a new thread so you can maintain it and call it something like Tonberry: Enhanced and put a link to the original.

So... Anyone interested in enhacing it's algorithm should refer to original Matthew Fisher website (look at Omzy's first post) and check the source code and... start thinking! :D

66
Of course I'm going to work on worldmap next. :)
Didn't touch the walkmesh yet, but as far as I just fast looked on those files is:

Wmrail is set of points. Probably points telling where tracks should go, just like splinemesh in UnrealEngine, but I'm not sure yet.
Wmtex is just a file containing textures only
Wmset is a file containing balamb garden model, train models, probably towns, consist similiar geometry data as levels and characters.
Wmsetus - almost same as above, but does have some differences?
And that biggest 20 MB file. Didn't test it out, but appears it doesn't have any textures in it.

I'll finish this .x file (texture support, and tool for it), then I'll start on worldmap. 

Wow, we'll take your word for it. That will be a really amazing tool indeed.

67
Very impressive video. The AI is opcodes just like the field files, right? I need to edit sounds into the battle scenes someday, and it looks like you're almost there.
Thanks!

Yeah, is opcode based, but it's still a bit messy for me. It seems that each opcode has certain number of associated bytes. I'm still discovering a lot of them but... it's a lot of work to do man. About battle sounds... I have no idea, but i'd bet they are stored with each attack, ability or spell.

68
This video is private. Mark it as public or unlisted.

EDIT: Working now. Looks freaking cool. Is the text box started when monster is defeated, or after dropping to some % of HP?

Hi MaKiPL, it's after dropping certain % of HP (doesn't remember just now). I think it's on a textbox, but not sure.

PS: I've been looking your work on .X files, it's really awesome. I think that combining the modification of .dat, .out, and .x files, we could make quite impressive and complete mods

69
Oh man, that thread caught my attention indeed... Finally someone is researching battlefield scenes. I think the .X files has much to do with the scene.out file...

70
Here's the video showing some stuff as promised:

http://youtu.be/FqXjO18fYFU

71
Is the same true for in-battle cutscenes, like when there's dialogue?

I'm afraid that I'm not understanding what are you saying...
You mean when, for example, Ultimecia starts to levitate and says "I'll summon blablablabla..."? If that's so, yes, it's the same. Yesterday I made some progress, I'll upload a video showing up as soon as I can, showing all that stuff.

72
Sorry for not been posting here for a long time... Have been real busy. The last thing I discovered is that an enemy summoning (for example Ultimecia calling griever) is coded as an enemy attack, and has to be edited in the AI script in the .dat file. Will post more info as soon as I can.

73
A few people thought I should post this here.

Thanks to Norwin, I've created a new mod for Xbox360 and PSX Controller Buttons!
Check it out:
http://forums.qhimm.com/index.php?topic=15905.0

Oh man, you kidding? I'm out a month or so and you release that so much desired button mod! Hahahaha congrats bro, I'll check it out as soon as I can.

74
I'll revive this thread since FFVIII and VII have discount again. Get them if you haven't :D

75
Oh god, that map looks GORGEOUS. I can't wait to see this finished...

Pages: 1 2 [3] 4 5 6 7 8 9