Article: 59317 of comp.sys.amiga.programmer Path: ifi.uio.no!nac.no!trane.uninett.no!sunic!news.kth.se!usenet From: d92-jfo@sandwich.nada.kth.se (Johan Forsberg) Newsgroups: comp.sys.amiga.programmer Subject: Re: 24bit chunky to Ham8 (longish) Date: 29 Nov 1994 16:15:00 GMT Lines: 66 Message-ID: <3bfk25$fl6@news.kth.se> References: <26641484@kone.fipnet.fi> NNTP-Posting-Host: magnum.nada.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit "Jyrki Saarinen" writes > >Is this possible realtime? Maybe palette recalculation >each frame, too? Hi Jyrki! Depends on how real a time you need... Terminology for the below: c1,c2,c3... chunky 24 bit pixels red(c),green(c),blue(c) gets the color values h1,h2,h3... HAM8 pixels, can have values 0,1,...,63, setr(n), setg(n), setb(n) where 0>2) h2 = setg(green(c2)>>2) h3 = setb(blue(c3)>>2) repeat until end of line. That is, set the correct r value every 3 pixels, the g every 3 and the b every 3. You loose a lot of contrast (since you're not using the base palette at all), but at least no 'streaks' of miscoloration. And VERY fast. For best result, buffer 32 pixels at a time through 8 registers (that is, reserve a0-a3, d0-d3 for instance, calculate value of first pixel, split that value into bit 0 of all the register, calculate 2nd value, split into bit 1, and so on. Finally write all 8 registers to the bitplanes. Inbuilt chunky conversion!) Slower, much better algo: Setup base palette as a color cube of 4x4x4 colors. Maximum error possible when using a base color for a 24-bit value is (63,63,63), or 109, so if we can do better than that by modifying, we do that. int close(c) { return (red(c)&192)>>2 + (green(c)&192)>>4 + (blue(c)&192)>>6; } /* The closest base color to a 24 bit color. Almost ;-) */ int sqrerror(c1,c2) { r=red(c1)-red(c2); g=green(c1)-green(c2); b=blue(c1)-blue(c2); return r*r+g*g+b*b; } h1 = close(c1) /* First pixel of line is set to closest base color */ A t = h2c(c1) Check which component (rgb) in t is most distant from c2, suppose red red(t)=red(c2) if sqrerror(t,c2)<11907 /* 63*63*3 */ h2=setr(red(c2)>>2 else h2=close(c2) repeat from A where h2c converts a 6 bit rgb value to a 24 bit. At least method 1 should be fast enough to be usable. It shouldn't be very much slower than an ordinary 8bit c2p! (using only processor) So, let's see some Doom-like demo in HAM8 :-) Johan Forsberg Article: 59352 of comp.sys.amiga.programmer Path: ifi.uio.no!nac.no!trane.uninett.no!sunic!news.tele.fi!news.csc.fi!news.eunet.fi!EU.net!sun4nl!hacktic!grafix.xs4all.nl!john.hendrikx Date: Tue, 29 Nov 94 18:55:22 GMT+1 Newsgroups: comp.sys.amiga.programmer Subject: 24bit chunky to Ham8 planar conver Distribution: world MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-GateSoftware: XEchoGate 1.3 From: john.hendrikx@grafix.xs4all.nl (John Hendrikx) Message-ID: Organization: Grafix Attack BBS Holland Lines: 36 In a message of 28 Nov 94 Mans Engman wrote to All: >> Is this possible realtime? Maybe palette recalculation each frame, too? ME> Some while ago, I did some experiments with ham8. Conversion can be ME> rather fast if you don't use the palette at all, just change the color ME> component which differs the most from the actual "hold" value. Actually, ME> it doesn't look too bad (just a little). My code achieved around 200k ME> pixels per second on my A1200 + 40 MHz 030. This can be considered ME> realtime for small buffers. However, the actual c2p was done with ME> old-fashioned add/addx method so with decent c2p you could probably do a ME> lot better. Perhaps rendering to scrambled chip buffer + blitting would ME> be the best, I don't know... Check out FastView on Aminet. Is has some pretty fast 24Bit->HAM6/8 conversion routines, but not realtime ofcourse (mostly because it needs to output reasonable good quality.) Anyway, it has got some of the fastest HAM conversion routines I've ever seen, and a reasonable C2P routine (partly from TextDemo :-)) ME> BTW Isn't it funny to see mp's humongous speed differences in ham6 / ME> ham8? ME> Smells like lazy coding ;-) No, for HAM6 it uses a huge table (if I read the doc correctly). For HAM8 this table would need to be a lot bigger (more combinations) and so I guess he didn't implement that at all, or you don't have enough memory :-)) Grtz John ----------------------------------------------------------------------- John.Hendrikx@grafix.xs4all.nl TextDemo/FastView/Etc... development ----------------------------------------------------------------------- -- Via Xenolink 1.90