R0J0hound's Forum Posts

  • To check the hsl values for a layer would require taking an average of all the pixels and getting it from that. At least that's how I understand it.

    The only reliable way to get all the pixels that I know of is to use the snapshot action to get an image of the screen. Then you could load that image to a Sprite, resize it to 1x1, and paste that to a canvas object (third party plugin that can read pixels from an image). Basically make the canvas object 1x1 in the editor, and position the Sprite object in the same position.

    Finally use the canvas.redAt(0,0) and similar functions to get the rgb average, more or less, of the layer. You can convert the rgb to hsl with algorithms that can be found online.

    Anyways, that probably would work, just not very fast.

    Really though this isn't something easily done in c2 if at all.

  • Maybe use the browser object to load the pdf in the same way as a webpage with the go to URL action? I don't recall what it's called, but you should find it in the list. It will either cause the off to download or maybe in the case of chrome it may let you view it there.

    Another way would be to use a pdf js library. It's hard because of all the hoops you have to jump through to get it to display in a c2 game. Probably nigh impossible if that didn't make sense.

    The final option, although you should check here first, is to see if a pdf plugin exists already that you can use. There in a topic in the addons section that lists all third party plugin's. I'm too lazy to check myself.

  • I guess you could do some smoothing of the position with previous one's. just save the previous physics position to a variable. Sampling older positions for more smoothing may not be too useful.

    every tick

    --- sprite: set x to int((phybody.x+self.oldx)/2)

    --- sprite: set oldx to phybody.x

    I guess you could also only move if the physics object moves 2 pixels or more. I think that may just make it look like things are getting stuck.

    pick by comparison: sprite: abs(int(pysbody.x)-sprite.oldx) >=2

    --- sprite: set x to int(physbody.x)

    every tick

    --- sprite: set oldx to phybody.x

    You may also try round() instead of rounding down with int() or floor(). Not sure that would matter in the slightest though.

  • I'm no longer updating plugin's but there may be a leak. Garbage collection doesn't happen immediately when something is destroyed so there's that. The runtime also does something called object recycling that doesn't actually delete the destroyed object so new objects can use it. That is so less garbage is created.

    I do know the main memory and cpu hog is every frame the canvas is drawn to I had it create a new webgl texture of it and discarded the previous. Honestly I've never been interested enough to improve that. The plugin was made before c2 had the webgl backend so maybe that explains that.

  • What's actually happening is the sprites are being marked to be destroyed at the end of the event. They aren't being destroyed right then which is why they can be picked multiple times.

    One solution would be to add a Boolean variable "alive" with an initial value of true and then do this:

    Space pressed

    Repeat 3 times

    Sprite Is alive

    Pick random Sprite

    --- Sprite: set alive to false

    --- Sprite: destroy

  • Is the canvas object at the top left of the layout?

    Maybe use

    Mouse.x-canvas.bboxleft

    Mouse.y-canvas.bboxtop

    If it isn't.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could just set the initial value of the frame variable to 1. Unless I'm misunderstanding what you're saying.

  • Desktop was an example, mobile is basically the same. Mobiles have more performance issues because they are weaker than desktops.

  • All the functions and globals made it hard for me to follow what the events do. Here's a simplified version that's a lot more readable to me:

    https://www.dropbox.com/s/tdcv8lil8p14f ... .capx?dl=1

    Maybe that's helpful. Yours may just have one or more simple typos somewhere.

  • Ok, now I can at least somewhat understand your events. The issue is event 44. To fix change it's condition to "else".

    what happens in that function is:

    if var != 4 then add 1 to var

    if var == 4 then set var to 0

    So if the var is 3 going into the function it will first change to 4 and then set to zero right after.

    The whole event sheet is kind of stretched out. You could simplify it to around 10 events i'd think.

    Edit:

    You're also messing with that frame variable at the end of the "Spawn_Ec_Ships" function. That probably also will cause the same kind of problem.

  • I'm not clear what the issue is. In the initial capx you wanted to create multiple sprites and have each one have a different frame. The solutions you got so far seem to correct that.

    Your Larger capx just creates four different sprites. I can't tell from your descriptions how you want it to want it to work. and in what way the result not correct.

  • There's a variety of ways other programs do it. To most "native" means an exe is produced and the game doesn't run with an interpreted language like javascript. Or in other word the runtime is made in a compiled language.

    Construct classic had a runtime and plugins made from compiled c++ as an exe and dlls. When exporting all game resources were then just put into the exe.

    Gamemaker does something similar as far as I recall. At one point before they added encryption they just put all the game scripts as is inside the exported exe, and the exe would read and run it. It probably does the same now.

    Gdevelop looks to have the option of generating c++ code from the game project and some compiler is used. They may use resource packing as above because a compiler doesn't seem to be required.

    zGameEditor looks to implement it's own compiler that generates an exe directly.

    Godot uses precompiled runtimes that resources are packed into as well.

    Unity may either just pack resources or utilized a c# compiler to generate the exe.

  • link updated

  • marceloborghi

    It works here.