www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - simpledisplay.d now works on as 64 bit on X

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I know someone here was asking about my simpledisplay.d on 64 bit 
a while ago.. I don't remember who so here's a general 
announcement.

I got it working for at least the parts I tried (display image, 
get keyboard input) compiled with -m64:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d

Quite a hassle, my xlib binding was apparently almost completely 
wrong, and it worked on 32 bit just by sheer luck. Many of the 
structs were the wrong sizes even there! General tip to C 
porters: do a static assert(S.sizeof) and make sure it matches 
what your C program gives. I got snagged in part here because 
unsigned long in X is apparently 64 bit. I thought it was the 
same as D's uint in all cases.

The file it also depends on color.d from the same repo. Another 
minor change is the key event used to take a delegate (int 
key){}. Now it takes (int key, bool pressed) instead. There's a 
static assert with a reminder message too, so just compile and if 
you need it, it will tell you. The (dchar){} event remains the 
same as before.

Been a few random bug fixes in the last few months too, timer 
events now work right on windows and linux is the big one that 
comes to mind.
Jun 02 2013
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
I'm sorry to hear that you ran into the unsigned long problem.
I noticed it in time and asked about it on the NG and was told
that the difference is between Windows and Posix. One takes
long as int32, the other as the native machine word size on
64-bit. We do the same stupid mistakes over and over. :p

Also eventually we should generate X bindings for all
platforms (including Windows) from the XML definitions like
XCB does. That means a small core written in D that enables
RPC to the X Server and a generator tool that creates
functions, structs and DDoc from what is the XML files.
(See /usr/share/xcb.)

-- 
Marco
Jun 02 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/2/13, Marco Leise <Marco.Leise gmx.de> wrote:
 I'm sorry to hear that you ran into the unsigned long problem.
This is why we have core.std.config: import core.stdc.config : c_long, c_ulong;
Jun 02 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 22:16:57 UTC, Andrej Mitrovic wrote:
 This is why we have core.std.config:

 import core.stdc.config : c_long, c_ulong;
I would never have thought to look in "config" for types! Well, hopefully I'll remember for next time.
Jun 02 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 This is why we have core.std.config:

 import core.stdc.config : c_long, c_ulong;
Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html I'd like to open a little documentation enhancement request for that. Bye, bearophile
Jun 02 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/2/13 7:10 PM, bearophile wrote:
 Andrej Mitrovic:

 This is why we have core.std.config:

 import core.stdc.config : c_long, c_ulong;
Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html I'd like to open a little documentation enhancement request for that. Bye, bearophile
And while you are at it, please also contribute the corresponding pull request. Time to inaugurate bearophile's additions! Andrei
Jun 02 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 And while you are at it, please also contribute the 
 corresponding pull request. Time to inaugurate bearophile's 
 additions!
As my friend, please understand, I can't afford to get addicted to that :-) Hugs, bearophile
Jun 02 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 Why isn't that linked in this page?
 http://dlang.org/phobos/std_stdint.html
It seems it lacks some of them, this gives an import error: import core.stdc.config: c_ulonglong, c_longlong; Bye, bearophile
Jun 02 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 23:19:18 UTC, bearophile wrote:
 It seems it lacks some of them, this gives an import error:
It only defines c_long and c_ulong. I guess this is ok because the other types don't vary, though I kinda think it should do them all just so you can be consistent. Not long ago I thought int on 64 bit was 64 bit too, because int on 16 bit is 16 bit so I figured it just did that the whole way up. But no, C's int is always D's int. A nice c_int alias would make that mindless too, even though it isn't strictly necessary.
Jun 02 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/3/13, bearophile <bearophileHUGS lycos.com> wrote:
 Why isn't that linked in this page?
 http://dlang.org/phobos/std_stdint.html
Because it's on this page: http://dlang.org/interfaceToC.html
 It seems it lacks some of them, this gives an import error:
 import core.stdc.config: c_ulonglong, c_longlong;
