kayin's Forum Posts

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

  • Since this will probably never be fixed, this is what I ended up doing...

    ((((displayheight - 114 - (displayheight /2)) - 114) * (1 - (LayerScrollRateY(bk.Layer) / 100) ))-(((global('oldyres') - 114 - (global('oldyres') /2)) - 114) * (1 - (LayerScrollRatey(bk.Layer) / 100) ))) + bk.y

    Replace 114 with whatever half of your default vertical resolution is. Use oldres as a 'detector' for resolution changes (if oldres != display res, run the above math on all the 'bk' objects.

    Anyways basically you put this family on any object that is ever on a parallaxing layer. If an object already has a family, just apply the above math to that whole family. If the object is on a gameplay layer, it'll know and won't move anything. It also doesn't require any variables or anything like that either.

    Obviously this isn't an ideal solution and might not be appropriate for a lot of projects who might require certain backround objects not to move, but it's what ended up working for me.

    Obviously this is an incomplete solution too, so you'll need to figure out the details of your implementation. If anyone really cares, maybe I'll make an example file to show how I'm handling things.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Just use the file plugin. It has a condition just for that. I use it too for the same reason!

  • Kicks is helping me out by the way.

    We're trying to change how parallax works so it's calculated from screen center rather than the top left corner, which would make things like scaling the the window easier while still having everything behave. So any help on this would be MEGA APPRECIATED.

    Also some other things too, but thats te big one. :O

  • The file disappeared when the forum software changed. I think the old files are archived somewhere but I have no idea how to get to them. Honestly that's super old code that probably isn't worth using anymore. It doesn't even run right on the current version of construct in case I recall.

    I'd say Custom Movement is my go-to for customized movement stuff now.

    Sadly I don't have a great way to explain to you how to do things like vertical platforms effectively but there should be some better examples somewhere for that sort of thing

  • Personally I'd be thrilled with an update that was a one liner that was either

    "Layer Offsets work"

    or

    "Option to calculate parallax from screen center"

    (in fact, if any of you can actually build construct and just hack in center based scrolling with no options or anything, i'd love you forever even if it wasn't an official, tested release. This sh*t is driving me up the walls.)

  • Workflow is definitely important. If you're basically drawing your levels and filling them with unique assets, you obviously HAVE To prototype. If you're working with tiles? Of course the disadvantage there is an area someone prototypes might not work as well as expected when 'arted' over. If your workflow involves tiles, you can make good looking places and make sure the composition works out while testing other things. Ultimately everyone needs to find their own workflow that works for their project, but I'd say as a rule, try and prototype in a way that both assures you a level will be cool both gameplay wise and visually. Some people can predict what all the collision rectangles will look like when painted over, some can't. Do what makes the most sense for you.

  • Boxy can be fine. You can do a lot with a box. U shape and C and C shaped levels, Spirals, circles, Vs and ^s, Each screen of IWBTG and VVVVVVV are boxy. It's what you do with the box that is the question! And yeah IWBTG can be fun to learn some of this too because I think a lot of the graphical stuff is hilariously weak (I was just sorta finding my feet with that sort of thing) and the tiles I made my self are kinda awful, but the aesthetic SHAPE of the screens and world are still pretty good. The only thing it has going for it is screen composition, since the elements within those compositions look like they were made in MS Paint. If you're careful about where you put things, even if you're doing it in a boxy manner, you can get surprisingly good results!

  • I build as I go. Full on. Generally I start with a thematic idea in my head and have some idea what 'shape' I want a section of game to be. A sine wave of rooms going both up and down? A 'stepped' progression? Just going straight up? I try and vary these shapes because that maximizes the effects of spatial memory in the player. Flow, pacing and aesthetics are also almost 'fractal'. So while the whole stage might have a shape, each seciton has a shape and each interaction has it's own pacing curve and blahblahblahblah, you don't actually explicitly DESIGN all this, but you FEEL it to make sure the level feels good and is varied. Since I tend to do rather long 'levels', I find it best to not plan too far ahead. I need to have a good feel for how one section of a level feels to make the next. Things rarely come out how I plan anyways.

    Priorities for each game vary but you want to have uniqueness of movement and uniqueness of aesthetic. Aesthetics doesn't mean you have to have new assets in each section, but it means you should try and use the assets you have differently. I find that what I'm ultimately doing a lot is adjusting ratios. If I have a foresty level with some ruins/bricks, some part of the level will be all forest, some of it some brick and one more ruins heavy. Mix that up with things like the direction the player is traveling and a few set peieces, and you can have very memorable stages.

    If you're doing longer stages, go look at Castlevania 1 and Castlevania 3 on the NES and look at how much they do with so little. You can head over to vgmaps.com to look at some of the techniques old level designers use.

    If you're working smaller, go look at Super Meat Boy, which is surprisingly varied for many of the reasons I describe, despite rarely having unique per-stage assets. If you wanna go per screen, look at my game (I Wanna Be the Guy) or VVVVVVV.

    Gameplay is obviously a top concern, but there is no good standard advice I can think of. Conversely, most amatuer games I play suffer from horridly bland level design, even on a movement and visual level. Everything is just samey and bland. Don't be one of those guys.

  • Yeah I'm pretty much ready to put Spritefont to the chopping block too. I wish I could just get normal pixel fonts to display without any subpixel induced sh*ttiness. Anyone got some code sittng around they'd like to share about doing this manually? I pretty much know how I'd go about it, but reinventing the wheel seems less than ideal if someone else has done it better and smarter.