Hello, On Thu, 11 Dec 2014 02:11:58 +0900 "Naruaki.Etomi" <[email protected]> wrote:
> I'm glad to receive a reply from you. > I appreciate your help. Sorry it took so long. > >The bitblt problem might be an endianness side effect, I remember lots > >of trouble getting it to work right in 8bit mode ( with copying pixels > >in 32bit quantities for speed ) > > It seems to be work fine on TVP4020 chip card. > (The reason I do not know...) > -------------------------------- > #if BYTE_ORDER == LITTLE_ENDIAN > adjust = 1; > #else > adjust = ((xd & 3) - (xs & 3)); > #endif Did you try this with a font that's not a multiple of 4 wide? Or an anti-aliased font? Unaligned blits won't occur otherwise, and I doubt the adjustment will always be 1 on little endian hardware. I suggest using something like this in order to trigger it: options FONT_DROID_SANS_MONO9x18 and no other font option. Or any other font with an odd width. With this you can trigger unaligned blits whenever characters are shifted sideways. Also, with an anti-aliased font characters will be cached in video memory, the cache will start at x=0, not necessarily aligned with the x adjustment due to centering the text output. > If you need, I will send Raptor GFX(TVP4020) card. What I have identifies itself as 'TechSource Raptor GFXP', node name is TSI,gfxp. If you have a spare PM2 with Sun or Apple compatible firmware that would certainly be helpful, I had no idea there are different versions of the Raptor with different graphics controllers. > Please contact me if you need anything. > I'll be happy to help you. Please test what I described above, I doubt that adjust = 1 is always correct, although it might be off by one from the big endian case. If you have a PM2V in a little-endian machine please try that as well, most hardware I have here is big endian and the only Permedia I have is a PM2V with Sun firmware. have fun Michael
