create program to create bitmap

[leopardpm]

testing printable ascii character set: looks like almost all of the character set is printable/copiable/pastable...
Sorry didn't take the time to re-format the whole thing, only the top label line and then the 1st line....

Code: Select all

Dec Hex chr  Dec Hex chr  Dec Hex chr  Dec Hex chr  Dec Hex chr  Dec Hex chr  Dec Hex chr
000-00:      032-20: sp   064-40: @    096-60: `    128-80: Ç    160-A0: á    192-C0: └    224-E0: α
001	01	☺ 	033	21	! 	065	41	A 	097	61	a 	129	81	ü 	161	A1	í 	193	C1	┴ 	225	E1	ß
002	02	☻ 	034	22	" 	066	42	B 	098	62	b 	130	82	é 	162	A2	ó 	194	C2	┬ 	226	E2	Γ
003	03	♥ 	035	23	# 	067	43	C 	099	63	c 	131	83	â 	163	A3	ú 	195	C3	├ 	227	E3	π
004	04	♦ 	036	24	$ 	068	44	D 	100	64	d 	132	84	ä 	164	A4	ñ 	196	C4	─ 	228	E4	Σ
005	05	♣ 	037	25	% 	069	45	E 	101	65	e 	133	85	à 	165	A5	Ñ 	197	C5	┼ 	229	E5	σ
006	06	♠ 	038	26	& 	070	46	F 	102	66	f 	134	86	å 	166	A6	ª 	198	C6	╞ 	230	E6	µ
007	07	• 	039	27	' 	071	47	G 	103	67	g 	135	87	ç 	167	A7	º 	199	C7	╟ 	231	E7	τ
008	08	◘ 	040	28	( 	072	48	H 	104	68	h 	136	88	ê 	168	A8	¿ 	200	C8	╚ 	232	E8	Φ
009	09	○ 	041	29	) 	073	49	I 	105	69	i 	137	89	ë 	169	A9	⌐ 	201	C9	╔ 	233	E9	Θ
010	0A	◙ 	042	2A	* 	074	4A	J 	106	6A	j 	138	8A	è 	170	AA	¬ 	202	CA	╩ 	234	EA	Ω
011	0B	♂ 	043	2B	+ 	075	4B	K 	107	6B	k 	139	8B	ï 	171	AB	½ 	203	CB	╦ 	235	EB	δ
012	0C	♀ 	044	2C	, 	076	4C	L 	108	6C	l 	140	8C	î 	172	AC	¼ 	204	CC	╠ 	236	EC	∞
013	0D	♪ 	045	2D	- 	077	4D	M 	109	6D	m 	141	8D	ì 	173	AD	¡ 	205	CD	═ 	237	ED	φ
014	0E	♫ 	046	2E	. 	078	4E	N 	110	6E	n 	142	8E	Ä 	174	AE	« 	206	CE	╬ 	238	EE	ε
015	0F	☼ 	047	2F	/ 	079	4F	O 	111	6F	o 	143	8F	Å 	175	AF	» 	207	CF	╧ 	239	EF	∩
016	10	► 	048	30	0 	080	50	P 	112	70	p 	144	90	É 	176	B0	░ 	208	D0	╨ 	240	F0	≡
017	11	◄ 	049	31	1 	081	51	Q 	113	71	q 	145	91	æ 	177	B1	▒ 	209	D1	╤ 	241	F1	±
018	12	↕ 	050	32	2 	082	52	R 	114	72	r 	146	92	Æ 	178	B2	▓ 	210	D2	╥ 	242	F2	≥
019	13	‼ 	051	33	3 	083	53	S 	115	73	s 	147	93	ô 	179	B3	│ 	211	D3	╙ 	243	F3	≤
020	14	¶ 	052	34	4 	084	54	T 	116	74	t 	148	94	ö 	180	B4	┤ 	212	D4	╘ 	244	F4	⌠
021	15	§ 	053	35	5 	085	55	U 	117	75	u 	149	95	ò 	181	B5	╡ 	213	D5	╒ 	245	F5	⌡
022	16	▬ 	054	36	6 	086	56	V 	118	76	v 	150	96	û 	182	B6	╢ 	214	D6	╓ 	246	F6	÷
023	17	↨ 	055	37	7 	087	57	W 	119	77	w 	151	97	ù 	183	B7	╖ 	215	D7	╫ 	247	F7	≈
024	18	↑ 	056	38	8 	088	58	X 	120	78	x 	152	98	ÿ 	184	B8	╕ 	216	D8	╪ 	248	F8	°
025	19	↓ 	057	39	9 	089	59	Y 	121	79	y 	153	99	Ö 	185	B9	╣ 	217	D9	┘ 	249	F9	∙
026	1A	→ 	058	3A	: 	090	5A	Z 	122	7A	z 	154	9A	Ü 	186	BA	║ 	218	DA	┌ 	250	FA	•
027	1B	← 	059	3B	; 	091	5B	[ 	123	7B	{ 	155	9B	¢ 	187	BB	╗ 	219	DB	█ 	251	FB	√
028	1C	∟ 	060	3C	< 	092	5C	\ 	124	7C	| 	156	9C	£ 	188	BC	╝ 	220	DC	▄ 	252	FC	ⁿ
029	1D	↔ 	061	3D	= 	093	5D	] 	125	7D	} 	157	9D	¥ 	189	BD	╜ 	221	DD	▌ 	253	FD	²
030	1E	▲ 	062	3E	> 	094	5E	^ 	126	7E	~ 	158	9E	₧ 	190	BE	╛ 	222	DE	▐ 	254	FE	■
031	1F	▼ 	063	3F	? 	095	5F	_ 	127	7F	⌂ 	159	9F	ƒ 	191	BF	┐ 	223	DF	▀ 	255	FF	  

[BasicCoder2]

BasicCoder: Instead of one palette per frame, I was thinking one palette (256 colors max) for all frames in the animation.... but you might actually be already doing this probably, I just probably misread something you typed...

I would have meant a whole sprite sheet.
Take this one for example,

http://img15.hostingpics.net/pics/37208 ... t8walk.png

It uses 64 colors so advantage can be taken of that using a palette of 64 rgb values.
It is also full of white space (when you remove the checker pattern background) so advantage can be taken of that to reduce the size of the resulting data statements as most of them will be strings of zero!

.

[MrSwiss]

looks like almost all of the character set is printable/copiable/pastable...

That's only true, if you *declare* the CP (code page) that *must* be used ...
(you seem to have 437 = US, but not everybody else does). In W-Europe common: CP 850.
This results in different *glyphs* (representation), which makes most above 127 unusable.

The lower *unprintable* characters (in a string) are: 0..31 (32 = Space) and so on ...

[leopardpm]

Mr. Swiss,
Are you saying that if I posted some text with codes above 127, and even though I can view them and copy/paste them directly from the forum, that other folks with different 'settings' (perhaps in other countries?) will not see the same codes so they would not be able to copy/paste the correct characters? Or is this just for display purposes and even if their view of the forum post might look different with different glyphs, if they copied/pasted then then the FreeBasic CHR command would still return the same code (1-255 whatever...)?

[Tourist Trap]

your way:
DATA 25.52,26.51,25.6,21.2,12.51,13.8,12.3,13.4,12.2 <--- 47 ascii characters (including commas) holding 9 color values plus the RLE... roughly 144 bits of data... not a good way to compare the two methods since you have RLE included already

Yes, but in fact there is a real first compression effort here. I mean for instance, color 65122 is divided by some number so that it is approximated by a small number (with of course some loss, and the uncompression use some reversal of this also obviously).

That 's why you see 25.52 for instance. 25 indeed is more something like 125625\n with some given factor n that is left to the intelligence of the code or the programmer.

Anyway, if you first do this compression with loss and apply then your string method, you should achieve a very small data file. If the objective is to share a quick sample on the forum, it should be sufficient, and a step further than just re-encoding. I mean, re-encoding yes, + data compression with loss -> should be very light in final.

[MrSwiss]

Well, I'll give it another try: CP 437 above 127, has all those "graphics-glyphs" allowing you,
to draw those ASCII-Windows in console (single and/or double line, on DOS/WIN).

This doesn't work with: CP 850 (many needed "graphics-glyphs" are replaced with other
symbols), unless you'd switch console to CP 437 beforehand. (Can be done with FB.)

In CP 850, most of those "graphics-glyphs" are replaced by "accented characters" and such.
Reason: needed for languages other than: french/german/english, e.g. spanish/portughese/
greek/scandinavian languages etc.

This means: the same ASCII code produces a different *symbol* in console. If you'd only/
exclusively rely on the codes and never on the *glyphs*/*symbols*, it shouldn't matter
(implying however: you'll never compare *glyphs* with *codes*, for any reason).

[leopardpm]

yes, it is the actual codes that are relaying information for us... not whatever symbol a persons system might display the code as...

[leopardpm]

your way:
DATA 25.52,26.51,25.6,21.2,12.51,13.8,12.3,13.4,12.2 <--- 47 ascii characters (including commas) holding 9 color values plus the RLE... roughly 144 bits of data... not a good way to compare the two methods since you have RLE included already

Yes, but in fact there is a real first compression effort here. I mean for instance, color 65122 is divided by some number so that it is approximated by a small number (with of course some loss, and the uncompression use some reversal of this also obviously).

That 's why you see 25.52 for instance. 25 indeed is more something like 125625\n with some given factor n that is left to the intelligence of the code or the programmer.

Anyway, if you first do this compression with loss and apply then your string method, you should achieve a very small data file. If the objective is to share a quick sample on the forum, it should be sufficient, and a step further than just re-encoding. I mean, re-encoding yes, + data compression with loss -> should be very light in final.

lossy compression not good, and no reason to use it except for actual pictures.... we will generally (perhaps always) use a palettized exact RGBA version of the sprite.

[Tourist Trap]

lossy compression not good, and no reason to use it except for actual pictures.... we will generally (perhaps always) use a palettized exact RGBA version of the sprite.

I don't agree. Maybe however I'm missing the plot of the topic. My goal, from my side, is to reach some maximum of compression. I had to split code listing in 2 so many times where a strong compression would have been sufficient for posting that I'm convinced that this is just good, for me at least.

Doing more involved stuff will probably inflate the code at some level. I'm not against paletization, but the palette will require some space in the code, or how will you store it? I don't know.

So now imagine you want, in the perspective of the forum, to post a game with 8 sprites and 8 giant background images. I really believe that ITOA and STOL, as well as a rough lossy compression, would allow you post it in one piece for the greatest comfort of the user. Otherwise this will be again those codes that noone executes because they come in so many pieces. Those last days I myself renounced to test some cool stuff here from famous authors because of the number of files. I also can be lazy in my days :)

[BasicCoder2]

Maybe however I'm missing the plot of the topic.

How to code an image in less than the 60,000 characters allowed in a single post.

Those last days I myself renounced to test some cool stuff here from famous authors because of the number of files.

That makes no sense to me. You will select/copy/paste three separate but complete program files but not test one program which would require the same amount of select/copy/paste actions?
.

[leopardpm]

My goal, from my side, is to reach some maximum of compression. I had to split code listing in 2 so many times where a strong compression would have been sufficient for posting that I'm convinced that this is just good, for me at least.

yes, we want perfect reproduction (lossless compression) within the smallest amount of characters for the forum post. Changing the color values of the images transferred to obtain better compression is not worth it IF we can obtain decent compression without loss.

Doing more involved stuff will probably inflate the code at some level. I'm not against paletization, but the palette will require some space in the code, or how will you store it? I don't know.

Palettization is just one form of compression and it works best when there are fewer number of colors used in the image. Combined with RLE compression (which works best with lots of pixels of same color in a horizontal line) should give plenty of total compression. Once compressed, the question is how to convert the raw compressed bytes into some format which can be copied and pasted into/from the forum - the best way I can think of is to convert the data into 7 bit modified ASCII which will only inflate the total size by 14% (7 bits raw = 8 bits modified ASCII). Your method of expressing the raw compressed data (whether you use a version of lossy or not, or RLE or not) greatly inflates the amount of bytes needed to transfer the data to the forum.

Take a look at your statement:
DATA 25.52,26.51

Here is the breakdown -
-----4 chars + space character for each statement = 5 characters
-----Each value has:
----------2 characters (16 bits) to convey 0-99 values which actually only need 7 bits (0-127)
----------1 Decimal point character (8 bits)
----------2 characters (16 bits) to convey 0-99 values which actually only need 7 bits (0-127)
----------1 comma character (8 bits)

so, ignoring the data statement part, you are using a total of 48 bits (6 bytes) of valuable forum post space (60k bytes max) which could be instead stored the way I suggest in only 14 bits (less than 2 bytes) - so your method, as ingenious as it is, will result in images taking up 3 times the space as my method... regardless of the compression used.

So now imagine you want, in the perspective of the forum, to post a game with 8 sprites and 8 giant background images.

Background images are really the only place where lossy compression wouldn't be awful to use. Sprites should be lossless.

I really believe that ITOA and STOL, as well as a rough lossy compression, would allow you post it in one piece for the greatest comfort of the user.

What is 'ITOA' and 'STOL'?

Otherwise this will be again those codes that noone executes because they come in so many pieces. Those last days I myself renounced to test some cool stuff here from famous authors because of the number of files. I also can be lazy in my days :)

Yes, I agree - that is the point of this discussion.

[leopardpm]

ok, here is a quick test program to do two things:
(1) test out automatically reading & writing to the clipboard (thank you Dodicat from another post...)
(2) Make sure that there is at least 128 characters which can be copied and pasted from/to the forum without errors/changes...

it works!

Code: Select all

' clipboard subs copied from dodicats posts in other thread...

#include "windows.bi"
dim as string s

Sub SaveToClipBoard(Text As String)       'write Text to the clipboard
   Var Num=GlobalAlloc(GMEM_MOVEABLE,Len(Text)+1)
   memcpy(GlobalLock(num), @text[0], Len(Text)+1)
   Var Chars=GlobalLock(Num)
    GlobalUnlock(Num)
    OpenClipboard(0)
    EmptyClipboard()
    SetClipboardData(CF_TEXT,Chars)
    CloseClipboard()
End Sub

Function get_clipboard() As String
        If IsClipboardFormatAvailable(CF_TEXT) = 0 Then Return "Error"
        If OpenClipboard(0) = 0 Then Return "Error"
        Function = *Cast(zstring Ptr,GetClipboardData(CF_TEXT))
        CloseClipboard()
End Function

cls
for x as integer = 35 to 35 + 128
    print x;" - [";chr(x);"]"
next x


for x as integer = 35 to 35 + 127
    s+=chr(x)
next x

s = "LENGTH="+str(len(s))+" "+s

SaveToClipBoard(s)
print "This string should be on the clipboard:"
print s
print
print "Start a forum post and paste the clipboard into it... then hit a key"
sleep
print "Now clear the clipboard by copying anything else,"
print "then copy the the same string back from the forum post"
print "but without the 'LENGTH=128 ' part... then hit a key..."
sleep
dim as string c=get_clipboard

print "Here it is:";c

sleep
end

so, all the pieces of the idea work:
1 - can store 7 bits into an 8 bit ASCII character which can be copied/pasted to/from the forums
2 - can palettize an image
3 - can RLE an image

so, I will put these all into a single utility which will allow a forum user to easily get an image from the forum:
(1) hit the 'select all' on a forum code section, then hit copy, then switch to the utility program and hit 'Convert Clipboard to BMP' and give it a filename and it will make a perfect BMP file

(2) Run the program, hit 'Load BMP to clipboard', choose the BMP file to load, switch the the browser forum post window and paste it, then hit Select All (ctrl-A) and hit the code button and post it....

There are NO data statements needed, which saves a decent amount of space, and it creates (and allows the FB forum to essentially host) 32 bit BMP files which are able to be natively read by any FB program. This means the programs don't need extra routines to decrypt added DATA statements containing graphics...

I think the ideal solution. The decision as to what compression to use is up to whoever - the utility could take any image and compress it however the user wants, so pictures could be JPEG (lossy and small), and sprites could be 32 bit BMP (lossless)

[BasicCoder2]

ITOA integer to ascii string and STOL is string to long integer.
If you have written some super duper game then you will have lots of files and none of this would be an issue as you would probably host images somewhere as others like Boromir have done packaged in a zip file. I only ever encoded simple images in text because they were just snippets of code that happened to need some kind of sprite image. I see no problem with lossy compression for demo sprites in a demo program posted to the forum. Reducing the colors in the parrot image didn't make much visual difference did it?

The limit will always be 60,000 characters or less whatever encoding you use.
.

[sancho2]

Mr. Swiss,
Are you saying that if I posted some text with codes above 127, and even though I can view them and copy/paste them directly from the forum, that other folks with different 'settings' (perhaps in other countries?) will not see the same codes so they would not be able to copy/paste the correct characters? Or is this just for display purposes and even if their view of the forum post might look different with different glyphs, if they copied/pasted then then the FreeBasic CHR command would still return the same code (1-255 whatever...)?

Also and apart from what Mr. Swiss is saying, some editors won't print those characters properly.
And FBEdit is one of them that won't.

[leopardpm]

I see no problem with lossy compression for demo sprites in a demo program posted to the forum. Reducing the colors in the parrot image didn't make much visual difference did it?

personal preference - I HATE how JPEG images will add a blurring effect around sharp edges, which to me is a no go - and most pixel art has hard edges which I wouldn't want blurred (not just character sprites, but houses, etc...) I would want them the way they were drawn and intended.

ITOA integer to ascii string and STOL is string to long integer.
.....
The limit will always be 60,000 characters or less whatever encoding you use.

ah, so the ITOA and STOL would be for converting the image data (however compressed) into a format for forum copying and pasting... and doing it this way inflates the image size by 3 times compared to the way I am suggesting by using almost every bit of each ascii character. 3 times space usage is ALOT when having such a limited forum post length of 60k.... right?