Again see http://dlang.org/interfaceToC.html
Jun 02 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote:
 http://dlang.org/interfaceToC.html
aaaaah then what is this page doing there? http://dlang.org/htomodule.html The documentation could def use a lil cleanup.
Jun 02 2013
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/3/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote:
 http://dlang.org/interfaceToC.html
aaaaah then what is this page doing there? http://dlang.org/htomodule.html The documentation could def use a lil cleanup.
There's a bug report for everything: http://d.puremagic.com/issues/show_bug.cgi?id=7346 I'm like a handy little bugzilla bot. :p
Jun 02 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:

 Because it's on this page:

 http://dlang.org/interfaceToC.html

 It seems it lacks some of them, this gives an import error:
 import core.stdc.config: c_ulonglong, c_longlong;
Again see http://dlang.org/interfaceToC.html
Good, thank you. I missed that. Bye, bearophile
Jun 02 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote:
 Also eventually we should generate X bindings for all
 platforms (including Windows) from the XML definitions like
 XCB does.
hmm I don't see an xml file for Xlib.h on my system, do you know if there is supposed to be one? Though I'm pretty sure I have most of it correct now, so I guess it isn't really necessary. I know everybody says Xlib is dying but I still use it. It is simple enough and gets the job done without having to learn a whole thing library...
Jun 02 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 03 Jun 2013 01:02:12 +0200
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote:
 Also eventually we should generate X bindings for all
 platforms (including Windows) from the XML definitions like
 XCB does.
hmm I don't see an xml file for Xlib.h on my system, do you know if there is supposed to be one? Though I'm pretty sure I have most of it correct now, so I guess it isn't really necessary.
XCB is generated from these XML files. They have nothing to do with Xlib. You can find the XML files here: http://cgit.freedesktop.org/xcb/proto/tree/src A generator tool for the target language (C in this case) parses them and creates include files from them that define all the remote procedure calls to the X Server. Internally those calls rely on a small generic set of functions that serializes the requests for transmission. What is needed are those generic functions written in D to establish the connection to the server and handling serialization, probably relying on std.socket. And then an XML parser that would write out .d files for the different modules of the X Server, like xrandr, xkb and so on, which are all available as separate XML files. This is what a RPC from glx.xml looks like: <request name="GenTextures" opcode="145"> <field type="CONTEXT_TAG" name="context_tag" /> <field type="INT32" name="n" /> <reply> <pad bytes="1" /> <pad bytes="24" /> <list type="CARD32" name="data"> <fieldref>length</fieldref> </list> </reply> </request> In general they also include documentation tags which can be made available through DDoc automatically and displayed in IDEs like Mono-D already does.
 I know everybody says Xlib is dying but I still use it. It is 
 simple enough and gets the job done without having to learn a 
 whole thing library...
The big deal about it is asynchronous RCP especially over internet connections to X Servers, since with Xlib you have to way for each response before the next request. -- Marco
Jun 02 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote:
 all the remote procedure calls to the X Server. Internally
 those calls rely on a small generic set of functions that
 serializes the requests for transmission.
