0-255 as single byte chars?

BlitzMax Forums/BlitzMax Programming/0-255 as single byte chars?

Chroma(Posted 2008) [#1]
I want to be able to represent the numbers 0-255 as a single char for compression purposes. Any ideas?


fredborg(Posted 2008) [#2]
Local char:Byte = Rand(0,255)


Chroma(Posted 2008) [#3]
Thx Fred. I also need to be able to write these to a .txt file and read them back in.


fredborg(Posted 2008) [#4]
WriteByte(stream,char)


Chroma(Posted 2008) [#5]
Perfect thanks. What I'm doing is writing a little proprietary image format for a bit of security. Now I'm just working on how to compress it a bit.


Arowx(Posted 2008) [#6]
Hi Chroma saw this in the code archives and though of your post



RC4 encoding would this be any use?


Chroma(Posted 2008) [#7]
Yep that would work for the encryption part. Now I just need a decent compression routine. I would like to write something similar to the .png format. Nothing too fancy but something that has compression, basic encryption, and supports alpha.


xlsior(Posted 2008) [#8]
Yep that would work for the encryption part. Now I just need a decent compression routine. I would like to write something similar to the .png format. Nothing too fancy but something that has compression, basic encryption, and supports alpha.


I think calling .png 'nothing fancy' doesn't quite do it justice -- it's actually a very, very good format.

If you're looking for an *easy* way to protect media, one thing that you could do is take an actual normal .png file, put it in a password-protected .zip file (no compression, just archiving -- you're not going to able to noticable compress .png or .jpg's anyway)

You can use Koriolis' zipstream module to read the images directly out of the password protected file from within blitzmax, just by using myimage=loadimage("zip::myimage.png")

you can even chain it together with incbin, and include the protected file into your final executable.

There's also other encryption/decryption libraries available... I don't think you're going to be gaining a whole lot by using your own built-from-scratch image format vs. just using a decent encryption on top of a well supported native image format.


Dreamora(Posted 2008) [#9]
Password protected zips are not even funny anymore, they are cracked even by brute force approaches in <= 24 hours normally.

If it is for Windows, use 7z and its AES encryption, alternatively implement an AES encryption stream (there are free C sources for AES / Rijndael encryption)... both will take care that only disassembling your application would allow them to get the media, if they steal the key. And using Kevins protection suite on the exe will make it quite a bit harder harder to get anything of from there if you did it correctly.


Chroma(Posted 2008) [#10]
I think a password protected zip would suffice. I really just want to keep my images safe from puki! I'll do a search for Koriolis's zipstream stuff. Thanks.