madster's Forum Posts

  • both 32 (lappy) and 64 (desktop) bit here, so I can make a fair comparison.

    64 bit's main benefit seem to be just access to my full 4Gb RAM. 64 bit dll's can't link to 32 bit program (nor can 32bit link to 64) so this bring incopatibilities in software that takes plugins... such as photoshop. Yeah. Don't go 64 bit there.

    Games are usually 32 bit... yet logitech insisted to force 64bit install on my wheel's drivers, so I get no force feedback (at least I think that's the reason).... so..... no gain, really, unless you need to handle huge memory loads.

  • Anyway, enough baloney.

    But.... but.... I like baloney!

    I also like Spam!

    when did all processed meat become so unfashionable? >_<

  • Hm. I have a tendency to not explain too clearly, so I'll elaborate.

    As for depth within a sprite. Your right, a default sprite in a default 2D world has no depth, being two dimensional.

    But what's stopping you from having depth? Consider a parallax effect, 10 layers all scrolling at a different speed. It's 2D, it has no depth. But what if the artwork on each of those layers were given a depth. The artwork in the background layers would be further away than those closer. You couldn't see the difference to look at it. But what if you then applied a DoF shader that takes depth maps into account? You've got visible depth.

    okay, say you have depth per object. This depth is..... PER OBJECT. So, any light occlusion effects will happen PER OBJECT.... thus doing them PER PIXEL is overkill. Just fake it with another object, as it will essentially be a drop shadow. DoF also doesn't make any sense in 2D. I did post a variable blur shader, that when applied to a whole layer accomplishes what you'd probably call DoF... but it's way simpler and doesn't rely on depth.

    [quote:1b9vt8q2]But give him a depth map, where his arm is closer, like an inverted height map. Add an SSAO shader on that, you've got realtime ambient occlusion.

    So you have a frame-based animation. This animation has a depth animation, where each frame has a corresponding depth map. This depth map has a SSAO shader. Notice that since SSAO is calculated on the depthmap that only changes with each animation frame, the results will also only change with each animation frame...

    Now, consider baked ambient occlusion. You only have animation, no depth... you have REAL AO, since you'd get it from your renderer of choice. No shader. Results also change with each animation frame.

    Same effect, half the texture memory, much faster, much simpler.

    Thus, SSAO in 2D is pointless.

    I only say this because I see a lot of people go and play Crysis or whatever and then come back and excitedly ask for something they saw there to be in Construct.... but VERY FEW 3D effects make sense in 2D.

    All that said, I'm still onto that blurred drop shadow effect. I've realised, though, that it's much easier and faster to have a smaller, stretched shadow object that follows the real one... why? well, it allows for some other effects that I'll attempt soon

  • I'm a girl who actually pats my neighbor's cat.

    That only makes it more awesome.

    I'm kidding! I'm really kidding

  • I'd like to point out that Norton really, REALLY ****** It's a paranoid system hog that won't keep you safe anyways.

    It used to be good back in the Win95 days =(

  • shouldn't it grab the layout AFTER drawing?

  • "pat" the neighbor's "cat"

    wink wink nudge nudge you know what I mean

  • I'd like to insist on how SSAO is pointless in 2D.

    Allow me to explain:

    SSAO is occlusion, independent from light sources, based on the depth difference between each pixel.

    Construct is 2D (mostly). What's the depth difference within a sprite? Zero. Always. What if you want to have a heightmap with heights? well, then the depth difference will be always the same, since the normal never changes..... so, the occlusion will always look the same and you're better off baking it, EVEN IF YOU USE NORMAL MAPPING.

    And if you layer one sprite on top of another? well that's why I suggest drop shadow.

    I'll try upping the pixel shader version and see if it's enough. I'm bumping into a lot of limits there (registers too)

  • Sweet. Thanks!

  • I'm hitting arithmetic instruction limits for PS2 when blurring the shadow with a 5x5 kernel.

    Blurs should really be done in two passes

    Since the kernel is symmetric, I'll try storing a quarter of it then doing each op four times.

    with less taps it would be useless.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This is why I wrote Heightmap Plus.... but sometimes heightmaps don't cut it and you really need to use a normal map.

    I plan to introduce a normalmap plus effect at some point, with an angle input to compensate effortlessly. You could do the math in events, but yeah it's a bit hard.

  • Any ideas how to lower the lag even more, to the twoframes from the Madster explanation?

    I know it looks like it is more, but it isn't. We're just more sensitive to mouse lag than to button lag.

    Also, it's two frames AND A VSYNC.

  • AFAIK 0 becomes left (or top) and 1 is right (or bottom) of the screen.... screen which is rotated along with the sprite.

    Yeah.

  • now try intensity at 2

    then do

    System: Always (every tick)

    SpriteSet position to Sprite 0 .X+3, Sprite 1 .Y+3

    bgmoonnormalBumpmapping : Set Light X to 0.5+(cos(timer*0.01))

    bgmoonnormalBumpmapping : Set Light Y to 0.5+(sin(timer*0.1))

  • I know a bit about this, so I guess I'll explain.

    To draw a frame you need to calculate it first. so:

    input -> framebuffer.

    Input is where the game picks up your commands and framebuffer is the screen. This is a 1-frame lag. This is the minimum you can get, there's no way around it. Think of this as an unlimited framerate, single-buffered game.

    This isn't so hot, because you're drawing directly to the screen. If your drawing code takes longer than a screen refresh, the scene might be half-drawn when presented.

    input -> backbuffer -> framebuffer

    So this is double buffering, where you can hold one frame in a backbuffer and draw to that one, and when it's done you copy that one to the framebuffer. This means your commands will show up two frames later.

    input -> backbufferA -> backbufferB -> framebuffer

    And of course, triple buffering is the same idea, just bigger.

    All of these were with unlimited frames per second (fps).

    Now what happens with vsynch?

    let's see the most common double-buffer scenario:

    input -> backbuffer -> VSYNC -> framebuffer

    the backbuffer is copied to the framebuffer only on a VSync, which happens 60 or whatever times per second. So now your input is delayed by one frame plus the time it takes to the next VSync.

    With triple buffering.... yeah

    input -> backbufferA -> backbufferB -> VSYNC ->framebuffer

    your input is delayed by two frames and one Vsync.

    Now, most video cards have a hardware mouse cursor, which is calculated in paralell to the rest of the screen drawing stuff and it's directly overlaid on top of the framebuffer, that's why it responds so well.

    I hope this clear things up. To sum:

    The fastest cursor will ALWAYS be the OS' cursor, followed by the 2-frame delay that's minimum for DirectX, with no VSync and doublebuffering.