The hotspot is the object's xy position as far as the game engine is concerned. The image of the sprite is drawn relative to the hotspot. So if the hotspot is at (0,0) on a 16*16 sprite, and the sprite is at (100,100) in the game, then it will be drawn in pixels (100,100) to (115,115). If, on the other hand, your hotspot was in the centre, your sprite would be drawn from (92,92) to (107,107), or there abouts.

You can use this to trick the player into seeing a 2D world that appears 3D. Imagine looking down on your game world from directly above at 12 0'clock, with the shadows of the objects acting as collision masks. If you were to tilt the camera upwards the shadows would appear below the objects and any objects off the ground would appear further from their shadows, but the game would still see the world in terms of the collision masks (i.e. the shadows).

I think a diagram may explain this far better than mere words, but I've been playing MegaMan 9 all night so I didn't get around to making that example I promised. It's coming, I assure you.

Can't help with that aiming issue though.

The trick is with the hotspots. You need to offset them to account for the height of the object, from the ground upwards. Your cannon ball is off the ground, but in 3/4 view your hotspot needs to be the centre point of the object on the ground. In this case, you need to shift the hotspot to account for the height of the ball. I'll try to put together an example or tutorial or something later today.

You need to do some Z sorting on your objects, since the view you are describing will have different objects obscuring each other based on how far down the screen they are. I'm making an assumption here, but if your game is based on the top-down 3/4 view (i.e. Zelda 2D games), then you will need to sort by Z.

The best approach i've seen uses a PV called Z. Every tick your objects set their Z to be equal to their Y, then you loop through all sortable objects based on their Z variable, and send them to back (or bring to front, can't remember now). It might take some fiddling of hotspots and image points to make it work properly, but the basics are all there.

This will mean that your cannonball will be drawn infront of objects that are further up the screen (i.e. behind), and vice versa. There was an example of this on the forums a couple of weeks ago, try looking for it.

can you set the sprite to check "overlaps at offset y+1 with vertical platform object", then deactivate gravity and directly set y to be the platform's y-height? Then just reactivate gravity when you jump. Don't have construct here, so can't confirm.

CVS systems store details of all revisions of every file in the project, so if you're using a website stripper to pull down a copy of the entire Construct CVS site, you may well be pulling down copies of every single revisions of every single file every uploaded to the CVS.

If you have a 'main.c' or something that has been revised 50 times, the CVS system will hold the current version of the file along with details of all changes made since the original upload, in terms of additions and deletions. This is stored as series of 'commits', likely as diff files. The online viewer for the CVS has links to all revisions, which would include a dynamically generated version of the file at that revision. Those links get recognised by your site downloader and it will download all those old versions that you probably don't need.

Do yourself a favour and follow lucid's advice - get a CVS program like tortoise, and download the source as a set of folders and not as an offline site dump.

I see what you mean now. I've also wondered about flipping sprites with regards to the hotspot position, although not with the idea of scaling to those magnitudes.

I suppose you could mitigate this problem a little, but not entirely, by using double or quad sized pixels (i.e. hs at [3,3] on an 8*8 sprite). If the hotspot is in the centre of this chunky pixeled sprite, it won't shift so much when you flip it.

the hotspot IS the entire pixel. This is the only way it can work - you can't place the hotspot in any particular part of the pixel - the coordinates for the hotspot are the exact same ones as the pixel it is placed in. When you are zoomed in, the pixel looks like it has a width and height, but this is deceiving - the pixel only has xy coordinates within the whole image.

1800 x 1800 is not very effiicient in terms of VRAM. You should be working with power of two sized textures - 2, 4, 8, 16, 32, 64, 128 .... 1024, 2048.

Your 1800 square image will actually use 2048x2048 pixels in VRAM, with over 200 pixels wasted in each direction. If I was you, I'd shrink it down to 1024, then stretch it up to the size you need. The texture should end up filtered and smoothed when you stretch it, and in motion you probably won't notice the reduced resolution.

Bear I mind that I often think I know what I'm talking about only to be proven wrong by more knowledgable folks, so take this with a pinch of salt.

Thanks for the reply guys. My plan was to introduce the CMB later on when things start to get more complicated. For the first couple of lessons, making games like PONG/Breakout, I was hoping to be able to keep things simple, i.e. Ball, 8-Way, etc. No big deal - the students probably won't even notice the inaccuracy (just my own perfectionism rearing its ugly head), and those that do can be pointed in the direction of the CMB.

As far as the expression is concerned, I was just wondering why "Ball[CustomMovement].Angle" works, but "Ball[Ball].Angle" doesn't.

I have made these two caps to illustrate an issue I'm having with the Ball behaviour.

The BB cap uses the ball behaviour. The ball has no randomness, so it should bounce at a steady 45 degree multiple. However, if you use the debugger, you can see that the bouncing has a very obvious variance to it.

The CMB cap uses the custom movement behaviour. The angles for speed, angle and collision response are basically the same, but in this case the ball bounces exactly as I expect it to.

Why is this? I don't have a problem using CMB for these things, but it would be so much more logical to use a ball. As far as teaching goes, I don't want to have to tell my students "don't use the ball behaviour for the ball".

On a side note - I could display the angle of movement for the CMB in the text object using the expression "Ball[CustomMovement].Angle", but I couldn't do the same thing with the Ball behaviour. Is there a way to do this?

Device name: Intel(R) 82945G Express Chipset Family

Pixel shader: 2

Estimated VRAM: 195 MB

Motion blur: No

My office PC - Yikes!

Ashley,

I've always thought it would be a good idea to have some way of attaching event sheets to objects, so that if you include an object in a layout it automatically includes the necessary events. Also, I was just thinking the other day how it would be awesome to have compound objects, or some form of grouping that goes beyond simple containers. What you describe sound like exactly that, and I really hope you develop this idea.