Messages

51

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-03-08 11:36:03 »

This is exactly why I asked.
I haven't checked SFX, but if we are talking about music, aside from SDLIB issue, the music in PC version is as good as it gets. There could be small differences due to the fact that PSX music is sort of "rendered" on-the-fly so I'm not sure if we can say that there is a way to do it 100% right, plus PC version sound is lossy-compressed so mathematically there is a difference. But both of these differences are inaudible for a human listener. I can probably provide samples to prove that, but I'll have to re-create them again cause I deleted em a while ago.

So if SFX is the same, seems like a wasted effort to me.

52

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-03-08 11:03:18 »

Anyone know how the sound engine works in that release?
Sharon over steam [https://steamcommunity.com/app/377840/discussions/0/133258593389989239/] is working on restoring the better sfx from the PSX version but he's struggling as of right now.

Maybe someone can lend him a helping hand and/or collaborate on it.

Just curious, what is exactly wrong with SFX so that they have to be replaced?

53

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.37)

« on: 2017-03-08 09:41:32 »

Well it would look exactly as my screenshot, that's not a photoshop (except the red question mark), I tried it before posting 

54

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.37)

« on: 2017-03-08 09:37:42 »

Why the heck the exclamation bubble got shifted?
Well I don't mind the both bubbles to be honest, but as long as there maybe a solution on the horizon that's always welcome.

