Mappy

Paradroid level maps, tiles, tile graphics etc are all ripped out and put in my code so now I can chose which level to display. I've got to do a multi-way remap of the tiles to get Ste's multicolour versions remapped to the same ones as the hires ones as he just redrew the tiles from a bitmap with all the tiles on so nothing actually matches up to the C64 charset. More PC app code there methinks but still all useful stuff as I can see this case coming up again in other games/graphics conversions.

Getting in the basics of the visual stuff for Paradroid should be fairly easy once the chars are remapped. The levels are done, I can do the console stuff (Robot display, level map etc) and the lift side on ship view. Even the sub/transfer game stuff is easy to drop in.

I really should do this mid-scanline image conversion as well at some point..


Pete

Bits and Bobs

As I've got sidetracked with Paradroid instead of just writing the probably small amount of code it would be to handle this mid scanline image stuff I'm having to add some more functionality needed for the app for it's main purpose, game creation/graphics manipulation rather than bitmap/image conversions.

I've re-worked my octree code to work in a simpler method to just count colours in an image and even using the slow VB.NET getpixel function it's still surprisingly fast, which is good. The idea is for most game graphics manipulation you'll want to be in some kind of indexed mode but there shouldn't be anything to stop people loading PNG or other non-indexed formats. Then before the code kicks in doing it's thing (remapping tiles, shrinking charsets, whatever) it needs to check the file format for indexed and if it isn't, be able to create some data from it that is, so knowing if there are too many colours (256) will let it know if some colour reduction is needed. For a fixed system (A8, C64, etc) that's not a massive problem because they'll be a fixed palette anyway and just running the image through the remapper will sort it out, other stuff will need to be allowed it's own palette.

Next up is the bitpattern selection box (sounds like chocolates). This will display a palette swatch, a dropdown (or other display) for available bit patterns (eg hires = 0 or 1, multicolour 2bpp = 00,01,10,11) and then let you select which colours on the loaded image match those machine internal bit patterns displaying the bitpattern over the colour as you click and probably doing a remap of the image to show what's happening. Probably also a good idea to have a colour picker to select the base colours for each bitpattern from the image.

Lots to do still but all this stuff goes well towards getting the app ready for Exploding Fist and some other projects I want to work on.


Pete

Paranoid Android

While I'm fiddling with the image stuff (and the long road to getting the app in a state where it's usable for it's original purpose) I decided to start messing around with doing an A8 version of Paradroid :)

Ste (STE'86 aka Steve Day) has already converted the hires graphics to multicolour, something which involves lowering the horizontal res by 1/2 and it looks pretty good. The A8, not having a colour attribute system just can't display Paradroid in hires. It would need more and better sprites (PMGs) and you'd basically have to build the screen out of those. Impossible.

All I've done so far is some setup code, a Display List, a couple of interrupts and set the top part of the screen to hires (I CAN use the PMGs there to change the text colour) and the bottom part to a mutlicolour scrolling window. I'll dump out the charset and a level later and drop it in and add some joystick based scrolling control so you can move around a level :)


Pete

Split decision

I've knocked up some 6502 source for the A8 display app. It has a couple of blank lines just before the picture (as well as the usual ~30) the first of which kicks off the displaylist interrupt. That enters, does a WSYNC then a few dozen NOPs which allows timing the start of the cycle counted line routine to a position I want it to start.

To begin with I've turned off PMG DMA so there's an extra few cycles on the line (most at the start) so there's plenty of room to do the 4 changes before the start of the visible screen. Then there's the positions across the screen to cope with. The problem with that is there are quite a few options on where those colour changes can take place. I think a simplest fixed approach will do to begin with and I'll see where it goes from there.

Now to change the code to a partial line version. That'll split the line into the same positions the splits happen and I'll have to come up with a couple of methods to decide which colour to change.


Pete

At a loss

One of the hardest things to do when reducing a high colour image down to VERY few colours is actually picking those colours. My original line remap code just used a histogram of most popular colours, took the top 4 and remapped each line to a palette of those. That's great for some images (lower colour source) but for high colour images with a lot of detail in it tends to lose a lot.

I'm now investigating original and modified diversity algorithms. Pretty simple code and it seems to sometimes produce an image that with dithering would turn out really nice. Other times it's nowhere near as good as that original most popular method.

I suppose I can leave all methods in the code and allow multiple passes, outputting an image for each and let the user decide. I'd also imagine most of these routines will produce a lot better result once a) dithering and b) PMG/mid scanline colours are added.


Pete

Quantification

I was pondering adding some auto line based A8 conversion to my app using the already written colour remapping when I saw Quantizator over on AtariAge forum so I thought there was no point, then last night I got bored of working on what I was doing so thought I'd just drop it in anyway. Turned out to be pretty easy to get the basics going, an hour of coding (plus some time for a blatant bug that took me ages to catch) and I'd got a 4 colour per line remapper.

It's not amazing so far and doesn't quite produce results that are as good as quantizator. I'm presuming that uses a method to find top used colours that are different hues whereas mine is a simple "most used" formula atm. I've also got no dithering to help spread colour matching errors.

Here's an example with a fairly simple C64 image.

Original


Converted


I think I'll continue messing with it as it's taken less time than I thought and add better colour choosing, F-S dithering/error spreading, PMGs for extra colour, maybe and/or mid-scanline colour changing.


Pete

The Colour of Magic

After adding colour matching to the app based on code I've written many times over the past couple of decades, stuff I've found on the web etc and then tweaking it a bit and thinking I was done, I ended up spending more and more time on colour.

An argument on a certain forum over which machine had a better palette, the Atari 800 or the Atari ST got me geared up to add some more functionality to the app. Simple things like the fact that none of the high end image apps seem able to remap to a fixed palette of anything over 256 colours because that's the most sensible maximum size for a fixed palette, it having one byte per pixel. A 512 colour palette would need 2 bytes per pixel (without bit packing) which is 16 bits which means you may as well write some raw RGB values in that pixels data instead. All that meant there didn't seem to be a standard image app that would remap to the ST's palette (9bit 333RGB = 512 colours). Also despite what one member (and I use that term with more than one sense) thinks just masking off bits of a 24bpp image doesn't have the desired result.

After faffing with all of that and posting remapped images in all kinds of formats and palettes and APAC 256 colour Atari 800 versions I thought I was done with colour. Wrong again :) The matter of picking complementary colours whilst designing a game came up as just having a shade of colour a bit "off" can ruin the look of a perfectly well done image. Soooo I've now added some more colour conversion functions: RGB to XYZ, XYZ to CIE-L*ab, CIE-L*ab to CIE-L*CH, some others, and all the functions to convert back. CIE-L*CH seems to be the one to use for automatically finding complementary colours so now the functions are all there I'll be able to fiddle with some kind of gui colour picker thing in that colourspace..

No more colour now! Different code!! :)


Pete