GUI library for D

[Adam D. Ruppe]

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.

I'm actually already almost to the point where the simple event
loop / gdi implementation works, so won't take long to finish
that off. Then we'll go back and see what to do with speed with
the simple base to compare against.

> It's good enough for desktop applications, and it's fine if
> you're just going to draw something once and display it.

Heh, that /was/ my original intention! But now, I think we can
go so much further.

> 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!

> 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.

> I'd love to do some of this.

Excellent!

> You were using getch() in a game?

Not literally, no, but this was quicker to write up in a post
than to dig up the old assembly and keymaps to paste it all in,
while still hopefully showing the same basic idea behind it.
(specifically that it was a simple loop rather than a callback
or virtual function system like most events nowadays)

> BTW, this is something I'd use DirectInput for. The Win32 event
> system is about as suitable for game input as the GDI is for game
> graphics.

All right. If you have the time to write that up too, I'd
appreciate it. I'll keep it simple now due to my lack of experience
with it. The one rule though is it needs to remain easy to use. One
idea here is that newbies can run with it quickly.

> Don't want to join one of the established companies though.

Oh, hell no. Especially since my preferred style is more NES than
XBox - I like the simple 2d, low resolution look. I like the
relatively low frame rate. There's a lot less pressure to code
it perfectly too (meaning I can just whip stuff out and it's good
enough as long as its fun).


> Interesting. I've had a lot of thoughts about game loops flying
> around in the back of my mind too, but talking about any of it
> will have to wait for another time, gotta get back to some other
> stuff right now

Yea, me too... I did start that eventLoop function last night
though. So far just tied in WM_KEYDOWN to a delegate, but it works
and it's easy, so I figure I'll continue to flesh it out for the
basic operations. This way, we can play with it soon and can go
back and switch to a better system later.