I wonder about the ini thing simply because the scope is so big, level wise. Like upward of 6000 objects. I could do python to capture the variables (... can you use python on the currently 'picked' object? Somehow I doubt my life will be that simple but who knows.... evaluated python command maybe? Is there any even vaguely decent python docs on how its integrated?)

But hey I guess I can give this a try without the variables and just see it it can hand;e things with a reasonable load time.

Excellent, good to know! And I have a few people I can probably bug to try and help me with this if I have any problems. Hopefully if this ends in a clean solution, I might end up with something to share, but who knows.

Trying to think about ways I can optimize things and survive in the horrible hellscape which is 'being trapped in a CC project'. Figured if I could export levels and load them I would be able to get rid of that whole 'bloated EXE with 20 copies of the same code' issue. Fortunately if I can't deal with that, with the amount of content left to do, I'll be left with an EXE, load time and ram usage that is embarrassing, but acceptable. But I'd like to fix that.

So the biggest issue with saving anything that I'm having is variables. So plugins like S seem to be good at sucking down a bunch of stuff and saving it, but S doesn't account for object variables from what I tell? Which would make it totally unusable. Then that would lead to the situation where I would have to manually export and load all the variables on everything and that would be an absurdly unacceptable amount of work. So is this at all possible? Would I need to write a plugin to make it manageable? Could it be done in a python script?

One gross method I played with a little bit but doesn't seem stable or safe is using save states. I could get some stuff working but it seemed far too gross and broken to fully consider, but maybe? Current method involved renaming the layout to be saved as what would be the 'loader' layout and then saving it and switching the layout back. It works pretty okay in test caps but getting it to work in a full game is something I haven't tried to do yet because I remember hearing some weird things about saving and loading being a bit wonky and also this being a real hack.

So any thoughts or ideas or other hacks, here? Whatever idea has to be a pretty robust solution. If there is an edgecase there is a decent chance I'd hit it.

I'm not good at math, I'm just stubborn. I don't even remember how I eventually figured it out, but being able to preserve parallax was really important to my project. I kinda went back to figuring out the math a number of times before it clicked. It turned out being simpler than I expected, really, so someone with a better intuitive understanding of math could have figured it out way fast. But yeah, you pretty much got it. Just plug that big long formula in resize into a different family to use on sprites and you can have all your background elements behave with different scrolling (as you assumed correctly.

also yeah PC games seemed to love doing big illustrative frames around games. Always a very distinctive feature.

Alright I got your holy grail.

http://kayin.moe/c1res.cap

This is how it works in Brave Earth. The big trick here is figuring out how handle parallax because for some nonsensical reason, Construct does not calculate that from the center of the screen (I dunno if C2 does this in the not-stupid way, but w/e). Some notes on how this works...

Make your layout big and unbounded. If it's not bigger than the resolution the game is running at the camera gives up on life.

The formula for handling parallax would have to be repeated for different object classes. I kept it to scrolling backgrounds for simplicity. You'd need to make another family to do sprites... which... isn't really a big deal. And you can use this fine with tiles in the gameplay plane and background plane without shit moving around weird.

The higher resolution, the less FPS you get at a rate that doesn't QUITE line up with what you'd expect. For most games you won't even notice though. Kinda an issue in BEP

