18 replies to this topic

[CrimsonCasio]

I am releasing a beta test for my new CGF (Calculator Graphics Format) maker, it is a BASIC program which scans the screen into a list file where it can be moved, resized, and inverted then pasted back to a new place on the screen.

currently the image can only be resized by intergers and the scaning always starts at 1,1 along with many other things, but they should be fixed in next release.

About the resize function:
-currently you must use a decimile to scale down a picture (.5=half size)
-increasing the size of the picture dose not increase the size of the file
-resize works very well, almost just like a bitmap

any way, here is a link to the file, please take a look, and feel free to post suggestions.

Thanks.

btw: please inform me if you download it.

[BiTwhise]

Looking at your title, it says: "Screen Compression Algorithm"
What do you mean, compression algorithm... you take screen data and put it in lists, increasing the size (one listvalue = 9 bytes = 72pixels, +list declaration = 27 bytes = 216 pixels). If you want to keep the size as low as it was, you'd need to manipulate the bitfields of the numbers in the list (which would be extremely slow in Basic). However, if you want to make the graphics truly compressed, and scalable, you should consider making vector graphics, rather than reading pixels and putting them in lists...

Hope your not offended by this. It's an ok idea (done it myself once)... but what is it usefull for?

[CrimsonCasio]

the program "compresses" the screen by counting up the number of on/off pixels in a row then storing it into the list file; but it takes it a step futher by storing more data in the dicimiles of the numbers:
if you had 38 pixils on in a row, then 20 off, then another 5 on, and another 31 off the first cell would read 38.020005031, try it, you will see what I mean.

the size program allows you to double, tripple, quadruple, ect the size of the picture. and the unzip program allows you to paste it to a diffrent place on the screen.

like I said, its a beta version so it will do more stuff eventually (possibly 3D rotation).

btw: compression is based off of how many times you go from having pixels off to having them on (so dont checkerboard the screen and expect it to work).

[BiTwhise]

I understand.. still you'll need quite a lot of pixels in a row for the size of the picture to decrease instead of increase

this is all kinda slow... being in basic and all
with plans for 3d rotation and stuff... why don't you do it all in asm/c instead?

[CrimsonCasio]

this is all kinda slow... being in basic and all
with plans for 3d rotation and stuff... why don't you do it all in asm/c instead?

because I dont know enough of either language yet, and yes it is slow.

[ross8653]

heres my stupid idea

store the pxls (0 or 1) in 8 bits binary as an integer
ie 00101101 = 32+8+4+1 = 45
then you assume that the answer is a 3 bit base 10 answer so
00000011 = 003
then you take 8 of those numbers and put it into one place of a list

remember that matrixs, variables, lists almost everything can hold 16 unique digits even if they arent displayed. so just keep tacking these 3 bit base 10's on it
this will allow you to have 8x6 = 48 pxls compressed to one list cell

this is very raw and i'm sure you can compress the result of this better
but this will allow for later compression and this gets rid of the "0" spacer that i see you had in your example

0 spacers just use too much space, and i think your way would almost use more space than it starts
what if you had 2 on 2 off 2 on 2 off....

i guess with your way you'd get
02002002002
but with my way you'd get
11001100 = 128+64+8+4 =
204 XXX XXX XXX XXX X
where the X's can still be used and thrown into one cell

[BiTwhise]

remember that matrixs, variables, lists almost everything can hold 16 unique digits even if they arent displayed. so just keep tacking these 3 bit base 10's on it
this will allow you to have 8x6 = 48 pxls compressed to one list cell

Still not compressing.. one list cell = 9 bytes = 72 pxls..
At least CrimsonCasios's idea actually has the potentiall of compressing the material
What you could do though, is, assume there are never more than, say 256 equal coloured pixels in a row, then truncate the list values, by multiplying the next number by 256, and then by 256^2.. and so on, you could fit 8 such numbers in 1 variable (if you use the exponent as well.. multiplying by 2^last_number, rather than adding last_number * 256^7)

Just my thoughts..
You could allways include som sort of pattern recognition algorithm.. but that would be extremelly slow in basic (for encoding)

[Martin]

a cfx doesnt have asm and c support if you are not called martin poupe

What a nice condition

[dscoshpe]

just adding my 2 cents in here, as this topic seems to come up every year...

just wanted to remind people that an algebra fx 2 can store complex numbers in the list and matrix effectively doubling its capacity to hold compacted numbers.

way back, i did alot of developing in this subject as i was making a calculator based rendition of the board game Axis & Allies in basic, and i needed to store tons and tons of information about the position of units and strengths and IPC's and everyhting else, while keeping enough room to have giant basic code filling the memory of my CFX-9850, so i made a compression system all contained in one, as i call it, subroutine.

i used it like this, the subroutine (a program called "~COMP") had a list that it used to keep its operating variables. those variables were conditions that ~COMP used when processing a compressed matrix. it could either extract or compact a series of values that were stored in another list, and it could use different number lengths and a couple other things. anyways, it helped alot because for this game i was drawing the map of the board rather than using a pre-rendered picture (to ensure playability) and a map of the world is not easy to generate.

the solution was for me to put key coordinates into a large matrix organized a certain way, then compress it with my system. then i would use my program "~COMP" to extract a few numbers at a time into the buffer list i mentioned, and then use 'f-line' to draw the lines.. it worked very well, and faithfully saved me a HUGE amount of space. the game statistics and information was used similarly but in a more complicated manner as insertion to the compressed matrix was often required soon after.

