On Sun, 9 Oct 2011, Chris Young wrote: > 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!)
Oops! At least it was something simple. > 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? Judging by the original code, it looks like all that's needed is to endian swap the source data. Some care will be needed with situations where the expand table or memcpy are used, but I think I can get the code to work. Stay tuned! Cheers, - Jeffrey ------------------------------------------------------------------------------ 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
