Jerome Grimbert wrote: > } Unfortunately this way there's currently no high colour sprite format > } in QXL/QPC > I beg your pardon, but there is a high colour sprite format for QXL and QPC. > How could sprted run on them otherwise ?
Sprted doesn't even offer to edit high colour sprites on QXL/QPC. Only 256 colours. QXL has definitely no 16bit sprites, I think I have re-enabled them on QPC. Not completely sure. Anyway, yesterday evening I had a development spree and the 16bit driver now also accepts mode 64 (32bit true colour) sprites. Only two dozens (even machine independent) lines of code in the end but still I needed ages to get there. I however started getting more into the concept of GD2. Anyway, it's done. With this I was also able to further develop WMAN while still maintaining its platform independences as mode 64 patterns unify the mode 32 and 33 platforms. Now only the system palette is still on the "to do" list. By the way, I remember you having problems with the sprite cache, i.e. that it didn't notice the changes in the sprite edited by sprted. The same problem already exists in WMAN, if you try to define different colours for several scroll/pan bars this will fail as only the first version gets converted. What solution did you come up with? I'd like a clean way to flush the sprite cache but didn't find one so far. On a related note, is anybody up to redesign the standard sprites (namely arrow, lock, black window, keyboard input, no entry and probably window move and window resize sprites) in high colour? A picture of any format would be enough for me to convert it into code. Phoebus perhaps? :) Marcel
