UberLou's Forum Posts

  • C2 has always struggled with OR, as OR just doesn't fit well with C2's primary mechanism of 'picking'. The problem here is both conditions are run, but that means that the 'on floor' condition has now picked no objects, so by the time the code reaches the action, no Players are picked. To prove this, add a sub-event that does a pick-all on Player, and move your action there. You'll see it now works.

    I avoid OR generally, as it just doesn't work well when picking gets involved. Either split up the conditions, or work around the issue as explained here.

    Well that's confusing. Thanks for the advice and workaround!

  • I have an issue using an OR block. Here is the code:

    When you press W, the player sprite gets sent to a dash state moving him forward. This works when the player is on the ground, however when you jump and push W, the player doesn't dash. It should dash because AirDash=1 right? If I delete the "Player is on floor" event, the player can then air dash as expected. Why doesn't it trigger with both conditions in the Or block?

    Here us the capx if anyone wants to check it out.

    Thanks for any help

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I would recommend not disabling collision checks for off screen objects since Construct already does this for you.

    Here is the Blog post about it.

  • that would be really weird if c2 added to your sprite... that doesn't sound right to me.

    Pretty sure of this. You can test it by making a 126x126 sprite and a 128x128 sprite and see what the sprite sheets look like after export.

  • Its probably because construct adds a 1px border around each image, so your 128x128 image becomes a 130x130 image and that needs to go on a 256x256x sheet. The border is to prevent antialiasing issues.

  • If you didn't make any [measurements], how do you know this isn't just a waste of time?

    "Remember not to waste your memory" is literally the title of your blog post. And I've just shown that C3 sheets waste memory in a small test case. In larger games, the amount of VRAM used will just balloon.

    Most engines allow you to have control over sprite sheet packing. There must be some reason they allow this, right? If you need links for proof: Unity ,Gamemaker, Stencyl, GoDot, Fusion 3 (which has an automated method using playthroughs)

    From Stencyl's page, "Our goal is to minimize our game's memory footprint. You do that by only loading what you're going to use in your scene."

    What measurements did you make that demonstrated this was necessary?

    None. I've shown that C3's spritesheets are wasteful. I have an 8oz cup that I need to fill with 8oz of milk and C3 will automatically put soda in there. If you are filling up VRAM, you want to be able to control what gets put in. I'm fine staying with C2 since I have that control.

    EDIT: I'm just realizing that you're asking about what measurements I took in C2, not C3. I did do a lot of testing awhile ago (been working on this project for years) and saw the need to break out non essential animations because of memory concerns. I don't have exact numbers at the moment.

  • Construct has no provision for only loading specific animations, it only loads entire objects.

    I'm sorry I didn't make it clear in this post. In a previous topic, I explained that these are all separate objects. Death, Death2 and Swim are not included in the main player sprite object. At the start of levels that have water in them, I load the Swim sprite that contains SwimIdle, SwimForward, SwimStop, etc so there is no jank. This is good memory management for large games.

    All these sheets together use just under 5mb of memory, which is not much given modern systems have gigabytes of memory.

    This is just a test case. Of course I won't complain about 5mb of memory. But brought out to larger scales, this becomes a problem. If I have huge bosses and C3 shoves in a small FX texture unrelated to the boss, then a huge texture will be loaded whenever I use that FX sprite. This is bad memory management especially for lower spec PCs. You have a whole blog post dedicated to not wasting memory.

    (From another thread)A manual tagging system is boring to do and error-prone (you could easily actually make it worse by getting tags wrong), and the editor has a lot of information it could use to apply grouping automatically, such as inspecting which layouts objects are used together on.

    Being boring is a strange excuse to exclude a feature. There are lots of things in game dev that require boring work but are necessary. There are also simple solutions to avoid errors. Unity lets you create tags, and then just assign that tag to sprites so there are no spelling errors. Thinking about this more, just use a similar system to creating families to create sprite sheet groups.

  • Ashley

    In another thread you asked for evidence that the auto spritesheeting could be a problem. I ran a test and wanted your thoughts. I cant give concrete numbers because I can't set up my whole game in C3 but hopefully this will show you there needs to be a better method to spritesheeting.

    I recreated how my game is set up but in C3. Here are my test spritesheets:

    The green sprites are the player, the red and blue are enemies, and the smaller ones are fx related to each of those. The green sprites that say "Death" and "Death 2" are animations that should never be loaded together as only one of those is ever needed when the player dies. The green sprite that says "swim" should only ever be loaded on levels that have water. There are also Enemy 1 red sprites which only ever exist on one level. But here it is loaded every time the player is loaded. Also on Sprite Sheet #4 there is a grey star which represents player FX. If I use this player effect, it will load a larger than needed sprite sheet which contains an Enemy sprite, and Enemy FX. Lastly, the red and blue enemy sprites never appear together in game, but they share spritesheets. Every one of these sheets are completely wasteful.

    Keep in mind this is just a small test of a few enemies and FX objects. My player character has 16 standard animations, 5 deaths, 6 cinematic animations, 3 unique level animations...and counting. Most of those shouldn't be loaded unless necessary to optimize as much as possible.

    The most simple enemy in my game has 7 animations averaging 6 frames of animation each.

    There are tons of FX most of which are animated too

    All of those player sprites and related FX would be spread out into multiple enemies and their related FX even if those enemies and FX should never exist together.

    I hope you can see why some type of sprite sheet grouping is necessary for larger games.

  • tunepunk This was my suggestion which i think would work for your needs too and it was unfortunately declined: https://construct3.ideas.aha.io/ideas/C3-I-104

    — there are far more users that don't care about this feature, sure. But wouldn't the fewer advanced users that are creating higher quality games (at least in the gfx area) give Construct more publicity and attract more developers?

    Also the feature I submitted isn't confusing. Tag sprites to be packed together. If no tag then do the auto sprite sheet thing. Game development isn't easy. People will always be confused about something, then come to the forums to learn.

  • I've noticed. Thats why I came to the same conclusion and put many objects into one spritesheet so it exists only on 1 texture. This is why both Unity and Gamemaker have ways to intelligently merge sprites onto one texture. This is why I've requested an optimization feature for C3 (that got denied).

    Maybe only the more advanced users come to this conclusion and that's why you don't hear it often.

    ...

    - Everyone in 2011

    This is looking back with rose tinted glasses. Flash absolutely blew away HTML5 then. So at the time, we couldn't export to the best web format or PC. Other engines could export to Flash and PC and then they added HTML5 later when it became viable. Isn't that a better solution than risking everything on HTML5? So sure you made a good prediction on HTML5 becoming a good web format but it took a few years. And still we've only recently gotten a PC export that works properly with Steam, an export to XBox that doesn't work, no PS4 and no Switch. So we are still dealing with the repercussions of having an HTML5 export.

    I'd be willing to bet most people here use Construct in spite of it being html5 than because it is html5. I'm here for the event system. A lot of posts have been made vindicating the choice to use html5, but i feel regardless Scirra is still a bit blind to its down sides and the on going issues it presents. Just my opinion.

    Exactly this.

  • I have global variables representing all the actions in my game, for example, key_jump. When the user wants to change controls, I wait for input using keyboard.LastKeyCode or gamepad.LastButton and assign that to key_jump. I then call those variables using keyboard.keycode or gamepad(0).buttonindex. That all works fine. However the mouse doesn't seem to have these features. I can't seem to assign an index of a mouse button to a variable. I then can't say on mouse index pressed - do something.

  • For keyboard and gamepad objects, I can get the last key or button pressed and assign that input to a variable to customize controls. I can't seem to find any similar actions for the mouse object so I can't let a user change those inputs. Am I missing something or are there any workarounds for this?

    Thanks

    -Lou

  • That seems like a crippling feature of C3 to me. I guess I just can't imagine not managing and optimizing graphics assets. Why would I want to load frames from a giant boss creature when I want to fire a bullet that may be auto sprite sheeted into the same texture. For another example, in my game I include a bullet graphic plus fx for the bullet all into the same sprite object so they will be in the same sprite sheet at around a 64x64 texture. In C2 I can load that on the fly no problem. No jank. In C3, if the system decides to split that off into different sprite sheets, then it will load in a sprite sheet that could be 1024x1024 for the bullet, then it might need to load in even more large sheets to get the other bullet fx in. Wouldn't that also be more jank?

    TBH unless your player animations are absolutely huge with loads of frames, splitting things out in to separate objects is probably a micro-optimisation that doesn't make much difference. It also can jank the game as it loads textures mid-frame if the object isn't already preloaded by being placed on the layout. And currently the engine doesn't release textures until the end of the layout, so the peak memory usage will be the same.

    I am probably in the minority, but I am working on a larger game with lots of animations in larger layouts. I depend on being able to smartly load in textures. Peak memory usage would not be the same, because as in my previous example, instead of loading in 10 death animations, I only load in the one that I need when it is needed. I never need all 10 death animations. Also there is no jank, even if there was, it wouldn't matter that there's jank when you die.

    I also don't understand all of this jank concern. Ori and the Blind Forest had jank when you got to new areas because it would stream them in instead of loading. Who really cares? Feeling like you were in a huge connected world was amazing. As long as you smartly load in textures in areas where it doesn't matter, the majority of the gamers won't mind. I guess thats personal preference though

    I've already had to make changes to my game design because I can't have large layouts (due to not being able to unload graphics.) .

  • The auto sprite sheet feature sounds pretty neat but I don't understand how it actually works for managing memory. In the blog post I see a sprite sheet with 2 enemies and bullets in it, which is great if they are all needed on that layout. But what happens if you need them separated because those 2 enemies don't ever exist together?

    For example, in my current game I have a lot of death animations for the player. Each animation is a different sprite objects so they exist on separate sprite sheets. When the player dies, I spawn one of the death animation sprites.

    This way I don't load 10 different death animations into memory that aren't needed. Will the system in C3 automatically lump all the sprites together into one sheet? Is there a system to tag objects that can be spritesheeted together and separate others? Or am I completely confused about whats happening?