Encryption of graphics files

I've concluded its better to load the files at given time from HD instead of keeping them all in frames of animations in VRAM and that's what all the heavily graphical 2D games I've played seem to have done - and is problably why they are so easily ripped. Anyway, what encryption method is available to Construct to make it so it's at least marginally difficult to rip?

Construct only keeps the current layout in VRAM unless you change that setting. Constantly loading everything off the HDD on-demand doesn't seem to be a good idea as constant HDD use is never good. Storing some stuff in regular RAM would be a great feature IMO if it works like I think it does and there'd be no HDD searching/reading.

I have more to say on this, but I'll wait for your reply. There's a topic in the Construct Discussion about lots of frames and animations and stuff that is directly related to your issue.

Loading an image at runtime still uses VRAM. In terms of VRAM usage, it's no different than having it stored as an animation frame. Construct loads it once to VRAM the same way all other textures are loaded to VRAM.

The only benefits of loading images at runtime instead of having them as part of the cap is it makes it quicker to preview and save, and if you want to update your game and save bandwidth/download time, the players don't have to re-download all the images they already have.

I don't mean loading every tick. I mean loading per outfit and equip change that alter animations or appearance - which is what I suspect all those MMOs are doing with their hundreds of customizable equipment. Instead of a exe, I see folders of large files that is assumable to be graphics and music. Most of the time the exe is tiny in comparison.

So how does one encrypt those files like those games do?

I don't mean loading every tick.

I was referring to Mr. Wolf's comment about constantly loading from the hard drive, though upon rereading it I might have misread it.

Sorry I forgot to address your original question - I've heard lucid's 's' plug-in has encryption, though I haven't tried it.

Sorry for confusion. I read that thread and I'll look into taking advantage of a separate layer. Due to simplicity of eventing, I like to use one animation with large number of frames so that I can use the loopindex as much as possible. With use of the Image Manipulator, along with separate layers, there should be a way to keep all frames in the exe - while still keeping the same ease of eventing. Regardless, encryption is still an issue I'm bound to come across again, so I guess the question will still remain. Which Lucid plug-in BTW? He's made like 100 since I last checked here.

Loading an image at runtime still uses VRAM. In terms of VRAM usage, it's no different than having it stored as an animation frame. Construct loads it once to VRAM the same way all other textures are loaded to VRAM.

The only benefits of loading images at runtime instead of having them as part of the cap is it makes it quicker to preview and save, and if you want to update your game and save bandwidth/download time, the players don't have to re-download all the images they already have.

I know that, I was referring to a sort of "on-demand putting into VRAM." From the other topic which is kind of related to this issue, I've found out that everything is stored in RAM until it's loaded into VRAM when you load the layout. I'd like to be able to decide what gets loaded into/unloaded from VRAM better. My post was a little unclear, sorry.

manontherun - That's sounds like Asset Streaming. 3D games really use it. It loads on-demand what it needs. That's why there can be a little delay before your character model changes.

Unfortunately, Construct is very limited with how it can use resources and a lot of features that 3D game engines use (and can really be in 2D games too!), aren't in Construct. Construct was originally made to just run everything from a single .exe. It is not a good practice and a lot of people don't like it, so the whole encryption thing is a hot topic.

Sorry for confusion. I read that thread and I'll look into taking advantage of a separate layer. Due to simplicity of eventing, I like to use one animation with large number of frames so that I can use the loopindex as much as possible. With use of the Image Manipulator, along with separate layers, there should be a way to keep all frames in the exe - while still keeping the same ease of eventing.

Separate layer? What do you mean by that? Objects being on different layers won't affect the VRAM usage, if that's what you meant.

If you put all of the graphics into one animation, construct will load those all at once. Construct loads textures on a per object basis. Create an object, and construct will load all of the textures for all of its animations. To break things up, you can categorize the graphics by object - have a sprite for level 1 section 1, for example.

