Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / CreateImage FromMemblock crash

Author
Message
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 15th Oct 2014 11:48
Link
Hi

I would like to knwo how I can load an image directly in the memory ?

I have tried that, but I have a crash :


What is wrong with function ?

Thank you.

http://www.dracaena-studio.com
Back to top
Profile PM Website
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 15th Oct 2014 12:14
Link
Probably nothing specifically wrong with the function, but how are you making that image file?

It would have to be a memblock, or an exact memblock format at least otherwise it'll just fail - you can't load an image file as a memblock then convert it, it just won't work that way.

An image memblock will have 3 integers at the start which define it's resolution and color depth, often referred to as a header...

Setmemblockint(1,0,256)
Setmemblockint(1,4,256)
Setmemblockint(1,8,32)

Not sure if that's the exact command, but that would set those 3 integers to make the image 256x256 with 32 bit colour, or basically a DWord per pixel. Once these 3 integers or 12 bytes are set, the actual image data can be assigned by bytes exactly the way your doing. I think the crash you are experiencing is the memblock trying to be a weird size or colour depth based on the header information.

So, you might want to use a standard image then convert that to a memblock and save the data. If this is to help you protect your image data, then consider not setting the image resolution in the file - maybe it would be cool to check the file size, and calculate the resolution based on the square root of that.

I am the one who knocks...
Back to top
Profile PM Email
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 15th Oct 2014 12:31
Link
In fact, I would like to load an image (jpg, png) directly in the memory with this function


I don't know if it's the good method.

My first test was to decrypt my image encrypted, copy it to the disk and load the new image decrypted, then delete this file.
But I would like to know if it's possible to load an image directly in memory, without LoadImage().

http://www.dracaena-studio.com
Back to top
Profile PM Website
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 15th Oct 2014 13:29
Link
you can save the 12 bytes (3 integer) header (x y depth) with the crypted image data or with non cryped data.

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini
Back to top
Profile PM Email
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 15th Oct 2014 13:57
Link
That would be fine I think, but don't specify the extension...

Like, have the function check for which file is present based on the filename, so if you save an encrypted memblock as say, .EMB - you can check to see if there's an EMB file, in which case load the memblock and decrypt it. If there's no EMB file but there is a PNG file, load the image directly and convert to a memblock and save out the EMB file. Then later you can just get rid of the PNG files, and all that will be left is the protected EMB files. The main benefit in doing it that way is you don't have to mess around with files every time - it'll just take care of itself as you add content. If you change an image, just delete it's EMB file to re-generate it. I think that would be a pretty neat system and would save you time. It could just be dropped into any project and take care of image encryption for you.

If you are targeting Apple devices, it might be an idea to make an image re-scale function as well, so if the device has less memory, you can reduce the resolution on less vital images - like a title screen might be 2560x1920 for an iPad3+ - but an iPad2 and a lot of cheaper Android tablets only need 1024x768, so there's a 84% data size reduction right there. It's especially important with Apple devices as device compatibility specs need to be exact, or people will complain - Apple users will complain 20 times before they will commend!
Frugality still has it's place in software development, there are a lot of lower spec devices out there that might struggle without these sorts of measures, so make allowances and maximize your apps compatibility, and reduce the chance of negative feedback.

I am the one who knocks...
Back to top
Profile PM Email
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 15th Oct 2014 15:59
Link
i would try this order

once:
loadimage
CreateMemblockFromImage
save memblock
always:
load memblock
CreateImageFromMemblock

once:
loadimage
CreateMemblockFromImage
crypt memblock
save memblock
always:
load memblock
decrypt memblock
CreateImageFromMemblock

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini
Back to top
Profile PM Email
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 15th Oct 2014 17:30
Link
@Markus :
I have made this one , but it doesn't work :
Quote: "once:
loadimage
CreateMemblockFromImage
crypt memblock
save memblock

always:
load memblock
decrypt memblock
CreateImageFromMemblock"


http://www.dracaena-studio.com
Back to top
Profile PM Website
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 15th Oct 2014 19:05
Link
hmm try this,

once:
loadimage
CreateMemblockFromImage
save memblock < with other filename
crypt memblock
save memblock

always:
load memblock
decrypt memblock
here save memblock with extra filename and compage with crc32 checksum the content.
CreateImageFromMemblock" '<- did not work u said

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini
Back to top
Profile PM Email
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 17th Oct 2014 13:49
Link
Hi

I have tried to use your method to create a simple image :

1) save an image :
- save in a file the 3 first integers (W,H,Depth) with writeint() and save the RGBA value as byte (with writebyte())
- encrypt this file (if needed)

