fcbpaint - graphics editor with drawable inline color splits

[tlr]

Great! For the moment, I would craft a dedicated test image, that is supposed to contain various combinations of splits, which I think should work.

That would be very useful. If I'm to update the compiler, I'm contemplating implementing a unit test for the compiler running on the dev machine. Making it work without a regression test suite seems too tedious and risky.

[Mike]

O.K. then ... here's the first test image (download):

The first test rows show splits 3 chars apart. All positions and all combinations [bck,brd|aux] -> [bck,brd|aux] are tested. The splits are positioned between two 'brackets' in black character colour, and go red to yellow, and back, etc.

Second set of test rows, same arrangement, with splits 3.5 chars apart.

Then, a position test, only single splits, first with background colour; below that, with auxiliary colour. All possible positions in a line are tested.

Finally, several tests with just the auxiliary colour:

=> I could trigger the issue exactly, when the first split of the auxiliary colour is to black - then it is ignored.

This happens regardless, whether it is preceded by no split at all, or when $900F has been split earlier in the line.

Will follow up with a more stringent scheduling test for 2.5 and 2 char splits.

Greetings,

Michael

[tlr]

O.K. then ... here's the first test image:

Very good! I will be away for a week so I won't have time to look at it in the near time.

[tlr]

Teaser...

Code: Select all

tlr@pinecone:tests$ ./tsuite ../examples/exin-doozy-tweaked.fcb ../examples/tf4.fcb ../examples/bug_mike/pokemon.04.fcb ../examples/bug_mike/test.03.fcb 
--- ../examples/exin-doozy-tweaked.fcb (exin-doozy-tweaked) ---
viewer: no compiler errors.
viewer: $1000-$4276 (12918 bytes, 51 blocks) in 855213 cycles (0.77 s)
viewer: 4 mismatched pixels in 2 cycles against model!
exporter: no compiler errors.
exporter: $1201-$4276 (12405 bytes, 49 blocks) in 865714 cycles (0.78 s)
exporter: 4 mismatched pixels in 2 cycles against model!
viewer vs exporter 100% match.
* failed! *
--- ../examples/tf4.fcb (tf4) ---
viewer: no compiler errors.
viewer: $1000-$30FA (8442 bytes, 34 blocks) in 405811 cycles (0.37 s)
viewer: 100% match against model.
exporter: no compiler errors.
exporter: $1201-$30FA (7929 bytes, 32 blocks) in 416312 cycles (0.38 s)
exporter: 100% match against model.
viewer vs exporter 100% match.
passed, ok.
--- ../examples/bug_mike/pokemon.04.fcb (pokemon.04) ---
viewer: no compiler errors.
viewer: $1000-$37BA (10170 bytes, 41 blocks) in 566351 cycles (0.51 s)
viewer: 666 mismatched pixels in 177 cycles against model!
exporter: no compiler errors.
exporter: $1201-$37BA (9657 bytes, 39 blocks) in 576852 cycles (0.52 s)
exporter: 666 mismatched pixels in 177 cycles against model!
viewer vs exporter 100% match.
* failed! *
--- ../examples/bug_mike/test.03.fcb (test.03) ---
viewer: no compiler errors.
viewer: $1000-$3BAC (11180 bytes, 45 blocks) in 716458 cycles (0.65 s)
viewer: 216 mismatched pixels in 44 cycles against model!
exporter: no compiler errors.
exporter: $1201-$3BAC (10667 bytes, 43 blocks) in 726959 cycles (0.66 s)
exporter: 216 mismatched pixels in 44 cycles against model!
viewer vs exporter 100% match.
* failed! *
--------------------------------------------------------------------------
viewer: no compiler errors.
viewer: total (42710 bytes, 171 blocks) in 2543833 cycles (2.30 s)
viewer: avg 635958 cycles (0.57 s) in 4 files.
viewer: 886 mismatched pixels in 223 cycles in 3 files!
all files match viewer vs exporter.
3 (of 4) files failed!
--------------------------------------------------------------------------
tlr@pinecone:tests$

...so now there is a mostly working testbench. Still need to integrate the reference compiler before doing any real work. More test cases appreciated.

[tlr]

Teaser 2...

Code: Select all

