Tuesday January 17, 2006 Seapegasus Blog
Tuesday January 17, 2006 Remind me to never convert C to Cocoa ever again
I meant the first longer post in the Mac section to be different, but here goes: Aaarrggghh!
Once in my life I go out of my way to learn and implement a real algorithm from scratch -- and then the book's incomplete. I'll tell you another time what kind of demo I'm trying to write (a game), but now it suffices to say I am using Cocoa and it required a very basic scanline algorithm.
Well, I just copied an old version of scanline from the afore-mentioned "Programming 3D games in Macintosh C" book, and changed a couple of lines to make it run in Cocoa. No big deal, it all scales very well to Objective C. The book's author even cleverly relies on a variable xUnit when stepping through the image buffer when coloring pixels. Dispite this clever move, his implementation still only works with 8bit graphics. :-(
In short -- 8-bit-color means the buffer uses 8 bit = 1 byte to store the color information of 1 pixel, boiling down to 2^8=256 individual colors per pixel. Alternatively, you could also use 24-bit-RGB-color, spoiling you with 16777216 different colors. (Using multiples of 8bit is preferable, since bytes usually can be more quickly accessed.) But in the 24-bit case, you have to make sure to make 3-byte steps in the buffer, otherwise everything you draw will slim down to one third its width and suddenly has a very very ugly coloring scheme... Trust me, I saw it.
Basicly, what happened was, that I relied on the authors's claim to be using xUnit consistently throughout his implementation. He, however, designed it with 8-bit in mind, where xUnit always equals 1. So when I tried to adapt the implementation to 24-bit by (roughly) simply setting xUnit=3, my pretty "6-color rotating cube demo" suddenly looked like a happily dancing multi-color architect's dream drawn by a two-year-old in the dark with mittens on. :-C
I spent half the month (well, the Sundays only...) systematically hunting down silly individual pixels in search for an explanation; only to discover that the original 8-bit implementation
a) in one case suddenly used ++ incrementors instead of +xUnit, and
b) in a second case didn't multiply by xUnit, (because xUnit=1 in his case)...
c) And then I noticed, that he had been using bytes per row instead of pixels per row all along...
Grrrmph. Well, it's obvious now, in 8-bit-mode, bytes and pixels per row are the same thing (1). But in 24bit, there are three times as many bytes as pixel, resulting in interesting patterns if mixed up. *SIGH*
Anyway, at least I can claim now in my CV that I'm a specialist in diagnosing typos in scanline-polygonfill by magically looking at crazy lines in an NSWindow... :-)
Posted by seapegasus ( Jan 17 2006, 11:41:58 PM CET ) PermalinkComments:
Post a Comment:
Comments are closed for this entry.
