I've been trying to do this for a few hours, but I can't figure it out. When I use angle(x1,y1,x2,y2) I get angles like in the left image. I'm trying to essentially rotate that 90 degrees and get angles like in the right image. Anyone know an equation to achieve that? Closest I've gotten to is (angle+270) %180

Thanks for any help.

p.s. any response towards giving users some control over which assets are combined to which spritesheets?

I've asked for this feature already. Possibly an automated method is coming for C3 based on this response. But probably only if more people ask for it as Ashley doesn't think its a major issue. I've stuck with C2 so that I can take advantage of one spritesheet per sprite.

The actions run, as explained in the manual here:

https://www.scirra.com/manual/75/how-events-work

There is just no object picked.

This is a the logic (not a workarround) if you would insist using 'OR' in a picking situation.

https://www.dropbox.com/s/0fb3727hnew5r ... .capx?dl=0

Personal i never us 'OR' when picking.

I did read the manual but it didn't click until blackhornet explained it. Just for clarity, does the OR not work because Platform on Floor = False so it clears the picking list?

I'm staying away from OR as much as possible anyway now. It's a shame because it's much cleaner than separating the events and repeating the actions.

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

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.