Glamthaus's Forum Posts

  • You are a man after my own heart Arsonide. I love this kind of stuff.

    Very interested to see how this turns out. Keep up the good work.

  • Freakin' ace. Haven't looked through it all yet, been real busy, but I'm sure it's all class.

    Thanks for making the tutorial Dave. I really appreciate it.

  • Awesome. Just... awesome.

    Ima chargin' my expectations for this tutorial.

  • Enjoy

    http://dl.dropbox.com/u/666516/c2010demo.exe

    LMAO, that was awesome. Good job.

  • I plan on releasing the tutorial then looking at another library (plus interpolation/prediction) to handle online lag.

    <3

    I already have a decent understanding on how one would write predictive net code so bring on the tutorial.

    Looking forward to playtesting some online gamage with my friends/brothers.

    Thanks again Scidave, you are a gentleman and a scholar.

  • Very cool indeed.

    I would love to have a looky at the cap for this. Looking forward to the tutorial regardless.

  • well construct can do 3d, but not in this sense, you have to scale back and using a sprite for each quad is seriously gonna cause some slowdown.

    Scaling back is a given.

    I disagree that using 1x1 distorted sprites as quads is less efficient than using 'meshes'; in all of my testing, meshes yeild noticably lower FPS.

    I hope that rumour about proper mesh support holds true. Would makes things much easier in the future .

  • And suddenly, a new contender emerges.

    Very cool man, and more efficient than my own obj loader by a pretty decent margin (I think, can't check using my own computer at the moment).

    3500~ faces at 35 fps is pretty impressive knowing how unsuited Construct is for 3D.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Very very awesome. You're always full of surprises Davo.

    I have uploaded an alternate version below that supports any aspect ratio and screen size instead of the default 1:1 ratio.

    Just change the window width and height, and change the 'Player2View' canvas to the same size (it is 800x600 in this example, which is 4:3 ratio).

    Enjoy.

    http://dl.dropbox.com/u/3541668/Split%2 ... ernate.cap

    EDIT: Is there any chance we'll ever get the option to change the Canvas size at runtime without stretching? It is currently impossible (I think, prove me wrong) to make the above automatically scale to DisplayWidth and DisplayHeight due to the Canvas stretching.

  • Thanks, that works better. Something is still a bit off tho, the particle object will start to leave the objects x,y after about 300 pixels.

    trange, works perfect for me, are you using scrolling? Use the following if so:

    ((Sprite.X - (ScrollXLeft + DisplayWidth*0.5)) * 100/(100 - Sprite.ZElevation)) + (ScrollXLeft + DisplayWidth*0.5)

    ((Sprite.Y - (ScrollYTop + DisplayHeight*0.5)) * 100/(100 - Sprite.ZElevation)) + (ScrollYTop + DisplayHeight*0.5)

    Other than that, I'm not sure what the issue might be. Throw me your cap if you still have issues.

    EDIT: Let me know if you're going to need help with transforming the Size, Speed, Acceleration, etc, of the Particles. I might make a cap/tutorial to save you some time instead of this slow back and forth if so.

    EDIT2: Just noticed you were in chat, I'm in there for about the next 20 to 30 minutes if you need help directly.

  • Yeah sorry about that, error on my part, should be:

    Always

    Particles set position to

    ((Sprite.X - DisplayWidth*0.5) * 100 / (100 - Sprite.ZElevation)) + DisplayWidth*0.5

    ((Sprite.Y - DisplayHeight*0.5) * 100 / (100 - Sprite.ZElevation)) + DisplayHeight*0.5

    By 'Where Object.Value('X') is Object.X before any Z emulation', what I'm really trying to say is don't do the following.

    Always

    Particles set position to

    ((Particles.X - DisplayWidth*0.5) * 100 / (100 - Particles.Value('Z'))) + DisplayWidth*0.5

    ((Particles.Y - DisplayHeight*0.5) * 100 / (100 - Particles.Value('Z'))) + DisplayHeight*0.5

    The 'Particles.X' would need to be what value X you want it to be pre-Z emulation, whereas here after a single tick it would be Z emulated, then Z emulated again, and again, exponentially, making it a complete mess. I hope that makes sense.

  • LOL, awesome + humorous all rolled into one.

    I also suck at it hard.

    I'll keep trying. Can't help but hum along to 'Ai Oboete Imasu ka.'

  • EDIT: The following is assuming I understand your meaning correctly. Ignore otherwise .

    Emulating Z height is actually pretty easy. Only thing you need to know is the Z co-ordinate of the Camera, which is 100.

    CameraZ is the Camera Z Co-ordinate EmulatedZ is the Z height you wish to fake Object.Value is the value you wish to offset by the emulated Z height

    The basic formula is:

    Object.Value * CameraZ / (CameraZ - EmulatedZ) or

    Object.Value * 100 / (100 - EmulatedZ)

    For anything that does not involve the X/Y axis (Size, acceleration, speed, etc):

    Object.Value * 100 / (100 - EmulatedZ)

    Where Object.Value is the original value before any Z emulation.

    For Object.X its:

    ((Object.Value('X') - DisplayWidth*0.5) * 100 / (100 - EmulatedZ)) + DisplayWidth*0.5

    Where Object.Value('X') is Object.X before any Z emulation.

    For Object.Y its:

    ((Object.Value('Y') - DisplayHeight*0.5) * 100 / (100 - EmulatedZ)) + DisplayHeight*0.5

    Where Object.Value('Y') is Object.Y before any Z emulation.

    The DisplayWidth and Height parts are basically telling the Z emulation where the Camera's X and Y are focusing, so it can emulate accordingly. Remove them if you want to see what I mean, the Z will be focused at 0,0 rather than the center of your screen.

  • Funny how looking at other people's code can confuse the hell out of you.

    You've given me some ideas, and how I would go about achieving what you have, but I'll be buggered if I can understand how yours works, lol.

    Cool though.

  • Awesome update!