Author Topic: [PC] External Texture Support - Tonberry: Enhanced (2.04)  (Read 467517 times)

Nightshade

  • *
  • Posts: 11
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #50 on: 2015-03-14 09:57:46 »
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
Installation:
Owerwrite d3d9.dll with my files in game folder.(After installing tonberry)

Nightshade

  • *
  • Posts: 11
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #51 on: 2015-03-14 13:56:36 »
And...



With tonberry can not pass episode in space. This is very big BUG.(No spacesuit in the picture)
« Last Edit: 2015-03-14 14:01:05 by Nightshade »

Devina

  • *
  • Posts: 197
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #52 on: 2015-03-14 20:34:52 »
With Tonberry 2.0, I keep getting "An unknown exception has occured" error messages. :(

Can't get past the title screen.

Mcindus

  • *
  • Posts: 929
  • Artist, Modder, Musician.
    • View Profile
    • Lunatic Pandora
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #53 on: 2015-03-14 21:10:10 »
With Tonberry 2.0, I keep getting "An unknown exception has occured" error messages. :(

Can't get past the title screen.

Tonberry 1.61 or even 1.5 is still recommended until the 2.0 fix is out.  Also, try disabling the Steam overlay or using my GeDoSaTo config to fix the overlay from crashing Tonberry

Devina

  • *
  • Posts: 197
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #54 on: 2015-03-16 16:39:27 »
Disabling the Steam Overlay seems to have fixed the crash.

So it seems Tonberry 2.0 is much less compatible with it... shucks.

JeMaCheHi

  • *
  • Posts: 194
  • You can just call me J!
    • View Profile
    • My YouTube Channel :D
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #55 on: 2015-03-17 00:03:46 »
Tonberry 2.01 release. We fixed the broken cache (and we deleted the 2.0 link, we told you guys not to download it but you still did it ¬¬).

Now everything should work fine. Don't forget to take a look at prefs.txt :)

Devina

  • *
  • Posts: 197
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #56 on: 2015-03-17 01:30:53 »
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.

Aavock

  • *
  • Posts: 303
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #57 on: 2015-03-17 03:34:14 »
Thanks for the latest release JeMaCheHi & mavirick, the game runs even more smoothly now! ;D
« Last Edit: 2015-03-17 03:58:21 by 5way »

mavirick

  • *
  • Posts: 76
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #58 on: 2015-03-17 03:53:42 »
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.

The Steam Overlay has been a problem since the earliest versions of Tonberry. At this point our efforts are focused on making Tonberry run as efficiently as possible without the overlay enabled.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #59 on: 2015-03-17 04:14:11 »
The Steam Overlay has been a problem since the earliest versions of Tonberry. At this point our efforts are focused on making Tonberry run as efficiently as possible without the overlay enabled.
The Steam Overlay is itself a d3d injector and, to my knowledge, 'there can only be one'

Kaldarasha

  • *
  • Posts: 2449
  • Prince of Model Editing
    • View Profile
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #60 on: 2015-03-17 05:52:32 »
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.

or using my GeDoSaTo config to fix the overlay from crashing Tonberry

Mcindus

  • *
  • Posts: 929
  • Artist, Modder, Musician.
    • View Profile
    • Lunatic Pandora
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #61 on: 2015-03-17 05:53:34 »
The Steam Overlay is itself a d3d injector and, to my knowledge, 'there can only be one'

http://youtu.be/_j6_H-PSml0?t=2m24s

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!



I don't think this will help him, because my 'fix' force-stops the overlay from loading.... but let me look into GeDoSaTo further... maybe something?
« Last Edit: 2015-03-17 05:55:39 by Mcindus »

JeMaCheHi

  • *
  • Posts: 194
  • You can just call me J!
    • View Profile
    • My YouTube Channel :D
Re: [FF8PC] External Texture Support - Tonberry: Enhanced (2.0)
« Reply #62 on: 2015-03-17 10:32:30 »
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! :)

mavirick

  • *
  • Posts: 76
    • View Profile
@_@ 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.
« Last Edit: 2015-03-18 00:12:15 by mavirick »

dheen

  • *
  • Posts: 5
    • View Profile
Hello,

 Will wait more for a new version to test.

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

FatedCourage

  • *
  • Posts: 337
  • I'll never regret knowing you.
    • View Profile
    • Youtube Channel
@_@ 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

mavirick

  • *
  • Posts: 76
    • View Profile
Hello,

 Will wait more for a new version to test.

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

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

My bad guys, I've been focused on my new hashing approach (which is a totally new version of the code) so I wasn't properly testing Tonberry in-game, just trying to fix the cache and get it released.

JeMaCheHi

  • *
  • Posts: 194
  • You can just call me J!
    • View Profile
    • My YouTube Channel :D
2.02 is out people. We fixed the debug folders issue (it seems we remove a code line by accident hehe  ::) ) and we've enhanced the comparisons in some algorithms.

Peace :)

mavirick

  • *
  • Posts: 76
    • View Profile
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.

Stay tuned.
« Last Edit: 2015-03-18 01:10:09 by mavirick »

FatedCourage

  • *
  • Posts: 337
  • I'll never regret knowing you.
    • View Profile
    • Youtube Channel
Good work. Glad to see things are progressing.

Now... As for 2.02. It seems I've ran into this problem. Surprisingly, this happened in the 2.0 version as well.

It doesn't appear to happen in the 2.01 version, though.

mavirick

  • *
  • Posts: 76
    • View Profile
Good work. Glad to see things are progressing.

Now... As for 2.02. It seems I've ran into this problem. Surprisingly, this happened in the 2.0 version as well.
[img width=640 height=360]
It doesn't appear to happen in the 2.01 version, though.


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?

FatedCourage

  • *
  • Posts: 337
  • I'll never regret knowing you.
    • View Profile
    • Youtube Channel
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.

Omzy

  • *
  • Posts: 205
    • View Profile
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

mavirick

  • *
  • Posts: 76
    • View Profile
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.

JeMaCheHi

  • *
  • Posts: 194
  • You can just call me J!
    • View Profile
    • My YouTube Channel :D
Good work. Glad to see things are progressing.

Now... As for 2.02. It seems I've ran into this problem. Surprisingly, this happened in the 2.0 version as well.

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