the drawbacks were of course speed, and the fact that if you needed to use more than one compressed matrix you had to keep enough memory free to swap it into the appropriate matrix, and then you had to consider the 7 or so bytes for the configuration, plus however many entries you wanted to fill the buffer with. in all though, space was not an issue any more, and if the insert/extract points were chosen carefully, the speed decrease wasnt too bad!

if you want to check it out they are on my page in the legacy section. i have also made a couple of examples of how to use it in a program, but all have been lost. if you want to search the net (very well may be around still) one was a periodic table (data stored compressed style), a 'breakout' game (level layouts stored compressed style), and of course an early Axis&Allies version. Someone other than me used the program in a rpg called "Albion" (i think thats the name). i do have all the tools for the matrix compression system up...

i know this isnt entirely in line with the thread but i figured that people interested in the thread would be interested in this program i am rather proud of - btw, i didnt know how futile the attempt would be at the time because the afx2 was released RIGHT after i finished the last version! lol.. oh well

- dscoshpe -

[CrimsonCasio]

I see you added this to your site, I will take a look at it and see if I can find a way to combine the best of both programs(with your permission), but as I said my ideal goals are to have rotation, high compression, image maipulation (stretch, invert, resize, ect), and anything else I can think of.

Ive been experimenting with this kind of thing for a couple of years now (on and off), it started as a copy/paste function for a drawing program. who knows where it will end.

also, about the speed problem, I have an idea for fixing that so that will draw extreamly fast (compression will still be slow) so that pre-compressed files can be used in games, the only problem is that Im not shure if it will work...

anyway, I will keep you posted and I really appricate the input, keep it comming.

btw: I dont exactly remember why, but when I stared off on this crusade I decided that I wasnt going to use matricies, Im sure I had a reason, I just dont rember what it was.

[CrimsonCasio]

Partial sucsess on making a fast decompression program, the new program goes about 4 or 5 times faster on average (it really depends on what the graphic looks like, it could range anywhere from same to instant) but has some strange bugs. It sometimes adds in extra pixels where there should be none and it does not currently work with the resize function.

here is how it works:
-instead of drawing each pixel at a time it draws a whole segment of like pixels with f-line
-skips spaces where the pixels are off, therebye saving time
-if you have say 11 pixels on in a row but your height is 10 it will do the 10, then do 1 on the next line over.
-if the line extends off the screen, it will crop the image at the edge of the screen instead of refusing to display the whole line.

Currently (unless I fix the bugs) I am going to include both "unzip" files (called UNZIP and F-UNZIP) they both use the same compiler so you could use one for accurate display and one for fast display. If your image looks fine in F-UNZIP then it always will, the glitches always appear in the exact same place on each image.

Once I fix the bugs in F-UNZIP then UNZIP will be obsoleat and will no longer be included in the CAT file.

I will update the CAT file found here tomarow (friday).

[CrimsonCasio]

New update, the resize function now works (very well) with F-UNZIP, and I have fixed a few of the bugs.

[CrimsonCasio]

New update: all bugs that I know of are fixed in F-UNZIP and I now have a program called OPTIMIZE which reduces the list size from 255 to whatever the image actually takes.

The new update is available here.

My new goal is to optimize F-UNZIP so that is runs as fast as posible and to increase the level of compression.

[BiTwhise]

Either you have some major debugging and optimizing to do, or I don't have the latest version of your programe.. (downloaded it just now)
Compressing and Decompressing an Image of 127x31 takes ages, and.. does not display correctly...

As for you program.. you need to optmize your algorithms, and try to put more into loops where possible (instead of endles if statements)..

I have my own set of routines to do the same, which doesn't incorporate all the functionallity of you programs, but works much faster and more reliable than the version I was able to download from you..
If you'de like, I can mail them to you, just to illustrate my version of how it can be done, and maybe give you som ideas

immidiate suggestions:
include your resize factor outside the main data, and incorporate it in your Line drawing part. This will keep it from causing errors, as well as speeding up the actual resize time
Stop using if statements to invert Boolean values. to invert V, use: 1 - V -> V

Anyway, good luck

[CrimsonCasio]

Odd, it works fine on both my calculators, what model do you have?

Anyway I will look at the code I uploaded and make sure that it is the correct version, but I will not be able to upload it for a few hours so I will post when I do.

in the meantime look through the code of the program, you might have goten a error when you downloaded it to your calc.

btw: you should have used COMPRESS and F-UNZIP to compress and decompress your image.

also thanks for the help with testing this thing.

[BiTwhise]

I use an AFX2.0 (ROM1.01)

Don't think there's been any error while uploading..
And looking through your code is quite confusing (think your making it harder than it has to be)

Running the F-UNZIP prog:
Starts off plotting completely wrong, and strangely slow..
After a while the prog gives me an error, I've never seen before: Undefenition Error, Error No[42], Press: ESC' />...
Solved this by rewriting parts of the code on calc, so it was probably a transmition/toke translation error

Also, what View-window do you use? it's not defined in your prog...
I use the ever normal 1,127,0,1,63,0 (y-axis inversion is not possible on AFX)

[CrimsonCasio]

I was just using the defalut widow size, but it should not matter.

I have tested this on both my CFG-9850 and my AFX 2.0 and it works perfectly

also, you should be using plot coordinates for F-UNZIP and pixel coords for COMPRESS.

I know that its not written as well as it could be, Im saving that for the last version, right now Im just trying to make it work.

[CrimsonCasio]

btw: right now I'm working on increasing compression.