it doesn't matter what editor is used since I am also proposing FB to read the clipboard directly and then make a BMP file from it... it never gets into the editor. Same for when posting an image... the utility will read from the raw BMP file, convert it to modified ASCII and put it on the clipboard for easy pasting...sancho2 wrote:Also and apart from what Mr. Swiss is saying, some editors won't print those characters properly.leopardpm wrote: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...)?
And FBEdit is one of them that won't.
create program to create bitmap
Re: create program to create bitmap
Re: create program to create bitmap
So, the question becomes:
(1) Do you prefer to use data statements and add a decrypting routine to whatever program? The PRO to this is that the final program is basically self-contained.... the CON is that the program is a little bit more bloated (not much, but...) and the max image information is reduced by the amount of characters needed for all the extra text: "DATA", a space, and 2 quotes to delineate the string = 7 bytes of extra (wasted) info per data statement line...
or
(2) Use the Encrypt/Decrypt Utility program I propose? The PROs would be: maximize the space allowed in a forum post, create regular BMP files for use. The CON is that it means you need to run the utility program when you want to post or download a graphic file, perhaps this is an extra step....
Either method would still use the ASCII encoding I am proposing which would mean maximum (as far as I can tell...) utilization of forum post space as possible, no matter what method of compression is used....
What say you all?
(1) Do you prefer to use data statements and add a decrypting routine to whatever program? The PRO to this is that the final program is basically self-contained.... the CON is that the program is a little bit more bloated (not much, but...) and the max image information is reduced by the amount of characters needed for all the extra text: "DATA", a space, and 2 quotes to delineate the string = 7 bytes of extra (wasted) info per data statement line...
or
(2) Use the Encrypt/Decrypt Utility program I propose? The PROs would be: maximize the space allowed in a forum post, create regular BMP files for use. The CON is that it means you need to run the utility program when you want to post or download a graphic file, perhaps this is an extra step....
Either method would still use the ASCII encoding I am proposing which would mean maximum (as far as I can tell...) utilization of forum post space as possible, no matter what method of compression is used....
What say you all?
Re: create program to create bitmap
so, now the trick is how exactly to convert a series of 8 bit bytes into a series of 7 bit bytes.... My bet is that Dodicat and some of the other higher level programmers probably have a simple method of doing this, but, in thinking about this over the past few days, my first inclination is to use some sort of bitmasking in conjunction with SHR or SHL.
Here is a visual of the issue, this is a series of 4 bytes showing them as 8 bits each:
---byte 1------byte 2-------byte 3-------byte 4
01010101...11011101...01011101...00010001
so, the result desired would be to take the first 7 bits and put into the first ascii byte, then the next 7 bits (even though it crosses the byte barrier) and put into the next ascii byte, and so on...
---byte 1------byte 2------byte 3-------byte 4-------byte 5
x0101010...x1110111...x0101011...x1010001...x0000001
The 'x' is the unused bit(set to zero) of each ascii byte, the RED bits are filler because the data doesn't fit exactly.
The first byte could be obtain by: ASCIIBYTE(1) = (RAWBYTE(1) and &B11111110) SHR 1
the next byte would be obtained by: ASCIIBYTE(2) = ((RAWBYTE(1) and &B00000001) * 64) OR ((RAWBYTE(2) and &B11111100) SHR 2)
but it starts getting complicated, even though I see the pattern I haven't figured out the algo yet...
Here is a visual of the issue, this is a series of 4 bytes showing them as 8 bits each:
---byte 1------byte 2-------byte 3-------byte 4
01010101...11011101...01011101...00010001
so, the result desired would be to take the first 7 bits and put into the first ascii byte, then the next 7 bits (even though it crosses the byte barrier) and put into the next ascii byte, and so on...
---byte 1------byte 2------byte 3-------byte 4-------byte 5
x0101010...x1110111...x0101011...x1010001...x0000001
The 'x' is the unused bit(set to zero) of each ascii byte, the RED bits are filler because the data doesn't fit exactly.
The first byte could be obtain by: ASCIIBYTE(1) = (RAWBYTE(1) and &B11111110) SHR 1
the next byte would be obtained by: ASCIIBYTE(2) = ((RAWBYTE(1) and &B00000001) * 64) OR ((RAWBYTE(2) and &B11111100) SHR 2)
but it starts getting complicated, even though I see the pattern I haven't figured out the algo yet...
Re: create program to create bitmap
BasicCoder2: I think the sprite sheet link you posted is a great test sample because it pretty much is exactly what we have been trying to transfer: sprites. We could use the parrot picture for a sample of picture transfer. We could instead use a sprite sheet which you created, but I think this one gives us a higher goal to achieve with its quality.... but I don't mind either way.
As you said, the sprite sheet has only 64 color values - just about ideal for palettizing. You seem to only use RGB images (whereas I prefer having the alpha too for purposes of semi-transparent things like shadows, windows, water, clouds/gasses,etc), but RGB works fine for most things - we can use Magic Pink to designate 'clear' pixels...
More image info:
....Image Size is: 488 x 968
....Frame size is: 61 x 121
....as an uncompressed RGB image, it is 1,417,152 bytes uncompressed (3 bytes per pixel)
....palettizing it would make it 472,384 bytes plus a palette of 64 x 3 bytes = 192 bytes... for a total of 472,576 bytes
....It has 8 facings, and each facing has 8 frames in the animation
....To fit it into a forum post, unpalettized it would need to be compressed to roughly 1/24 its raw size
....To fit it into a forum post, palettized it would need to be compressed to roughly 1/8 its palettized size, including palette
Here is your link again:
http://img15.hostingpics.net/pics/37208 ... t8walk.png
and it looks like this:
as a comparison, my goblin sprite sheet is way too large... 2432 x 512 = 3,735,552 in RGB! Though it does have ALOT of wasted space in it....
As you said, the sprite sheet has only 64 color values - just about ideal for palettizing. You seem to only use RGB images (whereas I prefer having the alpha too for purposes of semi-transparent things like shadows, windows, water, clouds/gasses,etc), but RGB works fine for most things - we can use Magic Pink to designate 'clear' pixels...
More image info:
....Image Size is: 488 x 968
....Frame size is: 61 x 121
....as an uncompressed RGB image, it is 1,417,152 bytes uncompressed (3 bytes per pixel)
....palettizing it would make it 472,384 bytes plus a palette of 64 x 3 bytes = 192 bytes... for a total of 472,576 bytes
....It has 8 facings, and each facing has 8 frames in the animation
....To fit it into a forum post, unpalettized it would need to be compressed to roughly 1/24 its raw size
....To fit it into a forum post, palettized it would need to be compressed to roughly 1/8 its palettized size, including palette
Here is your link again:
http://img15.hostingpics.net/pics/37208 ... t8walk.png
and it looks like this:
as a comparison, my goblin sprite sheet is way too large... 2432 x 512 = 3,735,552 in RGB! Though it does have ALOT of wasted space in it....
Re: create program to create bitmap
The point is to transfer the bmp from user to user via the forum. So now you have your image as ASCII in data statements and posted on the forum. Now the downloader must convert them back to images. So he selects and copies the data statements and pastes them into his editor and if it happens to be FBEdit the statements will be awry.leopardpm wrote:it doesn't matter what editor is used since I am also proposing FB to read the clipboard directly and then make a BMP file from it... it never gets into the editor. Same for when posting an image... the utility will read from the raw BMP file, convert it to modified ASCII and put it on the clipboard for easy pasting...
At some point the data statements have to make it into an editor.
Is your proposal therefore to create a utility that one must run and feed copied chars from the forum into it? Then that code creates data statements that can be used to build an image.
That might work well between users in the know (like yourself and basiccoder). Others may be frustrated and wonder why you don't just host the image file somewhere, as opposed to forcing them to use a utility program.
-
- Posts: 538
- Joined: Jul 15, 2005 4:13
Re: create program to create bitmap
I think basicCoder2's method is the best. It would seem that if we just use a single number to specify a specific rgb value then that would save the most space. even if the program contains a lot of rgb conversion lines, its still going to be able to build more bigger bitmaps because it can specifiy the amount of colors, although there would come a point where it would contain too many RGB conversion lines, but we don't use 60000 colors most of the time in a single sprite anyways.
-
- Posts: 538
- Joined: Jul 15, 2005 4:13
Re: create program to create bitmap
working with sprite sheets, there may be an alternative method as well, every color used is in one frame, there may be a way to 'skeleton' the frame work and just re-build a sheet from a few of the frames. In the above sprite sheet there seems to be some frames that are just a mirror image,
So in that event you could just reverse the building process to build half of the sprite sheet.
So in that event you could just reverse the building process to build half of the sprite sheet.
-
- Posts: 538
- Joined: Jul 15, 2005 4:13
Re: create program to create bitmap
I'm just throwing ideas out there, it may be useless i know.
Re: create program to create bitmap
Well, for this one, I disagree, downloading stuff, from *unknown* file-hosting-sites, is the frustrating part.sancho2 wrote:Others may be frustrated and wonder why you don't just host the image file somewhere, as opposed to forcing them to use a utility program.
Reason: *unknown* means *automatically* --> hands off, insecure, etc. (useless for me, because I won't
touch it).
Explanation:
I have, in the past, worked in system/network security, still not understanding, that people are trusting
just about "everything" on the internet. This is usually *the way*, to pick up unwanted guests ...
Re: create program to create bitmap
I think BasicCoder would agree with Mr. Swiss, it is because he doesn't like to have to give up email info in order to access some file hosting sites that this whole process began. Another issue is that images hosted by other sites go 'link dead' and are lost over time... if the image is converted to some sort of ascii form and actually contained within the forum, then it will be accessible for time indefinite....
There are 2 separate issues: compressing the raw data, and then converting that data into something transferable through the forum with copy/paste.
Method: Making a utility program that will allow the user to load any BMP file on their computer, compress it via palettization and then with RLE, convert that 8 bit data into 7 bit ASCII so that it is all printable characters,
Usage #1: The utility then outputs the ascii into a text file containing data statements and a subroutine to decompress back into a BMP. This is basically what BasicCoder is doing right now, except his conversion method inflates the data size to perhaps 6 or 7 times greater than the BMP 8 bit data size was.... sancho proposed to use a different conversion scheme which inflated the original graphic file to perhaps 3 times the size for transfer. Using the above method, the 8 bit data (however compressed) is expanded by only about 14% with the conversion to 7 bit ascii (only printable characters).
Usage #2: The Utility outputs directly to/from the clipboard (NO data statements) to just copy/paste into the forum, and allows the user to save the file copied from the forum as a regular BMP. This makes the most sense to me because it doesn't add additional data statements or code to the program using the BMP files and the user has a regular BMP to use however they wish.
The main issues I have with Usage #1 is that there is alot of wasted space in having to transfer the full DATA statements themselves: This line "DATA 'a3W*fTyie$%' has 18 characters and takes up 18 characters of valuable forum space, but the actual data it contains is only 11 characters. The other problem is that the complete transferred program/demo has extra parts in it: the subroutine to read/decrypt the data, and the data statements themselves. Usually, we have been working on specific routines related to gaming: path finding, ways to display the sprites, etc, and the actual demo program is the important part to relate to another, the graphics are just 'fluff'. Adding all that 'extra' stuff (DATA statements and decryption routine) just clutters up the program a bit more... in my eyes. Also, it seems to me to be very inefficient... but that just may be my own perception.
I don't think folks are grasping my description of the proposal... need to write a small example to show. My method of conversion into ascii of and 8 bit data file is the most efficient I can think of (any and all compression techniques can also be applied and are immaterial - the 'method' is just how to get as much informatin into printable ascii characters on the forum since the forum limits a post to 60,000 printable characters to copy/paste from.
that is another way of compressing the data, and would only work in limited cases where the sprites were indeed mirror images...In the above sprite sheet there seems to be some frames that are just a mirror image,
There are 2 separate issues: compressing the raw data, and then converting that data into something transferable through the forum with copy/paste.
Yes, and no. I propose one method with two different options for execution:Is your proposal therefore to create a utility that one must run and feed copied chars from the forum into it? Then that code creates data statements that can be used to build an image.
Method: Making a utility program that will allow the user to load any BMP file on their computer, compress it via palettization and then with RLE, convert that 8 bit data into 7 bit ASCII so that it is all printable characters,
Usage #1: The utility then outputs the ascii into a text file containing data statements and a subroutine to decompress back into a BMP. This is basically what BasicCoder is doing right now, except his conversion method inflates the data size to perhaps 6 or 7 times greater than the BMP 8 bit data size was.... sancho proposed to use a different conversion scheme which inflated the original graphic file to perhaps 3 times the size for transfer. Using the above method, the 8 bit data (however compressed) is expanded by only about 14% with the conversion to 7 bit ascii (only printable characters).
Usage #2: The Utility outputs directly to/from the clipboard (NO data statements) to just copy/paste into the forum, and allows the user to save the file copied from the forum as a regular BMP. This makes the most sense to me because it doesn't add additional data statements or code to the program using the BMP files and the user has a regular BMP to use however they wish.
The main issues I have with Usage #1 is that there is alot of wasted space in having to transfer the full DATA statements themselves: This line "DATA 'a3W*fTyie$%' has 18 characters and takes up 18 characters of valuable forum space, but the actual data it contains is only 11 characters. The other problem is that the complete transferred program/demo has extra parts in it: the subroutine to read/decrypt the data, and the data statements themselves. Usually, we have been working on specific routines related to gaming: path finding, ways to display the sprites, etc, and the actual demo program is the important part to relate to another, the graphics are just 'fluff'. Adding all that 'extra' stuff (DATA statements and decryption routine) just clutters up the program a bit more... in my eyes. Also, it seems to me to be very inefficient... but that just may be my own perception.
Yes, but we are specifically talking to those users who want to avoid downloading images from file hosting sources that they don't exactly trust. It is also a way to have the FB forum 'host' graphic files so that they do not expire as they do on other hosted sites. I agree with you personally, I am fine with using mediafire or some other sites, but not everyone likes to download potentially infected files...which I also understand.That might work well between users in the know (like yourself and basiccoder). Others may be frustrated and wonder why you don't just host the image file somewhere, as opposed to forcing them to use a utility program.
I don't think folks are grasping my description of the proposal... need to write a small example to show. My method of conversion into ascii of and 8 bit data file is the most efficient I can think of (any and all compression techniques can also be applied and are immaterial - the 'method' is just how to get as much informatin into printable ascii characters on the forum since the forum limits a post to 60,000 printable characters to copy/paste from.
Re: create program to create bitmap
AFAIK, the clipboard code (by dodicat) is WIN only, because it uses Win-API.leopardpm wrote:Usage #2: The Utility outputs directly to/from the clipboard (NO data statements) to just copy/paste
Isn't this a problem, for all the NON-Win users?
Re: create program to create bitmap
I guess, I don't know much about non-win FB code... is there code to do the same thing on other OSes? or perhaps some code that would be cross-compatible across operating systems? that would be the ideal solution.MrSwiss wrote:AFAIK, the clipboard code (by dodicat) is WIN only, because it uses Win-API.leopardpm wrote:Usage #2: The Utility outputs directly to/from the clipboard (NO data statements) to just copy/paste
Isn't this a problem, for all the NON-Win users?
Writing to/from the clipboard without data statements saves some space (4 chars + space + 2 chars for quotes = 7 chars) per line, so isn't 'necessary', I just remembered seeing dodicats code and thinking that could be handy...
Re: create program to create bitmap
There probably is, but it'll differ by OS (WIN <> LIN <> BSD <> OS X, etc.).leopardpm wrote:is there code to do the same thing on other OSes?
I'd say no, since its usually implemented at OS level (lower than Appl. level).leopardpm wrote:or perhaps some code that would be cross-compatible across operating systems?
Re: create program to create bitmap
then perhaps the best way is for the utility program to have an option of which method to use. That way different OS users could use the DATA statement method and bypass the easier, but OS dependent, clipboard methodMrSwiss wrote:There probably is, but it'll differ by OS (WIN <> LIN <> BSD <> OS X, etc.).leopardpm wrote:is there code to do the same thing on other OSes?I'd say no, since its usually implemented at OS level (lower than Appl. level).leopardpm wrote:or perhaps some code that would be cross-compatible across operating systems?
Basic menu options for utility program to transfer images via FB forum:
(1) Load Image from file
(2) Save Image to file
(3) Convert loaded BMP Image to ASCII and put on Clipboard
(4) Convert loaded Image to ASCII and write a text file with Data Statements and decrypt routine
(5) Import Clipboard as ASCII image and convert to BMP
(6) End program
Re: create program to create bitmap
BTW, been thinking about this whole conversion from 8 bit data into 7 bit data and I got a really clunky, slow, stupid way, waiting for some genius to write the algo that would do it the 'correct' way...
My way basically takes each byte, makes an 8 bit binary string of it, and adds it to one long string. Then it iterates through that string with the MID$ function and extracts the 7 bit segments. Here is the test code:
next I will actually load an image and convert it (no compression) and copy/paste to clipboard to make sure whole idea works... but new wife just finished cooking breakfast so I fear it might be a while before I get back...
EDIT: code modified to fit Mr. Swiss's adjustments
My way basically takes each byte, makes an 8 bit binary string of it, and adds it to one long string. Then it iterates through that string with the MID$ function and extracts the 7 bit segments. Here is the test code:
Code: Select all
dim as byte a(6)
dim as string is8bit(7)
dim as string to7bit(8)
dim as string holder = ""
a(0) = 255
a(1) = 127
a(2) = 63
a(3) = 64
a(4) = 15
a(5) = 128
a(6) = 31
print "8 bit data:"
for x as integer = 0 to 6 '<---- this is just an index to which byte of 8 bit data
is8bit(x) = right("00000000" + bin(a(x)),8) '<----- makes a 8 character string of binary data
print is8bit(x);".";
holder += is8bit(x) '<------- makes one long consecutive string of binary data
next x
sleep
' this section grabs consecutive sections, 7 characters at a time, and saves each individually
for x as integer = 0 to 7 '<---- this is just an index to which byte of 7 bit data
dim as integer y = 7 * x + 1
to7bit(x) = mid(holder,y,7)
next x
print
print "7 bit data:"
for x as integer = 0 to 7 '<---- this is just an index to which byte of 7 bit data
print to7bit(x);".";
next x
sleep
EDIT: code modified to fit Mr. Swiss's adjustments
Last edited by leopardpm on May 27, 2017 17:46, edited 1 time in total.