[Reverse engineering] DDP Daioujou Black Label

[austere]

Cool shit BarfHappy. I almost don't want to read it in detail because I'll be dragged back into it again (and I'm really behind on my studies)! I won't be able to help myself though.

[rtw]

@BarfHappy, thank you very much for this detailed information

To recap:
A bullet is instantiated from a master type, initialized according to the current situation and then put on a runlist which is processed by a function (BulletProcessor) ?

When a bullet is no longer visible does the BulletProcessor remove it from the list or mark the slot as empty ?

Is this bullet algorithm used on the newer SH3 boards as well ?

I have heard that this bullet algorithm was first conceived at Toaplan. Has anyone had a look at Batsugun to see if it behaves in a similar fashion ?

[BarfHappy]

Yep you got it. I had some fun changing bullets for others, give them faster speed (and changing enemies counters so they release more of them xD ). I had fun altering the levels playlists as well, but that s another story.

back to the bullets.
only the first 4 bytes are modified to deactivate a bullet slot, 0000 FFFF, the rest remains, the big cleanup only occurs at the beginning of a stage but that s not of a big use except debugging readability.

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.

[Despatche]

It'd probably go back to Grind Stormer/V-V at least.

[austere]

Doubt it, DonPachi is probably quite different to DoDonPachi for example.

we could see a portion of code from deathsmiles, and it was clear that the engine was not really overhauled xD

Why overhaul perfection. ;)

[BarfHappy]

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.

[austere]

So if you reverse engineer one Cave game, you've reversed engineered them all!

What about the hitboxes? I'm almost dead certain there's something strange going on in DonPachi.

[BarfHappy]

So if you reverse engineer one Cave game, you've reversed engineered them all!

What about the hitboxes? I'm almost dead certain there's something strange going on in DonPachi.

Nha, esp galuda is not part of the normal tree, that s why i set it apart.
Donpachi, to be honest, i have forgotten about it, I ll check it at home, i don t have it here xD i just happened to have batsugun on my phone (i have a mame setup on it so i can plug it to whatever computer as USB drive and play for some minutes, but i automatically enable debugger xD i love seeing the code behind my games)

Anyway, you know they add code, change bits and pieces, but when you steprun the games for hours on hand to debug, you get quite an eye for similarities
I love that kind of stuff, i guess i am abnormal, heck, i even debugged RAID pci BIOS for American Megatrends Japan (-of the AMIBIOS fare- they ran out of business, i hope this is not my fault ).

[austere]

Anyway, you know they add code, change bits and pieces

Oh of course, of course, I was exaggerating a little bit.

but when you steprun the games for hours on hand to debug, you get quite an eye for similarities

So that's your methodology. :) I tend to use interactive disassemblers these days, though a decade ago I was known for my SoftICE-skills, heh. I cheated a little to figure out standard rank for DOJBL though...

[Dave_K.]

So all bullets in these Cave games discussed use a single point for their collision detection? I find this rather hard to believe given the variety of bullet sizes, and my personal observations playing. I can see larger obstacles being entities with real hitbox dimensions, but was sure that bullets had varying size centers. Perhaps the code is tracking the center location, but bullet square size is factored in when computing the collision against the player's hitbox?

[BarfHappy]

So all bullets in these Cave games discussed use a single point for their collision detection? I find this rather hard to believe given the variety of bullet sizes, and my personal observations playing. I can see larger obstacles being entities with real hitbox dimensions, but was sure that bullets had varying size centers. Perhaps the code is tracking the center location, but bullet square size is factored in when computing the collision against the player's hitbox?

Nope, all bullets without exception are only checked on the center.
when they check larger (like big flame balls, saws etc) they are in fact enemies not bullets.
that is ONLY for non-espgaluda games hey :p

i went back to the dev forum:
here is the exact algorithm of cave engine (version DOJ). deltaY1,deltaY2,deltaX1,deltaX2 give the hitbox of the player

if(bullet flagged as non colliding) skip to next bullet
deltaY1=0x100
deltaY2=0x80
deltaX1=0x80
deltaX2=0x80
D0=YShip+deltaY1
D1=YShip-deltaY2
D2=XShip+deltaX1
D3=XShip-deltaX2
D4=YBullet
if(D4>D0) skip to next bullet
if(D1>D4) skip to next bullet
D4=XBullet
if(D4>D2) skip to next bullet
if(D3>D4) skip to next bullet
Set bullet as collided with ship
if(not invincible) go to ship destroyed
process next bullet

[rtw]

i went back to the dev forum:

Thanks for the update!

May I ask which dev forum you are referring to ?

[BarfHappy]

I just meant the dev subforum i already explained it to soneone in need. Btw nice to see you here (i m mikeneko from cave

[rtw]

I just meant the dev subforum i already explained it to soneone in need. Btw nice to see you here (i m mikeneko from cave

Hello mikeneko, awesome discoveries

[mjclark]

Really getting captivated by this now! Love the guide to DOJ hyper rank (especially the flow chart!) but where can I find a brief summary of standard rank mechanics? Looked in Strategy section first but there it says "Rank is increased only by using hypers"

[KNTain]

This is such a baller thread.

Thanks, austere and BarfHappy.

[austere]

where can I find a brief summary of standard rank mechanics?

I'll explain it more thoroughly in the guide when I get time to look at it more carefully (and that time should be briefer thanks to BarfHappy/Mikeneko's description of the bullet structure) but basically:

- Standard rank goes up by 1 every 256 (0x100) effective frames. I say effective because when there is slow down, vertical blanks are actually consumed by the slow down routine (but the vertical blank routine is still run since it's triggered by interrupt 6, obviously).
- When not in hyper mode, it tops off at 240 (0xF0) in the first loop, 248 (0xF8) in the second loop.
- When in hyper mode, your hyper rank multiplied by 16 (0x10) is temporary added to the standard rank and capped off at 255 (0xFF) regardless of the current loop.
- Your standard rank reaches its height at 1-4, assuming you beat the bosses fairly quickly. In fact the game pushes you up to the upper limits when you enter the second loop regardless of what the frame counter is.
- Your starting rank is not zero, in fact, there is a base rank at the beginning of each stage. For normal mode, this base rank is:
Stage 1-1 52 (0x34)
Stage 1-2 68 (0x44)
Stage 1-3 84 (0x54)
Stage 1-4 100 (0x64)
Stage 1-5 100 (0x64)
Stage 2-1 onwards: N/A

The standard rank affects bullet density and firing rate but like I said, I need more time to distill any other effects.

[mjclark]

Thanks again austere! So is standard rank affected by dying and bombing also (when not in hyper mode)- guess I can just look at the SR counter in DOJ+ and work that one out for myself
I also noticed from that previous DOJ strategy thread that there was a (rumoured) ROM hack for Battle Garegga that displayed a rank meter. Does anyone know any more about that?

[austere]

Dying will not reduce the standard rank (except of course, through taking you out of hyper mode which will reduce the temporary increment). There's really nothing you can do about it, the frame counter is not reset when you continue either. The only way you can reduce the standard rank is to kill the bosses faster.