[Reverse engineering] DDP Daioujou Black Label

This is the main shmups forum. Chat about shmups in here - keep it on-topic please!
User avatar
austere
Posts: 680
Joined: Mon Mar 22, 2010 10:50 am
Location: USA

[Reverse engineering] DDP Daioujou Black Label

Post by austere »

So, I've been working on something recently. I've been reverse engineering DOJBL from top to bottom. I won't bore you with the details but I've figured out how a lot of the mechanics work, enough to get something interesting going:

Image

This is a modified version of DOJBL I call DOJBL+, which should be able to run on DOJBL boards and a modified version of MAME I've included below (with changes to source noted). If you hold A while pushing start to select a ship, it will run in "plus mode" which will display your hyper rank ("HR"), standard rank ("SR) and current frame number ("FN") when the game begins. I have no plans for additional modifications for now, except possibly replacing the frame number with bullet speed. Anyway you can grab the patch (obviously the romset is not included) and the modified version of MAME 141u1 here:

Patch for DOJBL+: http://www.mediafire.com/?hh2l9f8uuh15dg7
MAME for DOJBL+: http://www.mediafire.com/?n6y83z1bycx6cx3

There's also an unfinished technical guide, which should interest all DOJBL players and will finally reveal everything about hyper rank:

http://www.mediafire.com/?2q36bkpz3uesm7v

I will be updating it soon to cover standard rank, slow down, hyper gauge and whatever you guys want to suggest. I don't like sharing unfinished work, but I'm dumping some stuff here so that I can get my mind off this for a while.

Oh yeah, when the other dude releases his hacked version, I will consider allowing this version to skip the NVRAM check. The reason why I don't want to do this just yet is because not all the DOJ versions have been dumped and it would thus be ideal to avoid extinction of white label boards due to this modification. Of course, it's easy to identify because it boots straight into black label but I'll play it safe for now.
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
User avatar
NFG
Posts: 7
Joined: Wed Feb 16, 2005 11:48 am
Location: Brisbane.au
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by NFG »

Nice work.
Please stop confusing your opinion with fact.
User avatar
emphatic
Posts: 7918
Joined: Mon Aug 18, 2008 3:47 pm
Location: Alingsås, Sweden
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by emphatic »

Very cool, and very nice work!
Image | My games - http://www.emphatic.se | (Click) I have YEN stickers for sale
RegalSin wrote:Street Fighters. We need to aviod them when we activate time accellerator.
User avatar
Vyxx
Banned User
Posts: 1020
Joined: Wed Jul 01, 2009 1:13 pm
Location: Ontario, Canada

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Vyxx »

Interesting.
User avatar
ptoing
Posts: 1118
Joined: Wed Jan 11, 2006 10:36 pm
Location: Gurmany
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by ptoing »

Thanks. This is interesting from a game design/programing point of view as well. Good stuff.
User avatar
Frederik
Posts: 2554
Joined: Sun Nov 06, 2005 7:14 pm

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Frederik »

Very nice :)

Also, does that mean that it is theoretically possible to do more romhacking with these games? It would be fun to tinker with the games, for instance modify bullet count, scoring systems and whatnot - basically make custom "arrange" versions. Probably is much harder than I imagine it to be...I have no idea how this actually works :wink:
THE BULLETS ARE NOW DIAMONDS!
User avatar
austere
Posts: 680
Joined: Mon Mar 22, 2010 10:50 am
Location: USA

Re: [Reverse engineering] DDP Daioujou Black Label

Post by austere »

Thanks guys, there's more to come I promise, I just can't spare the time for a while.
Frederik wrote:does that mean that it is theoretically possible to do more romhacking with these games?
Yup, in it's current state it wouldn't take much work either. There's a nice slice of RAM you can use for additional variables. The only difficulty is the hardware itself since it supports 256 sprites and DOJBL uses 210 of those for bullets already! There's no room for additional bullets and you'd have to optimise the game a bit (alignment issues, pretty fiddle) to squeeze out some extra cycles. Actually, a lot of the subroutine calls are redundant as well.

What would be more interesting to me, is a portable port of the game... once the mechanics are completely understood, it's not as unrealistic as it seems.
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
User avatar
BarfHappy
Posts: 160
Joined: Fri Jan 14, 2011 11:20 pm
Location: In a CAVE

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BarfHappy »

