BarfHappy is the one to study and disassemble how bullets work in CAVE games. The disassembly is from DoJ but he claims that the CAVE bullet engine is universal. These posts lend evidence to the collision flipping occuring in at least all non-ESPGaluda games. (This isn't to say that collision flipping isn't in ESPGaluda, he just hasn't looked!)
http://shmups.system11.org/viewtopic.ph ... 39#p672939
BarfHappy wrote:In CAVE engine standard implementation (excluding esp galuda series), enemy bullets are only checked for they center, even big ones, and so only once every 2 frames. So they can go right through you when you move. Don t bother escaping lines of large bullets, because they are only 6-8 dots to pass, imagine that each bullet is just a point at their center, you ll fare much better at the games xD .
Saws and other special bullets are made as enemies and are checked like enemies (and spawned like ones).
http://shmups.system11.org/viewtopic.ph ... 93#p673393
BarfHappy wrote:at each frame if the bullet is set to be collision detected it is checked against the player collision box through successive testing (i put a description in the development part of the forum somewhere with the exact code), if collision happens, tough luck, you die.
at each frame the collision bit is flipped.
http://shmups.system11.org/viewtopic.ph ... 60#p673660
BarfHappy wrote:And yep they kept it the same throughout afaik, it is easy to struct a bullet entry rewriting to C so that it acts the same way.
At least for ibara/mushihime+f

There s a bit more information in there, but the basics remain.
To be frank, I don't really know for deathsmiles, MMP, PS and DFK, i ll tell you more in a couple years when i can see their code :p
Esp Galudas are a different beast, i never studied them.
There was a picture in here somewhere, where in the background of a picture of some big shot (IKD perhaps, don t remember) we could see a portion of code from deathsmiles, and it was clear that the engine was not really overhauled xD
I would be surprised if the code came from toaplan, could you imagine, the same engine spanning from batsugun to DFK ?
I ll have a look at batsugun and see if indeed there are common chunks.
http://shmups.system11.org/viewtopic.ph ... 91#p673691
BarfHappy wrote:OK i quickly checked batsugun, and quickly this IIIIIIIIIIISSSSSSSSSS a quite surprisingly similar beast in some aspect.
However, there is one thing to note, not for bullets... it uses the same header for active bullets, except the active and colliding bit are 3 and 1 instead of 4 and 2. but other wise bullets operation is much more rudimentary and quite different.
at first glance float operations and transformation from gamespace to screenspace seem to be comparable.
it uses the same level playlist system:
a table gives gives the appearance of ennemies:
frame, offset, type, move table entry
then the move table which is the offset into the motion description table
and finaly the motion description table
motion description is: Y appearance value; X appearance value; and the actual move coded in several bytes(depending on the enemy types the move structure is different).
enemies motion handling is similar, i have not yet checked the enemies structure to see the way they fire if it is counters based like cave engine.
so, suprisingly, the level setup is a cave-engine style. If you want my opinion, cave used toaplan level designer tool, i see no other explanation.
(I would love to see a definitive 'Yes, this game does collision flipping' or 'no, bullets are dangerous every frame in this game' listed beside each Cave game, btw)