I see. I just skimmed an xcb tutorial and it isn't all that different than xlib so maybe I'll spend a weekend on it at some point and make it work in D. There's a few things we can do to make the async stuff pretty too, thanks to delegates and the sort. And perhaps I can add a concept of a sprite to simplediplay. This represents an XPixmap - distinct from an XImage in that it is on the server - or on Windows, we can probably just us an HBITMAP. These wouldn't offer direct pixel manipulation like simplediplay's current Image (which is an XImage and HBITMAP in implementation) but would be able to avoid transferring a lot of data to the X server. And lastly (optionally, like with terminal.d) tie it into my generic eventloop.d. Then we'll really be cooking with gas! It'll have to wait a while though, hacking on this stuff doesn't make my house payments :(
Jun 02 2013
parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 3 June 2013 at 01:31:27 UTC, Adam D. Ruppe wrote:
 On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote:
 all the remote procedure calls to the X Server. Internally
 those calls rely on a small generic set of functions that
 serializes the requests for transmission.
I see. I just skimmed an xcb tutorial and it isn't all that different than xlib so maybe I'll spend a weekend on it at some point and make it work in D. There's a few things we can do to make the async stuff pretty too, thanks to delegates and the sort. And perhaps I can add a concept of a sprite to simplediplay. This represents an XPixmap - distinct from an XImage in that it is on the server - or on Windows, we can probably just us an HBITMAP. These wouldn't offer direct pixel manipulation like simplediplay's current Image (which is an XImage and HBITMAP in implementation) but would be able to avoid transferring a lot of data to the X server. And lastly (optionally, like with terminal.d) tie it into my generic eventloop.d. Then we'll really be cooking with gas! It'll have to wait a while though, hacking on this stuff doesn't make my house payments :(
There is already a functional XCB binding somewhere on GitHub. I managed to compiled it and play with it last year with success.
Jun 05 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 5 June 2013 at 16:33:57 UTC, Dejan Lekic wrote:
 There is already a functional XCB binding somewhere on GitHub. 
 I managed to compiled it and play with it last year with 
 success.
cool... I found one on dsource but not github yet. The dsource one transforms the XML but doesn't seem to implement all needed functions. Shouldn't be hard to complete anyway though. This is kinda exciting. I gotta say, part of me wants to write an X /server/ now too. How hard can it be? Run the protocol generator in reverse if you will and implement the functions I want. Why? Cuz then I'll add extensions I want to play with easily and ultimately compile it to javascript :P
Jun 05 2013
next sibling parent reply "maarten" <maartenvd1994 gmail.com> writes:
Very good news that I can now compile it on my 64 bit machine,
because dmd not only refused to in the past but I couldn't even
get -m32 working. (Probably installed something somewhere
incorrectly?)

Thank you :)
Jun 08 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Saturday, 8 June 2013 at 22:45:36 UTC, maarten wrote:
 Very good news that I can now compile it on my 64 bit machine,
 because dmd not only refused to in the past but I couldn't even
 get -m32 working. (Probably installed something somewhere
 incorrectly?)
It should pretty much just work if you just grab simpledisplay.d and color.d and add both files to your dmd command to compile all at once. If not though let me know and I can look into it.
Jun 09 2013
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 06 Jun 2013 01:27:58 +0200
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 cool... I found one on dsource but not github yet. The dsource 
 one transforms the XML but doesn't seem to implement all needed 
 functions. Shouldn't be hard to complete anyway though.
Does that mirror XCB (independent of XCB, implements RPC) or add a wrapper layer around the C bindings? Because it would be kinda cool to have a real X sever binding in D and not just D bindings to the C bindings to the X server. :p -- Marco
Jun 08 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 05:53:40 UTC, Marco Leise wrote:
 Does that mirror XCB (independent of XCB, implements RPC) or
 add a wrapper layer around the C bindings? Because it would be
 kinda cool to have a real X sever binding in D and not just
 D bindings to the C bindings to the X server. :p
It is just bindings right not but it is built from the xml file so if I spent some time tweaking it and writing the 10 or so base functions it needs from the C library it should be good to go. Though tweaking it is harder for me than it should be because I don't know xslt at all. I might just do my own thing anyway, I'm reading up on the x protocol myself so I know all the needed details.
Jun 09 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d
Time ago I tried simpledisplay (on 32 bit Windows) and I remember I had to make the class Image final to have some performance. I used it on Rosettacode too: http://rosettacode.org/wiki/Forest_fire#Graphical_Version I have tried that Forest fire code with your new version and it gives me a: simpledisplay.d(676): Error: undefined identifier i, did you mean variable s? The line is here: void drawPixmap(Sprite s, int x, int y) { BITMAP bm; HDC hdcMem = CreateCompatibleDC(hdc); HBITMAP hbmOld = SelectObject(hdcMem, s.handle); GetObject(i.handle, bm.sizeof, &bm); << Bye, bearophile
Jun 09 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 12:09:03 UTC, bearophile wrote:
 Time ago I tried simpledisplay (on 32 bit Windows) and I 
 remember I had to make the class Image final to have some 
 performance. I used it on Rosettacode too:
Hmm probably putPixel and impl.putPixel is too slow, it is called a lot. I made the class final now and got a about 8% improvement, using linux right now. Eliminating those calls entirely, writing straight to the private rawData pointer, gives about 12% improvement, since this would get rid of calculating pixel offsets too (we can just do ptr++). Maybe I'll expose that and try to make it somehow cross platform. I got as high as 45 fps using that trick plus the dmd -inline -release -O -noboundscheck flags. (The original code without flags and without final gave me only 30 fps). I compiled and ran on wine too and it seems to have worked. Here's the nextState function using a pointer: void nextState(ref World world, ref World nextWorld, ref Xorshift rnd, Image img) { auto pixelPointer = img.getDataPointer(); auto linePadding = img.bytesPerLine() - img.bytesPerPixel * img.width; auto pixelPadding = img.bytesPerPixel() - 3; enum double div = cast(double)typeof(rnd.front()).max; immutable nr = world.length; immutable nc = world[0].length; foreach (r, row; world) { foreach (c, elem; row) { final switch (elem) { case Cell.empty: *pixelPointer++ = 255; *pixelPointer++ = 255; *pixelPointer++ = 255; //img.putPixel(c, r, white); nextWorld[r][c] = (rnd.front()/div)<P_PROB ? Cell.tree : Cell.empty; rnd.popFront(); break; case Cell.tree: //img.putPixel(c, r, green); *pixelPointer++ = 0; *pixelPointer++ = 255; *pixelPointer++ = 0; foreach (rowShift; sp) foreach (colShift; sp) if ((r + rowShift) >= 0 && (r + rowShift) < nr && (c + colShift) >= 0 && (c + colShift) < nc && world[r + rowShift][c + colShift] == Cell.burning) { nextWorld[r][c] = Cell.burning; goto END; } nextWorld[r][c]=(rnd.front()/div)<F_PROB ? Cell.burning : Cell.tree; rnd.popFront(); END: break; case Cell.burning: //img.putPixel(c, r, red); *pixelPointer++ = 0; *pixelPointer++ = 0; *pixelPointer++ = 255; nextWorld[r][c] = Cell.empty; break; } pixelPointer += pixelPadding; } pixelPointer += linePadding; } swap(world, nextWorld); }
 I have tried that Forest fire code with your new version and it 
 gives me a:
 simpledisplay.d(676): Error: undefined identifier i, did you 
 mean variable s?
oops fixed. I added a new function but didn't even compile the Windows version of this change (only tried linux) and made a typo there.
Jun 09 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 I got as high as 45 fps using that trick plus the dmd -inline 
 -release -O -noboundscheck flags. (The original code without 
 flags and without final gave me only 30 fps).
Some people keep saying how much nice the F# language is, and indeed I like it and it's nice. But on that page the F# entry seems to be more than 10 times slower than D entry (the image says 2.9 FPS, but maybe it's in debug mode): http://rosettacode.org/wiki/Forest_fire#F.23
 I compiled and ran on wine too and it seems to have worked.
thank you for your quick fixes and improvements :-)
 oops fixed.
After this you will probably be more careful in future, to avoid similar bugs :-) Bye and thank you, bearophile
Jun 09 2013
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 14:00:20 UTC, bearophile wrote:
 But on that page the F# entry seems to be more than 10 times 
 slower than D entry (the image says 2.9 FPS, but maybe it's in 
 debug mode):
They could have ran it on a slow computer too, only way to be fair with these kind of comparisons is to it yourself.
 After this you will probably be more careful in future, to 
 avoid similar bugs :-)
Yeah, I just made a new script on my linux computer called dmdw that calls the Windows version of dmd (through wine) for easy testing. Now I don't have to get out my laptop just to make sure changes still compile.
Jun 09 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 I got as high as 45 fps using that trick plus the dmd -inline 
 -release -O -noboundscheck flags. (The original code without 
 flags and without final gave me only 30 fps).
Compiled with dmd, on my slower PC I see about 37 fps on the original code. Using ldc2 on the same code I see 53 fps. Using the pointers with ldc2 I see 68 fps. And with a bit more cache-friendly data structure: alias World = Cell[worldSide][]; I see 74 fps with ldc2 with pointers. On Windows Vista the the window close X button on the top right doesn't work, and I have to use the close from the window menu on the top left. Bye, bearophile
Jun 09 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 20:22:24 UTC, bearophile wrote:
 Using the pointers with ldc2 I see 68 fps.
Good speed there. Another problem I just realized though: on Windows, bitmaps are stored upside down so you'd have to draw y-inverted too. Didn't make a difference here because the image doesn't care about orientation but it would be visible with a lot of other programs. Maybe simple functions or mixins (if inlining isn't reliable) could be used to hide this detail. Though for max performance you might have to know some platform specific details anyway. (and this library isn't really made for max performance, instead preferring simplicity of use and implementation. but still no need to be pointlessly slow)
 On Windows Vista the the window close X button on the top right 
 doesn't work, and I have to use the close from the window menu 
 on the top left.
OK I'll check that from my laptop tomorrow.
Jun 09 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 Another problem I just realized though: on Windows, bitmaps are 
 stored upside down so you'd have to draw y-inverted too. Didn't 
 make a difference here because the image doesn't care about 
 orientation but it would be visible with a lot of other 
 programs.

 Maybe simple functions or mixins (if inlining isn't reliable) 
 could be used to hide this detail.
This high level library should generate the same image output on all systems it compiles on.
 (and this library isn't really made for max performance, 
 instead preferring simplicity of use and implementation.
A small, basic and simple to use graphics library has its usages. For small single-module (or few modules) programs like the one I have linked in Rosettacode you don't want to import a large GUI library. Eventually I think such simple simpledisplay.d and color.d modules should go in Phobos, after some cleaning, ddoc string, a heavy cycle of review and improvements, API design, etc. It's a battery worth putting in the standard library. So people can write portable and very easy to use little graphical programs in D. Delphi has a large and efficient GUI toolkit in the standard library, but I think it's not a good idea to put a GUI toolkit in Phobos. But a little library as simpledisplay is OK. Maybe for Phobos simpledisplay.d could be renamed just graphicdisplay.d or something like that. Regarding color, I think it will enjoy few more color-related functions, like a function to generate a rainbow given the temperature of a black body, few more greying functions, a bit more colorimetry, etc. A color.d module for Phobos should not import simpledisplay.d. And it should be a top-level module (unlike now, that's inside a package). Even the Python standard library has a very minimal color module: http://docs.python.org/2/library/colorsys.html A third small module (less than 15-30 KB of code) worth adding to Phobos, that builds on graphicdisplay.d and color.d, could generate basic data plots (scatter plots and line plots). It's not meant to replace a complete library for graphing. It's meant for a quick and very simple display of all kind of data during development or for quick D script-like programs. When I program in Python I often use the good http://matplotlib.org/ . It's a large plotting library that allows me to plot data with few lines of code. This allows me to visualize intermediate data during debugging, like arrays, so it improves my understanding of data and such data. Bye, bearophile
Jun 09 2013
next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 10.06.2013 00:09, bearophile pisze:
 Delphi has a large and efficient GUI toolkit in the standard library,
 but I think it's not a good idea to put a GUI toolkit in Phobos. But a
 little library as simpledisplay is OK.
Hmm... What if Lazarus GUI code and/or LCL could be ported to D? I've seen full featured Object Pascal parser in their repository. Maybe it's possible to transcode the source to D ;) Just thinking loud.
Jun 09 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Piotr Szturmaj:

 Hmm... What if Lazarus GUI code and/or LCL could be ported to 
 D? I've seen full featured Object Pascal parser in their 
 repository. Maybe it's possible to transcode the source to D ;) 
 Just thinking loud.
Even if that's possible, I think it's not a good idea to put the resulting large library in Phobos, because everyone has different needs and tastes regarding GUI toolkits. Bye, bearophile
Jun 09 2013
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 10.06.2013 00:29, bearophile pisze:
 Piotr Szturmaj:

 Hmm... What if Lazarus GUI code and/or LCL could be ported to D? I've
 seen full featured Object Pascal parser in their repository. Maybe
 it's possible to transcode the source to D ;) Just thinking loud.
Even if that's possible, I think it's not a good idea to put the resulting large library in Phobos, because everyone has different needs and tastes regarding GUI toolkits.
Yes, I was just suggesting to not write such library from scratch.
Jun 09 2013
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 9 June 2013 at 22:09:55 UTC, bearophile wrote:
 This high level library should generate the same image output 
 on all systems it compiles on.
Naturally. But if we can get a 10% performance boost that can be worth it in a lot of cases. Maybe the api can actually be an output range for colors that does one pixel at a time from top to bottom, left to right. That'd be less raw than the pointer but still avoid recalculating offsets every time when it could just be a simple increment.
 A small, basic and simple to use graphics library has its 
 usages. For small single-module (or few modules) programs like 
 the one I have linked in Rosettacode you don't want to import a 
 large GUI library.
Yes, I agree. I used to do a lot of fun stuff in DOS back in the day when all you have is a 256 color, 320x200 framebuffer. It was great actually, much lower learning curve than today's huge GUIs and capable of all the fun stuff. That's why I made simpledisplay.d and terminal.d, an attempt to get that kind of thing easy again on new operating systems. There's libraries like SDL that are fairly simple and quite useful too but that is much bigger.
 Eventually I think such simple simpledisplay.d and color.d 
 modules should go in Phobos
That's something I'm not really interested in though, because....
 after some cleaning, ddoc string, a heavy cycle of review and 
 improvements, API design, etc.
that is starting to sound like work! I hack together most these modules over weekends, and even if I can spill onto weekdays it is still just getting it to barely work for me then time to move on.
 Regarding color, I think it will enjoy few more color-related 
 functions, like a function to generate a rainbow given the 
 temperature of a black body, few more greying functions, a bit 
 more colorimetry, etc.
Yeah, those would be cool. I think I have blackbody code somewhere, I wrote it for one of my games. My lazypng.d module also has a greyscale thing - the plan there was to do png files to and from ranges, and add various algorithm like things to operate on them. The png reader in there is actually more complete than the one in my png.d, but png.d includes nice helper functions for palette swaps, creating Windows icons, etc. that lazypng lacks. anyway I'm getting sidetracked, sometimes I wish I could get enough money to pay my bills just for hacking on random D stuff - maybe then I could kill this todo list!
 A third small module (less than 15-30 KB of code) worth adding 
 to Phobos, that builds on graphicdisplay.d and color.d, could 
 generate basic data plots (scatter plots and line plots).
What might be better is to do it on top of something like a simple image class, which can then be drawn to the screen or saved to a file. A downside though is a lot of graphics functions would have to be written, but I think I want to do that anyway eventually. I wouldn't do a great job, like most my modules I'd just hack it together over a weekend, but it'd be a start. I already have an image.d that can be saved to a file.
Jun 09 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/9/13, Adam D. Ruppe <destructionator gmail.com> wrote:
 on Windows, bitmaps are stored upside down so you'd have to draw
 y-inverted too.
I have some vague memory about a trick where using a negative height would flip the bitmap automatically. (something like that .. maybe wrong, worth trying though?)
Jun 09 2013