May 2023 Version Update (Part 1)
|
May 2023 Version Update (Part 1)
And Leaden/Trueflight on magic weak mobs, hybrid WS on certain enemies. Fudo was routinely hitting 99k for me on the bard Sahagin in Ambu couple months ago which was hilarious.
Lili said: » And Flaming Crush, and Climatic Rudra. Not on anything that matters. Dodik said: » And Leaden/Trueflight on magic weak mobs, hybrid WS on certain enemies. Fudo was routinely hitting 99k for me on the bard Sahagin in Ambu couple months ago which was hilarious. Again not on anything that matter, with the exception of TF/LS closing skillchains on specific magic targets. But again we were talking about Physical Damage Limit on current content. Vaerix said: » KujahFoxfire said: » Bahamut.Kahraba said: » Asura.Melliny said: » There's no reason to believe PDL on these new weapons would work any differently from every other existing PDL piece. If I understand correctly you're suggesting the aftermath might not only raise the attack cap by giving +PDL, but also provide the requisite attack values to make use of it outright. That's more than just a little unlikely. I wouldn't get my hopes up on that one. The weaponskills are probably going to be really good though. They pretty much have to be. I'm expecting them to have impressive mods and tp scaling. There's a chance they may have hidden properties not mentioned in the description as well. Howling fist has an attack mod and coronach has enmity suppression, so it's possible these new weaponskills could also be packing some surprises too. We'll just have to wait and see. Im fairly sure letting us go over 99k is gonna completely break game balance, but i'm all for it haha In current content hitting 99999 isn't something that happens regularly (even MS War wasn't popping 99999 vs v20 bumba) if they make a weapon that can break that damage cap it wouldn't be felt really on current content but would make old content like Fu absolutely hilarious. MipMap Information / Fix
SE decided to change how the mipmap setting is being honored for whatever reason in the latest retail client update. Here is the information in regards to what was changed and how to fix it. The client loads the mipmap setting in several locations and applies different rendering adjustments. The main one of interest though is loaded into a sub-structure that holds the value. In the old client, this looked like this when loaded and used: Code
if ( FUNC_CYmdb_GetMipMappingLevel() )
mmlvl = FUNC_CYmdb_GetMipMappingLevel();
else
mmlvl = 1;
*((_BYTE *)this + 42) = mmlvl;
However, in the new retail client, they changed this to: Code
mmlvl = FUNC_CYmdb_GetMipMappingLevel();
*((_BYTE *)this + 42) = 2 - (mmlvl != 1);
The block of assembly doing this now looks like: Code .text:10038D60 E8 BB BE FD FF call FUNC_CYmdb_GetMipMappingLevel .text:10038D65 FE C8 dec al .text:10038D67 89 5E 20 mov [esi+20h], ebx .text:10038D6A F6 D8 neg al .text:10038D6C 1A C0 sbb al, al .text:10038D6E 89 5E 1C mov [esi+1Ch], ebx .text:10038D71 83 C0 02 add eax, 2 .text:10038D74 88 46 2A mov [esi+2Ah], al .text:10038D77 8B 46 2C mov eax, [esi+2Ch] The code block here can be altered and updated to force a mipmap level of 6 like the following: Code
local patch = {
0x89, 0x5E, 0x20, -- mov [esi+20h], ebx ; original code restored
0x89, 0x5E, 0x1C, -- mov [esi+1Ch], ebx ; original code restored
0xC7, 0x46, 0x2A, 0x06, 0x00, 0x00, 0x00, -- mov [esi+2A], 6 ; forced mipmap setting
0x90, 0x90, 0x90, 0x90, 0x90, -- nop {5}
};
ashita.memory.write_array(mipmap.ptr, patch);
The pattern used for this patch ptr is: 'FEC8895E20F6D81AC0895E1C83C00288462A' For Ashita users, you can find a 'mipmap' addon available on our Discord: https://discord.gg/Ashita Windower can make use of this info if need be to make their own addon/plugin to restore this functionality as well. Example images of the way retail handles this now and with it patched back to '6': https://imgur.com/a/ys0r3jN Enjoy. :)
[+]
RadialArcana said: » Thank you! I don't get why they changed it. I can't say for sure, but I do have a theory/guess as to why they 'nerfed' this setting. With the influx of HD texture packs that heavily upscale or recreate new textures that are much larger than the base game textures, it adds up quickly to generate mipmaps for each texture that is used for a zone and its environment. XI is 32bit and is not (by default) marked as large address aware. Because of that, XI runs out of memory pretty quickly when using HD textures due to also being used with a higher mipmap level. My guess is that SE is intentionally locking this to '2' to try and meet a decent middle ground level while reducing the amount of memory allocated for all the mipmaps generated. Users that run into the issue of not having a zone load properly/at all (ie. loading into a black area with just models showing) would generate a bunch of invalid bug reports to SE due to using non-official mods/files. Rather than ban people for doing said mods, they instead may have gone this route to find a middle ground.
[+]
RadialArcana said: » Thank you! I don't get why they changed it. If the original code snippet that Wiccan showed was accurate... Probably someone new learning the code would be my guess. That sort of double function call for the same value would be the kind of thing that would get commented on in a code review and optimized out. If the FFXI config only supported values of 0 and 1, taking the if/else out is also a minor optimization to ensure that the expected input values from the config always mapped to an expected mmlvl. Something small like this and relatively harmless makes for a nice commit and pull request for someone learning the ropes. That's my guess. As for the HD texture pack issue, if there's no harm in making the game large address aware wouldn't it be a better fix to just do that? Wonder why they haven't.
[+]
Quote: I can't say for sure, but I do have a theory/guess as to why they 'nerfed' this setting. With the influx of HD texture packs that heavily upscale or recreate new textures that are much larger than the base game textures, it adds up quickly to generate mipmaps for each texture that is used for a zone and its environment. XI is 32bit and is not (by default) marked as large address aware. Because of that, XI runs out of memory pretty quickly when using HD textures due to also being used with a higher mipmap level. My guess is that SE is intentionally locking this to '2' to try and meet a decent middle ground level while reducing the amount of memory allocated for all the mipmaps generated. Yeah makes sense. Mipmapping is a double edged sword really. Being able to set it higher fixes the obnoxious shimmer problems but it also brings with it ram and hitching problems too if you use very high res texture mods. Cause unlike other games that store the mipmaps in the data files, XI makes them on the fly to save ps2 hd space and they are lost every time you zone. Assuming all this load is put on the cpu. I made some super high res textures on a specific npc years ago just to see what would happen, and when I got into range where it would load and with mipmap 6 the game would literally lock up for 2 seconds to make the mipmaps. With mipmap 0, nothing negative happened at all. Bump mapping also increases ram use too (especially since Amelia made custom bump maps), since it adds a lot of extra black and white textures to zone loading. Pity there seems to be no outside way to handle the mipmap / shimmer problem so the game setting can be at 0, since it's one of the major performance problems with modding the game.
[+]
Leviathan.Wiccaan said: » MipMap Information / Fix SE decided to change how the mipmap setting is being honored for whatever reason in the latest retail client update. Here is the information in regards to what was changed and how to fix it. The client loads the mipmap setting in several locations and applies different rendering adjustments. The main one of interest though is loaded into a sub-structure that holds the value. ... For Ashita users, you can find a 'mipmap' addon available on our Discord: https://discord.gg/Ashita Windower can make use of this info if need be to make their own addon/plugin to restore this functionality as well. Example images of the way retail handles this now and with it patched back to '6': https://imgur.com/a/ys0r3jN Enjoy. :) Thank you for the info Atom0s, we released MipmapFix a plugin that reinstates the original behavior. (did credit you on the author since you wrote the patch hope that is ok) The setting in the windower launcher still controls your mipmapping, so whatever you have that set to will be your mipmapping level with the plugin loaded. Once you launch the launcher, MipmapFix will be in the menu if you download it and enable you're good to go. If you want to use it on an already running box you can load it by doing: //load MipmapFix You then will need to zone before the change will take effect.
[+]
Carbuncle.Snicky said: » RadialArcana said: » Thank you! I don't get why they changed it. If the original code snippet that Wiccan showed was accurate... Probably someone new learning the code would be my guess. That sort of double function call for the same value would be the kind of thing that would get commented on in a code review and optimized out. If the FFXI config only supported values of 0 and 1, taking the if/else out is also a minor optimization to ensure that the expected input values from the config always mapped to an expected mmlvl. Something small like this and relatively harmless makes for a nice commit and pull request for someone learning the ropes. That's my guess. As for the HD texture pack issue, if there's no harm in making the game large address aware wouldn't it be a better fix to just do that? Wonder why they haven't. Why would I post non-accurate info? I am posting snippets pulled directly from the clients disassembled code. The naming of certain things (variables and some functions) that I post when I do things like this are not always 100% accurate to what SE has named them, but in many cases they are pulled directly from debug symbols and information left in the client. FFXI is coded on an ancient codebase originally coded for PS2 then ported to PC using a large amount of #ifdef and similar macros to keep most of the code base 1:1 to the console version while only replacing parts of code that need to be platform specific. (ie. Window creation, memory management, rendering, etc.) The code is still compiled on the old PS2 devkit tooling as well, meaning it is making use of VC6 for its compiler which has very few compiler based optimizations. On a modern compiler, a double call of the same function and storage into a variable would be automatically picked up and optimized away, but not the case for VC6. The raw ASM for the old client code is: Code .text:10038CE0 FUNC_CYyTexBase_CYyTexBase proc near .text:10038CE0 push ebx .text:10038CE1 push esi .text:10038CE2 mov esi, ecx .text:10038CE4 xor ebx, ebx .text:10038CE6 mov dword ptr [esi], offset PTR_vtbl_CYyTexBase .text:10038CEC mov [esi+4], ebx .text:10038CEF mov [esi+8], ebx .text:10038CF2 mov [esi+24h], bx .text:10038CF6 mov [esi+26h], bx .text:10038CFA mov [esi+28h], bl .text:10038CFD mov [esi+29h], bl .text:10038D00 call FUNC_CYmdb_GetMipMappingLevel .text:10038D05 test al, al .text:10038D07 jz short loc_10038D15 .text:10038D09 call FUNC_CYmdb_GetMipMappingLevel .text:10038D0E and eax, 0FFh .text:10038D13 jmp short loc_10038D1A .text:10038D15 ; --------------------------------------------------------------------------- .text:10038D15 .text:10038D15 loc_10038D15: .text:10038D15 mov eax, 1 .text:10038D1A .text:10038D1A loc_10038D1A: .text:10038D1A mov [esi+2Ah], al .text:10038D1D mov eax, [esi+2Ch] .text:10038D20 and eax, 0FFFFFE00h .text:10038D25 mov [esi+20h], ebx .text:10038D28 mov [esi+2Ch], eax .text:10038D2B mov [esi+1Ch], ebx .text:10038D2E mov eax, dword_10472CA4 .text:10038D33 mov ecx, eax .text:10038D35 inc eax .text:10038D36 push ecx .text:10038D37 push offset a10d ; "%10d" .text:10038D3C push (offset aUniq+5) ; Buffer .text:10038D41 mov dword_10472CA4, eax .text:10038D46 call _sprintf .text:10038D4B add esp, 0Ch .text:10038D4E mov ecx, esi .text:10038D50 push offset aUniq ; "-uniq" .text:10038D55 call sub_10038D90 .text:10038D5A mov eax, esi .text:10038D5C pop esi .text:10038D5D pop ebx .text:10038D5E retn .text:10038D5E FUNC_CYyTexBase_CYyTexBase endp There are various parts to this code that would be optimized in a much more efficient manner on modern compilers. As for the large address aware handling, it only goes so far just to mark the process as being 'aware'. Given that XI has its own memory pooling and management systems inside of the client, they are coded and designed to not be fully aware of that larger amount of memory or how to properly make use of when LAA is enabled. There are patches/tooling to already mark FFXI as LAA, but it only helps so much in moving the mark forward of when the client will go 'OOM' and crash still. Given the client is also coded to use Direct3D 8, it lacks a lot of the improvements seen to the DirectX SDK over the years since. Even just porting up to 9 would be a large gain in performance and additional feature sets for the game. SE had promised this was going to happen multiple times in the past, but it never came to be sadly. Fenrir.Niflheim said: » Thank you for the info Atom0s, we released MipmapFix a plugin that reinstates the original behavior. (did credit you on the author since you wrote the patch hope that is ok) Sounds good to me. :)
[+]
I remember being annoyed when anisotropic filtering stopped working with Nvidia cards around driver version 170. Cranking mipmapping up didn't reduce shimmering nearly as much as 8x anisotropic with mipmap at level 1. Also the mipmap level transistion became visible on ground textures around driver version 180. Anisotropic filtering also stopped working on ATI cards around driver version 9.4. Anyone know if it works these days?
Odin.Dirac said: » I remember being annoyed when anisotropic filtering stopped working with Nvidia cards around driver version 170. Cranking mipmapping up didn't reduce shimmering nearly as much as 8x anisotropic with mipmap at level 1. Also the mipmap level transistion became visible on ground textures around driver version 180. Anisotropic filtering also stopped working on ATI cards around driver version 9.4. Anyone know if it works these days? Was there a specific zone/area you recall that had this shimmer problem the most in regards to these settings? The only difference I see with cranking up anisotropic filtering is lighting looks slightly better on various wall lights, fires, and similar. This does require you to use something like dgVoodoo or another proxy to force the game to use the actual system GPU then setting the filtering to x16 in the Nvidia control panel to enable properly. Leviathan.Wiccaan said: » My apologies. That was just me hedging my bets in case you had simplified the code to make it easier to understand or something. I didn’t mean to suggest you were being intentionally misleading. Btw, it seems like SE released a ninja patch to fix the mysterious RoE quests.
Turning off mip-mapping in game entirely and using anisotropic filtering via the GPU drivers and a d3d proxy would likely be much better both performance and looks wise.
[+]
Dodik said: » Turning off mip-mapping in game entirely and using anisotropic filtering via the GPU drivers and a d3d proxy would likely be much better both performance and looks wise. What's the best way to turn this off? Windower mip-mapping slider to 0, all way to the left, is what I use.
Dodik said: » Turning off mip-mapping in game entirely and using anisotropic filtering via the GPU drivers and a d3d proxy would likely be much better both performance and looks wise. Mip mapping off, using dgvoodoo as a d3d proxy and using nvidia control panel to apply whatever anisotropic filtering or anti aliasing I want to have. (I use nvidia inspector for more in depth customisation because not every setting through nividia control panel always work in games). If anisotropic filtering doesn't get applied through control panel, you can use inspector to force it. I'd assume it works in general.
[+]
dgVoodoo2 lets you force both of those, been using them for awhile now.
Does dgvoodoo increase ram use or have any other negative impacts?
Mipmapping x6 increases vram use by about 60-80% You can increase vram allocation with dgvoodoo. I have mine set to 4096 per instance (don't set it this high, I did it because I can w/ my gpu, most cards will have 4-8gb of vram so 2gb is the most that you should really have it at especially when multi boxing) and haven't had a crash since w/ HD textures and ansitropy x16.
Anything that causes the game to ask the gpu to load more high resolution textures (mip mapping included) will increase vram usage.
[+]
RadialArcana said: » Does dgvoodoo increase ram use or have any other negative impacts? Mipmapping x6 increases vram use by about 60-80% I came across it at first when people were having black screen issues with HD zones, game was running out of memory and it fixed it. Can't say i've noticed an increase of vram being used by dgvoodoo, except for the extra ram I want it to use by uncapping it. It really is a massive positive being able to allow FF11 to use more vram if you're system can handle it, but you can also designate lower amounts of ram also, even keep it standard if that's what you want.
[+]
My experience with anisotropic filtering / mipmapping has been completely different. I use dgVoodoo, and while turning on anisotropic filtering (either through the Nvidia control panel, dgVoodoo settings, or even Nvidia Profile Inspector) can help reduce shimmering on HD textures, even cranking all of these settings up to their respective maximums does not eliminate it. It's still very noticeable and annoying, especially in high detail places such as the stone ground in Jeuno or the sand in Rabao. The only way I've found to actually get rid of the shimmering is to crank mipmapping up to 6.
Also, despite how inefficient the game's mipmapping implementation may be, I notice a far more significant FPS drop from anisotropic filtering than mipmapping. So for me, turning up mipmapping provides both better appearance *and* performance than anisotropic filtering. I just wanted to add this for those reading the thread, that YMMV based on hardware configurations. Out of curiosity, those of you who do not notice shimmering with mipmapping turned off, are you using the highly-detailed HD textures from this thread (FFXI HD Mods), or are you using lower detail up-scaled HD textures (such as those made by Ashenbubs)? Just curious why there's such a discrepancy. I use ashenbubs. When I do HD textures in games I typically want to keep the original design, just better looking. What I find in most other texture packs is they use a lot of artistic liberties which I'm not personally a fan of.
[+]
I use a combination of both, i'm not a fan of a lot of the more cartoonish upscales so just spent a lot of time mixing and matching.
Places like your example Jeuno, and many other places I'm using the high detail zones with no shimmering. I have: Super sampling: on Bump mapping: off Mip mapping: off Dgvoodoo 4gb: on Pol.exe patched with 4gb patch Not using dgovoodoos anisotropic filtering, forcing it through nvidia inspector. Another thing you can do that might improve texture quality is to apply a small amount of sharpening. Either through graphics drivers or something like reahade. If you overdo it you're going to make it look worse but a small amount helps with clarity.
Ok, that's interesting. I'm not surprised if you don't see shimmering with Ashenbubs' texture pack, it's really the highly detailed ones that have a problem for me, not the upscaled ones.
Also, I use all the same settings as Kruel, and it sounds like we're using the same Jeuno textures, but the shimmering in Jeuno without mipmapping is pretty terrible for me. |
All FFXIV and FFXI content and images © 2002-2024 SQUARE ENIX CO., LTD.
FINAL FANTASY is a registered trademark of Square Enix Co., Ltd.