[FF7PC-98/Steam] FFNx - Next generation modding platform for FF7/FF8

[TrueOdin]

Please make sure to give me and NFITC1 credit for the 60fps you are adding to source if it's based on or using the Hext file I released.  Cheers.  If using interpolated files, also give Obesebear credit.

There's no 60 FPS patch for battles on the source code yet, but if it will happen I'll let you know.

Likewise please do remember to release your fork source as well.

Cheers.

[Zara9]

Hey Trueodin

Just a quick question here, will i be able to play the ff7 NT mod on your FFNX plugin Mod at all?

[TrueOdin]

Hey Trueodin

Just a quick question here, will i be able to play the ff7 NT mod on your FFNX plugin Mod at all?

This is up to Sega Chief You need to ask him. AFAIK he has planned that, but I'm not sure when it will happen.

[DLPB_]

Your shader settings are wrong, so your FMVs are playing without full 0-255 range (so black is not black).  This was fixed a while back in Reunion by changing the shader file - but your shaders are different.  Definitely something to look into.  You'll need a properly calibrated monitor to see this and also need to set graphic card to use full range in main graphic control panel.


Reunion yuv.frag

#version 110

uniform sampler2D y_tex;
uniform sampler2D u_tex;
uniform sampler2D v_tex;

uniform bool full_range;

const mat3 rgb_transform = mat3(
   1.0,    1.0,   1.0,
   0.0,   -0.344, 1.77,
   1.403, -0.714, 0.0
);

void main()
{
   float y = texture2D(y_tex, gl_TexCoord[0].st).x;
   float u = texture2D(u_tex, gl_TexCoord[0].st).x - 0.5;
   float v = texture2D(v_tex, gl_TexCoord[0].st).x - 0.5;
   
   if(!full_range) y = (y - (1.0 / 255.0) * 16.0) * (255.0 / (255.0 - 16.0));
   
   vec3 yuv_color = vec3(y, u, v);
   vec4 rgba_color = vec4(rgb_transform * yuv_color, 1.0);
   gl_FragColor = rgba_color;
}

[DLPB_]

   _snprintf(dds_name, sizeof(png_name), "%s/%s/%s_%02i.dds", basedir, Mod_ID, name, palette_index);
   _snprintf(png_name, sizeof(png_name), "%s/%s/%s_%02i.png", basedir, Mod_ID, name, palette_index);

Looks suspicious? 

