9730a7b7-27e3-41ab-86ec-60f77ccc1fe5's Forum Posts

  • Hey!

    If the size per tile is 20 i would do:

    For height, width, x position, y position divided by 20 * 20.

    Height example: int(sprite.height/20)*20

    Your "TileTop" sprite had the origin in middle, and was created on a weird offset. So no wonder it did not snap on the grid. Either you take that offset into account, or created a grid of "TileTop's" from origin.

    Take a look at this example: gofile.io/d/6yD8iF

    Numpad + = increase width and height by 20

    Numpad - = "you guessed it" decrease width and height by 20

    WackyToaster I'm glad we have the freedom of talking to each other in the manner we like, as long as we follow the rules. How i spend my time, is my choice. Since im paying for construct 3, i believe it has some validity. You may disagree with me totally (my general stance towards bug reporting/fixing), and that's fine.

    I just think i wouldn't have been so reliant on my customers to chase down bugs. I would feel bad for doing that towards my customers. But hey, that's me. Maybe im in the wrong here, or maybe im old fashioned, i don't know. Frankly it doesn't matter. At the end of the day, as a customer, i can always choose.

    Dont get me wrong, i realy like Construct 3. That's why i am actualy spending time writing for once.

    "It's a great deal of work even just checking every possible thing that might have gone wrong based on passing mentions on comments and forum posts, and most of the time it's a waste of time because we're missing important details. As a small team with limited resources, we just can't afford to waste our time chasing impossible bug reports"

    It's like you don't have any pride in your own code at all? Your reliance on your customers to narrow down bugs so much so, you don't have to seek it out yourself, is concerning. So your whole model, your product is reliant on us doing a good work reporting YOUR bugs. Strange.

    Well, i can always take my bussines elsewhere.

    I have not. It was more of a general stance towards letting consumers do what testers are suppose to do. I never use the platform behaviour.

    Hey, i like construct 3. I just don't like the idea of doing what a professional tester would do, for free, while paying.

    I almost never write here on the forums, but this prompted me.

    This filling out a report nonsense is complete BS. We are asked to do the initial bug testing and paperwork for you, as a consumer, for free!

    I will never fill out any report, unless im getting paid.

    Doing bug testing paperwork for free? No thank you.

  • I put together a simple demonstration for you. It's the surface normal you want, not reflection. My bad.

    It is far from perfect, just an idea.

    gofile.io/d/VUZlpB

  • Maybe cast from players origin to a player imagepoint at his "feet". Or just below his "feet". I suspect you only need to cast one ray.

  • Hey!

    Maybe try the line of sight raycasting? You can get the reflecting angle from that.

  • Yea, i tried that also. A nice boost! Thank you again!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Oh wow, you are right Colonel Justice! That was MUUUUCH faster! Thank you!

  • What??? Using 128 rays shouldn't be a problem. The real performance hog using the built in LOS raycasting is amount of walls, not rays. If you make a map in the layout editor, say a room of 4 walls, you can use native resolution! 1920x1080. 1920 rays! But as soon as you add more walls to the map, even if you are not hitting them with a raycast, you will get a MASSIVE performance drop.

    When i look at the debuger, it's even calculating collisions, even though nothing is in my FOV! In order words, it's running collision checks with the walls, even though im not hitting them with any rays!

  • Hey folks!

    The official raycasting feature in the LOS behaviour is a nice addition, although i have run into a performance snag regarding how it calculates the raycasting hits. In my example i am using sprites as the FOV. So i create sprites "on start of layout" then i pin those to the player, and then cast to those points.

    My idea (and it's working nicely) was to create raycasting maps via sprite (that you draw), then capture that image with the canvas and populate it to an array (based on different color values etc). Then i create sprites for the walls (from the array), which i intended to use for the official raycasting.

    The issue is this: Since it seems that you are using the "overall" collision model for the actual raycasting, there is a HUGE performance hit when creating medium to large rooms. Since every wall is one sprite, and your collision model is using some sort of optimization (which works fine in most cases).

    I have only 128 rays, but alot of "2d" walls, that makes up the map. The idea of using raycasting is that in theory, the raycasting algo shouldn't be a big performance hog, since you are only testing the first collision (if you want). In Constructs behaviour you are obviously pre calculating stuff.

    Also, I only have 8 pixels of view distance. Still the performance is realy bad. The performance hit is already taken, even before you hit a wall!

    What i mean is, the number of walls shouldn't bog down performance barely at all. Only the amount of rays+distance used for the actual raycasting!

    Is there a better way to gain some performance perhaps?

  • Interesting, and good points overall!

  • Thanks! Anytime!

    Yes, precisely! You would probably not have 1800+ sprites on the screen at one time. I have tried the array approach with a raycasting engine, and i could actualy have a 4000x4000 array (creating walls, and sprites in front of the player, at runtime. No problem. It took a couple of seconds for construct to load everything in, but when it did, it ran smoothly! :)

    If you have a huge array, remember array.at(). That will give you alot of performence..."nobody" would want to loop through a 4000x4000...anything XD