Some screens of the bug:

<img src="http://img80.imageshack.us/img80/7523/lhittestdemo20080322173gr7.gif">

Tested, tested. It runs great, no issues with it being too fast. Some odd jumpiness with the lego blocks while running laterally, as they seem to... shift up and down like half a pixel, but, might be imagining it. Everything else seems fine; noticed the about screen, invincibility and such, but you said that's all intentional.

All in all, it seems great. Awesome stuff man. I like the gibs. Solid 85 frames per second, all screens. Oh.

Opstay on'tday ibgay.

Polka dots get to four-one-thousand, but perhaps I am just counting slow. Character doesn't jump while holding down.

I should probably have put this all in a PM.

I'm like the ONLY person here who ever surfaces complaint regarding such, but since I use dvorak, x and c are an odd layout. It's not hard to switch back, but something like ctrl and shift would be more universal. However, I am under the impression that userdefined controls are a possibility?

Perhaps this:

< arrow is left, ^ is jump, > is right, Ctrl is attack?

Okay, and I'm getting the random slight vertical shifting of all background graphics when I tap left and right spastically. The pink blocks fall out individually also, displaying their modular construction. Kudos!

I can, but it's totally up to you.

AMD Athlon 64 Processor 3700+, which is ~2.2GHz

NVIDIA 7900GT 256MB

2GB Kingston

19" Philips CRT

Motion Blur off and x20 move at the same speed, but x5 moves about twice as fast as that.

x20 is actually super fast here, so maybe it was just your loss of frame rate (is that possible with boxes) that made it the same as zero? Though I guess if Ashley's already fixed it this is irrelevant.

Then we just need normal mapping, haha.

That stuff looks cool deadeye. The scientist is very 'you', with the glasses. I look forward to seeing more of it, and what you're doing with the pixels.

My project is pretty immense and personal. It's mostly a test of game design and setting/character creation, little to do with Construct itself; Construct is just awesome, so it's probably what I will use to put it all together. The process yet involves a general outline of the world and story, character concepts, and a sad attempt at animating, haha. It's just roughed out but I'm thinking a lot more character could be added. Critique isn't really applicable to this image, it's old, but might be fun to look at.

<img src="http://img.photobucket.com/albums/v325/mwahaha/arrt/dmn/run01-copy.gif">

I haven't done a lot of 2D animation ever, so it's a huge learning process. However, it is fun, and I enjoy experimenting with it; surely doesn't hurt to play around. For this one, I cheated just to get a quick result. Referenced some screencaps of a video with someone running. I'll probably go out and find some learning material on animation when my life settles down and I can really dig into this sort of thing again.

In the end I plan to give him lots of animations and make things generally groovy, fast-paced and pretty. So, it should be an interesting journey.

You could try creating a system that, when the ball collides with the paddle, it is swiftly pushed back on track in whatever direction it is supposed to be bouncing. There are overlap and collision detection events that provide a great workaround for such issues.

It was not his intent to offend you, and I wish you had taken it more constructively.

Relax, in my opinion. Deadeye is peaceful and has some good points. However, it is doubtful anyone is going to stop you from posting what you want unless it becomes a serious problem to the forums.

The concept of a fun, fluid, lighthearted physics platformer with 3D elements totally reminds me of Little Big Planet. Did you see the videos for that? It's not come out for PS3 yet...

I really like the credits sequence concept. But don't really have anything else to say. It's neat. Are you making all the graphics yourself?

Yeah, I had a bit more polished system working with only one movement loop. What it did was keep track of direction, 1 being right, -1 being left, and add that to the x position when the movement loop was run. Construct ate the cap, though.

Keeping track of direction facing is useful for the sprite's animation, I would think. It had two animations worked out which were switched between when the direction variable changed. I'd also modulated player.xSpeed, so it would add smoothly. Could have different animations phase out when the speed exceeds a certain point, etc.

In my feeble fiddling however, before the cap combusted, the double-tap system was removed, and replaced with a 'run button' style a la Super Metroid, just for fun. It would gradually speed the player up.

You can just type them, but if you're going through the bottom object thingy in your event window, they're called "Get X position of * edge"... I'm thinking that if you nest some loops into movement to test overlap of objects, then individually test the edge positions, it could work? Will try it, but really don't know if it's any more efficient to introduce new queries.

Edit: Okay, I figured out a way to do it without either system. Dunno if it's accurate, but the result looks fine to me.

http://www.mediafire.com/?6lgnlltt21j

Yeah, I have it working that way, but the collision only recognizes the first wall object. Free of detectors, with leftmovement, checking that Sprite.Left is 'different to' Wall.Right correctly stops movement when hitting the left wall. The right wall however is simply passed through, because it's checking on the Wall.Left of the wrong wall object. Unless one wished to have distinct left and right wall objects, is there any way to solve this?

Something that references all instances involved...