Encryption of graphics files

For questions about using Classic.

Post » Sun Apr 04, 2010 6:36 am

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.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Sun Apr 04, 2010 7:03 am

Mipey - I thought that's what construct currently does.
[quote="Mr Wolf":211ydkbe]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.[/quote:211ydkbe]
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.
[quote="Mr Wolf":211ydkbe]Construct can't do texture streaming and it has to spawn the objects, it can't just keep the objects "there" without textures.[/quote:211ydkbe]
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.
[quote="Mr Wolf":211ydkbe]I'd really like to see loading that doesn't pause the game for one thing.[/quote:211ydkbe]
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.
[quote="Mr Wolf":211ydkbe]With spawning objects, it is entirely cumbersome and not at all dynamic.[/quote:211ydkbe]
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?

[quote="Mr Wolf":211ydkbe]Edit: What do you mean "unload them when leaving a layout"?[/quote:211ydkbe]
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.
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Sun Apr 04, 2010 12:25 pm

[quote="Arima":1msgk6op]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.[/quote:1msgk6op]Sorry, 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. [/quote:1msgk6op]
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.
B
2
S
2
G
4
Posts: 259
Reputation: 1,968

Post » Sun Apr 04, 2010 5:22 pm

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.
B
2
S
2
G
2
Posts: 372
Reputation: 1,794

Post » Sun Apr 04, 2010 8:11 pm

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
B
10
G
2
Posts: 33
Reputation: 1,091

Post » Sun Apr 04, 2010 9:50 pm

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.
Image Image
B
161
S
48
G
89
Posts: 7,347
Reputation: 66,249

Post » Sun Apr 04, 2010 10:25 pm

[quote="Mr Wolf":2gesp4uy]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.[/quote:2gesp4uy]

I know that's what you meant. I guess I'm not explaining myself clearly enough - my point is that would require a lot of manual coding to tell the game when to stream textures to VRAM, not that construct can stream textures at the moment anyway. Although, I suppose there could be a default "automatic" mode that could have a user definable setting for how far away the object should be before streaming its texture, and it could be adjusted for the max speed of the character.

My point is if you are making something like a sonic game, or a game with teleporting, you could go faster than the textures could stream to the card, so you'd have to set that up manually somehow. You'd have to tell the game when to load stuff - which is sort of what you're doing by creating objects.

Either way, this discussion is kinda pointless, because without the ability to stream textures it doesn't really make a difference.
Moderator
B
87
S
32
G
33
Posts: 3,005
Reputation: 27,397

Post » Sun Apr 04, 2010 11:01 pm

@ lestar. I don't think anyway here is disputing that. But there is a difference from letting the certainty of death come to you naturally and openly waving a weapon at police or jumping off a bridge.[quote="newt":c76ze6gq]Besides there's never been a case where someone stole graphics, and didn't get successfully sued.[/quote:c76ze6gq]Didn't someone in this very forum get their game "reused" and had someone make a profit off it?

I just remembered I made a user custom map creator that uses 999 frames as placeholders for the user to load their own sprites, adjust them at runtime, and it was made to let them set the neccessary values for 3D collision for 2.5 so that it worked in game. I didn't plan for VRAM issues at all with this, but it works in like 1-2 simple events with loopindex and simple image manipulator events.
B
2
S
2
G
4
Posts: 259
Reputation: 1,968

Previous

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 0 guests