On 2011-04-05 23:07:33 -0400, Adam D. Ruppe <[email protected]> said:
Note: I just updated my simpledisplay.d. My color constructor
said b = c when I meant this.b = c... hence everything was yellow!
You can download again from the same place.
I played with it yesterday and never found why the blue channel didn't work!
By the way it works well with X11 on Mac OS X (if I change the "version
(linux)" to "version (OSX)").
I also made a working OS X implementation (Cocoa).
Nick Sabalausky wrote:
I haven't benchmarked or even tested this, and heck, maybe I'm just
a dinosaur, but for better speed and flexibility I'd recommend
something more like what I've attached.
Yea, that does sound better. Though I have a few comments...
The width is statically-known, so the compiler can optimize the
index calculation from multiplication to shifts when appropriate.
One concern I have here is will it be an incompatible type with
dynamic widths? i.e. an image loaded from a file? (I'll be hopefully
cleaning up my png and bmp loaders in the near future to use with
this.)
I don't think having fixed-size image will be a useful optimization,
except perhaps if you manipulate a lot of tiny images of the same size.
Maybe it could use an interface to smooth that over.
I actually had a similar fight with myself over Indexed vs TrueColor
when writing the original thing. They really don't have compatible
interfaces. Sure, you could do some kind of putpixel(uint data)
for each of them, but it's not really the same.
So I think they should be separate types, with functions to convert
back and forth. (both conversions being lossy in their own way..
just because two palette entries have the same rgb values doesn't
mean the two colors are semantically the same.)
Don't forget that there's actually much more colorspaces than indexed
and RGB. There's RGBA (when you need semi-transparency), there's CYMB
(for print), there's grayscale. And in some cases HSV or XYZ could be
useful too. And for each of these someone might want different bit
depth. Can't we make things flexible enough for that by using a
template?
final class Bitmap(Color) : Image {
void opIndexAssign(int x, int y, Color color) {
pixels[y * width + x] = Color(color);
}
size_t width, height;
Color[] pixels;
}
This way, you can have a bitmap of RGBColor, or RGBAColor (with an
alpha mask), GrayColor, IndexedColor, or whatever color type you can
come with, and algorithms can be reused.
Wow, I'm off topic again. Anyway, for the event loop here, I'm
thinking something similar to how std.concurrency does it might
be a good approach: a bunch of delegates, matched to events by
their signature. Simple signatures could be accepted as well
as fancier ones.
// need to make a simple window separately here so it is persistent
auto win = new DrawableWindow(width, height);
// still use an image the same way. Alternatively, DrawableWindow
// could implement the same interface as Image, probably double
// buffering internally anyway, so pretty much same implementation.
auto image = new Image(width, height);
window.eventLoop(
50, // first parameter is the timeout. can be 0 to only react
// to events, but putting one in gives you an easy to use
// frame pulse for drawing
(int keyPressed) { // might be a struct KeyEvent rather than int
// react to the key
},
(int x, int y, int mouseButton) {
// react to a mouse click
},
() { // no params means your timeout happened, time to draw
// draw your frame...
image.display(win); // this overload uses the existing
// window and returns immediately
// rather than making and waiting
}
// might also offer a platform specific msg, wParam, lParam
// so you could in theory do all of Win32 based on this same
// framework
);
Overall, I really like this concept. I'd like it better if
image.display(win) was replaced with "window.image = image" however.
--
Michel Fortin
[email protected]
http://michelf.com/
