Helper for drawing C64 or ZX spectrum images

[GoogleCodeExporter]

Proposition of a tool to help draw retro pictures. I'm waiting for approval
or comments by people who DO draw such pictures.

I won't cover exporting issues here, only drawing. If you need special
format writing, open a specific issue, and we'll need exact specifications
or source code :)

First, issue 171 (Grid) is required to see what you're doing in each 8x8 or
4x8 block. 

A small screen allows you to choose between different checkers: C64 Hires,
C64 Mcol (you also choose a BG color number), ZX Spectrum.

In my opinion it's much simpler and really sufficient to assume that the
color numbers in Grafx2 match the color numbers in the target computers, ie
0=Black for example. You're free to choose the exact RGB values that you
prefer, more or less saturated, or "monochrome screen", etc.

I imagine 2 possible methods to help draw within the color restrictions of
each block of pixels:

1 : Checker - A keyboard shortcut checks all the visible image (zoomed and
unzoomed) and briefly flashes all the blocks that don't follow the
restrictions. The flash can be a "XOR 16" for example, so the change is
visible whatever the color. I like this idea as it lets you draw as you
want, in any order, and it's not "destructive".

2 : Enforcer - Like I saw in 0xPaint: When the Enforcer mode is enabled
(like a picture FX), any plotting of pixel will ensure the target block
stays within restrictions, by replacing colors in the whole block if
necessary. For example, if a block already has color 1 2 3 4 and it's
limited to 4 colors, plotting one pixel of color 5 over an existing color2
pixel will replace all color2 pixels of this block by color5 - so the
colors are then 1 5 3 4, so it keeps 4 colors total. (note: This system is
much harder for us to implement, because drawing one pixel somewhere is
never supposed to modify other parts of the picture, especially parts that
may be outside the visible screen. 

It's also possible to implement both, so the user can use both methods as
he prefers...

Ptoing's page on C64 restrictions: http://www.ptoing.net/html/c64info.htm

Original issue reported on code.google.com by yrizoud on 10 Aug 2009 at 10:00

[GoogleCodeExporter]

Since I occasionally do C64 graphics myself, I'm all for adding features like 
this
one. The problem is that as soon as you go past the standard bitmap modes, the
restrictions get weird really fast. E.g. FLI has one background color per 
rasterline,
two colors per each 4x1 cell (with wide pixels), and one color per 4x8 cell 
(again
with wide pixels). Throw in a sprite overlay, and you get another grid with 
24x21
tiles as well...

As I've had to do a few custom converters, I developed a python class for 
layers of
tiled images with palette restrictions. FLI as above would be three layers:

  1. 40x25  4x8 cells, aspect ratio 2:1,   single color per cell
  2. 40x200 4x1 cells, aspect ratio 2:1,   two colors per cell
  3.  1x200 1x1 cells, aspect ratio 320:1, single color per cell

If Grafx2 is adding layers (and it looks like it might be), it might be worth
considering adding configurable tiles, aspect ratio, and color restrictions per 
layer.

Giving something as complex as this a good user interface would be a challenge
though... :)

Anyway, just my two cents. Even just adding a simple inspector showing colors 
per
tile would be useful, as yrizoud describes above.

Original comment by MagerV...@gmail.com on 10 Aug 2009 at 5:40

[GoogleCodeExporter]

Let's start with basic modes...
On AmstradPlus you can also get 15-color sprites with hardware zoom independant 
of 
the screen resolution, so you can have a monochrome 640x200 picture and add 
15-color 
sprites that use a 160x200 resolution on the same area. This could be done as 
blocks 
allowing only 1 color.
But you can also add rasters (palette changes at each line) and then you end up 
with 
a maximum of 4096 colors on screen. We can't render that.

The rasters constraints are quite interesting too : you can position them 
anywhere 
on 8-pixel limits, change any color, but if you change one color, you can 
change it 
again only after 32 pixels, and if you want to change the color for another 
palette 
index, you need to add 32 more pixels. So the blocks end up being of variable 
length. Quite messy I guess...

