Alright, I did end up fixing it. Canvastolayer and layertocanvas are very taxing on system resources evidently and I ended up eschewing them entirely. Runs a million times better with a simple "star.x < viewportleft(starlayer) - offset" type of condition. I shouldn't have tried to be so fancy or worried so much about being super precise with parallaxes.

I just did as you said and it's my star field wrapping. I'm currently trying to move blocks of the field at the same time cause I thought it would be easier on the processor... maybe someone has a much better suggestion than the horribly jury-rigged set-up I have? I'd go the "in visible window" route but I'd like a less repetitive starfield than that if possible... since the player will be able to move in any direction at any time it's not like I can just shoot stars at them from the other side of the screen.

Also, my current setup for detecting where stars are is a pretty heavyhanded use of canvastolayer and layertocanvas. If someone has a more reasonable way to compare their positions to the screen/an object in a different layer parallax that'd help too.

I don't think it's the whole story. When I disable the enemy AI events it runs around 40-45 FPS, indeed better, but obviously not the whole problem. It also doesn't explain to me why canvas2d would run faster (pretty much the opposite of what the manual implies). Maybe I have some runaway effects hanging around...? Hmm...

yeah. 400 sprites on a desktop based computer does seem low. Do you have any specifications on your computer. Try turning WebGL off if you can. if your on an older laptop your computer might try to software render the effects which will kill performance.

When I turn off webgl I generally get higher framerates... chrome gets even smoother (while still saying 55-60 fps) and firefox *claims* to hit 60 fps but it continues to look chunky and stutter, nothing like chrome at all.

My laptop isn't old per se but again it's not top of the line and has an integrated graphics card (i5-2435M 2.4 ghz duo). It's also running it on a much larger desktop monitor which I noticed does affect performance (1650x1050).

Forgot you had to delete the plug-in from the object list... I suppose that would have the fastest way to do it in the first place. Retry the link!

Forgot about that, sorry. Here is the capx with the CSV events removed.

dropbox.com/s/ey8n0hhatzsjub7/gutted.capx

You won't be able to fly but firefox still runs slow regardless.

My PC may well not be powerful enough as it's a laptop with an integrated graphics card (it runs the lower end AAA stuff fine though). Still, I did just go and test it in chrome and chrome runs it smooth, so I don't know how much this has to do with my computer.

Here is my capx... I did have to do clean up work to make it readable as I tend to strike through events/actions as I iterate on them. The first event sheet has star stuff: dropbox.com/s/70g33v2ae8bbm6c/starproj.capx

The stars themselves are actually sizeable 16 x 16 sprites that I size downward for variety... in reality they don't get bigger than 4x4 but I like starting big and sizing small since it makes things a bit more crisp. I didn't think it would hurt much to have them start a little big since the manual said that size doesn't really matter.

I'm making a space game with a starry background using a bunch of star objects more or less randomly placed each time you load. The player can fly in any direction for forever so I'm making the stars wrap. What's unclear to me from the manual is whether replacing all the star sprites with small star tiled backgrounds or small star particles would help performance at all, as the manual mainly discourages sprite tiling (which I am not doing). I like my stars and would like to be able to fit a lot in, though I don't relish the prospect of making 30 different tiled background objects for different colors, sizes, and brightness levels (as currently I do most of that in a single sprite with animations).

I'm not planning to "release" this game on mobile devices but my current framerate of 27-40, average 35 fps in firefox (with ~400 objects) is bugging me and I like things that run as smoothly as possible.

Thanks!

sprite1.X is the absolute X coordinate of sprite1's origin point. imagepointX similarly gives the absolute X coordinate of sprite1's image point relative to Construct's coordinate system (the top left corner). So subtracting the two gives us the difference or relative position of sprite1's imagepoint to sprite1's origin point. This is important because with the Set Position action we are forced to figure out where the sprite's *origin* has to be in order for it's image point to be in the correct place.

For example, if we have a sprite with origin (1,2) and imagepointXY (3,2) (which means relative difference of (2,0) which you want to move to sprite2's point (5,6) this is how the expression math works out:

5 - (3 - 1) = 5 - 2 = 3

6 - (2 - 2) = 6 - 0 = 6

Notice how in the parentheses we got the relative diffence between sprite1's origin and it's image point. The object's new origin point is (3,6), placing the image point (2,0) from that at (5,6) absolutely.

If it helps my #1 method for figuring out how exactly what some number means or what something does is to make a quick blank project with a sprite or two and a text object set to any/all values I'm interested in and just muck around until I understand what's going on.

In answer to your second question, yes it is possible but the math is more work than what I just did. You'll have to use more expression variables like sprite.Height and sprite.Width and resize things. If I have time I might be able to look at your capx later and advise you further but I don't know if I can.

To put sprite1's image point on top of sprite 2's image point (both non-origin) by setting sprite1's position you'd do this:

sprite 1 set position -

X: sprite2.imagepointX(q)-(sprite1.imagepointX(r)-sprite1.X)

Y: sprite2.imagepointY(q)-(sprite1.imagepointY(r)-sprite1.Y)

I haven't tested that one but I think I got the signs right (it's kinda late for me, zzz). Last time I was faced with this problem I did this which is a little more flashy:

sprite1 set position -

X: sprite2.imagepointX(q) y: sprite2.imagepointY(q)

rotate sprite1 180 degrees

sprite1 set position - X: sprite1.imagepointX(r) y: sprite1.imagepointY(r)

rotate sprite1 180 degrees

It's hard to understand exactly where you are since you haven't posted a link to your project as a capx, I'm not sure what's going on but I'll try to help.

You *should* be using the "simulate button press" actions in the event editor to control the non-player sprites. The player can't control the sprites if you set the default controls to "no" in the layout. As long as you're using the "simulate button press" actions the sprite should be using the "set angle" movement property you can change in the layout.

I really can't tell you more until you post a capx or at least a screenshot of your entire event sheet. Can you be any more specific about what the problem is?

My spanish is bad but basically they haven't been able to get their questions answered and Joanne pointed them out to a facebook group.

Honestly I do not blame them. I looked at the Spanish forum linked in the language communities thread and the "How do I" section is displaying 2 topics with 1 post each and no replies. We aren't exactly a huge multilingual community.

Glad they got some help.