R0J0hound's Forum Posts

  • 1.

    Yes that should still be a top-level event. They didn't use to be but it was changed, so maybe that's the confusion.

    2.

    It depends on where the function was called from.

    3.

    It depends when the event was triggered.

  • Usually you'd use two tilemaps. One would be for the visuals, and one would have the solid behavior and define the walls.

  • christina

    Glad it helped the performance.

    Changing the position and size of the canvas wouldn't affect the performance. What would affect it, I imagine, is the "resize canvas" action, which changes the texture size. If you can i'd leave the texture size be, and just change the object size. The only issue is the positions would be off when you zoom in and out because the line draw commands are relative to the texture, not the object. This doesn't apply for the "paste" action though, it will paste in place regardless.

    Typically when the texture size is the same as the object size you can do this to map layout positions to the canvas:

    sprite.x-canvas.left

    sprite.y-canvas.top

    When the sizes are different you can do this instead:

    (sprite.x-canvas.left)*textureWidth/canvas.width

    (sprite.y-canvas.top)*textureHeight/canvas.height

    I didn't seem to include a way to read the texture width and height so you'll want to save them to variables. Just note when the canvas object is created the texture size will be the same as the object size. Then you if you ever use the "resize canvas" action you'll want to update those variables with the new size.

  • Another thing you can look at is the .asJSON expression and the "load from json" action. Every object has them and you can use that to save only objects that you want.

    Here's an example:

    https://dl.dropboxusercontent.com/u/542 ... load2.capx

    The saving saves three values for each object:

    "zindex" so the when we load they zorder will be the same.

    "name" so we can know what object to load.

    ".asJSON" the actual object data.

    after all that is put in the array it sorts the array by the zindexes, so then the array has each object that needs to be created in order of z.

    Loading is simple enough, and we use the "name" to create the right object type, and then the json is loaded.

    The capx has some comments of what you can do and what would require further implementation. Globals could be saved too but I'll leave that as an exercise for the user.

    But actually the more you want to save the more you probably should just use the save/load actions included with C2. You can use the "no save" behavior on objects you don't want to save.

    https://www.scirra.com/tutorials/526/ho ... -savegames

  • When you add an effect you can use an action in the event sheet to do it. My machine doesn't like webgl so I won't make an example.

  • yes you can. Look on the left side.

    Or click on an empty space in the layout.

    in the properties bar click on project properties.

    scroll down and you'll find it

  • You mean in an exact way? The normal physics behavior should be a good approximation. You can turn up the iterations to make things more accurate with the "set stepping iterations" action of the physics behavior.

    If you want an even more precise simulation, you'll basically need to make your own, but that would take lots of research and time.

  • You can add a text file to your project's "files" folder then use the AJAX object to load it to a variable when you run your game.

  • If that doesn't work then I think there was a change in C2 that caused it not to work. However there should be a fix in the topic it came from as I recall.

    Alternatively this also works:

    mouse: left button down
--- create dot at (mouse.x, mouse.y)

for each dot ordered by dot.zindex ascending
--- sprite: set angle toward (dot.x, dot.y)
	system: compare distance(sprite.x,sprite.y,dot.x,dot.y)<sprite.bullet.speed*dt
	--- dot: destroy
	else
	--- stop loop[/code:2r77i6tp]

  • You can do it with an effect. Maybe set color? and just set the red, green and blue parameters from events.

  • If they're the same no matter what computer you're on couldn't you just make the list beforehand and include it in your game?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Paster would only make a difference if webgl is used, and even then with one instance of the canvas it's not going to effect a whole lot.

    Had a look at the capx. Nothing stands out as a problem. For me the debugger eats up the most of the cpu so maybe you could just add a fps counter to your game/app to get a better idea of the perfomance.

    You're not running into an issue of drawing too much, at least not with 100 of your dialogs. Even the line drawing isn't causing much of a slowdown. I disabled drawing them and didn't notice much of a difference.

    The collision checks are caused by the "overlapping", "on object clicked" and drag n drop behavior. I don't really see any place you can reduce those in your capx. You could reduce the amount of checks if you did something like the following so the top dialog and it's container are checked for hover and click events. If the click is elsewhere then the rest of the dialogs are checked. This should reduce the normal cpu usage. One caveat is hover effects only apply to the top dialog, and you may want it to work with everything.

    pick top dialog
mouse over dialog?
--- do stuff

on click
	local number case=0

	pick top dialog
	mouse over dialog?
	--- set case to 1
		mouse over button1
		--- do stuff
		mouse over button2
		--- do stuff
	case = 0
	mouse over dialog?
	pick top dialog
	--- set case to 1
	--- move to top
 
	case = 0
	--- //clicked on empty space[/code:o6q4mgap]

What the most likely cause for the slowdown is the high object count and the picking of events.  If you can reduce the number of times you have to filter the SOL for an object.  Not always possible but utilizing sub-events instead of picking from "all" can help.

The first culprits of events that slow things down are nested loops.  In your "update canvas" function, it loops over each dialog and then each of it's children. One thing you could do to speed things up is to store the children's uids in the list so you can then use "pick by uid".  Picking by uid basically picks the object directly, whereas using a comparison casuses all the objects to be checked.
A second idea would be to not store a list of the children but instead only store the uid of the parent.  This would require reworking your event sheet but the result is much simpler.  As a note if the dialog doesn't have a parent set the variable to -1.
[code:o6q4mgap]local number endx=0
local number endy=0
local number parent=-1

for each dialog
--- set endx to dialog.x
--- set endy to dialog.y
--- set parent to dialog.parent
	pick all dialog
	pick dialog by uid parent
	--- drawline from (dialog.x,dialog.y) to (endx,endy)[/code:o6q4mgap]

That way each dialog is looped over once and it's connected parent is picked directly. should be much faster.

  • Well first of all, have a look at the "pick closest" condition. It does exactly what your loop does. So you could do your above code with three conditions.

    Objectfinder: ischeckingfortarget is true

    System: For each objectfinder

    ObjectA: pick closest to (objectfinder.x, objectfinder.y)

    So now let's talk about what you want to do. So roughly this:

    Start

    Each finder pick closest obj and save it as finder.target

    Move finder to their target

    If the distance to the target is less than some distance

    Then go back to start and pick another close object but not the old target.

    What I'm not clear on is when the finder gets close to it's target and it picks a new one, do you want it to ignore just the last target or do you want to ignore all previous targets? Or do you want to do something else?

    I just re-read what you wrote, so I guess you want a target, once reached to be ignored until the finder gets X distance away.

    I guess you could filter away all the objects that are close to the target before finding the closest.

    I'd give your finder object a variable called target with a default value of -1. Then Your events could look like this:

    Finder: target = -1

    For each finder

    System: pick Sprite by comparison distance(Sprite.x,sprite.y,finder.x,finder.y) > 100

    Sprite: pick closest to (finder.x, finder.y)

    --- finder: set target to Sprite.uid

    For each finder

    Sprite: pick by uid finder.target

    --- finder: set angle to (Sprite.x, Sprite.y)

    --- finder: move forward 100*dt pixels

    For each finder

    Sprite: pick by uid finder.target

    System: compare distance(Sprite.x,Sprite.y,finder.x,finder.y) <100

    --- finder: set target to -1

    Edit: ninja'd

  • newt

    Not really. I mean you can think of it as a combination of sprites and tiled backgrounds when it's drawn, so as far as draw calls, maybe. In reality it's probably less, but that's not what's happening here IMO.