Now that the zbuffer contains floating-point-values, the ztest became a bit suboptimal:
fld dword ptr [ebp-380] ' load Cur_Z (floating-point)
fcomp dword ptr [eax] ' Compare with Zbuffer(it)
push eax ' Save Register ax
fnstsw ax ' load fpu-state to ax
test ah, 0b01000001 ' test for bit containing "lower" state
pop eax ' restore register ax
jnz .Lt_05EA ' jump if bit was set
' render pixel
.Lt_05EA:
' continue
(piece of assembly-output from the freebasic compiler)
As this is a general overhead even for those pixels which don't pass the ztest, I suggest you scale your interpolated z-value to reasonable size and store it into an integer zbuffer:
dim as integer Cur_Z,d_Z
...
d_Z = xDiv * (_zz2 - _zz1) * 2147483647.0
Cur_Z = _zz1 * 2147483647.0
for i as integer = 1 to size
If Cur_Z > ZBuffer(it) then
ZBuffer(it) = Cur_Z
...
end if
...
Cur_Z+=d_Z
Next
(Using 2147483647.0 [2^31-1] assumes your front-clipplane is >=1)
Alternatively, because the binary bitset of strictly increasing positive floating-point values is also strictly increasing, you can simply "assume them as integers":
Make integer-pointers to your (single-)zbuffer and (single-)z-value and compare those.
Both ways end up equally:
mov eax, dword ptr [ebp-380] ' load Cur_Z (inetger)
cmp dword ptr [eax] ' Compare with Zbuffer(it)
jle .Lt_05EA ' jump if smaller or equal
' render
.Lt_05EA:
' skip
If your sub (including macros) is called often and has a lot of local variables, declare them static.
Otherwise the compiler will initialize all local variables to zero when it is called, which looks like this:
mov dword ptr [ebp-4], 0
mov dword ptr [ebp-8], 0
mov dword ptr [ebp-12], 0
mov dword ptr [ebp-16], 0
mov dword ptr [ebp-20], 0
mov dword ptr [ebp-24], 0
mov dword ptr [ebp-28], 0
mov dword ptr [ebp-32], 0
mov dword ptr [ebp-36], 0
mov dword ptr [ebp-40], 0
mov dword ptr [ebp-44], 0
mov dword ptr [ebp-48], 0
mov dword ptr [ebp-52], 0
mov dword ptr [ebp-56], 0
mov dword ptr [ebp-60], 0
mov dword ptr [ebp-64], 0
mov dword ptr [ebp-68], 0
mov dword ptr [ebp-72], 0
mov dword ptr [ebp-76], 0
mov dword ptr [ebp-80], 0
mov dword ptr [ebp-84], 0
mov dword ptr [ebp-88], 0
mov dword ptr [ebp-92], 0
mov dword ptr [ebp-96], 0
mov dword ptr [ebp-100], 0
mov dword ptr [ebp-104], 0
mov dword ptr [ebp-108], 0
mov dword ptr [ebp-112], 0
mov dword ptr [ebp-116], 0
mov dword ptr [ebp-120], 0
mov dword ptr [ebp-124], 0
mov dword ptr [ebp-128], 0
mov dword ptr [ebp-132], 0
mov dword ptr [ebp-136], 0
mov dword ptr [ebp-140], 0
mov dword ptr [ebp-144], 0
mov dword ptr [ebp-148], 0
mov dword ptr [ebp-152], 0
mov dword ptr [ebp-156], 0
mov dword ptr [ebp-160], 0
mov dword ptr [ebp-164], 0
mov dword ptr [ebp-168], 0
mov dword ptr [ebp-172], 0
mov dword ptr [ebp-176], 0
mov dword ptr [ebp-180], 0
mov dword ptr [ebp-184], 0
mov dword ptr [ebp-188], 0
mov dword ptr [ebp-192], 0
mov dword ptr [ebp-196], 0
In TextureT.GenerateMipMap you should take into account that texture do not need to be quadratic.
Especially for sky-domes it's common to have 1024x256 or something like that.