Feels like you're headed down the rabbit hole with the memory management bit.
You have to take whats doable for both webgl, and canvas into account.
Rex's solution deals with that to some extent.
newt Ideally the layout data would not be parsed, but split into separate files based on the layout zones. I'm not sure how Ashley would feel about that, though.
rexrainbow I would prefer to see an official implementation of this but your plugin certainly looks promising. I'll have to look into it further.
EDIT: Ok I've been messing around with the GridFreezer plugin for a while now and I'm not sure if it's really a suitable replacement...Unless I'm missing something...
-You can only store one object type per GridFreezer instance, and have to specify it with an event.
-Your "rooms" have to be the same size.
If there could be a way for it to store all objects within a room instead of specified instances, and a way to for each room to have its own size, then it could probably
This is what I managed to come up with.
Notice what happens when you change the size of a room. Not really sure what to do about that.
This topic has two sides to it. The I don't know how to transition rooms/ layouts side. And the we need better memory and world managment side. I'm only going to talk about the memory side of things. As that is my main concern.
I feel no matter how you look at this, it will boil down to data driven world creation, be it arrays, dictionaries, xml, in the end it does not matter but some sort of room storage would need thought up. For the non-technical just ignore that sentence.
But with data driven creation the issue becomes the textures and memory.
One big concern of mine, is how will textures be loaded and destroyed from memory? A big part of this is being able to create and destroy the world. I can see how the cpu/gpu get immediate benefits.
But issues I come into with my own projects, cpu and gpu issues are easily avoided with dynamic data driven creation/destruction. Strings stored in arrays, or xml parsing.... But memory is where everything falls apart.
If the layout has 200mb of sprites and textures, it keeps those available even if not being drawn. If we have dynamic creation that "rooms" is hoping to achieve, we need a way to load different textures per chunk/room as needed. Without that, everything is pointless. You get a large map of different environments and we can do nothing to optimize.
Loading/destroying textures can have performance issues where people have to take a moment to pause and load new textures. Think minecraft chunk generation, very similar concept.
Having to load/unload/reset the entire layout for a room change sounds terrible for performance and gameplay reasons. layout load region as you described sounds like a performance killer with larger more complex worlds taking longer and longer to load each time you need to go to a new room. I can't see layout zones being a good strategy in the long run.
It sounded like they would load the entire layout, choose that region, and destroy everything outside the region?
An "easy" solution is honestly if layouts had better transitions or options on how they interact. A layout is a room. Does everything a room does as is being discussed but without the redundancies. If these could transition nicely and had ways to better work together between layouts this discussion probably would not be taking place. Memory and textures would be handled. Rooms/layouts would be easier to chain together in nice seamless ways.
The above "solution" does have its own set of problems though. Such as segmentation of level design.
Thats why I mentioned the entire array topic. It would do EVERYTHING you guys keep talking about. Without the redundancies of being a handicapped layout.
Aphrodite described the system I previously talked about rather nicely.
The "Room" simply needs to store object locations and types/ statuses like a container(array).(all of which is currently possible, simply the room object would make this easier and visual)
Drag the items into the room, a layout like object and it will remember where everything is, and what all the behavior states are set to.
In the event sheet, that room object would be called. When you do, you see all the objects events inside of that object. This gives easy control over that specific room.
Because all the objects in a room are associated with the room, you can destroy the room(or create) and all the objects also get destroyed(or created) Just like an array, you can modify, delete or add objects to the room without deleting or affecting the rest of the room.
Whatever the solution. Textures/memory still remains an issue.
For those set to believe I simply don't like this idea or what have you...
No it does not replace arrays. No rooms don't replace layouts. There is in fact a visual and code disconnect, most of what is being talked about can be done, simply not as easily as it could be. Get that self deluded fantasy out of your head. And stop going in circles about issues Nesteris not understand something I describe is one thing, continuously placing false words or beliefs into my mouth is something entirely different. I'm not against this idea of "rooms"...I fully support it, and would advocate this is an essential feature that MUST get implemented at some point. However, I want it done right. So yes, I am going to talk about all the flaws I see in it. Anything that I can see holding some1 back or creating a limitation I am going to bring up. If solutions to the flaws cannot be thought of, the system will be pointless.I don't want a half thought out feature implemented. Would you get in an airplane without landing gear? Sure it flies. But at some point it will come crashing down.
Like turret behavior, rex_grid_freezer plugin could listen more then one object-type (but I had not tested multiple object-type yet).
The room - or "logic mask" in my plugin is configure-able. The size could be changed. You could also use hexagon grids in my plan.
Basically the room/logic mask is configured with a little larger then view port.
I get glitches when I preview it in Node-Webkit, all the graphics look fuzzy.
When I previewed it in Waterfox it works normally but all the red lines from the 9-patch are either missing bits or popping in and out, also when I move from "room" into the next the previous area flashes for a frame or two.'
Also sent you a PM.
Alright, my apologises for misinterpreting your previous comments. As for the current ones.
[quote:o1okcbye]Having to load/unload/reset the entire layout for a room change sounds terrible for performance and gameplay reasons.
We're not resetting the entire layout, only parts of it.
[quote:o1okcbye]Layout load region as you described sounds like a performance killer with larger more complex worlds taking longer and longer to load each time you need to go to a new room. I can't see layout zones being a good strategy in the long run.
This might be different since it's a 3D game example, but Metroid Prime actually did the exact same thing you're saying is a bad idea.
You only had the room you were in loaded into the game and the rooms that were adjacent to it ready to take the player. The rest didn't exist. The loading of the rooms and such was hidden in the transitions i.e. The time it takes for the doors to open when they need to.
[quote:o1okcbye]An "easy" solution is honestly if layouts had better transitions or options on how they interact.
Yes it would be nice, but sadly they don't so here we are. I am with you on that though.
[quote:o1okcbye]The "Room" simply needs to store object locations and types/ statuses like a container(array).(all of which is currently possible, simply the room object would make this easier and visual)
Pretty sure you just perfectly summarized what we want the Room Object to do.
[quote:o1okcbye]And stop going in circles about issues
not understand something I describe is one thing, continuously placing false words or beliefs into my mouth is something entirely different.
I apologize but I do remember you saying:
[quote:o1okcbye]if that means sacrificing local variables. And removing layout persistency I am fully against the idea. Layouts would be obsolete
But anyway let's shake hands, be friends and not argue about things that will just waste time.
The important thing is that we both want this "Room Object" in Construct 2 and that it's done right.
However, do put words in my mouth and try to make me out to be the bad guy, you did say you were against it (something now the opposite) and I quoted what you wrote, if you want the link to that comment or even a screenshot I'm happy to provide.
And at first you advocated using arrays instead of this. So do not try to turn this against me.
I came up with the Room Object idea in the first place too :3
What I'm try to do at this point is just help facilitate Tokinsom and the other greats to help improve upon the "Room Object" idea, so let's stop pointing fingers and do that instead. I left supposedly "putting words in your mouth" as you put it alone in the old thread, I suggest you do the same.
Since you obviously have experience making plugins, could "Room Object" be made into a plugin? Might be less hassle for Ashley
Just an idea.
As for any confusion, I apologize.
Is the request to bind instances on a "room", to create them or store/destroy them together?
[quote:2mo6oayy][quote:2mo6oayy]Having to load/unload/reset the entire layout for a room change sounds terrible for performance and gameplay reasons.
[quote:2mo6oayy]1) Re-Load layout zone (x1,y1,x2,y2)
2) Destroy all objects outside layout zone (x1,y1,x2,y2)
I was referring to this which seems to imply having to load the whole layout, and destroy everything outside the zone.
That would make each room change become a full layout load, and need to destroy potentially many objects outside the zone.
[quote:2mo6oayy][quote:2mo6oayy]Layout load region as you described sounds like a performance killer with larger more complex worlds taking longer and longer to load each time you need to go to a new room. I can't see layout zones being a good strategy in the long run.
The issue is Construct still holds all the textures in memory. Even if a "room" only needs a grass zone sprites. The game still has the grass+arctic+interior+any other graphics the layout uses loaded in memory. If the idea is to have multiple rooms, this means many tilesets potentially being used. We meet very similar issues we already face. CPU and GPU load will go down, but memory usage would go up until people keep reporting games are crashing. You could have 60fps on a device with enough memory. And an instant unexplainable crash on a device with too little memory.
This is why a plugin won't work.
hopefully I'm wrong about how construct works and how memory is managed in layouts, but this is why it would have to be internally changed by ASHLEY.
[quote:2mo6oayy]if that means sacrificing local variables. And removing layout persistency I am fully against the idea. Layouts would be obsolete
I am against that. I don't believe creating a layout inside of the layout is a solution. And that was the route things were headed in the other discussion. Many of the "features" being discussed were not necessary and caused many redundancies.
[quote:2mo6oayy]But anyway let's shake hands, be friends and not argue about things that will just waste time.
[quote:2mo6oayy]However, do put words in my mouth and try to make me out to be the bad guy, you did say you were against it (something now the opposite) and I quoted what you wrote, if you want the link to that comment or even a screenshot I'm happy to provide.
I support the idea, but was against the implementations. This thread has deviated away from the implementations of the old thread so I couldn't have been too crazy to think the implementations or direction discussions were going were less than ideal...
I still advocate arrays can do this to an extent. Memory issue aside, you can create and destroy entire levels/rooms stored in arrays/xml. Doing so is simply far more complicated than it needs to be.
1) Re-Load layout zone (x1,y1,x2,y2)
Yes, they are the main ideas of my rex_grid_freezer plugin.
The problem is - how to indexing the saved instance for better performance. I split whole layout into grids, to save instances into these grids or load them all in a grid.
It might not fit your request I guess.
[quote:39e70516]Is the request to bind instances on a "room", to create them or store/destroy them together?
Whichever saves more memory. Maybe you could think of a room as a customizable pre-set that you make.
I.e. Room Preset 1; Contains Missile Power Up (Persistent so it disappears and can't be farmed.) Enemy A and Enemy B.
Say the player went into this room, the missile and A-B enemies are here. Player takes missile and kills enemies A-B.
Player then leaves and re-enters, Missile is not present but Enemies A-B have been reset/respawned.
I think I'm just making it overly complicated, this might be better explanation;
Stores the binded instances on the room, when the player enters the room they're created, when player leaves they're destroyed.
Hope that was simple enough. I'm just pure bad at explaining, but that's why Tokinsom exists.
Ok I need to point out that this method of dynamically loading/unloading parts of a greater layout IS NOTHING OUT OF THE ORDINARY. The whole reason I pitched it in the last thread is because Megaman X: Corrupted (and likely many, many other games) does it flawlessly. THE ONLY DIFFERENCE is that game's editor seems to save rooms in individual files, and textures and such are loaded/dumped on the fly (C2 should probably give you more control over this anyway).
Obviously we have to work within the confines of C2 until Ashley decides how to handle this, but it doesn't seem like anything too complicated to implement.
Finally, we do not have all the answers, but we have most of them. Less problems, more solutions!
Tylermon You have valid points but also misunderstood part of what I was saying. No, the whole layout is not loaded and the rest destroyed every time you change rooms...Instead, only one room is loaded, and only one is destroyed. This can be changed to more depending on the game type, but would likely never be above ~5 rooms at once, which isn't that big of a deal. As for memory, I guess we just need a way to dump it manually, right?
Nesteris The very first event sets the layout scale to 0.5 to view areas outside the current room (for testing). No bugs there. Just disable that event or increase it to 0.8 or something.
Develop games in your browser. Powerful, performant & highly capable.
Thanks, 0.8 actually did fix the red bars showing up weirdly, chucks of it were missing before.
Also [quote:2m3l7wbd](I can show you exactly how I did it in my ZM engine; it's really not that hard...I was just being stubborn and didn't want to hand out my code, but I don't care now.)
Could I please see it? Been wondering about that and the player animations. I PMed you my email.
Thanks, I had fixed this plugin bug and fixed the capx, too.
Download rex_gridfreezer plugin and download fixed capx at this link. This capx is pretty cool, thanks for sharing.
Sorry that I had not tested the case of adding multiple object-type.
I had played this capx.
The "room" will be created when player moves across boundary, it might not be smooth while player is stand at the boundary, only half of floor had been created.
I tried your suggestion, I think that either you broke it or it doesn't work on my computer.
When I open it in Construct 2, it looks normal;
Then I go to preview it and get this;
I then click okay and it looks like this;
Any idea what how to fix it?
Tylermon Unless I am wrong, objects will get loaded only when created if they are not physically in the layout view, however, what I am unsure about, which is also the main problem in theory of the current methods, is objects that are created only at runtime, do they get unloaded from memory when destroyed? (I remember seeing that indeed, in the case of created at runtime objects, they will be unloaded when they are destroyed, could be wrong though, but as long as we have no confirmation, we are making assumptions only.)
My idea of room objects is that it will create the objects at runtime, not by default, and som unload If my interpretation of it is the good one.