kayin's Forum Posts

  • Yeah I mean making a list of like 700 objects is a pain but it's a doable pain. Any way to rip a list of object names out of a cap? (I'd have a much easier time excluding stuff not to save, but it's not a huge deal).

    Curious to hear what the 'not quite actually an object' issue is though.

  • http://kayin.moe/forrojo.cap is a stripped down cap where the issue still happens. The iteration error I think is because I named my family "save" >_> Maybe not the best call.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Actually I fixed it. The problem was I had no edit box... which I didn't realize until I deleted the one layout with an edit box (which gave me a different error which helped me realize I need to remove that one line of code). So it works! Besides the family stuff, but that's a good sign.

    If I try and use the same family I get...

    File "<string>", line 1, in <module>

    File "<string>", line 9, in save

    TypeError: 'function' object is not iterable

    or like

    TypeError: 'NoneType' object is not callable or something like that which might have to do with things in other layouts? Not sure.

    Edit: Another major issue seems to be that the other instances of an object don 't seem to actually exist? So for example, take your cap and set it so sprite rotates slowly... So then you'll have 3 spinning boxs, but once the load happens, only one of them will spin.

  • If you want I can package up stripped down cap of a stage with my current implementation of it. for testing?

    Families "work". If I make a new sprite on your test and throw them into a family and save the family, it "works" but it doesn't get the individual objects right (Like having a bunch of grey boxes and a green box in a family, it'll save, but all the boxes will be grey boxes when it loads).

    As for accessing memory --- requirements aren't a big deal and if you're willing to do that, that'd be AWESOME but they are things within my power to work around so if it's a pain in the ass for you, well... just know they're not problems that are going to muck me or anything.

  • Sadly getting a lot of errors trying to get this to work with the test implementation.

    I get this when trying to save even a single object on a relatively empty layout with the game. I had to rename some stuff and kill some families to get past some other python issue s(gonna have to track down those cleaner scripts) so could it be left over from that?

    Second issue... Any way to get this to work with families? It'd be way easier to add everything to a serialization family than have like a list of 700 objects or whatever. I mean, I''ll do the list if I have to, but that'd be way nice.

  • It can't save instance variables? Thaaaaat's annoying but I guess I can work around that too (not too many that have variables, so I can just use a sprite object overlapping them on startup to give variables or something). Collision mode is annoying but like I said, I guess I could do some gross "opacity 99" or something to indicate non-colliding. Never use gradual opacities for anything anyways.

    So... this is manageable! And as such, R0j0... you, as if you didn't know already, are amazing and I just have to thank you for TIME and TIME again, helping me with stuff and allowing me to get the most I can out of a project that has taken years. I really can't thank you enough for your help and support with this long dead editor. ;_;

  • Hashtable load speeds = immediate. AWESOME. This is getting quite reasonable.

    Doing a few things shouldn't be too bad. I'm pretty sure sprites and tiled backgrounds are the only two object types that need to be saved.

    edit: Yeaaah I can see that being a problem now. Especially the 'next tick' part (spending 6000 ticks generating a level is no go).

    I'm trying to do a thing where I make another set of hash keys with like oid : x : y with all the other parameters to try and identify things and run through that list the next frame, but for whatever reason that has problems too (size mismatches on random objects and such. Enough headbanging for tonight. Especially curious if python could help with any of this. Anyways, thanks for all the help.

  • Awesome, thanks everyone. Interested to see what you have in mind, r0j0

    So my 'objects as huge string' experiment was massively successful. Load time is like a second or two. Gotta figure out selection too for handling things like width and height. Creating objects by name/oid doesn't seem to do selection, sadly? But I'm sure there is a way to do most recent object or something?

    Anyways, works at a reasonable speed. Also sad that there is no expression for visibility either. That is a pain. (Though I guess I can work around that one fairly easily) I could wrestle some edgecases if I have to though.

    I suppose I could do something goofy and set tiles that are non-colliding as like opacity 99 or something. It'd be a pain to track all that shit down but I definitely could.

  • Heeeey 9 seconds to load a level (excluding a lot of details and important variables and whatever). That's.... not good enough. And I'd say I'm on an optimal system (reading off an SSD and stuff).I'm guessing the ini plugin is the bottleneck here but who knows. I might be asking the impossible out of poor construct.

    Bloated EX issues add like 20 seconds or something to the booting of the game, but that seems preferable to slow loads every death. Maybe if I do all the object attributes in single strings I can cut down on reads and speed things up. Gonna try that next.

    I think this direction might be boned though because I realize there isn't a way to detect collision settings, which I use very very very frequently. =/

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