Note that there aren't any tools on CPC that allow doing such things in 
realtime. 
Graphists are used to draw in 4 colors and add the rasters at a later stage.

So, let's start with the basic simple block constraints and add the other 
things 
later.

Original comment by pulkoma...@gmail.com on 10 Aug 2009 at 5:52

[GoogleCodeExporter]

I just started with load/save for raw c64 pictures, and that one will give you 
the
constraint checker for free. At least for hires and multicolor to start with.

Someone just has to make the stuff that highlights the violating blocks.

And I need some input on what different restrictions there is. Easiest to think 
of
was a bitmap of 1000 bits, buts that's only enough for the hardware modes. Ok, 
I read
the above texts, but that didn't tell how to represent the internal violation 
bitmap.

And this is a little "hey, some work is going on"

Original comment by mumu21...@gmail.com on 2 Sep 2009 at 6:32

[GoogleCodeExporter]

I think you are free to do it as you want, and make something that checks only 
for 
what you need. There is no need to store the errors, just check and highlight 
on 
screen.

It seems a good idea to have a Highlight_block(x,y,w,h) that highlight a block 
of 
the picture on the screen (and on the screen only). The highlight would be a 
simple 
XOR 16. Could probably be done as a loop calling horizontal_xor_line. So you 
loop on 
the picture (pixel by pixel, block by bloc, or whatever) check each block, and 
call 
the Highlight function whenever you find a bad one. As the highlight is done on 
screen only, the user see it, but then discard it by pressing a key and start 
fixing 
one of the blocks.

You only need to check the visible part of the picture, but you may need to go 
a bit 
outside of it to check for full blocks, full lines, and so on. The whole 
original 
picture is available in memory, so no worries about that.

Original comment by pulkoma...@gmail.com on 2 Sep 2009 at 8:06

[GoogleCodeExporter]

Yep, the way I saw it, each block is tested independantly from others. I can 
write
the generic block scanner (it's very similar to what I did to draw the grid) 
which
will call individual block checks and make them "flash" on the screen when they 
don't
comply to the restrictions.
Flash was my initial idea, but maybe a bit too epileptic... Maybe the highlight
should last until you release the key, instead.

Original comment by yrizoud on 2 Sep 2009 at 8:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I just want you to know that I've started working on this one.

Original comment by mumu21...@gmail.com on 16 Sep 2009 at 1:56

[GoogleCodeExporter]

I added you to the contributors so you can set you as owner of issues. Commit 
access 
to the svn can be done if you want it.

Original comment by pulkoma...@gmail.com on 16 Sep 2009 at 7:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

besides c64 and zx-spectrum, please don't forget msx1 as well (8x1 colour cells)

Original comment by nitrofur...@gmail.com on 27 Jan 2010 at 1:21

[GoogleCodeExporter]

Excellent idea. spectrum and pc-engine are the retro platforms I'd like to be 
supported 
:D

Original comment by jouni.no...@gmail.com on 6 Feb 2010 at 10:43

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 10 Apr 2011 at 8:43

• Added labels: Milestone-2.4

[GoogleCodeExporter]

We now have Amstrad CPC "Mode 5" constraints working well (with a layer-based 
system), as well as a checker for C64 FLI (also layer-based).

Needs some GUI integration...

Original comment by pulkoma...@gmail.com on 24 Sep 2011 at 2:23

• Changed state: Started

[GoogleCodeExporter]

Arbitering issues that make it to v2.4

Original comment by yrizoud on 8 Mar 2012 at 7:18

• Added labels: Milestone-2.5

[GoogleCodeExporter]

Just an idea. The highlighting could be done on the grid instead. That way you 
can keep working without distractions. You would have the grid set to visible 
anyway, if you are working with block-restrictions.
I've been using Dawnbringer's Multicolor checker so far, and the only real 
drawback is that you have to pause your work to check for errors, instead of it 
checking while you work.

Original comment by ilija.melentijevic on 23 Jul 2012 at 3:04

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 6 Oct 2012 at 6:57

• Added labels: Milestone-NotPlanned
• Removed labels: Milestone-2.5