add comments about y-sorting

desmume/src/gfx3d.cpp

@@ -2090,7 +2090,20 @@ void gfx3d_glFlush(u32 v)
 	GFX_DELAY(1);
 }
 
-static bool gfx3d_ysort_compare(int num1, int num2)
+static inline bool gfx3d_ysort_compare_orig(int num1, int num2)
+{
+	const POLY &poly1 = polylist->list[num1];
+	const POLY &poly2 = polylist->list[num2];
+
+	if(poly1.maxy != poly2.maxy) 
+		return poly1.maxy < poly2.maxy; 
+	if(poly1.miny != poly2.miny) 
+		return poly1.miny < poly2.miny; 
+
+	return num1 < num2;
+}
+
+static inline bool gfx3d_ysort_compare_kalven(int num1, int num2)
 {
 	const POLY &poly1 = polylist->list[num1];
 	const POLY &poly2 = polylist->list[num2];
@@ -2112,6 +2125,14 @@ static bool gfx3d_ysort_compare(int num1, int num2)
 	return (num1 < num2);
 }
 
+static bool gfx3d_ysort_compare(int num1, int num2)
+{
+	bool original = gfx3d_ysort_compare_orig(num1,num2);
+	bool kalven = gfx3d_ysort_compare_kalven(num1,num2);
+	assert(original == kalven);
+	return original;
+}
+
 static void gfx3d_doFlush()
 {
 	gfx3d.frameCtr++;
@@ -2197,6 +2218,11 @@ static void gfx3d_doFlush()
 			gfx3d.indexlist.list[ctr++] = i;
 	}
 	
+	//NOTE: the use of the stable_sort below must be here as a workaround for some compilers on osx and linux.
+	//we're hazy on the exact behaviour of the resulting bug, all thats known is the list gets mangled somehow.
+	//it should not in principle be relevant since the predicate results in no ties.
+	//perhaps the compiler is buggy. perhaps the predicate is wrong.
+
 	//now we have to sort the opaque polys by y-value.
 	//(test case: harvest moon island of happiness character cretor UI)
 	//should this be done after clipping??