Tool to convert a graphic into BDG's

[Bubu]

Jarl, torpedos!

Hi, all!

I'm programming some... thing, and I need to save in memory for the graphics, and I wonder if there's a tool that converts a graphic, e.g. in BMP format, or PNG, I don't mind, into the characters 128 to 143.



Thanx!

[Evil Genius]

Those characters are stored in ROM and not changeable. Of course you can create a redefined character set but that uses more memory so not what you want. Those 16 chars only use 128 bytes, there must be a better way to squeeze that out of your program.

[Bubu]

I meant, a tool for Window$ to transform a pic into a low resolution graphic by printnig only those 16 characters.

[zup]

You could explore other options:
- Copy the font into RAM (768 bytes), "strip" it from unneeded characters (i.e.: lower letters if you intend to use only caps) and put your graphics there.
- Define an entire "font" with your graphics and switch between character font and graphics font (768 bytes in RAM, plus some POKEs in your code).

[lfaria]

No tool to do that pops up on my mind, sorry.

But you'll end up with a 4x less resolution screen (64x48... "big" pixels), is it still useful for your... thing?
I know Heavy on the Magic used a 2x less resolution for some graphics and it still looks good (mainly because they're mixed with the normal resolution ones), but 4x is maybe pushing it...
Just my 5 cents...

[AndyC]

Really you'd want two things if memory is tight. Something to downgrade an image to a two colour, 64*48 bitmap - which probably any paint package could do (albeit possibly not well).

Then something to render that, either by printing characters or by just drawing directly to video memory (which might be easier).

Not much point storing them as character codes as it would be massively wasteful.

[8BitAG]

There's been some projects to try and make a similar sort of tool for Commodore PETSCII graphics...
http://www.c64os.com/post/petsciiartrenderer

Also...

[redballoon]

@Bubu What art package in windows do you use? Photoshop? Gimp? Aseprite?

[JMcGibbitts]

As others have said here - there's no tool.

The way I would go about this is:-
1 Load the image in ZX Paintbrush and save it out with .scr extension.
2 Use BasinC to load the image (load "" screen$).
3 Start a BASIC program in BasinC.
4 Write code to process the bitmapped screen memory 8 bytes (1 character block) at a time.
5 For each character block, do some math across the 8 bytes to select the most appropriate GRAPH character and color values.
6 Write that GRAPH chr$ value to a 768 byte area of memory, with the color (minding the possible inverse issues) to the same address offset +768, then repeat from step 5 until done.
7 Save the 1536 byte area of memory.
8 Start a new BASIC program in BasinC.
9 Load the 1536 byte file into RAM.
10 Go through the first 768 bytes, writing out each graphic to the display, then write the following 768 colors to 22528+ and check how the new picture looks.

I'm pretty sure this isn't especially common, probably because it doesn't look especially great. For some reason, I associate these kinds of graphics with Melbourne House, or BASIC type ins. I guess if you're thinking of submitting entries to the 'guess that screen' competition that's lurking somewhere around these forums then that's a nice use for it!

[bobs]

Coming at this from a ZX81 point-of-view, you might want to try ZXPaintyOne:

http://chunkypaint.zxdemo.org/zxpaintyone/

It’s an editor for ZX81 screens, but has the same predefined graphics as the Spectrum that you want to use, and copy/paste for the image as a stream of bytes. You’d need to map the values produced between the two systems, and remove the line feeds, but it’s a really simple & nice editor. From my experience it’s easier and you get better results from drawing at the final resolution, rather than trying to reduce a high-res image, as the reduction produces too rough results at such a low resolution.

[R-Tape]

There's also Mat Gubbin's Chunky Graphics Compressor. In your case this might work:

1 - open the photograph/image in ZX-Paintbrush, save it as a .tap
2 - load the Chunky Graphics Compressor, then load the screen.tap as instructed
3 - see how well it's converted it, and also compressed it too

[druellan]

You can also try with an ASCII art image tool, like this one https://github.com/TheZoraiz/ascii-image-converter that allows the use of custom mappings and ttf fonts, so in theory you can load a ZX font and map the conversor to use the symbols.

The result is going to be a string of chars, that I suppose it is what you want. I bet it's not going to be perfect, but perhaps a good base to manually tweak later.

I did a test with an online one (https://ascii-generator.site) using ASCII blocks and the result looks interesting already, so, if this is what you need might worth the time to play with the one above.

[Bubu]

Thanx all for answering, I can't use ASCII characters cause I need to scroll the graphics on the screen by 4 pixels, so the best (and only) solution is to use those BDG (Basic Defined Graphics) from 128 to 143 ASCII characters. Ah, and 2 colors every 8x8, obviously.

There's also Mat Gubbin's Chunky Graphics Compressor. In your case this might work:

1 - open the photograph/image in ZX-Paintbrush, save it as a .tap
2 - load the Chunky Graphics Compressor, then load the screen.tap as instructed
3 - see how well it's converted it, and also compressed it too

This seems to be the right way, I'm going to try it, thank you, R-Tape

[AndyC]

If you're going to scroll the screen, colour is going to be a big issue unless you're using a multicolour routine. Using ASCII characters isn't a problem though, "printing" characters at arbitrary vertical positions isn't particularly difficult.

But, in any case, avoiding using actual ROM characters and just drawing chunky pixels in m/code from a bitmap will be massively faster.

[g0blinish]

For a long time I was going to write a similar converter. Of course, it can be improved. bmp and png available
https://disk.yandex.ru/d/CVDLJtYRXv2pBw

[MatGubbins]

Thank you R-Tape for suggesting the Chunky Graphics Compressor.
The original routine is ideal for a static title page, but not fast enough for a scrolling game.

During July 2021 I re-wrote the entire decompressing routine to be a lot faster and a few bytes smaller, didn't use the ROM print routine, it also used just one decompressor for the compressed data/colour.
I have managed to find that bit of code and hacking around it at the moment!

Bubu, how are you writing your program, BASIC or asm/machine code?

[Joefish]

Just an aside, those graphics blocks aren't stored in ROM as part of the font. They're constructed by the PRINT routine on-demand from the bits in the ASCII code that represents them!

https://skoolkid.github.io/rom/asm/0B24.html#0B38

If you consider the squares in the order TOP-RIGHT=1, TOP-LEFT=2, BOTTOM-RIGHT=4, BOTTOM-LEFT=8, you'll see the ascending ASCII codes represent a binary count from 0 (empty) to 15 (all four squares filled).

[Sol_HSA]

As someone who ran a text mode demo competition for a decade..

If I understood correctly, you want to covert a random bitmap into... a low resolution bitmap, encoded as "graphics" characters. That bit is fairly trivial to do. Not a huge storage win (each 8x8 pixel char only represents 2x2 chunky pixels, or 4 bits of data), but I guess it might have its uses.

Additionally one could include color information, which in this context is also pretty easy to just brute force. With the color information included, the bitmap only needs 3 bits of information per 8x8 chunk, but adds another 7 bits of color data =) Anyway, I assume the use case is such that it makes more sense to store each 8x8 as two bytes (bitmap and color), and not try to compress things at bit level.

I can give it a go if you need it..

[Sol_HSA]

Okiedokie.

256x256 Test image:


Ran through my "ulaer" photoshop filter for reference...



Reduced to chunky stuff with color.. (cropped to 256x192)



..and without color..



So what remains is, what format do you want the output data as? Binary dump, ascii file with separated values, something else?

[Sol_HSA]

Am I on the right track, @Bubu ?

[Bubu]

Am I on the right track, @Bubu ?

Completely, @Sol_HSA, you're 100% in the way. That's just what I wanted. I have a given pic 256x192 (or less), then convert it to /4 resoution, but not whatever characters, but only the ones that comes with BASIC:

11110000
00001111

or

11111111
00001111

or

11111111
11110000

and so on

but not these ones:

10101010
11111111

01010101
00001111

etc

[Sol_HSA]

Completely, @Sol_HSA, you're 100% in the way. That's just what I wanted. I have a given pic 256x192 (or less), then convert it to /4 resoution, but not whatever characters, but only the ones that comes with BASIC:

Yeah, I use the symbols you listed. What format do you want the data out? Binary blob, ascii file, what order (glyph,color,glyph,color.. or glyphs first, then colors)

[Bubu]

errr... I'd love every one but perhaps... bynary, and gfx 1st, then colors...



Are you developing such a tool?

[Sol_HSA]

Are you developing such a tool?

Sure, I should have a few minutes next week..

[R-Tape]

Sure, I should have a few minutes next week..

If it's not too much trouble, I'd find it useful in both ASM and BASIC ready formats:

db 128,129,133,

DATA 128,129,133,etc

An option to have all CHR$ followed by ATTR, or CHR$ mixed with ATTR would be the cherry on the cake :–)