As for the plug-in, it wasn't a typo - Lucid's plug-in is named "s".

I'd like to be able to decide what gets loaded into/unloaded from VRAM better.

As mentioned above, you can sort what you want loaded by objects. Construct will simply load all of the textures for all the objects in the layout. If you create an object from another layout, it will load the textures for it then.

manontherun - That's sounds like Asset Streaming. 3D games really use it. It loads on-demand what it needs. That's why there can be a little delay before your character model changes.

If there's a pause, I don't think it counts as real streaming - it's simply loading. I think actual streaming is when the application uses idle time to load things, and doesn't complete the task immediately. If there's a pause, that's because the application is waiting for the data.

Unfortunately, Construct is very limited with how it can use resources and a lot of features that 3D game engines use (and can really be in 2D games too!), aren't in Construct. Construct was originally made to just run everything from a single .exe. It is not a good practice and a lot of people don't like it, so the whole encryption thing is a hot topic.

Personally I don't think it's very limited with how it can use resources. How do you think it's limited? The one glaring feature that bugs me is there's no way to have construct load things when it needs to, but not unload them automatically when leaving a layout.

Construct can't do texture streaming and it has to spawn the objects, it can't just keep the objects "there" without textures. With spawning objects, it is entirely cumbersome and not at all dynamic. I'm not entirely sure about all the different definitions of "streaming" and although I could discuss the wording of it, I'd rather not take the time. There's two different things here: 1) The type of loading when you change outfits in a game. Somtimes there's a tiny pause of the character model though not of the game itself, as it changes the model. 2) Only keeping textures of things in the immediate area of the object in VRAM. I would presume they still exist, just without their normal textures. I'm not sure how much of this sort of the loading is normally scripted and how much is dynamic.

Really, Construct is limited with these kinds of things. I do not know all the details of implementing this for Construct, but I'd like to see something being worked on. Resource management is a must in 2D games as they are more VRAM hampered than 3D games. I'd really like to see loading that doesn't pause the game for one thing.

Edit: What do you mean "unload them when leaving a layout"?

Hm, what about reading a single data file on HDD and storing it in RAM entirely, then retrieving compressed images from that image on request? Sort of like .zip file with all images stored in RAM. I figure that'd require a plugin.

Mipey - I thought that's what construct currently does.

I'm not entirely sure about all the different definitions of "streaming" and although I could discuss the wording of it, I'd rather not take the time.

No real discussion needed - streaming means the application doesn't pause when loading data, but you don't get all of the data immediately. Like streaming music.

Construct can't do texture streaming and it has to spawn the objects, it can't just keep the objects "there" without textures.

I'm not quite sure - are you saying you want construct to keep the objects there without their textures?

I assume you mean you would want to be able to place the objects in the layout and not load the textures until they're needed, but you'd still have to tell construct when to load them. Otherwise, simply having them load when they needed to be rendered would result in tons of little pauses as you play. That's why texture streaming in some situations would be awesome.

Even then, though, texture streaming only works when you can predict what you're going to need, and I'm not sure there's any way to do that automatically. What if you switch to a different animation? How would the game know you were going to do that? How would you know the player was going to do that? You might be able to tell if the player was going to teleport somewhere, but you'd have to program it manually, which would be a similar hassle as the way it works now.

Otherwise, there are three options - one, keep the game playing but without the textures. That would make the game rather hard to play when the hero turns invisible because he can't be rendered! Two, wait for the textures to render the screen. Causes constant pauses. Three, load all of the textures for all of the animations the object has the same time, resulting in one pause and no rendering issues. I like option three best.

I'd really like to see loading that doesn't pause the game for one thing.

The real issue is this is a hardware limitation. Getting a texture from RAM to VRAM isn't as fast a process as it seems like it should be. You could buy the most powerful gaming PC on the market and still get these pauses. While some games are able to mask this, as I understand it it's by cleverly streaming textures as the player goes from one area to the other and requires a lot of manual programming to do so.

