[Reverse engineering] DDP Daioujou Black Label
[Reverse engineering] DDP Daioujou Black Label
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:
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.
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.
Re: [Reverse engineering] DDP Daioujou Black Label
Nice work.
Please stop confusing your opinion with fact.
Re: [Reverse engineering] DDP Daioujou Black Label
Very cool, and very nice work!
| 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.
Re: [Reverse engineering] DDP Daioujou Black Label
Interesting.
Re: [Reverse engineering] DDP Daioujou Black Label
Thanks. This is interesting from a game design/programing point of view as well. Good stuff.
Re: [Reverse engineering] DDP Daioujou Black Label
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
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
THE BULLETS ARE NOW DIAMONDS!
Re: [Reverse engineering] DDP Daioujou Black Label
Thanks guys, there's more to come I promise, I just can't spare the time for a while.
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.
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.Frederik wrote:does that mean that it is theoretically possible to do more romhacking with these games?
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.
Re: [Reverse engineering] DDP Daioujou Black Label
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.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
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
And there shall be TTLB... <3 Muwohohoho
Re: [Reverse engineering] DDP Daioujou Black Label
For Dreamcast please.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.
| 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.
Re: [Reverse engineering] DDP Daioujou Black Label
Actually that s pretty possible, it just takes some time but not that much.emphatic wrote:For Dreamcast please.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.
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
And there shall be TTLB... <3 Muwohohoho
Re: [Reverse engineering] DDP Daioujou Black Label
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...
Can't make any claims about the rest of what you have said as I've only been looking at DOJBL.
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.BarfHappy wrote:Just so you know, cave engine is not limited to 256 bullets
Can't make any claims about the rest of what you have said as I've only been looking at DOJBL.
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:you are better off recreating the development framework to recalculate all the offsets
Slowdown, in this case, is not as difficult as you may otherwise be led to believe.BarfHappy wrote:Making your speed and slowdown accurate is the real challenge
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
Re: [Reverse engineering] DDP Daioujou Black Label
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.
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
And there shall be TTLB... <3 Muwohohoho
Re: [Reverse engineering] DDP Daioujou Black Label
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.
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.
Re: [Reverse engineering] DDP Daioujou Black Label
If you talk about the bullets slot, then yep, it is pretty much generic iirc. there is difference in Esp Galuda series though.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.
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
And there shall be TTLB... <3 Muwohohoho
Re: [Reverse engineering] DDP Daioujou Black Label
Fantastic! This opens up whole new realms of possibility and is a really exciting project with enormous potential so please keep up the good workaustere 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.
-
PROMETHEUS
- Posts: 2450
- Joined: Tue Feb 27, 2007 1:00 am
- Location: France
Re: [Reverse engineering] DDP Daioujou Black Label
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??
Follow me on Twitch??
-
BulletMagnet
- Posts: 13901
- Joined: Wed Jan 26, 2005 4:05 am
- Location: Wherever.
- Contact:
Re: [Reverse engineering] DDP Daioujou Black Label
More rank-o-meters are always a good thing - best of luck with the rest of the project.
Re: [Reverse engineering] DDP Daioujou Black Label
Very nice work austere
I'm curious about the slot system would it be possible to detail it a bit ? Feel free to illustrate with code samples
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
The future of ST-V rests upon our work and your work
Re: [Reverse engineering] DDP Daioujou Black Label
Is there any information on bullet hitbox sizes, or if the bullets that change sizes during their animation also change their hitboxes?
Re: [Reverse engineering] DDP Daioujou Black Label
Very interesting info, guys. Love reading about this kind of stuff!
THE BULLETS ARE NOW DIAMONDS!
Re: [Reverse engineering] DDP Daioujou Black Label
Hey BarfHappy how do you know so much about Cave engines?
Re: [Reverse engineering] DDP Daioujou Black Label
Yeah sure. The main loop of DOJ does a few things:rtw wrote:Very nice work austere
I'm curious about the slot system would it be possible to detail it a bit ? Feel free to illustrate with code samples
- 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.
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.Udderdude wrote:Is there any information on bullet hitbox sizes, or if the bullets that change sizes during their animation also change their hitboxes?
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
Re: [Reverse engineering] DDP Daioujou Black Label
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 .Udderdude wrote:Is there any information on bullet hitbox sizes, or if the bullets that change sizes during their animation also change their hitboxes?
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
And there shall be TTLB... <3 Muwohohoho
Re: [Reverse engineering] DDP Daioujou Black Label
So what you saying is that the slots are really function pointers in an array which are setup by the main code and executed ?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.
@BarfHappy
Could you please explain the bullet slot system in a bit more detail ?
All this is very interesting
http://world-of-arcades.net
The future of ST-V rests upon our work and your work
The future of ST-V rests upon our work and your work
Re: [Reverse engineering] DDP Daioujou Black Label
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.
Re: [Reverse engineering] DDP Daioujou Black Label
So basically if the hitboxes of the bullets were visible it would look like this?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 .
THE BULLETS ARE NOW DIAMONDS!
Re: [Reverse engineering] DDP Daioujou Black Label
Yup i can see the imagz now and yes that s it :p
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
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):rtw wrote: @BarfHappy
Could you please explain the bullet slot system in a bit more detail ?
All this is very interesting
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
And there shall be TTLB... <3 Muwohohoho
Re: [Reverse engineering] DDP Daioujou Black Label
Bullet spawns. Serious business.
(Honestly though, insane write-up!)
(Honestly though, insane write-up!)
Re: [Reverse engineering] DDP Daioujou Black Label
This is starting to look like it belongs in Development .. (j/k)
Re: [Reverse engineering] DDP Daioujou Black Label
Great work on the hacking! Some very useful information in there and thanks for sharing it.