R0J0hound's Recent Forum Activity

  • I'm glad it's still useful.

    That probably is the oldest capx I've uploaded. The interesting thing about that capx is it was made before c2 had variables or animations for that matter. The only drawback is how it works is obscured because of that.

    I'd say with some certainty it won't be useful to the op.

  • That's expected. It's C2, not the behavior that combines tiles with bounding box collision polygons. I haven't looked in a bit but I'm sure it keeps track with a flag. Once a tile's collision polygon is modified it can't be combined with neighboring tiles. I mean we could come up with something to do it but it wouldn't be fast.

  • It's just moving, resizing and rotating the cards around. Probably could be done with easing or tweening with a behavior or just the lerp,qarp,cubic, or cosp expressions. An actual example is where i lose interest.

  • A few thoughts:

    The walls have a curved distortion. You can correct that by multiplying the height of the walls by cos(player.angle-raycast.angle) or something like that.

    You don't need to make the sprites so big. You could make them 32x32 and they would be able to be stretched to any size you want. That would make for a smaller download.

    It possibly may not work when you export the the arcade due to the frames being packed together and the filtering causing the wall slices to not be visible. I don't have any thoughts on correcting that yet.

    Textured walls should be no problem. Take say a 128x128 texture you want to use and import it as spritesheet in the image editor with 128 horizontal parts. You'll then have 128 vertical slices of the texture and you just set that from where you hit the wall.

    The raycasting events can also be changed in many ways:

    One way could be to jump 16 pixels at a time, then when a wall is hit it would back out 8 at a time until not overlapping, then back forward by 4... and so on till it's precise enough for you. It would be more efficient for further distances.

    You could also make the loop stop if the distance got too big so far away stuff just wouldn't be drawn.

    Another approach could be to line intersection math of the ray against the four edges of the walls ( or only some of them that actually face the player). It would be more precise and would make finding where on wall easier for texturing purposes.

    The is also a raycast plugin that could be useful instead of the previous.

    A final idea would be to use what wolf3d actually used, a dda. Basically it would step the ray along the edges of a grid, and supposedly it is very efficient. Most wolf3d tutorials online explain it in more detail.

  • No, it's not.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Basically you'd store all the info you want to save (positions, variables, .. etc) in something that can saved to disk. Offhand the array object could be used. Then when you load the file later you can to take that info in the array and recreate and re position everything. That's the general idea, but really it can become as thorough as you want.

    So for example a save event would do this:

    Set array size to (0, 10, 1) 
    
    for each sprite
    --- array: push 0 to back
    --- array: set (array.width-1, 1) to "sprite"
    --- array: set (array.width-1, 2) to sprite.x
    --- array: set (array.width-1, 3) to sprite.y
    
    array: save to file[/code:75i6wn73]
    
    Then the loading would be something like:
    [code:75i6wn73]Array: load file
    sprite: destroy
    
    array: for each x
    array at (array,currentX, 1) equal to "sprite"
    --- system: create sprite at (array(array,currentX, 2), array(array,currentX, 3)) [/code:75i6wn73]
    
    It's a starting point anyway.  If it doesn't make sense then I think it explains why I'm on here less and less.
  • vubidugil

    links updated in original post

  • vubidugil

    link updated in original post

  • link updated

  • Int(time*1000)%1000

  • That's easy, when the amount of bugs is low enough for them to consider it stable. You could possibly read dev responses to see when they hope to reach that point but that's just an estimate.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 followers

Connect with R0J0hound