Hitscan weapons

[cxong]

This will also require drawing the bullet, in a way that has nothing to do with its hit detection.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[cxong]

On updating the bullet, it will need to draw out a line to the destination, checking collision at each tile, and step (if tile is not empty). An easy way to do it is to give it a suitable speed, then update in a loop until its range is complete.

To represent, add a bullet attribute IsHitscan. This way we can still reuse the speed/range variables for pushback and range calculation.

For drawing, we'd probably want a new attribute: HitscanFrames. This controls which % of the flight path we want to draw the bullet sprite per frame. That is, if the value is 3, the first frame will draw the bullet 1/4 of the way between shooter and target, the second frame 1/2, and the third frame 3/4. Add a random offset so repeated shots actually look like an unbroken path instead of discrete points. Will probably need to experiment with this to get it to look right.

Weapon ideas:

• Laser
• ~~~Rework the nuke fun gun to use laser indicator~~~ Add laser pointer
• Stun gun (short range, petrify effect - rework petrify to an electrocute effect instead?)

[cxong]

Depends on #372

Since hitscan weapons play nicer with antilag, we may want to change some existing weapons to be hitscan too, like:

• Pulse rifle
• Pistol
• New shotgun?
• New sniper?

Also, with the addition of bullet mass (#444) it doesn't make sense to use speed/range anymore. Instead:

• Speed = "Inf" - not really valid JSON double, but since we're parsing using atof, this works
• Range still used, but purely for animation now (see comments on the HitscanFrames)
• RangeHitscan used for the actual range now, in subpixel units

[cxong]

Actually, with #372 (almost) done, hitscan weapons aren't any different from normal weapons - they just move really fast. So they are still represented using Speed and Range - range just being 1 usually for an instantaneous movement, and Speed being how many subpixel units they move.

But then there's the question of how to draw the trail. This could be done using SDL_RenderCopyEx, possibly with a new TrailPic attribute. But be careful - SDL_RenderCopyEx may not be compatible everywhere.

[cxong]

Another cheap option is to draw a simple line with SDL_RenderDrawLine

[cxong]

This is actually going to depend on #440, since trails need to be part of the map, occluded by walls etc.

[cxong]

Warning: GCW-Zero has a bug where SDL_RenderCopyEx is broken - it always renders unrotated at 0,0. Will need a workaround, or disable trails for GCW-Zero.