Frederik wrote:Very nice :)

Also, does that mean that it is theoretically possible to do more romhacking with these games? It would be fun to tinker with the games, for instance modify bullet count, scoring systems and whatnot - basically make custom "arrange" versions. Probably is much harder than I imagine it to be...I have no idea how this actually works :wink:
You can shrink bullet count, you can modify the way enemies shoot, you can change the levels playlist pretty easily, change the way they move etc.
The game engine is pretty versatile anyway. If you want to do so, you can have ketsui enemy patterns within BLK. With some little work, you could have ketsui bosses within BLK, you ll need some more thorough RI though ahahaha (you ll have to go over other graphical elements, tanaka and wakabayashi will hate your guts). Of course you can change the scoring system, it all depends on how much you want to change. I guess that if you want to change too much, you are better off recreating the development framework to recalculate all the offsets, you ll need some pretty extentive assembler knowledge.

Just so you know, cave engine is not limited to 256 bullets, esp ra de implementation had a dual 199/299 bullets limit (at the time there wasn t really a need for too much bullets anyway, the only risk would be disapearing bullets anyway once the display list of the various hardwares is exhausted).
It is really funny to see the gap between the previous CAVE hardwares and SH3 ...
st5ex0boss/st5ex0boss.cpp, st5ex0boss/st5ex0b_appear.cpp, st5ex0boss/st5ex0b_disp.cpp, st5ex0boss/st5ex0b_move.cpp, st5ex0boss/st5ex0b_anime.cpp, st5ex0boss/st5ex0b_check.cpp

And there shall be TTLB... <3 Muwohohoho
User avatar
emphatic
Posts: 7918
Joined: Mon Aug 18, 2008 3:47 pm
Location: Alingsås, Sweden
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by emphatic »

austere wrote:What would be more interesting to me, is a portable port of the game... once the mechanics are completely understood, it's not as unrealistic as it seems.
For Dreamcast please. 8)
Image | My games - http://www.emphatic.se | (Click) I have YEN stickers for sale
RegalSin wrote:Street Fighters. We need to aviod them when we activate time accellerator.
User avatar
BarfHappy
Posts: 160
Joined: Fri Jan 14, 2011 11:20 pm
Location: In a CAVE

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BarfHappy »

emphatic wrote:
austere wrote:What would be more interesting to me, is a portable port of the game... once the mechanics are completely understood, it's not as unrealistic as it seems.
For Dreamcast please. 8)
Actually that s pretty possible, it just takes some time but not that much.
The real issue, to stay true to the timing, is to properly simulate the behavior of the graphics subsystem and CPU, and of course the real speed of the board and not NTSC/PAL. Making your speed and slowdown accurate is the real challenge, not transcoding the mechanics.
st5ex0boss/st5ex0boss.cpp, st5ex0boss/st5ex0b_appear.cpp, st5ex0boss/st5ex0b_disp.cpp, st5ex0boss/st5ex0b_move.cpp, st5ex0boss/st5ex0b_anime.cpp, st5ex0boss/st5ex0b_check.cpp

And there shall be TTLB... <3 Muwohohoho
User avatar
austere
Posts: 680
Joined: Mon Mar 22, 2010 10:50 am
Location: USA

Re: [Reverse engineering] DDP Daioujou Black Label

Post by austere »

Dreamcast wouldn't be a bad idea if it wasn't for the three frames of lag due to the PowerVR pipeline. I guess the PS3 would have similar difficulties...
BarfHappy wrote:Just so you know, cave engine is not limited to 256 bullets
The PGM VDP itself is the bottleneck, the engine obviously supports an artbiary number of bullets as long as it fits in RAM. I actually haven't taken a look at the other games (though I plan to when I have time) but it's simply a matter of changing the bounds on one of the loops to get more bullets for DOJBL. Not absolutely sure what the sprite limit was on the 1st generate cave hardware but it may have well been either 512 or 1024 from a cursory reading of the code in MAME. Around that stage, the limit might be the CPU rather than the VDP.

