Yes, the images are decompressed before loaded into memory.

https://www.scirra.com/manual/183/memory-usage

[quote:3uv4df2v]First of all it is important to note the image format has no effect on memory use. You can save on your project's download size by setting some images to PNG-8 or JPEG format in the image editor. However this does nothing to memory use: compressed images cannot be directly rendered, so upon loading all images are decompressed in to a 32-bit ARGB bitmap format. This means each pixel takes four bytes for the alpha, red, green and blue channels.

Consequently, the approximate memory use of an image is simply its number of pixels multiplied by 4. For example a 100x100 image would use 100 x 100 x 4 = 40000 bytes, or about 39kb. A HD-sized image at 1920x1080 would take 1920 x 1080 x 4 = 8294400 bytes, or about 7.9mb.

It's regarding RAM memory.

I see two options here:

1. As described in my tutorial mentioned above. Basically you show loading screen at the end of the first layout and you hide it once everything is loaded/stable on the second layout. It doesn't speed up the loading process but at least you get rid of that "freeze" feeling.

2. C2 engine clears the memory while switching between layouts, but it keeps the objects which are used both in the layout you are now and the one you are switching to. So basically all common objects remain in the memory and there is no need for the engine to reload them. You can use this fact and load the assets you need in the next layout just before switching to another layout (or during gameplay... up to you).

I think you don't need to place the second layout assets in your first layout. Never tried it myself but simply spawning those objects from the code should do the job.

There's another trick here. Keep in mind that C2 engine does not load objects which are outside visible area, so spawning an object at position -9999, -9999 won't work. Also invisible objects are not being rendered. So you need to do some kind of dirty trick like:

a) spawn object at any position

b) set it's opacity to 1 (almost invisible)

c) set it's position to overlap visible area (it doesn't have to be the middle of the screen, it can be partially visible somewhere in the corner)

d) wait 0.017s (that's the duration of 1 tick), not sure if this's gonna be needed but I believe it will to force the engine to load/render the asset

e) set it's position somewere far away

Might look complex but if you prepare good generic code then it's just a matter to setup some lines in event sheet for each layout.

You should not rely on UID, instead create a string instance variable - let's say - "instanceName". Give each object an unique value/name. Then pick anyone you want by System -> Pick by comparison.

Yes, that's precise. Thanks — Also worth to mention that it is the same with toggling groups placed in separate event sheets. If you include event sheet below "toggle action" it will take effect in the same frame, if above then next tick. It's common that event sheets are always included at the top (then toggling always takes effect next frame), but it actually matters where you include them.

Not sure which one is respected if you include the same event sheet multiple times in various places but I guess it's the first one.

If you hardcode an encryption key in your C2 apk, they just have to look into your source with apk http://www.javadecompilers.com/apk and they can find it and decrypt anything you encrypted

That's true, but there's already a need for source digging, so it's much less "hackers". Still you can make combined salt key which will discourage another part of "hackers". But after all it's a client side... the app is in player's hands so smart guy can do whatever he wants. Again I wouldn't worry about this minority. You will spend more time/money by trying to secure your app on this level than by letting them cheat a bit.

Ok thank you all for the replies.

—

I wonder, the groups. I use groups but just for the cosmetic reason, to make it look better in the events page.

I do not have any runtime actions about groups. So the events inside group should simply be run top to bottom, right?

If you're not toggling the groups then your code runs top > bottom all the time. Active groups do not affect anything, no worries .

If you trigger a function before any other event, engine will first execute the function and then go back to your events. So it will not run the function asynchronously. Otherwise we would have really big problems with building our apps. But if you use groups then there's a different story. Unlike triggering the function, toggling a group takes one tick. So if you activate a particular group, code which is under this group will be triggered next tick.

Here it is fixed in the way you started: https://drive.google.com/file/d/0BwT_0lczDpc9Vndva1ktMlgtUnM/view?usp=sharing

But just FYI, it is not the best approach for a flappy bird. You should use platform behaviour for the bird instead of physics (physics are much more CPU consuming, so use it only when you really need physics behaviour). Also background should move infinitely and player should remain in one position (X position I mean). So you just make an illusion that player is moving forward.

There is an example template built-in in C2, you should check it out and investigate. That will give you a better picture.

I'd agree in a way with newt and — You shouldn't worry too much about hackers. I'm not saying you shouldn't secure your app at all, but just don't freak out. If you want to secure it completely, this will be a neverending fight as they will find a new way for your new securities all the time. If you both (hacker and you) get stubborn enough this will be a ping-pong game between you both.

So I suggest to secure it from the noobies-hackers and kids with some cracking soft and that's it. They are the majority of problems. Real hackers which dive into your code and search the way to bypass your security are really minority. And well if they struggled to do it... take it as a complement, it means your game was worth a hassle.

From my experience, the noobies-hackers are less than 0.5% of your game users. In my case it was 0.2%. The real hackers are far less part of your game community.

Now keep in mind that most of the noobies-hackers have no idea about anything related to development. Someone showed them a tool and they simply use it. So if you want to get rid of kids who make direct changes in your storage, simply encrypt the data - this step should already discourage most of kids.

For data encryption you have to use some two way hashing algorythm like Base64. So you could encrypt and decrypt data. Also don't bother to encrypt/decrypt all the values separately. You can use one LocalStorage key "gameData" and save there encrypted Dictionary JSON which you can then load and decrypt on game start. In that way "hacker" will see only one local storage entry containing some mystery hash and you will have your data loaded in RAM memory.

You can go a bit further and give some salt to the encryption process in case there is one smarter kid who heared of Base64.

Much more secure would be to have all data on your server in some database and sync this data each time user spend resources. But this is pretty complex to do for someone who is not experienced in PHP/MySQL or any other backend technology as you have to secure your data transfer as well. If you have time, then go learn it, backend technology is very useful and fun, if not then encrypting storage should do the job for kid-ackers.

Backend part for such a tool is really nothing fancy. If you make it with some lightweight framework (or even just some libs) and cache it with APC for instance then you can handle pretty anything. It's lightning fast on an average server with some decent amount of Apache forks available, so I wouldn't worry about the PHP.

Thanks for your opinion by the way .