On 07.04.2011 0:11, Nick Sabalausky wrote:
"Adam D. Ruppe"<destructiona...@gmail.com> wrote in message
news:ini1jr$2lj3$1...@digitalmars.com...
Nick Sabalausky wrote:
Of course, if you see any fundamental
problems with this, feel free to let me know :)
I'm pretty sure your plan would work and would provide a boost,
but I'm not sure if it's worth the extra time.
I think the best thing to do will be to partially implement it,
write a little program with both methods and run some speed tests.
See if it's still easy to use and how big the difference really is.
Yea, sounds like a good plan. Although, my design is heavily dependent on
inlining working, so that may be a problem until DMD issue #5708 gets fixed:
http://d.puremagic.com/issues/show_bug.cgi?id=5708
There another similar -inline related bug in there too, but I don't remember
offhand what it is.
And even then, things like line drawing, fills and image
blitting are still better off skipping the
individual-pixel-access routines
Aye, even my homegrown DOS would always write them separately.
Horrible waste of instructions doing another y<< 8 + y<< 6 when
a simple "inc ax" would suffice!
Yup, exactly. Which reminds me, I've always wanted to actually check to see
if modern compilers (or at least DMD) would be smart enough to optimize
something like:
for(i in 128...256)
arr[i] = ...;
Into something like:
auto ptr = arr.ptr + 128;
auto ptrEnd = arr.ptr + 256;
for(; ptr< ptrEnd; ptr++)
*ptr = ...;
My guess is no (and I'm fairly certain it was "no" back in my DOS days: that
was the sort of manual optimization I remember doing all the time), but with
all the improvements that optimizers keep making, I'm not really sure
anymore.
Of course, even if the compiler can optimize that, I still doubt it would be
able to automatically do an equivalent optimization to effectively create,
for example, Bresenham's algorithm (ie, straight diagonal lines between two
arbitrary points).
But anyway, I don't know exactly how you were going about it, but
the way to do this in OpenGL or DirectX would be to do all your
drawing to a texture buffer
I at first just used a SetPixel function in opengl, but when it
was unacceptable, I simply abandoned the idea of drawing pixels
to the screen. Instead, I started focusing on polygons and textures -
a rectangle with a bitmap attached as a texture makes an excellent
sprite that draws very very quickly, even if rotated or misshapen.
Once I realized that works so well, pixels weren't important
anymore so I just stopped using the old functions entirely. They're
still in the code, still godawfully slow, but I don't care enough
to change it.
Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we
could do better (as long as we had direct access to the texture's buffer).
Mmm, am I the only one wondering where did you guys get SetPixel in
OpenGL ? It's must have been GDI.
At any rate OpenGL and DirectX is all about sending commands and data
back and forth between CPU and videocard (well, there is driver
involved, doing some translation into specific chip's commands and such).
So no, SetPixel couldn't exactly get inlined just because you can't
access video ram without jumping through some hoops: OS -> HAL-> driver
------->PCI-E or AGP -> ... -> video RAM. OpenGL and DirectX subsytems
bypass some of these additional hoops, but still you have to send the
data down this route. That's why it's usually used for massive
asynchronous transfers.
E.g. every time you need GetPixel you send "read pixels command" and
wait utill all the data already streamed in is processed and stored in
the video RAM, then it reads framebuffer and sends you results
(effectively stalling all it's processors).
So for "straight" setpixel/putpixel drawing, software render + blit to
screen is the way
(but I doubt you need only pixels, and going futher inevitably shows
why software render sucks).
--
Dmitry Olshansky