When you load textures from RAM to VRAM, the computer has to send the compressed texture from RAM to the processor, decompress it, and then send it to the VRAM on the graphics card. That process isn't actually all that fast, and that's what causes pauses when loading textures.

The only thing that could be done about it in some cases is implementing texture streaming, but again, it still would have to be more of a manual process than you'd like. If the game suddenly needs those textures, there's no way around it - the game has to wait for the textures to get from RAM to VRAM, and the only solution for that its better hardware.

With spawning objects, it is entirely cumbersome and not at all dynamic.

I guess I'm not sure of any better way to do it. Construct loads graphics for sprites as they're needed - how else would you want to work?

Edit: What do you mean "unload them when leaving a layout"?

When you leave a layout in construct, as long as it's set to 'per layout' construct dumps all the textures of the current layout and then loads all the textures of the next layout. This can be annoying because if you want to jump back and forth between two layouts, there's no way to get construct to leave the textures for both in memory at the same time. You can eliminate the pause going from layout a to layout b by loading the textures for layout b at the beginning of layout a when layout a is loading its textures, but as soon as you go to layout b, it dumps the textures for layout a. Going back to layout a will result in a pause. The only thing that can be done about that is to make everything global and manually create and delete everything.

Separate layer? What do you mean by that? Objects being on different layers won't affect the VRAM usage, if that's what you meant.

orry, while being distracted I confused layers with layout.

Anyway, by keeping the models frames low and using the Image Manipulator to attach correct frames for correct equipment from the long list of frames in another layout, will allow less use of VRAM during rest of the gameplay. The limit to this is I can only switch animations during Inventory screen and not dynamically during all the action. If there where some way to communicate with the another layout to retrieve the small amount of frames I need during that time. Such as making a certain amount of frames global dynamically at runtime, or tooling with another object not in VRAM so I can have the frames I want ready, or something. Then there possibly wouldn't be a pause. Not sure if that's possible though. Would be cool if I can mess around with layout 2 while I'm in layout 1.

It seems currently I might still need to load the frames from HD - so some way to do encryption might be needed. Thanks for the posts guys. Interesting topic.

[quote:1msgk6op]@ manontherun - That's sounds like Asset Streaming.

How does Big 2D RPGs and MMOs do it? Such as Dungeon Fighter and Ragnarok. The unpacked folders of those types of games are riddled with hundreds or thousands of 32x32x/64x64/128x128 animations. Same as 3D? I think they just manually refer to each new sprite and don't load the rest but not really option for me. I use loopindex and want the frames to work with the rest of the events.

Arima, you aren't quite understanding which textures would be put in VRAM. Let's say you have a huge game level or world. All your character animations and everything around you is in VRAM. As you walk through the world, everything X distance around you gets put into VRAM and stuff beyond that is dumped. I'm talking about that sort of thing. A lot of 3D games use all sorts of ways to manage their resources. They are big companies and have tons of people to work on this stuff, so I don't think it'll happen in Construct, but it'd still be nice to have some of this. I'm just going to work with what Construct has since it probably won't change.

I only mentioned the definition of "streaming" because I saw it the other day being used for what looked like on-demand loading of character models, though I may have been mistaken. It doesn't really matter.

manontherun - Their engines were made to do those things. The Construct engine is a generic and straightforward engine. It wasn't made to handle those kinds of things. Diablo II for example, doesn't use full color PNGs I hear. They optimize their engines for what they need.

it's imposible to avoid sprites ripping, there are many ways, ram-vram dumping, exe hacking, or more simple, screenshot the game frames and ripping from images, there is no way to avoid it

Way to hijack a thread lestar... oh wait.

Anyway he's right. If its worth ripping/ hacking, then it will be. Also along with that line of thinking, you could assume that being hacked is a positive sign. Besides there's never been a case where someone stole graphics, and didn't get successfully sued.