R0J0hound's Forum Posts

  • It looks like it can't find some files. Can't say I know how to fix it as I always found compiling c/c++ stuff a pain.

    The old wiki here has an old tutorial that maybe helps? If not try reading older topics about building plugin's. You'll probably get better info there as opposed to now with no one familiar with it anymore.

    Edit:

    Actually the issue is where the sdk in relation to the sdk folders. It's looking for those files relative to the plugin's solution. In those file paths .. Means the parent folder if that makes sense.

    One way to handle it is to just download the entire construct source and see where the plugin source plugin's are and put the plugin templates there. This is off the top of my head, I know it to work but haven't messed with it for a few years.

  • There is the angleDiff(a,b) expression that will do that. It gives a value of 0 to 180.

    If you need a signed angle result of -180 to 180 you can do angle(0,0,cos(a-b),sin(a-b))

  • I can't be much help since i don't have Construct classic installed and would need to re-familiarize myself with it. Aka figure out how many parts of it works, identify crashing points, and working around it.

    There is this old discussion with some examples and such. I fixed my links, i'm not sure about the others.

    Also maybe look at Jayjay's example kit in his signature. It may have something useful.

  • KeeghanM

    You can look at this old topic for some examples and some links to pages that are good references.

  • I'm glad it's still useful.

    • Post link icon

    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