oosyrag's Forum Posts

  • playfuljs.com/a-first-person-engine-in-265-lines

    My understanding is that the original Doom was still pretty much a 2d game. Neither z elevation or the 3d object are necessary. If you are able to follow the above in Construct you should end up with a pretty good idea on how to customize and add to it for your own purposes as well.

  • You do not have permission to view this post

  • 21:9 is likely the widest aspect ratio you will encounter (minus any multi monitor shenanigans) while 4:3 is the squarest.

    To deal with it, you can either use scale outer by setting your viewport to a 4:3 resolution, and design with the consideration that up to 1.75 times that width might be viewable to any given user, or you can use scale inner by setting your viewport to a 21:9 ratio and design with the consideration that a user might have 25% of each side of the screen cut off.

  • This event is not likely to cause any problems. It is probably something on the next layout you are going to.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • OK, so two things.

    Regarding the angle of motion to start - if your bullet speed is 0, it does not have an angle of motion, and then it defaults to -180 for some reason (left). If you set the speed by default to some small number like 0.1, it will be able to set the motion properly to 270 (up), but also immediately go back to 0 speed due to event 2. Then when you start moving again the correct angle of motion is already set.

    Second regarding the rotation speed, perhaps your original device was running at 30 fps to follow the road with /200, so the correct dt value would actually be /(dt*6000) instead. On both my computer (60fps) and phone (90fps) it now follows the road.

    However do note that this method of turning in general is subject to minor imprecision due to rounding errors and fps variations. You won't get the same exact result every time, but it should be enough to follow the road.

    dropbox.com/s/ngdd3lb57x8mgg2/CarTurning-updated.c3p

  • Yes, the engine will try to run at your monitor/system's refresh rate.

    Regarding your problem, it's not clear what your exact issue is from the information you have given. If you could create a minimal example project and upload that it would be much simpler to help you.

  • Well dt is the time between frames, so assuming you're getting 60 frames per second, dt*60 would equal 1, so dt*60*200 should equal 200, giving you the same result. What framerates are you normally getting on your devices?

    Edit: bullet.speed/(dt*12000) would make a difference

  • I scanned through my c3 library and didn't find an example for it, I may have made it in C2.

    Check out howtoconstructdemos.com/category/virtual-joystick , there are a few implementations there. See if you can adapt the way the virtual joystick is displayed to your sprite, it should be similar.

  • I used set position to center and move at angle every tick. Condition is that the analog stick is not in deadzone.

    Normally you have an else after this to reset to center, but if you don't then the reticle will remain where it is.

  • You would normally use families, which are groups of multiple objects.

  • You can use scale inner to chop off extremities instead.

    But the standard I would say is to use scale outer, and design for a larger viewable area. You don't necessarily need or want to stretch your assets, just plan for more to be viewable.

    construct.net/en/tutorials/supporting-multiple-screen-77

  • Actually in this case in a lerp it might be right to use dt, not sure. For the rotation you can try changing 200 to dt*12000 instead

  • Try replacing that with 0.1.

  • The host, upon receiving an input (or message) indicating the preferred choice from the peer, can spawn and associate the correct synced object for the peer.