ErekT's Forum Posts

  • I think I figured it out. I had been resizing collision on the collision object to roughly fit with the sprite object animation so when the object landed the collision hull itself got resized. I removed that and it seems to work no problem now. Sometimes I wonder if my brain is too small for game development

    Thanks for helping out

  • lennaert Thanks for the reply It's a good guess but it doesn't seem to be what causes the problem.

    If I set acceleration and deceleration to 0 when IsOnFloor is triggered then the object will slide along the platform until it either falls off the other side or hits a wall. That's to be expected obviously, but it'll *still* slide off the edge it lands near to in some cases. I'll post a couple of images to illustrate the problem better:

    Player jumps:

    And sometimes land just long enough to trigger IsOnFloor but *doesn't stay on the platform*:

    Acceleration/deceleration set to 0 on IsOnFloor:

  • I use a startup layout to create my global objects. This layout only ever gets run once at the start of the game. Maybe that's something you could try?

  • If characters with the platform behaviour land right at the edge of a solid or jumpthru platform they'll slide off it and fall to whatever's down further below. They'll touch the platform just long enough to trigger the IsOnFloor mechanism, which means they'll immediately start falling again but with the landing animation playing. This kinda ruins the feel of my game and I need to fix it somehow. I'm already using very very high values for acceleration and deceleration, 10000000000 or something like that, but it's not enough. Any ideas what to do?

    Sorry about cross-posting and stuff but I really need to find out if I have to write my own platform collision system and the Beginner's Forum doesn't seem to get much traffic so...

  • Hello.

    I'm using the platform behaviour with acceleration and deceleration set insanely high, 100000000000000, to simulate a kind of binary movement; either players move full speed or they don't move at all. No easing in or out. Works fine except if my characters land right at the edge of a platform they'll slip off it sometimes. That's not good. I need them to stay on the platform if they connect with it. None of this slippery slope business please. Has anyone else had this problem? Is there a way to fix it?

  • It's slower than NW 10.5 here too but getting relatively smooth performance at least. The occasional jank. Nothing big.

    The screen tearing though is ugly as balls. Isn't that what vsync is supposed to be for?

    [quote:k794pqf7]It would be awesome if Scirra made it's own custom desktop exporter. Or Monzilla made their own, google has a major tendency to ruin a lot of things.

    Yeah, dependency sucks.

  • 198 updates is practically 200. Come on now

  • Browser.screenwidth & browser.screenheight?

  • Yo!

    Just to elaborate a bit on Aphrodite's explanation. Check these out:

    Imagine that the grid you see here is your target resolution, the one you want to scale your gfx up to. Four pixels; blue, green, yellow and red. So if you have four pixels you want to scale up to a target resolution of 12 then you'll have no problem since 4 pixels * 3x scale = 12. Three pixels per each original pixel match up nicely.

    But what if your target resolution is only a grid of 10? You can't scale 4 pixels up and make them fit perfectly within the 10 unit grid. So, what to do? You can either use go-between values to approximate the way it's supposed to look (interpolation), or just go with point sampling and skip rendering the pixels you don't have room for:

    Interpolation works pretty well but it'll blur everything slightly while point sampling makes everything distorted and ugly since the upscaled pixels have to be of an uneven size now. The third, and imo best, solution is to just use letterbox integer scale. You'll get black borders and stuff but eh, what can you do?

  • I use it because there's a minimum of technicalities to have to deal with so I can just get on with the good stuff. I've tried some others too: Unity, BlitzMax, and Monkey-X. Unity is a convoluted mess (imo), while the other two are very nice. None of them as fast or intuitive to work with as C2 tho.

  • All event sheet code gets combined into a long .js file on build, so it makes no difference how many event sheets you have. Like Spongehammer says, do whatever you feel is more organized. I do short event sheets for individual layouts to control things specific to that layout, like bg animation for instance. Little things that I don't need cluttering up my more general-purpose event sheets.

  • C2 is great as-is but here are two main things I'm missing that I'd love to see in C3: Better asset/object management and more control over project settings in general.

    Better asset/object management:

    I'm sure some of these have been asked for before by others but I'll mention them again just in case. On deleting objects or variables, have an option to keep the events associated with them with some kind of placeholder object. Ability to duplicate objects/sprites so we don't have to build similar objects from scratch. And PLEASE allow us to manipulate sprite atlases from within the editor; it's absolute hell to tweak sprite frames one-by-one when you have a lot of them and batch-processing external images doesn't cut it in some cases, like doing palette tweaks (AFAIK).

    More control:

    Allow users to set things like sprite atlas resolution themselves, control is always nice! Also, some things can only be controlled from the editor project settings right now, like point/linear sampling and WebGL on/off. It would be great if we could toggle these from the runtime to allow settings to be saved to and loaded from an external config file on runtime startup instead of needing separate builds(!) for different settings.

    [quote:2mprls82]The idea here being that C2 files can be opened in C3 (possibly with a once-off conversion or the like), which would encourage existing users to migrate to C3 when the time is right for them

    Oh yes.

    [quote:2mprls82]I totally agree. C2 is still have field to improve. It's a great (and probably necessary) step from Scirra to start planning C3, but don't just hype it yet.

    I agree too but the question is, with the way C2 works under the hood, how many new features can be included? Ashley has already mentioned that some things aren't easily doable without a major re-write, like modularity.

  • 1) I don't understand these people who understimate casual mobile games. If you want to make big desktop game - it's okay. Good luck.

    Mobile has touchscreen controls only. I have zero interest in touchscreen games. And that's why I'm creating for desktop. You don't *have* to go the AAA route for desktop you know.

  • No image atlas. I personally believe that binding the imags to the sprite is the wrong design. Instead images should be atlas by the developer and sprites then reference images in the sheet/atlsas.

    There is no modularity. it's annoying to pop in designed works. I need to duplicate the objects before copy/pasting an event sheet. currently I just have a master game frame work that does a lot of the gui work done.

    Agree 1 million percent with these.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks