or he has a mutant calc 

that not exactly this

I create my list : n
I sort it, and directly create the id list : n²
then I read,to the id list to render :n

I have 2n+n² in all,wich is ... slow.
But how can I sort and create the ID while creating the distance list?

then make an other one

Why are we always in the wrong line in the supermarket ?

yes that the goal of the GSort()

but, if I delete the cmd, add a GDrwSortArray() cmd, who include direcly the sorting algo with somethng like as willrandship say (if I well understand):
for(nb_poly)
CALCULATE DIST
end

for(nb_poly)
for(nb_poly)
find the greatest value in dist list and retrieve ID
end
draw The ID e poly
make the IDe dist value be 0
end


it will be more optimized. (save data)

BUT the algorithm still in O(n²) and optimizable 

The Gsort() command create a 2 bytes list of distance, sort them and give a list of ID like :

{1000,2500,5000,100}  -> list created
{2,1,0,3}  -> list of ID

I'm currently using a O(n²) algorithm, so it's sure it can be optimized 

as side part, I work on portal and run some speed test, with a constant speed for clipping :

a large world (256 vertices with 16 portals,16 vertices by sector) are rendering at the speed of +-17 fps  (in wired mode)
so it's perfectly playable !!
I hope the clipping will not be too much slow, tough.

wow this is a very fun game.     It's great that you do a reboot. Let's see where this going to lead   

this is a very great program  good job 

it's sure that a MC can't be done on a z80 even in 15MHz... it's require too much game mechanics, but I think that a VERY simplified engine can be done, though.
(like in black and white, no texture, only wired...)