[Verasev]

I'm doing projectiles by writing them on the overlay. What's the best way to check if a particular projectile is colliding with a particular sprite.

[Wervyn]

Probably not to write projectiles to the overlay, you end up having to do a lot work for collision handling yourself this way. The method I've used in the past for this is to draw projectiles to a viewport-sized sprite, layer the sprite over the view, and then just set a collision box for each individual projectile and let the built-in sprite collision handler do the rest. That way you can get both proper multi-character and object collision AND know what thing a projectile collided with just by looping over a list of projectiles and a few lines. I take it as a given that you've got a list of these things already and that you're redrawing them all every cycle if they're all moving, so this doesn't actually add much overhead to what you'd already be doing. I've basically described the setup you need for this in my old sprite tutorial, so take a look at that for details.

[Dr Lancer-X]

I typically have a sprite specifically set aside just to do collision checks - put it on the board somewhere then just do a bunch of if c00 sprite_colliding. Wervyn's method sounds like it could fail to detect off-screen collisiions, but that might potentially even be desirable depending on your needs.

There's also just using the 'if c?? Sprite p?? # #' method, but it fails to respect individual sprite collision settings so if you are using these, best to go with the above method.

Oh, and I've also got a tutorial of sorts about projectile engines, although it's less recent. Also, it uses a linked list, which is a really awful thing to do.

[Maxim]

Dr Lancer-X, on 08 April 2017 - 05:12 PM, said:

tutorial of sorts about projectile engines

This is one of the best things ever written on projectile systems. Read it slowly, multiple times and you will understand.

[CJA]

I'm guessing this projectile system isn't set up to use sprites at all, right? You can also use a temporary 1x1 sprite. When you init, set its width, height, and use xpos and ypos to reference some non-blank offscreen character. Or vlayer (0,0)... that usually works. You can put it on top of your projectile for a cycle to check and then move it away. A few hundred put commands per cycle... is that such a sin?

[Verasev]

Thanks, Wervyn and His Excellency Lord Doctor Lancer-X.

This post has been edited by Verasev: 10 April 2017 - 08:06 PM

[Dr Lancer-X]

CJA, on 11 April 2017 - 01:09 AM, said:

You can put it on top of your projectile for a cycle to check and then move it away. A few hundred put commands per cycle... is that such a sin?

It's unnecessary though. You can use it to check for collisions as long as the sprite has been put somewhere, no matter where that is. So you can put it at 32767,32767 if you want.

[Verasev]

I tried adapting Wervyn's example to what I was working on and screwed it up. I can't figure out what I've done wrong. The projectiles aren't showing up at all and it seems like the engine is instantly removing them or they aren't getting added in the right place or something. I've zipped up what I have. Could someone look it over and fix it and tell me precisely where I messed it up? Arrow keys to move, X to shoot, C to swing your sword (that works right, at least).

Attached File(s)

•  TestProject1.zip (26.56K)
  Number of downloads: 2

[Wervyn]

Three things. First, you reference but never define "bminx", "bminy", "bmaxx" and "bmaxy". These should be initialized in the global robot to the dimensions of your playing field, which according to your player movement are 0,0 and 80,25. Since the bullet layer is using math on these to set its size, right now it's a 0x0 sprite and won't show up.

Second, in your #drawbullets subroutine, you're doing this:

copy block at "#&spr_pb_x&" "#&spr_pb_y&" for "spr_pb_w" by "spr_pb_h" to "#('lyr_pb_x'+'pbullets&loopcount&_x')" "#('lyr_pb_y'+'pbullets&loopcount&_y')"

However, the sprite references you're using for your bullet art are actually on the board, you never did anything to put them on the vlayer. So instead you want this:

copy block at "spr_pb_x" "spr_pb_y" for "spr_pb_w" by "spr_pb_h" to "#('lyr_pb_x'+'pbullets&loopcount&_x')" "#('lyr_pb_y'+'pbullets&loopcount&_y')"

Finally, your attempt to copy the overlay to the vlayer to clear the bullets for redrawing won't work, once you make the first two changes you'll find that nothing ever gets erased. This is because copying with the overlay treats character 32 as a transparent mask, to leave whatever currently exists on the target alone. This is why I had you make a blank.mzm, which I see you've done in the global. So instead of doing this:

copy overlay block at 0 0 for 80 0 to "#0" "#0"

Replace that with this:

put "@blank.mzm" Image_file p02 at "#&lyr_pb_x&" "#&lyr_pb_y&"

All of the bullet art is drawn facing the same direction right now, so I'll let you sort out how to reference the correct directional art yourself for now unless you need some further help with that.

[Verasev]

Okay, I did precisely what you suggested as far as I am aware. It is giving me an error message. "Error: File is not an MZM or is corrupt. Debug code:6660h." It continues you to do this everytime I press O for OK, forcing me to exit megazeux through the windows task manager.

[Graham]

Did you create a .mzm file? If not, create one named blank.mzm. You can look up how to do this in the help file if you've never done it before.

[Verasev]

The problem got fixed nicely in the discord chat.