GUI library for D

[Nick Sabalausky]

"Adam D. Ruppe" <destructionator at gmail.com> wrote in message 
news:ini1jr$2lj3$1 at 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).

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

Ahh, I see :)

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

Yea. Actually, I think I'll need to take look at Derelict again. I know that 
project already has a lot of these game-appropriate APIs wrapped for D (or 
at least bindings). I don't remember: Did you say this would ideally be 
something for Phobos? If so, I wonder if requiring Derelict would be a 
problem. If it is, then maybe I could just borrow the appropriate code from 
Derelict, depending on the licenses involved (I don't remember what 
Derelict's license is).

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

Yea, same here for the most part. Although I have fallen completely in love 
with the first three Splinter Cell games :) And Pikmin. And Moonbase 
Commander (Although that one's more SNES-style). Actually, there's a fair 
amount in both gaming eras I'm really into (and in-between stuff, like Doom 
1/2/64 and the first two Quakes). But with the newer stuff it just seems to 
be getting harder and harder to find the gems, and even when you do, they're 
likely to have more problems than they used to (Like Sonic Unleashed: The 
daytime levels and puzzle areas were fantastic, but then they had to cram in 
reams of utterly pointless dialog, cutscenes and nighttime levels - and then 
Sonic Colors didn't *remotely* live up to the claims of "It's Sonic 
Unleashed's daytime!" Sonic Team really needs to just step aside and let 
Dimps handle everything...)

And along the NES/SNES lines, I've always been a huge sucker for DOS VGA/EGA 
gaming. Back when Epic put out good games, and Apogee was still relevent 
(and actualy existed). Three hidden gems of that era that I'd highly 
recommend are Capture The Flag (EGA, turn-based strategy), Space Chase (EGA, 
platformer), and God of Thunder (VGA, sort of a slightly linear SNES-Zelda). 
And, of course, almost any of Epic's, Apogee's and id's DOS games. You'd 
probably need DOSBox for all of them these days.