Construct 0.99 released (UNSTABLE)

[Arima]

Is there a way to keep layouts from being unloaded? I have a town layout and a shop layout that I want to be able go between without pauses, but while I can load the shop's textures at the start of the town layout to get a pauseless transition from town to shop, it needs to reload not only the town when I exit the shop, but the shop again after it was automatically dumped from vram. Telling construct to load the town textures upon entering the shop doesn't help much either.

As far as I can tell, there are two main settings - load textures at startup or per layout, and then there is more control using the load/unload layout textures action, but I can't use load all at startup because there's too much and per layout automatically dumps stuff from vram that I don't want dumped.

I would prefer a setting that would load stuff at when a layout is loaded, but not dump it from vram. Also, a 'clear all vram except current layout' action would be handy so you don't have to list all the layouts you want to unload.

[Ashley]

If you set a layout to load on app start, with the application setting being load per-layout, that one layout is loaded at startup and isn't freed until the application ends, so it never frees the VRAM. Does that help?

[Arima]

Not in this case. I don't want to load anything other than the currently needed layouts when the application loads and runs because the game is using a lot of vram - I can't keep lots of unused layouts in VRAM like that.

If a person loads a game past that town, I can't know if they'll go back to the town or not. Then what about the next town? I'll need to basically have everything that needs instant transitions wasting vram, and there's a good chance that all of that combined with the current layout will be more vram than a lot of people have.

I might be misunderstanding what you're saying though.

[deadeye]

Here's something I found that was odd, but I don't know if it would necessarily qualify as a "bug" exactly...

Check out my burst.cap (located in this thread).

In v0.98.9 the swarm of sprites looks like this, all nice and evenly distributed:


But if you run it in v0.99 it looks all lopsided like this:


It's like the sprites are favoring the right side of the swarm, as though they're choosing to turn in that direction more often. It's kinda weird, but like I said I don't know if this is what you would call a bug, or what might have been changed in 0.99 to make it do that.

Edit:
Whoa, I just noticed there's actually a big difference in the way the images are rendered too. The 98.9 version looks more, er... compact. If that makes any sense. The 0.99 version definitely looks like the alpha on the additive sprites is spreading out more. Strange.

[Crystal]

For the render, I prefer your 0.99 sample, alpha and additive blende are better than the 0.98.

But, yes in the 0.99 example, they are pushed on the right...I don't know why.

[Glamthaus]

I love you all. Seriously. You just simultaneously solved about all the issues I had with making a 3D engine in Construct.

I'm going away for the week, but damnit, when I get back, its 3D game engine making time!


EDIT: Honestly, all it needs is a rotation matrix and a way to import meshes. Two things I've already done (or mostly done, for the meshes) in Construct anyway. As I said in the beginning of the post, I love you all.

[MikeD]

Awesome update ! Can't wait to grab the stable version of this

[gammabeam]

Hey guys! Create update!
The Z elevation is so cool!I'll think of something to use it...

Yet, I've run into a strange, simple... bug?

On this new version, if I simply create a sprite and then rotate it on the editor, the sprite gets misplaced on certain angles.

Is this happening because of some new feature?
It was my first attempt at creating something on 0.99

//EDIT
Another bug report (but I guess someone already mentioned it): I imported a .cap from 0.98 and the player controls weren't working. I went to the events and found a "Player %1 "Run" is down".
The "%" symbol was messing with the event, but simply double-clicking it and pressing Finish got it corrected.

[konjak]

Great work guys!

Maybe it was stated and I missed it, but does the Z-ordering make the objects "parallax" according to the scrolling. Like if they're closer they'll pan faster, and the opposite.

[Ashley]

gammabeam: those are both known bugs, the former is fixed in the next build.

konjak: try it. It should do that