Icons are centered on a character. Be it one or two. So making one invisible does not remove the shift. One must hack the engine to take care of that =(

55

FF9 Tools / Re: [FF9] General editor - Hades Workshop (0.37)

« on: 2017-03-08 08:39:47 »

Removing textures by replacing them with dummies is a bad approach.
Hiding card icon this way is probably possible, but that will still leave the exclamation mark in a displaced state.

And hiding exclamation mark may remove it even in places you don't want.

As for hand icon, that one can be disabled in settings.

56

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-05 18:46:37 »

Updated 1st post with latest version of the images. They are of the same scale. Just had to cut them a bit to better fit on the screen. ALso they are like ~5mb so wait up till they fully load.

57

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-04 10:58:47 »

zwuw
Here is a hopefully better explanation. Below is a some random patch of grass straight from PSX. 4x Lanczos+4x Point

See these colorful spots? These used to be some kind of flowers or something.
They are too small and subtle to be upscaled reliably. Features they belong to are not present in the upscaled version. So an attempt to keep them creates out-of-place colorful blobs.
So they are being filtered out on purpose.
It does looks similar to reducing chroma subsampling of the PSX image. But this is not the case. There are no reasons to do that stuff anyway.

The tradeoff I am talking about is: making those parts that you pointed out better means keeping more of these colorful blobs. Which is not something I want. I choose to remove blobs completely. There are much less parts that suffer from color loss than the ones that benefit from it. Those that suffer can be fixed manually at some later point. Or not fixed at all, cause personally I'm ok with them as is.

58

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-03 19:12:22 »

BTW you seem to think that I applied some smoothing on top of the upscaled image. Which is not exactly the case.

For example one of the requirements is to be able to turn this: https://i.imgur.com/oDgx1qk.png into this: https://i.imgur.com/aOG5nWu.png (this is 4x point upscaled for better viewing)
In my case this is done on upscaling step. Probably can be done by smoothing it out, but I can only imagine what it will look like.
Edit: Achieving this without turning everything else into a blurred mess, like original waifu does is not easy. The price are the things you marked on the main street image. Perhaps it can be improved some more. Current version meets my goal, which is to make images that look better than the one in PC version and make the difference between backgrounds and 3d characters less apparent. It is not my goal to re-draw, re-create  or make the best possible images in general. The limit to how good it can be is rather high. However with that, the timeframe at which it can be done extends indefinitely. I have some soft dedlines I've set for myself and I work with the intention to meet them, more or less.

59

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-03 18:30:33 »

What I was trying to explain is that the last picture doesn't have that specific problem and you wouldn't need to waste much time finding out what you'd have to change in your workflow.
In the following picture, I applied heavy denoising while trying to keep most of the detail:
http://i.imgur.com/9LvGGYr.jpg

It's not a perfect example and it has different states than yours. I just want to point out that, even with this denoising strength, it doesn't get that kind of problem and neither does your last picture, even if I clean it up. These are the places with more noticeable color loss in "Main Street":

http://imgur.com/a/P9bau

I've had similar problems in the past because of incorrect colorspace conversion, bit depth and compression so I thought I should tell you about this while you're still working on the backgrounds, in case you're not aware of it. In my pov, there's no trade-off regarding this problem, there's only doing it right or wrong. If you think it's fine the way it is and people like it, that's all that matters.

Sure I got what do you mean even 1st time. This is not a bitdepth or colorspace issue. In fact even if there would be an issue, It would probably affect the image less. And compression is not involved at all.
Too bad we're doing it with this dark image, but oh well...

Denoising strength on your image does not match the one on mine. Look at the wall's edge near the door, just above the lamp thing. How much stronger processing you should apply to make it look like mine color-wise? Quite a bit stronger, regardless of the method, I suppose. What will happen with other things (such as the ones you outlined) if you'll do so? Most likely same as the "problem" that you described. (Achieving similar effect by tweaking color values doesn't count).
That's the trade-off. Sure this particular dark wall is an awful example and it probably doesn't needs this much of stuff.

Now the things you marked on main street image. I agree that some of these places may look better. The question is how to make it so without affecting other parts of the image? The answer is not possible, unless on image-by-image case-by-case basis.

As for people, I don't know nor care what they like.

60

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-03 14:11:12 »

Although the visual impact might seem subtle on Guardhouse's first picture, it can get much worse on other backgrounds with more color intensity and micro details if that problem persists. "Main Street" is a better example where more prominent colors are too washed out or fading out, and important details are lost because of that.

I agree it's important to apply chroma denoising on FF9 (PSX) backgrounds and it's normal for color properties to change with resizing and filtering, especially on sources like this. But I believe that washed/fading out color problem in fine details can be avoided, giving your backgrounds better visual quality and fidelity. Your last picture doesn't have that problem so I think it'll be easier for you to identify what's causing it.

It is pretty hard to guess what are you talking about.
Flags on windows (or whatever that is)  or flowers (if they are flowers), that sort of thing?
If so, this is known. From computer's perspective there is no difference between details and noise so just like any kind of image processing, this is a trade-off between removing what I consider bad and keeping what I consider to be good. It is practically impossible to tune processing in such a way that will fit all parts of every image.
Posted images may be a bit outdated, but they are made in a way that produces consistently-pleasant results for me across all images. Anything else requires manual tweaks (like limiting processing for certain parts ff the image) which I'm not doing much. For now this is a very low-priority stuff for me because I quite like the results as is. Huge amount of work on edges and animations concerns me much more.

But I believe that washed/fading out color problem in fine details can be avoided,

To put it simply, no it can not be avoided. An attempt to do so also exposes stuff that I do not want to see. On the main street image, except flowers and flags I do not want to see anything else on other parts of the image (not counting badly made sky that, I believe, was fixed since.)

Edit: you said that last picture of Guardhouse does not have a problem. Well, for me it does. The most obvious things like "lockers" look better indeed, but I don't like most of the other things. And this will affect some of the other images much more strongly. That said, most of the stuff that you call a "problem" is most likely made on purpose and/or known but not sure when or if it will be changed.

61

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-03 08:52:36 »

Here is a different version. Do you like this one more? I'm not sure I do. What works for one (part of the) background, not necessarily works for another. At this moment I cant say what the final version of this one would be. Maybe this, maybe that or (most likely) a combination of two.

Edit: woops, wrong link. Fixd.

62

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-03 08:27:05 »

I noticed color loss(washed out colors) in the two screenshots you provided when compared to the originals. The problem is visible in both waifu and yours. Does this happen with all of the backgrounds you're working with?

Are you talking about that locker-like thing at the back? If so then no, it is specific to that background. The process of making these textures is not fully automated and I may do manual changes to some parts of the backgrounds. I agree that this place may have to be tweaked a bit, but I try avoid doing so for the 1st pass (unless i see something really ugly or for test).
If you are talking about stone wall however, the way it looks like is what I believe it should look like. Most of the color loss in this case is due to it having less color noise.

There are other differences compared to the PC textures that are not visible on provided images. Many of my textures have a bit different levels (a bit brighter) It is a subject for a separate debate which is more correct, PSX or PC levels as there are reasons to think that either or both are incorrect. But for now I am going with psx ones. It shouldn't be very hard to switch to PC-like levels if I'll decide so in the future.

63

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-03-02 09:21:00 »

So I've finished the first Disc. Also I made a small webpage. If you are curious about progress, from now on you can check it there.

64

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-02-27 17:29:24 »

Would anyone be interested in recreating entire scenes in 3D and re-rendering them for background use? I can probably manage to pull off some convincing ones that use mostly simple geometry. Hard-surface stuff, not so much the organic stuff.

I am skeptical about that.
- too big of a project to complete in reasonable timeframe given very limited resources. I, for example, don't have that big of an attention span.
- too hard to make it look close enough to the original. If I'll render re-created scene at PSX resolution, I would expect it to look virtually identical. Anything less won't cut it.
- this game is not that popular overall. People are struggling with projects of that sort even with much more popular games.

65

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-27 09:05:53 »

you are working on backgrounds, shouldn't you know that without me telling?
Anyway I believe this is one of the Hilda Garde 3 images. I haven't looked at it since I'm pretty far from that. Should be this one fbg_n53_hlg3_mapv50_g3_brg_0

Edit: the difference is actually so small I barely noticed it. They added 58 pixels to one of the layers. Perhaps they covered some kind of seam or something. I don't even have a savedata there yet.

66

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-27 08:36:35 »

The patch is actually pretty huge (in terms of the amount of changes, not size). 100+ files were changed. They changed a bit of everything, effects, shaders, system... that includes one background texture.

67

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-26 19:07:20 »

There is two settings in the HW:
"Sort layers by depth" and "Revert layer ordering"

You have checked the first. Yes, Memoria will can read this files by the meta in the field's folder.

Not sure what do you mean. These settings are for import. HW -> tiff export is not influenced by these settings (if it is, that would be very badly designed). I did checked first. If i wouldn't, it wouldn't read layers correctly. Sorting by depth is the default. But this does not matter for Memoria. Only Export is relevant. There is no sorting choice for export (and it is not needed as export must match the one of PSX). And that export does not match the one Memoria expects by default.
But as long as there is a way to read it, it doesn't matter, I suppose.
Edit: I am leaving this export discussion in hands of Fraggoso, since at this point, he is the one interested in having his backgrounds work with Memoria.

68

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-02-25 17:16:07 »

Cargo shipped really sucked so far the most yes.
It gets better but Lind Blum also have some nasty animations.

So far so good. Lindblum-the-town is pretty straightforward. I did like half of it today https://i.imgur.com/1ekOKuA.png, hopefully the rest would be the same.

69

Support / Re: [FF9PC] Field Background replacement (patch?)

« on: 2017-02-25 11:52:35 »

Uh, oh. So I've finished Cargo Ship... It was a hardest scene so far. HW bugs, PC port bugs (unlless they are HW export bugs too), and overall difficulty...
And in the end it still looks kinda ugly cause of these dirty edges, but generally plans haven't changed, most of the edges will have to wait.
Next one is Lindblum... I guess. Ouch, I hope there aren't as many animations as It looks.

70

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-21 11:57:40 »

1) Unfortunately, this is contrary to our policy. Your changes will conflict with mods other players. In addition, you cannot control the order of loading mods (any player's mod will overwrite your changes), and a player cannot delete your mod. Any game update will erase your mod and force the user to download 200-3000 mb from the steam. It's a realy bad idea!
2) Hm. Thank you, I will see how HW order layers. Maybe by Z. It's very strange but not the problem. We will use the same order.

1) I see. I just wanted to clarify how are you going to do it.
I don't think that Square will update this game in the future, maybe once at best (someone mentioned there was some kind of update that never went live).
As for conflicts with other mods, I don't find this to be a problem. If there will be other mods that I will use, maybe I''ll add support for them in one way or another. From what I see, this is just a matter of creating correct AssemblyCsharp.dll that will be able to support more mods. Or something like that. Other than that, if people don't like this approach, they are free to not use my mod.

