FF7 Translation

  • Thread starter Thread starter mav
  • Start date Start date
Status
Not open for further replies.
A lot of the problems with transparencies can be fixed by changing the blendoffset code to '-1' and reloading the level. That tells it to try and autodetect all the transparency codes, which doesn't *always* work, but it's fairly good. Try that.
 
I mostly agree with everything ficedula has said here, apart from some earlier bugs the LZS compression routines we use do produce compatible files (or FF7 wouldn't load at all). Any errors found (especially specific ones such as th Wutai shop script issue) is far more likely to be a problem with the editor itself.

fice: I was wondering why you called it Haruhiko...

_Ombra_: Since the FF7 LZS compression has no levels of compression, your last argument is a bit redundant. The fact that FF7 even accepts the files and shows the correct scene is proof enough of compatibility in this case. However, the preferable choice for this sort of game hacking is always to use the exact same compression algorithm used by the original. The advantages over my own implementation is unknown, but one could always hope for a speed increase in FF7's file loading (my own implementation tends to produce significantly slower-loading files for some reason). How is the speed of the compression itself though? (looks reasonably fast because of tree handling, but one never knows... :) )
 
Well... "zip" theory or not, the compression is like the original and fast, so, stop talking about it  :P
I think you'r right Qhimm, you got the point, but r u sure is always compatible? Well, it doesn't matter... it works :D

btw i think you'r right... i was checking again the Wutai thing and others... probably is a problem of the editor but anyway i'm using a custom editor that we made especialy for editing the text (doesn't look cool like Cosmo and is in LibertyBasic... there's no backgroud preview or realy cool things like that, but works at the moment :P)

ficedula, why did you called it Haruhiko ?? if i'm not too curious :P
 
Ombra: Maybe you share with me this editor ?? :). I would be glad :D.
Fice & Qhimm: Problems with locations like Wutai, Midgar Train or Costa del Sol lies in their construction (i think), which isn't compatible with Cosmo. Maybe that files was created with some diffrent, or something. And Maybe if you try to Debug Cosmo, when it open these files and when it tries to save, you'll find an answer.

And for background viewer: Ok, everything seems to be OK, but one more thing. What are these black dots ?? There are a 'unpainted' pixels or something in each level. It can be see very clearly in smkin_3. You know how to fix it Fice?
 
The black dots you are referring to was a constant pain in the you-know-what when I first made the background viewer for Gast. I never could find a suitable answer, and hypothesized that these pixels might be covered by some of the effects layers I couldn't decode at that time. Ficedula should know much more about the format and its quirks than me now, though.
 
Firstly; I call the compression Haruhiko because (as Ombra noted), the LZSS compression was originally devised by Haruhiko Okumura, so far as I can tell. I don't call it LZSS compression because *all* the compression algorithms output LZSS files - Haruhiko's algorithm just outputs better compressed LZSS then ours do ;)  So, since the algorithm Cosmo uses is essentially a direct port of Haruhiko's code, I call it LZSS/Haruhiko compression.

Qhimm: The Haruhiko code compresses very fast - it uses fixed trees, and so the speed seems *comparable* to your own. I haven't benchmarked it in any way, but for FF7 purposes, if it compresses a level in less than a second, you're happy enough, regardless of small differences...

M4v3r: Yes, the problem is that Cosmo is 'too clever'. If you change the length of a piece of text, it tries to rewrite all the pointers in the level to accomodate the new size. When it works, that's really funky. Unfortunately, when it doesn't, it corrupts the level file. Even worse, sometimes (I don't know why) it thinks you've changed the length when you haven't, which is obviously worse still...

The black dots: Yes, they're still a pain in the proverbial. Unfortunately, I've pretty much now decoded about 95%+ of the background (see latest LGP Tools for working-in-many-locations animations and transparencies) and they don't change a thing at all - quite a few of the black dots appear in locations that aren't covered by animations or transparencies at all, so it's a more basic problem than that.

I've developed one or two simple filters that try to eradicate them, but they're less than totally effective...LGP Tools has a checkbox to enable the filter; you can see the difference by loading a level with the filter off, turning it on then clicking 'Reload'. Sometimes it works really well and eliminates lots of the dots. Often it doesn't. If I were to actually pay attention to some of my lectures at uni, I might be able to develop a better filter... ;)

(Actually, I really should see what's on my departments pages about this sort of application. There's a surprising amount of code and information available if you know where to look, although I'm not sure how useful it'd be for this. I suspect the format of having some sort of horrible quirks that you'd only discover by guesswork.)
 
interesting,
looks like this may have kickstarted something good :D
 
1. I think that 'black pixel problem' is a palette problem, because, when you load a palette from that level, there is some black pixels in there. Maybe this will help you:
http://members.xoom.it/m4v3r/screen.zip
You have here a screenshot from the game, and the same location in cosmo (320x200 converted).
2. Why in LGP Tools 1.55 there is no Export to BMP function ?
3. I've looked for battle texts in LGP's and I have a question. Are the files in battle.lgp compressed ? Because when I select extract all fuction, there is no dialog like 'files seems to be compressed. decompress them? [Yes/No/All]' like in flevel.lgp files.
 
I think I've mentioned that before ... no the files in the battle.lgp are not compressed (at least to my knowledge)

 - Alhexx

 - edit -
...and like I said before: I doubt that you will find any texts in the Battle.lgp, since there are only battle character models and the battle locations... so keep on searchin' anywhere else
 
M4v3R: The link is not working...

By the way... i was thinking... it's possible that the game use a color for the background ? maybe those black pixels are filled with a background color... i'm just wondering :P (maybe is just a stupid theory :P)
 
No, I've checked it, these pixels has diffrent colors.

Edit: I've updated that link.  :roll:
 
Now it comes to my mind that battle texts could be pictures ... i haven't checked it out yet .. so try looking at the battle model textures ......
 
mirex, i don't think is graphics beacause the font is the same as the in-game text...
 
Hm.. Mirex, good point ;). I've decompressed every file from the game and searched only one word from the battle texts (counterattack as I recall) in them with no result, so it can be true :). But that's a wacked theory :D.
 
The in battle texts are overlayed exactly like the "assistance" text stuff you can activate by hitting select, just on the top of the screen instead.  So, I'd think they'd be stored similarly, and not as graphics.
 
Status
Not open for further replies.
Back
Top