(dds_name, sizeof(png_name)


-- Additionally, png loading times are around 4x as long as they were under aali's opengl code.  So something is making it take a long time to load compared.

[myst6re]

-- Additionally, png loading times are around 4x as long as they were under aali's opengl code.  So something is making it take a long time to load compared.

Do you use compress_textures option in Aali's OpenGL on your benchmark? You can use DDS directly instead of PNGs to improve performance.

[DLPB_]

nah   it's way longer even without

[satsuki]

png remains for compatibility but it's not optimised at all (also because the driver search for a dds and only if not here search for a png file).
png is useless compared to dds in ff7 even with high quality background like jusete's ones.
so go for dds you'll be happy with it ^^

[myst6re]

The difference between the drivers is that FFNx uses bimg and bgfx to create the texture, and Aali's driver uses libPNG directly without bgfx.
It is possible that something is wrong either in how we use these libs or inside bimg/bgfx. Maybe address this will also speedup DDS, dunno

[LordUrQuan]

The difference between the drivers is that FFNx uses bimg and bgfx to create the texture, and Aali's driver uses libPNG directly without bgfx.
It is possible that something is wrong either in how we use these libs or inside bimg/bgfx. Maybe address this will also speedup DDS, dunno

TrueOdin said on Discord that he has found bugs in bgfx's engine and submitted patches upstream.  Whether or not any of those bugs address this, though, I'm not sure.

[TrueOdin]

The difference between the drivers is that FFNx uses bimg and bgfx to create the texture, and Aali's driver uses libPNG directly without bgfx.
It is possible that something is wrong either in how we use these libs or inside bimg/bgfx. Maybe address this will also speedup DDS, dunno

I've already clarified it here, in order to avoid duplicating the effort: https://github.com/julianxhokaxhiu/FFNx/issues/56#issuecomment-638129028

Let's see where this goes

[TrueOdin]

DDS will be used, but PNG support in current FFNx is not fit for purpose.  It's excruciatingly slow and in fault, which definitely needs to be looked at.  If not- I'd say PNG support should just be removed.

Why? PNG is a failsafe for people using existing mods. But DDS is suggested and the way to go. When all the mods will be DDS only, then I guess that will be the time to deprecate the PNG layer. Until then it will stay in place.

[TrueOdin]

The load time is too slow to be usable.  With the battle PNGs alone, the game pauses for 0.25 - 1 second every time an action is made.  Field screens take 5 seconds to load every time.  With Aali's - it was no delay in battle and very little in field.

Feel free to not use FFNx if you judge is not good enough for your own use case. I'm tired of this attitude. Either you don't want to understand or you want to create a thread where you just complain about FFNx. Either way, you're not forced to use it. If you prefer Aali DLL use that one.

[TrueOdin]

I am reporting to you a bug.  One that makes PNG loading unusable.  You either fix it or you don't - I won't be using PNG because no one can with latest FFNx and hope to play the game.

And I already replied three threads above why this is happening, that I am working on it. I also replied to your own issue on GH. You should have received a notification about it.

Everyone is using DDS textures with FFNx because of many improvements going on behind the scenes. Is not only about "speed", is about everything that has to do with GPU memory, RAM, GPU cycles, etc.

[TrueOdin]

That's fine.  If you're working on it - so be it.  You replied:Why?

To my earlier query.  You made no mention of actively working to fix it here.

I'm not actively working on it because, as you said too, it's going to be deprecated. So the less effort we put on this, the better it is. PNG textures should just fade away. Until then, you can still load them, despite being "slower" than DDS. This means that you should convert all of your textures to DDS, and most of the community is now well aware of this, as well as conversion tools done by Satsuki. Just hop on the train and forget about PNGs.

[sl1982]

I can see there being advantages and disadvantages to both really. If using lossless formats such as PNG (or flac for music) cause slowdowns or other issues then lossy formats are usually 'good enough' (especially if they are vastly more performant.) Most people when actually playing a game arent going to notice some slight degredation.... But i have to admit the archivist in me prefers lossless formats.

[LordUrQuan]

I believe Jusete is still doing all original rendering in PNG and handing that off to Shampignon for cutting.  Pretty sure S will continue releasing PNG format files (max compatibility), and allowing us to convert to DDS if we wish.

[sl1982]

Any thoughts on doing an initial internal conversion? That way people can use whichever they want and get benefits both ways.

[LordUrQuan]

but if pngs could use cache files like aali's dll it should work.

As I understand it, that cache was where many (most?) of the really nasty memory leaks lived.

[sl1982]

Thats not what i meany. More like what aalis cache does. If it sees a png it converts it to dds and saves in a cache. Would be slow the first loads but after that would be fast

[satsuki]

I can see there being advantages and disadvantages to both really. If using lossless formats such as PNG (or flac for music) cause slowdowns or other issues then lossy formats are usually 'good enough' (especially if they are vastly more performant.) Most people when actually playing a game arent going to notice some slight degredation.... But i have to admit the archivist in me prefers lossless formats.

Let's be clear about that, i'm a quality addict, archiving my cds as flac, ripping my UHDBR as a simple mkv repack (no transcoding)... but outside my home server, i'm using loosy virtualy lossless formats to gain from 30% to 200% space or compatibility with some hardware, lossless is pointless if you can't use it smoothly (i've started studying lossy and lossless numeric formats 25 years ago, before the mpeg1 became a real standard so i've seen many formats and their limits - mpeg2 rgb full range for medical archive at time witch was unusable real time where yuy2 was great...)

DDS BC7 is 100% visualy lossless (not to compare with older dds codec), i've done countless tests before convert my mods to dds.
Even why my 4k projector (>2m base) i cant tell witch one is png and witch one is dds.

It's like wav vs mpc@320kbps (musepack), you'll never be able to spot any audible difference even with a very good hifi amp.
Or uncomp avi vs 4k h265 hight bitrate, you can't tell witch one in compressed even with a good projector.

Png is good for archiving sources files (so you can edit/mod the source loselessly, even if you edit/record 1000 times) , for live game engine it's pointless.

Thats not what i meany. More like what aalis cache does. If it sees a png it converts it to dds and saves in a cache. Would be slow the first loads but after that would be fast

No need for a cache as dds is loaded first, only need to convert dds in the same folder as png.
But as dds bc7 is realy powerfull, it's also realy slow to convert specialy on older GC (i own a 1060gtx and convert a full fields car take around 30s)
>>not usable for a realtime conversion

[sl1982]

Well that is good to know. I didnt expect a 30s conversion. That really puts the on the fly conversion idea to rest.

[Red46]

Does this supports linear/bilinear filtering for textures? I realise I might be in the minority but I just can't stand the pixels

[satsuki]

yes the bilinear option is usable (only need to activate it in the cfg file, like with aali)
but you'll need it only with vanilla game, with hd external texture you won't need it

[TrueOdin]

Allright, this is let everybody knows that together with Satsuki we did some tests on top of some new implementation and we made PNG loading times even faster.

FFNx now it will support all PNG types ( against original Aali DLL which supported only RGB/RGBA PNG formats ) like: Grayscale, Grayscale w/Alpha, RGB, RGBA and Paletted. All of them should load fine.

Time to load has improved A LOT but ( just to be honest ) is a little bit slower than Aali DLL just because I don't cache anything and I load it fresh. Anyway, on modern PCs this small % of slowdown is not even noticeable. For a daily gameplays it should work more or less like DDS, a bit slower. DDS is still a way to go as it provides the fastest experience related to texture modding.

Some memory optimizations and usage has been made, which means even less memory used to handle a texture in memory. This means a bit more space for your mods, again

Finally, the DLL code is now built with the maximum optimization available through the compiler, which means faster execution on top of your CPU.

All of this available on latest canary. Feel free to test!