ome6a1717's Forum Posts

  • Refeuh - correct me if I'm wrong, but there is no built-in sorting and distance-based functionality other than distance(x,y,x,y)?

    I do have entities will follow-like behaviors, but it's as simple as "if x < player.x, follow player > that way". And I'm using line of sight in order to determine whether or not the chasing boolean is active. I could always just disable the platform behavior for enemies until you're close enough to them, though?

    Colludium - thanks for the advice. Stupid question, but if an object has no collision events but has collision enabled, is it using any cpu/memory? I'm also wondering if distance between every object will run less cpu than overlapping a tile. I'd imagine at that level it's not a huge difference, but I want to be able to optimize to the fullest extent possible.

  • Refeuh - thanks for the reply. That does make a lot of sense. I tried something similar on Viktor, but ran into problems (probably because of my skill level in terms of coding), but I would "disable" things off screen and then re-enable them when they were on screen. However since there are so many of the same object type on screen simultaneously, it seemed to bug out if it was off screen, on screen, and then off screen again.

    Could you technically do a

    "For Each Sprite"

    if Distance(Sprite X & Y and Player X & Y) < Layoutwidth+500 = ENABLE BEHAVIOR

    Else = DISABLE BEHAVIOR

  • A while back when I first started Viktor, I made the first level into one layout. The level took about 5 minutes to beat, so it was relatively long (maybe 40,000 x 40,000 layout size). I had a friend who had a non web-gl pc to test the game, and his fps was in the low single digits. When I split the entire stage into 10 "mini stages", his fps dramatically improved (to the high teens; low 20s). So my question is this:

    If you're not adding more "new" images by creating large layouts and instead reusing 90% of the sprites you're going to have in every mini stage anyway, is there a bad reason to have a super large layout like this? I did a test to see the memory and CPU usage, and the memory usage was virtually the same between the full size layout and the mini layout. The CPU, however, did seem to jump a fair amount (went from 30 to about 60), but I think that's normal given that a lot of sprites, even though being reused, all had sine behaviors, etc.

    I personally have no way of testing this because I get 60 fps no matter what, but Viktor had some minor complaints on Steam that would experience certain framerate related issues that were otherwise untestable on my end. I'm assuming due to the fact that some pc gamers don't have a webgl-enabled graphics card.

  • hundredfold - what I'm trying to say is that, like the object list, if you're scrolled down in the list and edit an object, it sometimes selects the object at the top forcing you to scroll back down to find the object you were editing. I'm not sure if that makes any more sense?

  • I'm not sure if there's a preference I'm missing for this, but when dealing with lots of layers in the "Layers" panel (enough to create a scroll box), clicking things like "unlock all", "show all but this", renaming, etc. always go to the top of the layer list after doing so. It's a small thing, but I'm wondering if it's an easy fix?

  • korbaach - Of course! I always keep forgetting about the force texture settings.

    Thank you!

  • I'm trying to play around with blend modes, and I'm having trouble figuring this out:

    Ideally I'd like to have 2 sprites - one sprite as the "solid object", and one sprite as the blend mode sprite. I want the blend mode sprite to be completely transparent, but when it overlaps the "solid object" sprite, it makes the the bits of the "solid object" sprite that are overlapping transparent as well. Is this possible using blend modes, or does this require something more sophisticated?

  • KaMiZoTo - I've noticed somethign similar to this, too. I can't remember how long ago, but the platform behavior alone seemed to start racking up and enormous amount of collision checks a few updates ago. I'm not sure if it pertained to that, though.

  • Is there a way to enable/disable the persist behavior via events?

  • jayderyu - thank you! that's exactly what I needed to know.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm still curious if doing this is a big no-no...can anyone with actual development and programming experience chime in?

  • Katala - I'm glad I'm not the only one who thought of it! However I'm noticing; I made a text file that has the memory usage, and when sprites get destroyed, the memory usage isn't going down (I think it might be when I'm using the debug editor, but because the debug editor cannot include event sheets, I'm unable to use it properly)

  • I've been thinking about this for a while, and wanted to see what other people thought. In a game, you have to keep animations and sprite sizes small in order to keep the memory usage as low as possible. Sometimes that makes it difficult to make a game look as good as most modern games look today. So I had a thought:

    For long or large animations, could you do an "on animation finished" check, and in that event put a "create second part of the animation; destroy the first part"? And then "on second animation finished", "create first part of the animation and destroy the second part", effectively having the animation split as 2 sprites. In theory, they would never be loaded simultaneously clearing up the memory, and as long as what you're loading isn't too large, you wouldn't receive any hiccups.

    I'm talking about this mainly for PC games, not mobile.

    Would something like this work?

  • A0Nasser - The core team was really just 3 people; the rest were testers. Viktor would unfortunately not stand a chance on a tablet or phone; the game has way too many collision checks and art for it to have a solid framerate.

  • A0Nasser - Newt is correct - that's just the work of our brilliant artist, James O'reilly.