2)open the file (encrypted or not)
- open the file : readint() for the W,H, depth and readbyte() for the rest of the datas
- decrypt -if file is encrypted
- createimagefrommemblock()

And it works.
But the problem is the size for some files (>64*64). For 128*128, my original png is 16 ko, and my file is 64ko, in some file, the size is increased by 10 and more.
So, unless to create a compression algorithme, I don't know how to use this method without explode the size of my game ^^.

http://www.dracaena-studio.com
Back to top
Profile PM Website
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 17th Oct 2014 19:47 Edited at: 17th Oct 2014 19:47
Link
plan b

once:
loadimage
CreateMemblockFromImage
get the first 3 integers x,y,depth
creatememblock with file size +12
put in x,y,d
load raw image data in memblock , means .jpg or .png from offset 12
save memblock 1. (x,y,d + data)
crypt memblock (all)
save memblock 2. (crypted data)

always:
load memblock 2.
decrypt memblock
CreateImageFromMemblock

or
load memblock 1.
CreateImageFromMemblock

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini
Back to top
Profile PM Email
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 18th Oct 2014 01:04
Link
Thing is with any sort of encryption, unless it's compacted from source, there's no real gains. I mean, when data is encrypted it becomes very difficult to effectively compact.

I guess it depends on how complicated your media is - if you use long lines of the same colour for example, you could make a simple compression method with a repeat count, you'd get gains for sequences of the same colour and it could be part of the file load/save procedure.

Like..
load the original PNG file.
Convert to a memblock.
Get each pixel and count how many of the same colour is repeated.
Write out the encrypted pixel data and count to a file.

Then..
Load the file byte by byte, decrypt pixel data and count and write the data to a memblock.
Convert memblock to image.

Admittedly you will get diminishing returns with that method if your media doesn't 'mostly' have at least half of it with repeating pixel colours. Might be a benefit to ensure any alpha 0 pixels are the same colour, some art packages can be messy with that.

I am the one who knocks...
Back to top
Profile PM Email
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 18th Oct 2014 01:36
Link
the simplest crypt is value xor value
if data is already compressed, u just need to crypt, the size stay the same.

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini
Back to top
Profile PM Email
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 18th Oct 2014 11:57
Link
Quote: "the simplest crypt is value xor value
if data is already compressed, u just need to crypt, the size stay the same."
Yes, it's what I use for the moment.

But, when I decrypt, I have to copy the decrypted image to the disk, load it (with loadImage()) and delete it. It's easy to create a programm to copy the temporary file ^^, so I 'm trying to found another method.

In other langage, I can directly load an image PNg/jpg in the memory, but for the moment, it's not possible in AppGameKit (excpet with the method described above, which increase the size of each image.

I have the choice : have a "lite" game but easy to hack the image or have a big game with more secured image ^^. I think I will choose the lite game . (I tall that for a PC game, because in android, to copy the file, we have a rooted system).

http://www.dracaena-studio.com
Back to top
Profile PM Website
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 18th Oct 2014 14:28 Edited at: 18th Oct 2014 15:11
Link
Try the following steps:

Preparing:

Load real image into memblock.
Scramble, leaving the first 64 bytes alone
CreateImageFromMemblock()
SaveImage as xxx.jpg or xxx.png
Rename saved image as xxx.dat

Using in program:

LoadmemblockFromFile(xxx.dat)
Decrypt the memblock
CreateImageFromMemblock()

I haven't tried this, but it should work in theory! This should give you a smaller file on disk.

Alternatively, leave the image on disk as .jpg or .png and just load it to a memblock, decrypt and create the image from it.

The advantage of these techniques is that there is never an unscrambled file on the computer/phone.

You can also just encrypt the header of files, which makes them unusable.

You can do the same with .wav files. You probably don't want to smack the whole lot, which could be very slow on low-power devices.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Markus
Valued Member
20
Years of Service
User Offline
Joined: 10th Apr 2004
Location: Germany
Posted: 19th Oct 2014 12:20 Edited at: 19th Oct 2014 12:25
Link
see Posted: 17th Oct 2014 19:47 Edited: 17th Oct 2014 19:47
plan b
its only 12 bytes more each.

@JimHawkins
hmm i think save image from crypted data with jpg use
compression u lost real data.

AGK 108 (B)19 + AppGameKit V2 Alpha .. : Windows 8.1 Pro 64 Bit : AMD Radeon R7 265 : Mac mini
Back to top
Profile PM Email
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 19th Oct 2014 13:27
Link
Possibly - but PNG should be ok.

Just smacking the header zone means you can just save it as a DAT file.

-- Jim - When is there going to be a release?
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-04-25 16:01:50
Your offset time is: 2024-04-25 16:01:50