Can't make any claims about the rest of what you have said as I've only been looking at DOJBL.
BarfHappy wrote:you are better off recreating the development framework to recalculate all the offsets
There's plenty of free space on the ROM, as long as you can fit your stuff in there, it's just a matter of careful redirection. There are so many wasted cycles and opcodes it's not funny. This indicates that it has been heavily modified as you'd expect.
BarfHappy wrote:Making your speed and slowdown accurate is the real challenge
Slowdown, in this case, is not as difficult as you may otherwise be led to believe. ;)
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
User avatar
BarfHappy
Posts: 160
Joined: Fri Jan 14, 2011 11:20 pm
Location: In a CAVE

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BarfHappy »

I did a lil list on cavestg :) And yes there s plenty of room, heck there are 2 versions of the game on BLK you could sacrifice one xD

Esp Ra De: 199 and occasionally 299 (very seldom, not sure it is even triggered...)
DoDonPachi: 224
DoDonPachi DOJ: 210
Esp Galuda: 200
Progear: 260
Ibara: 720 afaik, perhaps 1000

I don't know about the DS games, i didn't inspect them.
anyway, i loved working on the CAVE engine, learned a lot with it.

Keep up digging though, that s a good hobby :p curiosity is human's best quality. And if you are on some deadend, just open a dev thread, perhaps i can help.
Last edited by BarfHappy on Tue Mar 29, 2011 8:37 am, edited 1 time in total.
st5ex0boss/st5ex0boss.cpp, st5ex0boss/st5ex0b_appear.cpp, st5ex0boss/st5ex0b_disp.cpp, st5ex0boss/st5ex0b_move.cpp, st5ex0boss/st5ex0b_anime.cpp, st5ex0boss/st5ex0b_check.cpp

And there shall be TTLB... <3 Muwohohoho
User avatar
austere
Posts: 680
Joined: Mon Mar 22, 2010 10:50 am
Location: USA

Re: [Reverse engineering] DDP Daioujou Black Label

Post by austere »

Yeah, there's all of white label for a sacrifice in this case, heh. Maybe we should share notes. ;)

By the way, do all of the 1st generation and PGM Cave games use the same slot system in DOJBL? I'm guessing that's Ikeda's handywork, it's a lot cleaner than the rest of the code base.
User avatar
BarfHappy
Posts: 160
Joined: Fri Jan 14, 2011 11:20 pm
Location: In a CAVE

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BarfHappy »

austere wrote:Yeah, there's all of white label for a sacrifice in this case, heh. Maybe we should share notes. ;)

By the way, do all of the 1st generation and PGM Cave games use the same slot system in DOJBL? I'm guessing that's Ikeda's handywork, it's a lot cleaner than the rest of the code base.
If you talk about the bullets slot, then yep, it is pretty much generic iirc. there is difference in Esp Galuda series though.
the enemies slots handling is the same as well. And in fact surprisingly, most was adapted to progear, offering capcom basically the CAVE shmuping knowledge.

It is really fun going through the code you can clearly see huge differences in the code style. I like that :p
You can clearly see clean, optimized code JSRing to amateurish code when an intern took over for a subroutine xD
st5ex0boss/st5ex0boss.cpp, st5ex0boss/st5ex0b_appear.cpp, st5ex0boss/st5ex0b_disp.cpp, st5ex0boss/st5ex0b_move.cpp, st5ex0boss/st5ex0b_anime.cpp, st5ex0boss/st5ex0b_check.cpp

And there shall be TTLB... <3 Muwohohoho
User avatar
mjclark
Banned User
Posts: 1384
Joined: Fri Aug 22, 2008 10:04 pm
Location: UK Torquay

Re: [Reverse engineering] DDP Daioujou Black Label

Post by mjclark »

austere wrote:So, I've been working on something recently. I've been reverse engineering DOJBL from top to bottom. I won't bore you with the details but I've figured out how a lot of the mechanics work, enough to get something interesting going.
Fantastic! This opens up whole new realms of possibility and is a really exciting project with enormous potential so please keep up the good work :D :D
Image
User avatar
PROMETHEUS
Posts: 2450
Joined: Tue Feb 27, 2007 1:00 am
Location: France

Re: [Reverse engineering] DDP Daioujou Black Label

Post by PROMETHEUS »

That is very cool work austere !
Scores, replays, videos || I have written a guide about getting good at shmups. Check it out !
Follow me on Twitch??
User avatar
BulletMagnet
Posts: 13888
Joined: Wed Jan 26, 2005 4:05 am
Location: Wherever.
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BulletMagnet »