tlr@pinecone:tests$ ./tsuite ../examples/exin-doozy-tweaked.fcb ../examples/tf4.fcb ../examples/bug_mike/pokemon.04.fcb ../examples/bug_mike/test.03.fcb 
--- ../examples/exin-doozy-tweaked.fcb (exin-doozy-tweaked) ---
viewer: no compiler errors.
viewer: $1000-$4252 (12882 bytes, 51 blocks) in 852535 cycles (0.77 s)
viewer: 4 mismatched pixels in 2 cycles against model!
exporter: no compiler errors.
exporter: $1201-$4252 (12369 bytes, 49 blocks) in 863036 cycles (0.78 s)
exporter: 4 mismatched pixels in 2 cycles against model!
viewer vs exporter 100% match.
* failed! *
--- ../examples/tf4.fcb (tf4) ---
viewer: no compiler errors.
viewer: $1000-$30FA (8442 bytes, 34 blocks) in 405811 cycles (0.37 s)
viewer: 100% match against model.
exporter: no compiler errors.
exporter: $1201-$30FA (7929 bytes, 32 blocks) in 416312 cycles (0.38 s)
exporter: 100% match against model.
viewer vs exporter 100% match.
passed, ok.
--- ../examples/bug_mike/pokemon.04.fcb (pokemon.04) ---
viewer: no compiler errors.
viewer: $1000-$3ABA (10938 bytes, 44 blocks) in 674459 cycles (0.61 s)
viewer: 100% match against model.
exporter: no compiler errors.
exporter: $1201-$3ABA (10425 bytes, 42 blocks) in 684960 cycles (0.62 s)
exporter: 100% match against model.
viewer vs exporter 100% match.
passed, ok.
--- ../examples/bug_mike/test.03.fcb (test.03) ---
viewer: no compiler errors.
viewer: $1000-$3C78 (11384 bytes, 45 blocks) in 733623 cycles (0.66 s)
viewer: 100% match against model.
exporter: no compiler errors.
exporter: $1201-$3C78 (10871 bytes, 43 blocks) in 744124 cycles (0.67 s)
exporter: 100% match against model.
viewer vs exporter 100% match.
passed, ok.
--------------------------------------------------------------------------
viewer: no compiler errors.
viewer: total (43646 bytes, 174 blocks) in 2666428 cycles (2.41 s)
viewer: avg 666607 cycles (0.60 s) in 4 files.
viewer: 4 mismatched pixels in 2 cycles in 1 file!
all files match viewer vs exporter.
1 (of 4) file failed!
--------------------------------------------------------------------------
tlr@pinecone:tests$ 

[tlr]

Name: fcbpaint-0.9
Author: tlr
Release Date: 2019-01-29
Requirements: VIC-20 (PAL) with 32Kb expansion.
Download: fcbpaint-0.9.zip

Description:
This is an editor for a special software defined graphics mode with 168*192 pixels with 8x4 char color and inline color splits.

News:
fcbpaint V0.9, 2019-01-29
- rewrote the editor display layer to save space.
- black pixels are now shown as inverted with blue outline in the editor. (toggle with 'O')
- show bytes left for compiler instead of end andress.
- coordinates are now shown correctly rounded in quick fill mode.
- fixed bug where loading a file that is not a picture might crash fcbpaint.
- fixed bug where display of render errors would "stick" in the border area.
- fixed bug where size of rendered data and render errors wasn't cleared after initializing or loading new picture.
- fixed nasty compiler bug where the first change on a line would sometimes be mysteriously optimized away. (reported by Mike)
- rearranged memory layout to allow for future improvements.
- added example pictures by Tokra.

fcbpaint V0.8 beta, 2016-02-22 (not publicly released)
- show information on the distance and nature of the closest splits on the top row.
- splits can be pushed/pulled on the left and right side using Y/<shift-Y> and U/<shift-U> respectively.
- got rid of a few nasty viewer crashes related to too short splits in the picture (e.g only 1 half char)
- show compiler end address in editor.
- show number of lines with compiler errors in editor.
- show marking for lines with render errors.
- corrected exporting bug where a few char blocks in the middle of the picture would get corrupted. (reported by tokra)
- verifies that the correct memory config and machine is used (PAL & 32Kb)

Screenshots:

[tokra]

Great! The blue line around the black pixels will be very helpful in the future, espcially if you don't know if you have pixeled two hi-res pixels or one multicolor-pixel in black.

S : toggle show splits *
F : toggle show flanges *

It seems these two options don't work (yet?)

[tlr]

Great! The blue line around the black pixels will be very helpful in the future, espcially if you don't know if you have pixeled two hi-res pixels or one multicolor-pixel in black.

S : toggle show splits *
F : toggle show flanges *

It seems these two options don't work (yet?)

Correct, it's a placeholder. I should have mentioned in the docs that an asterisk means not yet implemented.

[Mike]

fcbpaint V0.9, 2019-01-29
- rewrote the editor display layer to save space.

That possibly broke something, because (even though the picture displays fine in the viewer), the editor shows the top-left corner of my Pokémon picture like this:



That portion of the picture actually is in hires, but the editor displays it in multi-colour, for whatever reason.


