Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
[deleted comment]
[deleted comment]
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
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
[deleted comment]
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
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
Original comment by pulkoma...@gmail.com
on 10 Apr 2011 at 8:43
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
Arbitering issues that make it to v2.4
Original comment by yrizoud
on 8 Mar 2012 at 7:18
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
Original comment by pulkoma...@gmail.com
on 6 Oct 2012 at 6:57
Original issue reported on code.google.com by
yrizoud
on 10 Aug 2009 at 10:00