More rank-o-meters are always a good thing - best of luck with the rest of the project.
User avatar
rtw
Posts: 1936
Joined: Wed Jan 26, 2005 6:46 pm
Location: Norway
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by rtw »

Very nice work austere :D

I'm curious about the slot system would it be possible to detail it a bit ? Feel free to illustrate with code samples :)
http://world-of-arcades.net
The future of ST-V rests upon our work and your work
User avatar
Udderdude
Posts: 6266
Joined: Thu Feb 16, 2006 7:55 am
Location: Canada
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Udderdude »

Is there any information on bullet hitbox sizes, or if the bullets that change sizes during their animation also change their hitboxes?
User avatar
Frederik
Posts: 2554
Joined: Sun Nov 06, 2005 7:14 pm

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Frederik »

Very interesting info, guys. Love reading about this kind of stuff!
THE BULLETS ARE NOW DIAMONDS!
User avatar
bitkid
Posts: 148
Joined: Sun Mar 23, 2008 3:36 am
Location: Violent City
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by bitkid »

Hey BarfHappy how do you know so much about Cave engines?
User avatar
austere
Posts: 680
Joined: Mon Mar 22, 2010 10:50 am
Location: USA

Re: [Reverse engineering] DDP Daioujou Black Label

Post by austere »

rtw wrote:Very nice work austere :D

I'm curious about the slot system would it be possible to detail it a bit ? Feel free to illustrate with code samples :)
Yeah sure. The main loop of DOJ does a few things:

- update game counters
- update inputs/input deltas
- a mystery update routine
- a sprite related routine I don't fully understand
- slowdown routine (wait for vblank routine completion basically)
- run all 'slots'.

The slots are basically routines with their own memory space and called on with fixed parameters. The game adds slot 8 before running the loop. In-game the only slot change happens during the score tally screen as far as I can tell.

In order to add those rank meters at the bottom, I hijacked the game state finalisation slot.
Udderdude wrote:Is there any information on bullet hitbox sizes, or if the bullets that change sizes during their animation also change their hitboxes?
I honestly haven't taken a good look at the bullet array code. It's a queue of some sort, 0x40 memory locations per bullet, if I recall correctly. It seems BarfHappy has taken a better look at it.
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
User avatar
BarfHappy
Posts: 160
Joined: Fri Jan 14, 2011 11:20 pm
Location: In a CAVE

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BarfHappy »

Udderdude wrote:Is there any information on bullet hitbox sizes, or if the bullets that change sizes during their animation also change their hitboxes?
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).

And how to i know so much ? ahaha long story. It dates way back to ibara PS2. And i dug much more when i got the full AC code thanks to mame.

Anyway, many question on the engine i should be able to answer, i spent weeks in mandays on cave engine. xD
st5ex0boss/st5ex0boss.cpp, st5ex0boss/st5ex0b_appear.cpp, st5ex0boss/st5ex0b_disp.cpp, st5ex0boss/st5ex0b_move.cpp, st5ex0boss/st5ex0b_anime.cpp, st5ex0boss/st5ex0b_check.cpp

And there shall be TTLB... <3 Muwohohoho
User avatar
rtw
Posts: 1936
Joined: Wed Jan 26, 2005 6:46 pm
Location: Norway
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by rtw »

austere wrote:Yeah sure. The main loop of DOJ does a few things:

- update game counters
- update inputs/input deltas
- a mystery update routine
- a sprite related routine I don't fully understand
- slowdown routine (wait for vblank routine completion basically)
- run all 'slots'.

The slots are basically routines with their own memory space and called on with fixed parameters. The game adds slot 8 before running the loop. In-game the only slot change happens during the score tally screen as far as I can tell.
So what you saying is that the slots are really function pointers in an array which are setup by the main code and executed ?

@BarfHappy
Could you please explain the bullet slot system in a bit more detail ?

All this is very interesting :D
http://world-of-arcades.net
The future of ST-V rests upon our work and your work
User avatar
austere
Posts: 680
Joined: Mon Mar 22, 2010 10:50 am
Location: USA

Re: [Reverse engineering] DDP Daioujou Black Label

Post by austere »

Yeah kind of, actually "function pointers" are obviously very common in 68k code. The reason why I call them slots is because you can reorder them, queue up other tasks from within them and they'll still have their own independent area in memory. It's really a neat system, though you have to be careful with the upper address registers.
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
User avatar
Frederik
Posts: 2554
Joined: Sun Nov 06, 2005 7:14 pm

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Frederik »

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 .
So basically if the hitboxes of the bullets were visible it would look like this?

