R0J0hound's Forum Posts

  • It just sets the return value and does not exit the function. There is no way to exit the function other than running to the end of it. So what you did with else’s is one solution to do that.

    You can consider the event sheet as its own unique programming language. The object picking is the most unique part. Take away that and it’s similar to most programming languages with if/else/loops/functions. It does have its differences though, such as no way to immediately exit out of a function or loop like return or break.

    I don’t have a good explanation for why that is. It was inspired by the click team products event sheets, but made more hybrid to better resemble structured programming. At this point we are in comparability mode. They can add new features but changing existing ones will break a bunch of things. But event sheets as a whole would benefit from tweaks and redesign in parts.

  • No idea. But your event screenshot gives a very partial view of what’s happening. Can’t see all the behaviors used, or other events that may change the scroll.

    As is, it looks like it can be simplified to one event:

    Right mouse down: scroll to mouse.x, mouse.y

    Anyways my best guess is some of those other camera objects also have the scroll to behavior. When the scroll is changed the mouse position will change since it gives the position on the layout.

  • It starts as 0 till you there is some kind of mouse input such as a click or motion.

    Never have encountered it always being zero. You’ll have to provide more info.

  • The variable is a local variable, so it resets every frame. You can edit it and make it static, that will make it remember it's value.

  • Nice. It is helpful to do stuff from another point of reference. Can be easier to debug in 2d, plus easier to use behaviors.

    Those game jams do look fun. I haven’t done one as of yet. Seems like a good challenge to make something in a short amount of time. Good way to break out of the endless design phase and just start making something. Although I’d probably bite off more than I can chew.

    I do like reading the progress updates for such challenges though.

  • I like the idea to limit the range to try casting rays.

    Here's the current idea. We find the bounding circle of the target object and only shoot a random ray that would hit that circle. It tries at most 20 times to find a ray that hits the object. Seems to work well enough, but the more obscured the object is the less likely it succeeds.

    dropbox.com/s/w8f937c8y0edfyh/LOS_Object.capx

  • I was curious about the math so he's an attempt. I got much of the math from this skinning tutorial.

    webglfundamentals.org/webgl/lessons/webgl-skinning.html

    dropbox.com/s/o6s9wuot219egx0/skinning_test.c3p

    Making the mesh itself and weighting it is probably one area it can be improved. How the verts are weighted now makes the joints turn sharply. I just had it linearly blend the weights between the verts.

    Another idea is to make a curve fit through the points to make the distort.

    Also here is an idea to do the ik without trig, if needed.

    iquilezles.org/articles/simpleik

    Anyways, as always just some ideas and preliminary attempts. Hope it's useful in some way.

  • 1.

    Conceptually they should be the same. The graphics card can draw tiled textures just as fast a non tiled ones.

    2.

    You’ll have to look in the manual/blog posts about it. C3 had more work on the atlasing of textures so it’s probably all lumped together when it can. Power of two textures shouldn’t matter. That is handled behind the scenes with construct. Atlasing is to use less vram mostly.

    3.

    Construct’s renderer is batched. Which just means it draws as many objects with the same texture all at once with one draw call. They are always bragging about the speed of that in blogs

  • I often use for each ordered to do that. Here it would shoot at the 3rd closet. This method is also useful when you want to do stuff with the n closest like it sounds like you are. 

    For each enemy ordered by distance(player.x,player.y,enemy.x,enemy.y)ascending
Loopindex+1=3
— stop loop
— shoot

  • I like that kind of problem.

    One idea is a rough LOS check. Basically repeatedly pick a random point inside the collision poly a do a LOS with that. Would fail more with smaller loops if the object is obstructed but it may give a true eventually. Could be a useful approximation of vision. Anyways the main sub problem to solve would be to get a random point in a polygon.

    A second idea is to utilize raycasts. Either a uniform spread of rays in roughly the direction of the object or use a bit of random. If any of the rays hit, there is LOS. I think this one is the most doable. Not sure if the ray cast feature in c3 can be used for this but making a ray cast with events would work.

    Another idea if to calculate the view polygon from one point and check to see if that view poly overlaps an objects collision poly. May be tricky to calculate though. One approach would be to do what shadow casting does and clip away from the collision poly the shadow bits. This would give an absolute is in in Los or not check.

    Anyways just some ideas, each with their own set of sub problems to solve. Maybe some are useful.

  • Since they are all trees you could just make them all one type and use different frames or animations to look like the various trees. That would save on events.

    For the random id go for something like this which would make each tree at closest 0.5 sec apart. 

    Var next=0

Next<time
— set next to time+random(0.5,5)
— spawn tree
— tree: set frame to int(random(5))

  • Here's a rough demo of iso. I'm poor at ripping/creating art but it gets the point across.

    dropbox.com/s/7pz214ogx58jzz0/sokoban_like_iso.capx

  • I've gotten that error when trying to open a c3p file saved with a newer version of c3 than I have open.

    If that isn't it then you can open the c3p file with a zip program as it's just a zip file. If a zip program can't open it then it may be corrupted.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are many ways to do that.

    One is to just use the touch location when you tap. Use it with a non scrolling layer. You can subtract the center of the screen to make it so tapping the center of the screen centers the view.

    touch.x-screenwidth/2, touch.y-screenheight/2

    Another is to change the rotation values based on how far you drag.

    Roughly this. You'd want to get touch coordinates from a non 3d layer. 

    var rotx=0
var roty=0
var oldx=0
var oldy=0

on touch
-- set oldx to touch.x
-- set oldy to touch.y

is touching
-- add touch.x-oldx to rotx
-- add touch.y-oldy to roty
-- set rotation to rotx, roty
-- set oldx to touch.x
-- set oldy to touch.y

    At least that's something to try. You may run into gimbal lock or rotation in a non desirable way but it depends on what you're doing.

    Worst case I'd do the rotation math directly with a 3x3 matrix and apply that with the look at action. It would give the most control of how you rotate. Like instead of the arbitrary euler angles like when you set the rotation you can rotate by any axis such as one relative to the screen. But I may be overthinking it.

  • I don't have any third party addons so I can't open your capx but here is one way to have a scrollable area with scrollbars and hand pan. It clamps to the Scrollwindow to the scrollArea but the scrollwindow has to be smaller than the scrollarea.

    dropbox.com/s/qshp8w4mmp1jzro/scroll_area.capx

    In concept you can have multiple scrollable areas. One per window, but the capx would need modifying to handle that.