Edit: mod load order should not be an issue. I don't plan to do any mods or anything that will affect gameplay. In case of textures, whatever someone uses my  textures or does not use them. I don't see why would someone want to use half of my textures and half of some other textures. And even if there is a reason for that, I don't want to assist people in doing so. If, for example, there will be a mod that changes the story of the "I Want to be your canary" and while doing so it adds some changes to the Prima Vista stage textures - I don't want my mod to be used together with that so it is up to the user to figure out how to achieve that.

2) Maybe this has something to do with it?

Hades Workshop export the layers of the backgrounds by depth

@Meru If you don't want to distribute your psd files, this'll not work as Memoria will override the scenes on the fly instead of them being repacked into the unity container.

Yes, I already got the idea. In this case I will not use memoria.

71

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-21 10:41:41 »

1) I plan to distribute patched files on my own in a way that is not compatible with nexus mod manager. I will have my own patcher that will directly modify game files. So I was trying to figure out if this would be possible to do with memoria
2) How is it the same? I even posted screenshots? 3rd layer from the bottom and up is different. I am not talking about layer names but layer content. FOr the same layer number the image data is not the same.

Edit:

72

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-21 09:51:35 »

Well I just posted my psd above for the sake of comparison and the layer order is different from the one Albeoris posted... Is it not? Pls check it out.