If you get shimmering with scrolling (Especially if you're like me and end up using a complicated, smoother camera) not related to vsync issues, scroll to your camera's floored X and Y.

I really don't recommend 150 and 250 zooms. 300% onward, 50% zooms become less obvious. Not perfect, but good enough for Shovelknight to run at 1080p.

Besides for weird performance issues in BEP on lower power hardware (in which case, the game can be ran at 320x240 full screened to get max performance), this is the best solution I think you're gonna find.

The only cons here is you get a lot of subpixeling which, depending on how much you care, may or may not be a problem. I don't care about sub pixel positions too much myself, but if you resize an object it will 'break' resolution' in a way it wouldn't at 100% zoom.

You can also use high quality, high res art for the sidebars (and maybe punch out a viewport with the erase effect) and it will show at max resolution which is pretty nice, so you can do stuff like this http://static.gamespot.com/uploads/scal ... 30_004.jpg

Did you get significant performance increase from them? As someone working on a game with no sprite scaling and some performance issues I'd be VERY interested in anything that helps out with that.

Weird. I guess it's just multiple things snowballing together (Because it's only a problem on stages with lots of offscreen content which gets exponentially worse when things get zoomed in.

Sadly stretched doesn't preserve aspect ratio so that makes it real hard to do anything neatly scaleable. Wondering if I could do something crazy like use canvas to grab the screen content and then squish it back to the right size, but dealing with low resolution pixel art, I have a feeling if I did that I'd end up with a good bit of distortion.

Sadly the transferring a five year old project to C2 is kinda out of the question unless r0j0 gets the converter in slightly better shape. If that end up happening, I do not look forward to what a nightmare process that conversion will be on the re-coding and bug fixing front.

Ashley, do you have any recollection about how possible it would be to change things like rendermode at runtime through a plug in because I think optimally Id want to use the 'high quality scaling' mode I made which is a bit slow but fine on most systems, but say, switch to stretching as a fall back for weaker systems.

I don't expect much from this, but since it's a runtime issue I figure it's worth a shot in the dark.

So Construct doesn't use zoom levels to cull what it draws (or so it seems). Running the game at higher resolutions totally kills the frame rate on some systems.

Current implementation for it is to use the 'show more content' and layer zooms and a nice overlay to letterbox or pillar box the game neatly as needed. It's a really nice and functional implementation but apparently it's garbage, performance wise.

Option 1: The easiest option is to just use stretch, make the window snap afterward to whatever the closest multiple is and be done with it, but that really fucks with people trying to full screen the game and stuff. Not great.

Option 2 seems horrible and gross. Allow no resizing (besides menu based resizing which is fine) and then use some directx injection hack to put in a global shader which will magnify that image to the appropriate screensize. I'm not even sure I can legally do that though as it involves distributing hacked DX Dlls?

Option 3: Some sorta horrible manual culling with setting things invisible (Are objects with 0 opacity culled?). Maybe using different layers for different slices of the stage? This is a little messy for a few reasons

Option 4: Hope to god someone doesn't care about noodling with the Construct Source a bit and can change -something-. I don't care if it's a hack or if someone puts in a call for a normal shader at the start of the application so I can at least affect the whole screen. Or if the culling just always assumes a screen size of 640x480 (perhaps exempting certain layer names?). Or really, just any advice with dealing with this might help. What do plugins have access to? Would it be possible to make plugins that toggle vsync and the stretch mode? Could I use a plugin to put in other options? Like, different stretching and resize behaviors?

I have multiple routes for for optimizing the game (all of which I'm exploring) and this is just one of them, but it's one where the things I want to be able to play with seem beyond what construct allows me to do, currently.

Oh hey my friend made me play that at some point and I had no idea it was a CC Game or a Davio game. Was quite fun. But yes, one day we will all be free.

That would be rad. Obviously, Construct Classic, as things get larger, is becoming much more of a horrible monstrosity to work with.

One things with events that could be useful (but maybe too hard to actually do? I dunno how events look in CC source) is converting code to comments? It would at least streamline the process of trying to go through, rebuilding stuff. All the non event stuff would go a long way though. While transcribing everything over would be tedious, it kinda can't be helped anyways since stuff is going to have to get changed anyways. But still, thousands of tiny tiles. ;_;

Just gonna throw out that a few of us are still stuck in CC big projects, so anything that can help free things down the road would be appreciated. Even if it is just breaking a cap up into a bunch of images and stuff.

Granted, I think those of us (... it might just be me and Konjak at this point?) who are stuck this deep probably have the capability to sorta... brutally export stuff in a sloppy manner through construct itself, but just being able to get graphics and layouts into C2 would do wonders for the possibility of porting large-as-fuck projects.

This can happen for a whole bunch of reasons that I can't even remember, but try deleting the xaudio object if you're using. If that's the problem, switch to audiere.

Generally the process you should use is to eliminate objects until it doesn't crash. When I'm trying to figure out something like this I make a new save and just shred the game until the problem stops. Then I can figure out the source and fix it.