I'm not exactly sure from your description what it is you're trying to do, but the layout object has a lot of bugs, so using layers is probably the better option. Why don't you want to use them?

You can press tab enter to close the window. Sometimes it goes backwards though.

Completely missed that thread. :/ Ah well.

At long last, sprite-based text is finally here! 100% through events. Also updated the font splitter to support alpha (didn't realize it didn't before).

One disadvantage of making it 100% through events is that you can't just drop it in your game. Since copying and pasting between projects hasn't been completed in construct, you're gonna have to re-create it.

SERIOUSLY, DO NOT ATTEMPT TO COPY THE CODE OR OBJECTS IN THE EXAMPLE INTO YOUR OWN GAME. DOING SO COULD MAKE YOUR .CAP UNUSABLE.

Instructions are in the .cap. Enjoy!

Http://www.amirai.net/forums/Spritetexttools.zip

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 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.

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.

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.

What I was basing that off of was Ashley's post here: - it would be awesome if texture streaming was possible!

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.

You can swap textures mid-level, but it requires some manual work. First you have to store all of your objects on a different layout from the game level layout. That will prevent construct from loading all the textures at once. Next you'll need to make a level editor, and load the placement of all the objects in the level from something like an array. When you load the layout, create the objects you need for the first section of the level. Construct will automatically load the textures for those and not for the second section. When you reach the second section, in the same frame, delete the objects you don't want in VRAM anymore, dump the unused textures and load the rest of the level from the array and create the objects needed, and construct will load the textures then.

The downside is that you're going to get a pause when it loads the textures for the new objects. I seem to recall that texture streaming isn't possible with DirectX - might it be possible with OpenGL for C2?

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.

Is Windows 32 or 64 bit? I had a friend try to run my game on a 64-bit version of Windows and it wouldn't run. It might've been the SSE bug, he hasn't tried it since that's been fixed, but it's a thought.