Image
THE BULLETS ARE NOW DIAMONDS!
User avatar
BarfHappy
Posts: 160
Joined: Fri Jan 14, 2011 11:20 pm
Location: In a CAVE

Re: [Reverse engineering] DDP Daioujou Black Label

Post by BarfHappy »

Yup i can see the imagz now and yes that s it :p


rtw wrote: @BarfHappy
Could you please explain the bullet slot system in a bit more detail ?
All this is very interesting :D
I think you wonder how bullets work, there you go (that s all based on my memory of it i may be a little off depending on game implementations):
The bullets are all properly cleared at the start of a level. (zeroed for all but Y value which is FFed).
When an enemy fires a bullet, it creates a spawn entry which in turn translates to the copy of the master values from the bullet type table (in CPU area) to the definitive bullets entry in memory at the proper location (at the first available space).
It starts its life as a spawning bullet, which is in fact the plumet you can see when en ennemy fires some types of bullets. A plumet does not collide.
Luckily i have an old description table at hand here :p
The bullet has:
status byte (plumet, active, destroyed) with the 4th bit indicating if the bullet collides or not.
type byte
Y value (CAVE float,word, 1 byte for int value and 1byte for decimal value)
X value
Y conv. parameter, word, used to convert gamespace to screenspace iirc
X C.P
sprite offset, dword
sprite format, word
bullet cancel sprite offset end, dword
bullet cancel sprite to sprite max, dword
speed manipulation counter, byte
speed manipulation counter max, byte (0 for infinite)
byte: ?
1A
Y speed, cave float (updated from a precalc table for elyptic moves)
X speed, cave float (updated from a precalc table for elyptic moves)
pointer to the sprite frame handling
user counter byte
user counter max (0 for infinite) byte
entry trace A+B 2 words (i don't remember what it is used to diagnose sorryyyy, i just remember it is a slight alteration of the original speed reading)
user counter 2 byte
user counter 2 max byte
working value 1 byte
working value 1 byte
Initial Speed Y cave float
Initial Speed X cave float
Looping count A
Looping count B
user counter 3
user counter 3 max
user counter 4
user counter 4 max
bullet speed, cave float
0000

Aaanyway, once the creation is done, after exhausting the plummet animation, the bullet transforms into a real bullet, the 4th bit is flipped.
at each frame, some key positions are checked (Y value iirc) and if they are set, the number of bullets entries available increase accordingly.
At each frame, the bullet position (center) is checked against gameworld boundaries, if they are outside, the status is set to 0, the type to 0 and the Y position to FFFF.
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.
at each frame the sprite frame is changed, the change of frame and looping are handled by the routine at the pointer contained in the bullet structure.
The bullets Y and X positions are altered with the Y speed and X speed values. These values depending on the bullet type is either fixed or changing. When they are changing, their value is read from a table of Y+X speed entries. The various user counters are used to control the way speed values are read.

I don't know if that answers your question xD
Last edited by BarfHappy on Thu Mar 31, 2011 4:27 pm, edited 2 times in total.
st5ex0boss/st5ex0boss.cpp, st5ex0boss/st5ex0b_appear.cpp, st5ex0boss/st5ex0b_disp.cpp, st5ex0boss/st5ex0b_move.cpp, st5ex0boss/st5ex0b_anime.cpp, st5ex0boss/st5ex0b_check.cpp

And there shall be TTLB... <3 Muwohohoho
User avatar
Jockel
Posts: 3071
Joined: Tue May 20, 2008 5:15 pm
Location: Berlin, Germany
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Jockel »

Bullet spawns. Serious business.

(Honestly though, insane write-up!)
User avatar
Udderdude
Posts: 6266
Joined: Thu Feb 16, 2006 7:55 am
Location: Canada
Contact:

Re: [Reverse engineering] DDP Daioujou Black Label

Post by Udderdude »

This is starting to look like it belongs in Development .. (j/k)
User avatar
yosai
Posts: 274
Joined: Wed Jun 11, 2008 9:37 pm
Location: London

Re: [Reverse engineering] DDP Daioujou Black Label

Post by yosai »

Great work on the hacking! Some very useful information in there and thanks for sharing it. :D
Image
Post Reply