Hello!

I am currently making a platformer and i have managed to program my own particle effects like wind and smoke (though they are probably far from optimised). Though i have been stumped with jumping. I would like to use pget() to get the colour of the tile below you so when you jump, little pieces of the same colour will fly up and then land in all directions. I would appreciate some help or perhaps some sample code for me to study. Thanks!

Hello!

For jumping and other platform things, you could study this code: https://www.lexaloffle.com/bbs/?tid=27626

I like the idea of particles using the color of the ground tile!

Let’s say your player is on a grass tile like this picture:

You already have player coordinates, the blue X/Y on the top-left corner of the sprite.
I think the idea would be to transform X to be at the center of the sprite (X1) and transform Y to be the feet of the sprite (Y1). Then, X1/Y1+1 will be the coordinates of the pixel at the center of the top row of the tile under your player. Call pget function to get the color!

@merwork Thanks! Whilst this is still helpful, I was more struggling with the particles themselves, so they arc towards the floor then stop.

Hello again.

Although I didn't get back to playing it, your improvements on Bermeja looked good. (I'm hoping here that I have correctly remembered you as the creator of the game.)

What Merwok says is correct. It's roughly col=pget(p.x+v,p.y+8)

where p is player, and v is any value (or all values) from 0 to 7 presuming your player sprite is 8 pixels wide (and high).

You then create a table of pixels and give them a life that counts down 1 every frame, then in a loop over each pixel pix if (pix.life < 1)del(pixtable,pix)

or whatever condition you want for keeping the pixel table small. You also give them whatever other data you need such as x,y,xd,yd so you can update them every frame or so. (If you have a standard level for your land, rather than testing to see if they're falling and have collided with land, you can just let them fall/exist until their y>groundlevel, which should avoid some collision detection processing, but I doubt that you have a standard groundlevel, so some collision detection will be necessary, then a smaller bounce and after a couple of bounces, deletion.)

Also, there are a couple of things you might encounter.

The first is rather obvious - the pixels need to be generated before moving the player (or with the previous_x, previous_y of the player).

After that, it gets less obvious. If you're using pixel detection with pget and there are other elements on screen that can get drawn over the background (and these comments are going to presume this, because for example clouds could obscure the landscape pixels), then the pixel detection has to occur a) after drawing the parts of the background you want to detect, b) before drawing anything that might go over it.

This has the consequence that parts of your draw code may end up in your update code, or vice versa, which I'll presume you don't really want. (At least, I believe it will have these consequences. If it doesn't, great! And my advice could then be disregarded.)

So it can be cleaner to use something a little less direct. Presuming you're putting sprites down for your background, the chances are you have a way of knowing which sprite is (or which 2 sprites are) under the player. You can then get the pixels of this (or these) using sget(x,y)

which gets pixels from the sprite sheet. Presuming n is the sprite you're looking at, the formula for the first (top left) xy postion is sget(n%16*8,n\16*8)

- that's from memory, so do check it (I make mistakes). If you're only interested in the top pixels of the sprite, you leave the y as it is, and give the x a +i where i is a variable that changes from 0 to 7, and you can then add one or more random pixels from the top of the sprite to your jump_particle table.

Disclaimer: Any code in this is untested. My thoughts on this are based on a badly written cart from last night - I was too tired to write it (and it did not anyway go so far as to get pixels from the sprite sheet as I have suggested) - so my conclusions could be erroneous through tiredness.

Note: I've just read your comment to Merwok; perhaps none of what I've written above is of any help with the bit you're having trouble with, but anyway, perhaps some of it will help someone else. :)

@remcode This is exactly what I needed! I just needed some general ideas of how to get started. Thanks for the kind words on Bermeja! I have taken down the pre-alpha as I'm planning to release the full game with music and the full (pretty good and plot twisty if I say so myself) plot! I'll implement this code and if you would like, I'll put you in the 'special thanks' part of the credits :)

@RaspberryPye Glad I could help. I'm looking forward to the release. Being mentioned in the credits would be fairly awesome. :-D Thanks.

@remcode