On Sun, 4 Sep 2011 20:23:38 +0100 (GMT Daylight Time), Jeffrey Lee wrote: > * Amiga & GP2X display code has been modified to use the palettised > driver. So with any luck both those platforms will work with only minimal > fixes. However I haven't tried to add any endian swapping code, so you > might need to sort that out yourself, Chris. The routines which do the > data copying are in arch/displaydev.c, so that's probably the first place > to start. I have a feeling it might be easiest to write seperate versions > for big-endian hosts.
I've finally got round to having a proper look at the Amiga display code. The problem was that the palette wasn't being set, due to SetRGB32() taking a 32-bit left-aligned value for each colour component (I don't understand either; some sort of over-optimistic planning of how many colours would be needed in the future!) Patch attached. However, the endianness is wrong for the display as expected. I don't know how to change this, as displaydev.c calls BitCopy(), BitCopyExpand() and even memcpy() to move the data into the display buffer (and I imagine messing with those is going to upset other things). Ideally the display needs to be big endian (or endian-neutral) all the way through. Any ideas? Chris ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