One Folder = Rename to the Fieldname and put one psd in it = Finish

I got this. But what happens after this? Memoria will read the files and update p0data1X.bin archives, after which I can delete PSD's? If so that's cool.

Edit: I can put the question differently.For user to apply the mod, do I have to distribute PSDs? If yes, this is what I "fundamentally dislike".

Edit2:
Bottom layers in File posted by Albeoris https://i.imgur.com/7IZdrq9.png
Bottom layers in my file (that I converted from tiff without any additional modifications): https://i.imgur.com/1WG3HKD.png

73

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-21 08:52:58 »

Thanks for explanation, Fraggoso!

So from what I get, there will be a folder that will have a few hundred PSDs... I count this as "loose files" and fundamentally dislike this approach. I prefer when textures are contained in unity archive, so I'll probably stick with HW. But I see possible good sides about this approach too. Generally you only need to rasterize all PSD layers and they should be ready to use.

Multiple languages and scenes are not a problem then.

That still leaves one biggest issue there. Layer order in my psd's (and probably yours too). I don't really want to create a copy of my psd's and re-arrange layers in them...

74

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-20 16:34:27 »

First: Please contact with Fraggoso: http://steamcommunity.com/profiles/76561198022328654
Seems you both do the same work. Split the scenes and work together if you can.

I'm well aware that he is working on backgrounds, but we are doing things differently so splitting the scenes is not an option since I want things to be consistent from start to end. Plus there are other complications, so I prefer to do it alone.

About your question:
Share your PSD file for example.
To import it to the game you need put the fileto the override folder with a scene name.
For example, Alexandria's central squad: FBG_N01_ALXT_MAP019N_AT_CNT_N(Any your description here)
Sample PSD: https://yadi.sk/i/YFHGHHhZwo99h

Limitations:
1) You have to use a simple PSD without any smart objects, 128 bit depth, etc.
2) You cannot add any details to the transparent layer if it did not have it before. If you want to do that, we can generate a new tile but it depths will be interpolated. It can lead to errors on such objects as stairs.

By the way, you can use upscaled backgrounds. x2, x4, x8, ...

Not sure if I understand you correctly... Are you saying that your solution can read PSD directly? And that Sample PSD you posted is what Memoria will expect to read?

As for my PSD's, in terms of layer order they are the same as tiff files produced by HW. Here is my (raw, unmodified) PSD of Alexandria/Square. From what I see, layer order is indeed different from the PSD you posted.

Edit: what about backgrounds that have multiple angles? Like PrimaVista/Cargo Room? For me they are 2 separate tiff's/psd's

Yea I already use resolution higher than in PC version.

75

Scripting and Reverse Engineering / Re: [FF9]2016 release

« on: 2017-02-20 09:11:33 »

Albeoris
Can you share some info on a future process of importing backgrounds and what the end-result (complete patched game) will look like? I am interested mainly in context of compatibility with HW's input/output files.
Right now I am in the process of making backgrounds (just finished Ice cave) and would want to try your solution, so I want to figure out if it'll be possible to transform my 1.7gb of PSDs (that is growing every day) into something that your solution will be able to read without me having to re-arrange and/or re-create all the layers.

Edit: to clerify a bit, HW gives a multi-page tiff as output and expects a sequence of full-size images with the same order as input. While the image format should not be an issue and I should be able to convert into pretty much anything, I'm afraid that layer order may be an issue. For example layer order of an animation in HW's output does not match the order at which it will be actually played in game. And any layer in general can be at the foreground, while in-game they are in background.

Edit2: about end-result, I am interested if patched game will be able to function with replaced game archive and Assembly-CSharp.dll or it will require something else? Ideally it'll be best to not have any other dependencies. Textures in form of loose files (not in container) is suboptimal too. There will be hundreds, possibly thousands of files.