Creating a ddp type laser

[shark1982]

From a 2d artwork and programming standpoint, can anyone expand on how Cave creates the laser shots in donpachi games? Is it broken into segments of some sort, or is it one continuous animated sprite? Suggestions or thoughts on how I should go about creating such for my own game?

[BPzeBanshee]

http://shmups.system11.org/viewtopic.ph ... 66#p750066

If you're using Game Maker you'll want to take a look at that. It is indeed one continuous animated sprite, the trick is not only drawing it that it only shows the part of the sprite up to where you need it but also collision handling.

I warn you though: in GM it's pretty damn performance-intensive which is why I removed it from GMOSSE (Rule #1: 60 FPS on my legacy PC) and why other alternatives may be better depending on how good you are at drawing lasers. It may be that you only really need a laser's sprite width to stretch on its x-axis if you use simplistic sprites that don't animate like how DonPachi does it.

[ptoing]

I think the DDP laser is actually not an animation but a tiling bit of graphic that just gets moved upwards and masked/cut off in some way. They might do it with smaller bits of animating tiles tho i guess, so that they can easily change the length of it in given sections. which they then can mask with the impact animation thing.

BPB: What are the specs of your legacy PC?

[Rozyrg]

I was thinking about that too. If you used sections, you could make it so that each of their starting image_index/animation frames follows the preceding in sequence, giving the sense of a smooth, flowing beam if done correctly.

Crappy mockup I threw together in GM: (It looks less crappy in motion, though. )

left side - first frame, right side - image repetitions.

Also, here's a simple game built using the above if you're interested in any of the collision stuff; although it might be a little messier to extract.

[BPzeBanshee]

BPB: What are the specs of your legacy PC?

1 Ghz Pentium III with nVIDIA RIVA TNT2 M64. Ironically Dodonpachi runs pretty well on it through MAME.

Rozyrg: nice animation!

I still find it difficult to believe that that sort of method is how the DDP lasers were done. Your example is good however I did notice it's actual collision not working very well against some enemies (it just passes through and doesn't seem consistent on which one it stays with), which is one of the problems S20-TBL and I had with our experimentations. In addition the DDP laser also has non-straight edges which flux, though I suppose with a bit of trickery you could just edit the sprite animation to do that with its edges.

[ptoing]

I did some screenshots using single frame advance, and the laser always moves up in 16 pixel steps, which leads me to conclude that the laser graphic is actually only 16 pixels high (the bit they have in memory) and it is 20 frames.

Look at this:


The thing in the top left is just the top of the laser to show where I think the laser starts, this does not really matter tho. The little 48x16 pixel graphic with 20 frames is all you need to make this laser. All you do is offset it by 1 frame each and place them in vertical spacings of 16 pixels and move that together with the ship, mask the top and bottom with extra animations, and you are done. I do not see any other way the laser is done in DPP, this is by far the most straightforward method of doing things like this.

[Rozyrg]

Rozyrg: nice animation!

I still find it difficult to believe that that sort of method is how the DDP lasers were done. Your example is good however I did notice it's actual collision not working very well against some enemies (it just passes through and doesn't seem consistent on which one it stays with), which is one of the problems S20-TBL and I had with our experimentations. In addition the DDP laser also has non-straight edges which flux, though I suppose with a bit of trickery you could just edit the sprite animation to do that with its edges.

