This is the infamous 'GFX' bug that happen for people using NVIDIA. Unfortunately this is a client bug that is not easily fixed.
So i'm assuming no pre-bb server has actually fixed this issue? Just worked around it?There's not much info but Private Servers usually suggest you to change your GFX setting a lot during bossing (which refreshes it) or getting an XP VMware, or just turning off NVIDIA altogether.
There's currently no known fix for Windows 10 + NVIDIA (client memory leaks). We have fixed it for OS's prior, but the method is not currently public, since it wasn't completely done by us.
So i'm assuming no pre-bb server has actually fixed this issue? Just worked around it?
I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.
Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.
From what I understood its a memory leak exclusive to Windows 10, because after we've applied different ways to load .wz files the GFX issue was resolved for everyone, including NVIDIA users, except those using NVIDIA AND Windows 10.
But yeah we didn't found the solution for the W10 issue yet, sadly.
Very fantastic news to hear it <exist> though. Private or not, I don't really care. It means that someday this whole stupid GFX issues can be resolved.
Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files.
I'll take this chance to ask a question that's been bugging me for a little while, if this isn't going too off-topic.
A few months ago I used HaRepacker to remove certain weapon type nodes that are unused in v83, from some Cash weapon covers.
However, that edit would cause people to face this issue at seemingly random times; they'd disconnect, crash, get glitched menus and graphics, even after having just been sitting idle in Henesys.
From what you said, I'd assume that the edit itself is the culprit. So, is there any other way to implement that change, in a way that wouldn't be prone to crash?
As for windows 10 compatibility on all versions/clients, the issue is indeed what I had documented and pinpointed in my thread here on RZ. If you can fix/patch the location that I mentioned had caused the parameter error, then you've got windows 10 completely compatible with any version, no more parameter error ever again. I've tested it on v83, v90, and v117 to confirm it.
@0:15 - The first encounter of client glitch in which the attacking animation of Targa is facing the opposite direction of attackers and dissappears
@1:01 - Key config GUI gets broken
@1:02 towards the end - Gradual increase in fps stutter. You should be able to notice it well since the clip has been recorded in 60 fps. Also the face animation starts desyncing.
@1:19 - chat box GUI gets broken
@1:23 - menu GUI gets broken
@2:39 - unusually fast walkspeed?
I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.
Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.
So, it's okay to save as A8R8G8B8 when using post-big bang clients? Did they just add A8R8G8B8 support to the newer clients or what? Just curious why you mentioned that the MapleLib/WzLib issue doesn't happen on post-big bang clients.I've fixed both of the issues in my client(s), so it can be done if you know what's involved and what you're doing. For now, however, I plan to keep all of my implementations regarding these issues private.
Oh, and do you by any chance use a lot of WZ Edits, or any at all? This can also be caused because of the MapleLib/WzLib library and how it repacks WZ files. If not, then this is just the same issue that would occur in GMS. It is indeed a client memory leak though, and it is fixed in all post-bb clients.
So, it's okay to save as A8R8G8B8 when using post-big bang clients? Did they just add A8R8G8B8 support to the newer clients or what? Just curious why you mentioned that the MapleLib/WzLib issue doesn't happen on post-big bang clients.
public override WzConstants.COMError raw_Serialize(WzArchive pArchive)
{
if (pArchive != null)
{
WzStream ws = new WzStream(pArchive, null);
ws.ReadByte();//pData
if (ws.ReadByte() != 0) {
WzSerialize ppProperty = null;
WzPCOM.PcCreateObject("Property", out ppProperty);
this.pProperty = (WzProperty) ppProperty;
this.pProperty.raw_Serialize(pArchive);
} else {
this.pProperty = null;
}
this.uWidth = ws.Read();
this.uHeight = ws.Read();
if (this.uWidth >= 0x10000 || this.uHeight >= 0x10000) {
return WzConstants.COMError.INVALID_CANVAS;
}
this.nPixFormat = ws.Read();
if (this.nPixFormat != (int) PixFormat.A4R4G4B4 && this.nPixFormat != (int) PixFormat.A8R8G8B8 && this.nPixFormat != (int) PixFormat.R5G6B5
&& this.nPixFormat != (int) PixFormat.DXT3 && this.nPixFormat != (int) PixFormat.DXT5)
{
return WzConstants.COMError.INVALID_TYPE;
}
this.nMagLevel = ws.Read();
if (this.nMagLevel < 0) {
return WzConstants.COMError.INVALID_CANVAS;
}
for (int i = 0; i < 4; i++) {
ws.Read();
}
int uSize = ws.ReadInt();
if (uSize != 0)
{
bool bEncrypted = ws.pArchive.Encrypted();
SerializeData(ws, uSize, bEncrypted);
}
return WzConstants.COMError.SUCCESS;
}
return WzConstants.COMError.INVALID_ARCHIVE;
}
internal WzPngProperty(WzBinaryReader reader, bool parseNow)
{
// Read compressed bytes
width = reader.ReadCompressedInt();
height = reader.ReadCompressedInt();
format = reader.ReadCompressedInt();
format2 = reader.ReadByte();
reader.BaseStream.Position += 4;
offs = reader.BaseStream.Position;
int len = reader.ReadInt32() - 1;
reader.BaseStream.Position += 1;
if (len > 0)
{
if (parseNow)
{
compressedBytes = wzReader.ReadBytes(len);
ParsePng();
}
else
reader.BaseStream.Position += len;
}
wzReader = reader;
}
Thanks for this.If you apply the same amount of wz edits you would in a pre-bb client, it would still apply to post-bb. Don't forget, GMS has still had this image glitching bug even in recent versions because the client begins to eat up so much memory. Also, another thing to point out is that by saving all images as that format is what is making your files so much bigger than they were before. If you were to save your file but with every node saved and nothing changed (so it's clean, but a re-save under MapleLib), your file will be significantly bigger than before even knowing it's completely identical.
EDIT: Since someone had asked me how to determine what the pixel format is of each property read from the wz's, here is nexon's raw serialization parsing for WzCanvas that determines what each byte is.
PHP:public override WzConstants.COMError raw_Serialize(WzArchive pArchive) { if (pArchive != null) { WzStream ws = new WzStream(pArchive, null); ws.ReadByte();//pData if (ws.ReadByte() != 0) { WzSerialize ppProperty = null; WzPCOM.PcCreateObject("Property", out ppProperty); this.pProperty = (WzProperty) ppProperty; this.pProperty.raw_Serialize(pArchive); } else { this.pProperty = null; } this.uWidth = ws.Read(); this.uHeight = ws.Read(); if (this.uWidth >= 0x10000 || this.uHeight >= 0x10000) { return WzConstants.COMError.INVALID_CANVAS; } this.nPixFormat = ws.Read(); if (this.nPixFormat != (int) PixFormat.A4R4G4B4 && this.nPixFormat != (int) PixFormat.A8R8G8B8 && this.nPixFormat != (int) PixFormat.R5G6B5 && this.nPixFormat != (int) PixFormat.DXT3 && this.nPixFormat != (int) PixFormat.DXT5) { return WzConstants.COMError.INVALID_TYPE; } this.nMagLevel = ws.Read(); if (this.nMagLevel < 0) { return WzConstants.COMError.INVALID_CANVAS; } for (int i = 0; i < 4; i++) { ws.Read(); } int uSize = ws.ReadInt(); if (uSize != 0) { bool bEncrypted = ws.pArchive.Encrypted(); SerializeData(ws, uSize, bEncrypted); } return WzConstants.COMError.SUCCESS; } return WzConstants.COMError.INVALID_ARCHIVE; }
and this is MapleLib:
PHP:internal WzPngProperty(WzBinaryReader reader, bool parseNow) { // Read compressed bytes width = reader.ReadCompressedInt(); height = reader.ReadCompressedInt(); format = reader.ReadCompressedInt(); format2 = reader.ReadByte(); reader.BaseStream.Position += 4; offs = reader.BaseStream.Position; int len = reader.ReadInt32() - 1; reader.BaseStream.Position += 1; if (len > 0) { if (parseNow) { compressedBytes = wzReader.ReadBytes(len); ParsePng(); } else reader.BaseStream.Position += len; } wzReader = reader; }
Thanks for this.
However, still, what did you mean when you said post big bang clients don't have an issue. Was that a memory leak separate from the pixel format saving? Just wanted clarification on what you said earlier.
Yes, they're two different issues that go hand in hand with each other. While post-bb clients may have the memory leak fixed regarding the wz libraries and loading/disposing/etc, that just means that if you were on clean GMS files then you wouldn't be crashing while trying to fight Zakum/Horntail. However, if you apply crazy amount of wz edits in a high version just like you would in a low version (which is rare because people copy hundreds of thousands of high-version content into low versions, not the other way around), then you would end up with graphical bugs in UI windows and eventually crash. By saving them in the default format that HaRepacker always uses, it uses a lot of memory - hence why the files are bigger. At the same time, this means the client will utilize more memory for every image it has to load on the items (which is a lot). This is what will cause even post-bb clients to hog a ton of memory and eventually crash.
lai not exactly the "correct" format, but their "original" given format. imagine saving every image into the new DXT5 image bitmaps, it'd be even bigger than it already is now. but yes, you basically got the idea - a lot of wz edits can cause graphical issues due to a lot of memory.