Cool, that makes sense, except what value to use for counting. Doesn't that mean I'd need to know either the interection point's X or Y value beforehand?

Ok, I follow that transparency colours are a problem when rendering images in hardware mode, but I don't think that you looked at the sample I put up? Please take a look at the code in this project (Also, try running the .exe):

http://etgames.q.org.za/tmp/Prototype2.zip

I am not using any images in this example, and the problem is not caused by transparencies. I am cycling a value through the shades of blue, then clearing a surface to that colour, then rendering the surface to the main DXDraw surface:

Code:
    Inc(Temp,10);
    Surface.Fill(Temp); 
    DXDraw.Surface.Draw(0,100,Rect(0,0,Surface.Width,Surface.Height),Surface);
In software mode: You see the surface cycling through shades of blue
In hardware mode: The surface gets "stuck" on the last colour that it was changed to in software mode.

So, that is what I mean by rendering failing is that any drawing to the surface in hardware simply doesn't happen. I get exactly the same behaviour if I try to render an image to the surface.

This functionality is definately working in the older version of unDelphiX that I am using, and no longer works in 1.0.7. (I've verified this on more than one computer)

Thanks for the suggestion regarding storing of images. I'll look into putting together something like that in the future. (No time to revise my image storage system at the moment)