(... also, pressing 0 to change the border colour in the editor (still) messes up the memory/split display at the top, but as this can be recovered with SPACE to toggle between preview and editor, I'd consider this a minor issue for the moment ...)

[tlr]

fcbpaint V0.9, 2019-01-29
- rewrote the editor display layer to save space.

That possibly broke something, because (even though the picture displays fine in the viewer), the editor shows the top-left corner of my Pokémon picture like this:

I’m out travelling at the moment but you might want to check if the color mem in the picture file has the high nybbles zeroed. They are supposed to be and I have a vague recollection of using a cmp #8 to check for mc mode.

(... also, pressing 0 to change the border colour in the editor (still) messes up the memory/split display at the top, but as this can be recovered with SPACE to toggle between preview and editor, I'd consider this a minor issue for the moment ...)

I noticed this too and it is fixed in the current code base.

[Mike]

[...] you might want to check if the color mem in the picture file has the high nybbles zeroed. They are supposed to be and I have a vague recollection of using a cmp #8 to check for mc mode.

This requirement is something that changed just with the latest revision of fcbpaint.

I checked against MG2FCB: when I wrote the converter in 2010 (shortly after the 0.5 release of fcbpaint), for some obscure reasons I coded it to duplicate the lower 4 bits of the colour RAM data into the upper four bits. Possibly because I thought you'd use some compression strategy here (as I do with the MG format which indeed packs two colour RAM nibbles into one byte) - and going from (4/8)x16 pixel attribute cells to (4/8)x4 cells would anyhow need to write the same colour data four times.

The first try didn't quite work, and from some more analysis I went and also duplicated the colour RAM data block, then everything worked, the duplicated nibbles didn't do any harm, and I forgot about these. This is what happens, when file formats aren't fully documented as was the case when 0.5 came out.

An updated version of MG2FCB is in the works, and that will also sort out the top/bottom border colour definition, which, when converted from MG, now always comes out as black.

Doesn't solve the issue though, that there might be quite some more converts done with the original MG2FCB converter around in the wild, and you might consider reverting/loosening that requirement of the zeroed high nibbles. I'm mentioning the Principle of Least Surprise just in passing.

[Mike]

An updated version of MG2FCB is in the works, [...]

... and done:

Code: Select all

10 REM ** MG2FCB V2
11 :
12 INPUT"MG FILE";S$:INPUT"FCB FILE";T$:DN=PEEK(186):@LOAD(S$),DN:B=PEEK(36879)
13 OPEN2,DN,1,T$:PRINT#2,CHR$(0)CHR$(81)CHR$(70)CHR$(67)CHR$(66)CHR$(0);
14 PRINT#2,CHR$(BAND7)CHR$(BAND7);:FORT=1TO250:PRINT#2,CHR$(0);:NEXT
15 FORY=0TO11:GOSUB21:NEXT:FORT=1TO32:PRINT#2,CHR$(0);:NEXT
16 FORY=12TO23:GOSUB21:NEXT:FORT=1TO32:PRINT#2,CHR$(0);:NEXT
17 GOSUB25:GOSUB25
18 A=PEEK(36878)AND240:FORY=1TO192:PRINT#2,CHR$(A)CHR$(B);
19 FORT=1TO30:PRINT#2,CHR$(0);:NEXT:NEXT:CLOSE2:@RETURN:END
20 :
21 FORX=0TO19:AD=4352+192*X+8*Y
22 FORT=0TO7:PRINT#2,CHR$(PEEK(AD+T));:NEXT
23 NEXT:FORT=0TO7:PRINT#2,CHR$(85);:NEXT:RETURN
24 :
25 FORY=0TO23:AD=37888+20*INT(Y/2)
26 FORX=0TO19:PRINT#2,CHR$(PEEK(AD+X)AND15);:NEXT:PRINT#2,CHR$(8);:NEXT
27 FORT=1TO8:PRINT#2,CHR$(0);:NEXT:RETURN
28 :
29 REM ** MG2FCB V2 WRITTEN 2019-03-02 BY MICHAEL KIRCHER

(download)

I've also updated the post with the original release, so hopefully no one continues to use the original version of MG2FCB.

The above download link contains the Smurf picture I first tested the converter with. And here is the redone Pokémon picture that now displays fine in both editor and viewer of fcbpaint 0.9.

[tlr]

[...] you might want to check if the color mem in the picture file has the high nybbles zeroed. They are supposed to be and I have a vague recollection of using a cmp #8 to check for mc mode.

This requirement is something that changed just with the latest revision of fcbpaint.

Yes and no. fcbpaint will never produce a file that has anything else than 0 in the high nybbles, or at least it isn't supposed to. There is a note about unused bytes supposed to be set to zero in INTERNALS.txt which I guess isn't really clear with regards to the color mem. I've added a specific note for the next release.

I checked against MG2FCB: when I wrote the converter in 2010 (shortly after the 0.5 release of fcbpaint), for some obscure reasons I coded it to duplicate the lower 4 bits of the colour RAM data into the upper four bits. Possibly because I thought you'd use some compression strategy here (as I do with the MG format which indeed packs two colour RAM nibbles into one byte) - and going from (4/8)x16 pixel attribute cells to (4/8)x4 cells would anyhow need to write the same colour data four times.

I have considered packing the nybbles but haven't done so for now. This is purely for editor rendering speed reasons. That's also why I don't mask the nybbles everywhere. I might be able to retain the speed using some caching scheme but I don't want to waste too much code space. There are other optimizations that could be done that would gain more space, e.g dynamic size of the changes for each line.

An updated version of MG2FCB is in the works, and that will also sort out the top/bottom border colour definition, which, when converted from MG, now always comes out as black.

Doesn't solve the issue though, that there might be quite some more converts done with the original MG2FCB converter around in the wild, and you might consider reverting/loosening that requirement of the zeroed high nibbles. I'm mentioning the Principle of Least Surprise just in passing.

Nice! I've added a nybble clear on load for now which should solve the issue.