Thanks. I love figuring out simple things like that as much as I do making really intricate stuff. Also, you could pretty much put whatever you want in between where the 1st frame is and where it repeats and just cut that up into the appropriate sized frames (which is what I'll do if I decide to reuse the code.) As for the collision...yep. In actuality, it's probably even less sophisticated than what we were experimenting on before. Like the rest of that game (which I put up on Yoyo just for the hell of it), I just put enough in for it to work honestly.

[BPzeBanshee]

EDIT:
Holy, crap, you're right. I took a look at Rozyrg's code and managed to put the DDP laser sprite in as a replacement and sure enough, it tiles just like in DDP!

However it looks like with this method it'll be very difficult to put in a collision method which actually works, and unlike the one S20 came up with there's just about no chance in hell this could be used for multidirectional aiming. If you do use this though, the code will work just fine with the DDP sprite (or any sprite you can animate well enough of around the same size) and if you get the collision handling fixed somehow it'd behave pretty close to Cave's own.

I spent a few hours mucking around with this and trying to get somewhere with it but to no avail. I'll send a message to S20 though, he might be interested in this.

[ptoing]

Hah, why would anyone mind Gogogo, looking forward to what you can do.

[BPzeBanshee]

Beat me to my edit.

Seriously though, trying to figure this one out gave me just as much a headache as S20's code, and Rozyrg's scripting methods conflict with mine enough that I get a headache just looking at it (no offense intended, I've always been a more simplistic coder). I think it might be a while before I get anywhere with this.

[Ixmucane2]

The little 48x16 pixel graphic with 20 frames is all you need to make this laser. All you do is offset it by 1 frame each and place them in vertical spacings of 16 pixels and move that together with the ship, mask the top and bottom with extra animations, and you are done.

What's the advantage of a small 48x16 sprite with 20 frames over a large 48x320 directly tileable sprite containing the 20 frames stacked together? I'd expect drawing up to two portions of the sprite (plus whole copies in case the beam is very long) to be less expensive than making many draw calls and easier than fiddling with frame numbers.

[ptoing]

Memory for one, also you still need to have a good way to crop the laser somehow because it is not always the same length. This would be a lot harder with one big image instead of something you can chunk of 16 pixel pieces. Also the fiddling with frame numbers is not very hard either, it is just a +1 increase as you go up or down. Not complicated. I think that actually masking of the laser would be a lot more fiddley if it was a big bitmap. I am not a coder, but I have some technical understanding of how this kinda shit usually pans out because I have been doing art for games for nigh on 8 years now.

BPB: Hehe, yeah I guess approach as far as coding goes matters. But from my view as an artist once I actually looked at DDP a bit closer it was super obvious that it is done this way.

[n0rtygames]

EDIT:
However it looks like with this method it'll be very difficult to put in a collision method which actually works, and unlike the one S20 came up with there's just about no chance in hell this could be used for multidirectional aiming. If you do use this though, the code will work just fine with the DDP sprite (or any sprite you can animate well enough of around the same size) and if you get the collision handling fixed somehow it'd behave pretty close to Cave's own.

Well that's just not true! You can rotate these kind of lasers however you want and still use the same technique. All you're doing is basically taking the relevant part of the texture as you traverse the length of the laser and drawing that on to the screen. If you keep your point of origin the same on each step of the laser, you can rotate this however you want.

As for collision, if you're firing your laser only straight up, or horizontally - then yes you can just get away with using a rectangle that perfectly fits the laser. Otherwise you do a series of overlapping checks at evenly spaced points along the laser in whatever direction it's travelling. CB once had an option to rotate your ship to take on enemies coming at you from all angles, but was ditched because I felt it was just too gimmicky.

My lasers use a big long image, much larger than the DDP laser. To the nay sayers about this approach, sure - you might save a small amount of memory on the texture itself but you're introducing WAY more draw calls if you use a smaller laser graphic as you need to draw it multiple times. I stack the laser on top of itself, so its twice the length of the original graphic and then scroll a source rectangle along that to produce the wibbly effect. Masking isn't too hard

[Shaman]

I did it in my game on Game Maker haha
Use surface if you're running on Game Maker, your laser pic has to be the max height possible (screen height), use a surface to draw it, because you can actually cut a surface in the middle of it so you only see the part of your sprite.
EDIT : I've written this about how to do it

First of all i have a sprite that is the whole screen long vertically (320 for me), its animation is the sprite moving vertically 20 pixels up each frame and looping into himself (that's very simple to do with character maker 99) so the sprite is composed of 16 frames.

Then i've programmed a surface for the drawing, surfaces can allow you to cut a sprite in the middle of it when you draw. That surface is starting just in front of the ship and ends at the first collision point, when you start shooting the surface has a progressive increase from the ship to the collision point (to fake the laser coming out from you).
That surface is drawing the sprite, so there you have the basic (and that was the hardest to find) part of the programmation.

For the damage, it's invisible objects that are spawned in front of the ship and going to 90° with speed 12, and they are locked to stay at the same X as the ship, on each step there's a x = ship.x command. The first of these objects goes at the same speed the laser is shot to avoid an enemy being it before the laser is touching him. On collision with an ennemy, these objects spawn another "flame impact" object on it that is not moving and lasting long (like 6 ou 8 frames only), there's a lot of these.

For the cosmetic part, there is a "head" sprite that you can only see if the laser is not yet touching things, when it's coming out, 2 sprites being drawn on your ship for the shockwave and shot effect

[BPzeBanshee]

I'm a little apprehensive about using surfaces as I've heard of stability/compatibility issues using them. On the other hand, the same source I heard that from said joystick support was impossible, and it's not like we're going for stuff that's 1000+ pixels in size (although some machines will actually cark it at 512 I think most of us devs keep the game size small enough to fit these constraints).

Well that's just not true! You can rotate these kind of lasers however you want and still use the same technique. All you're doing is basically taking the relevant part of the texture as you traverse the length of the laser and drawing that on to the screen. If you keep your point of origin the same on each step of the laser, you can rotate this however you want.

As for collision, if you're firing your laser only straight up, or horizontally - then yes you can just get away with using a rectangle that perfectly fits the laser. Otherwise you do a series of overlapping checks at evenly spaced points along the laser in whatever direction it's travelling. CB once had an option to rotate your ship to take on enemies coming at you from all angles, but was ditched because I felt it was just too gimmicky.

I think my comment on not being plausible for multidirectionality was more specific to Rozyrg's code. I'm not that great at reading his code but from what I tinkered with it was very reliant on going a specific direction at one time and it didn't even 'collide' consistently. In the method S20-TBL used (as seen above) it will rotate perfectly to wherever the mouse is

It seems to me that making use of draw_sprite_general to easily generate the laser itself (with a width the size of the largest dimension of your room) while using something more simple (underlying objects) for collision handling would combine the best of both worlds but I'm not sure how I'd make the underlying collision objects consistently stay under the laser (usage of lengthdir_x/y and ???), and then there's the tip.