oosyrag's Forum Posts

  • It really is hard to tell from the video, it looks mostly fine/smooth to me. Probably doesn't help that the video is recording at 30fps. I don't think it's a big deal on something that the user normally wouldn't be focused on, especially at high speeds. The wheels and train and tracks look great (from the video at least, I don't doubt that it's worse in person as you mentioned).

    I have a minor suspicion you may be nearing the limits of your device, as the fps as shown was at the low 50s and even dips below 50 at the beginning, and you said it looks fine on PC. I wouldn't normally call that a stable fps. I do note that it gets back to around 60 in the latter half, but I'm also not clearly seeing your jank/jitter either.

    If I were to pursue this I would try taking everything out except the foreground plants (especially any physics actors), and seeing if it makes a difference on the device.

    Edit: Any parallax on the layer? Or just varying speeds between foreground and background objects?

    Another long shot to consider - are you updating your debug text every tick? Try disabling the text updates to see if it makes a difference. I've had issues with this before where my debug text was slowing everything down, although mine was significantly more text objects to display the contents of a data array.

  • Personally, I wouldn't target 4k resolution for a 2d game.

    It becomes more about pixels per inch at that point. Most users won't be able to discern a difference unless their screen is huge like a TV or something.

    I'd rather target a larger audience with lower end devices, unless cutting edge, industry leading, high fidelity graphics are a huge selling point of my game.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Got a minimal example project or video? It would be useful to troubleshoot your issue, or for the devs to look into. I've seen jank and jitter mean different things to different people.

    For example, your sprites could be jittering back and forth position wise at 60 fps if there is a positioning issue such as the previously mentioned pixel rounding. It can happen when your camera and object are moving at the same speed but with slightly offset timing. There can also be pinning issues if you're using a pinned camera where the camera position updates one tick later. This can happen no matter how high your fps is.

    One time in discord someone was complaining about their game recordings showing "jank" when running at 60 fps, but it was because their videos were recorded at 19fps or something silly like that.

    It's highly likely your stuttering/jank/jitter has nothing to do with fps at all.

  • Doesn't look like those expressions work. If you need it soon, file a bug report and they'll probably get around to it quickly since they've already been working on the object lately.

    Alternatively just use an instance variable to keep track of the class/id in the meantime as a workaround.

  • There are many things that could be causing performance issues. Having 3000 objects is probably not one of them. Test yourself - downloads.scirra.com/labs/piggyperf

    Are your sprite resolutions reasonable for your target resolution? Try turning fullscreen quality to low and seeing if that makes a difference.

  • You normally do not want to sync or communicate animations between peers/hosts. Have each peer play animations based on the actual movements of each object.

  • Create a "mask" layer above the main layer with the 'Force own texture' property enabled, the 'transparent' property disabled, and the background color set to black.

    Put a sprite object on the mask layer, and set the blending mode to destination out. The opaque areas of this sprite will let you "see through" the mask layer to the layer below. You can set the position of this sprite to the mouse position every tick.

  • A tag is not the object name. You want to put the tag you assigned to that object there.

  • If you ever forget, you can refer to the system expressions page in the manual.

    random(x)

    Generate a random float from 0 to x, not including x. E.g. random(4) can generate 0, 2.5, 3.29293, but not 4. Use floor(random(4)) to generate just the whole numbers 0, 1, 2, 3.

  • Gonna throw a wild guess and say it's because your first column of tiles is only 14 pixels wide while the rest are 16 pixels. Try adding two columns of transparent pixels on the left edge.

  • I don't know the video or specific algorithm you might be referring to, but the first approach I would try would be with a random walker algorithm, where the walkers are not allowed to move into existing tiles (or out of the bounds of the map). If the walker "traps" itself or reaches the exit, then start over, following the same previous path until there is a valid tile to branch into, and continue from there. You can add the constraint of not allowing 4 way rooms, but if you don't allow 3 way rooms either that would be difficult to always arrive at a specific end tile, and it may not be solvable at if there is a requirement for every tile to be filled in. Repeat until all possible tiles are filled or unreachable.

    This should result in a map where all tiles are reachable from both the entrance and exit. By keeping track of the number of existing exits from each room, additional constraints can be added, like only one exit for the entrance and exit rooms.

    So at each step, generate a list of valid tiles/exits to walk to, and pick one randomly, until there are no more valid exits. Then start over from the beginning until a valid exit is found to make a branch.

    The blue x on the second iteration represents the constraint where the first room can only have 1 exit, so a branch cannot be made there. The red x on the third iteration is the constraint that a room cannot have 4 exits, so it can't branch there and continues until it finds a valid tile to branch into.

  • Nope, I didn't. But if I could tell my past self to, I would mention that it's not really all that long, it's well written, and there's a lot of interesting information in it that would have saved me significant amounts of headache in the future.

    Therefore, that's the first thing I think anyone should be taught. I understand there are many like you (and me) who jump in. I now think that not reading through the manual a bad idea, as I've seen the results of it commonly in these forums over the past ten years.

    I also understand how it might have been difficult to find. But if you actually did read through the manual, this post wouldn't have been necessary since it would have been a thing that you knew existed. Even if you didn't quite understand how to use it at first, you would have known it was a thing and then looked it up again when it could have been applicable.

    Sorry that's a little bit of an off topic rant. I think containers are a very useful shortcut for a very specific thing, but you can work fine without them. I don't really think they're required knowledge compared to multitudes of other things like picking, how the event sheet works, expressions, loops, and arrays.

    Arrays would be my specific topic of choice to introduce outside the beginner tutorials. I die a little inside after every post where people are intimidated by the concept of arrays, when they're so useful and basically just spreadsheets that everyone is actually already familiar with. I blame high school array/matrix math for the confusion.

  • I think the first thing that anyone should be taught is to read the fab**ous manual. At least up to the references section.

  • You do not have permission to view this post