I've added information about capsule generation, virus generation and just now how the gravity works to the Dr. Mario wiki article. Check there for a description of how the game works.
Cool cool cool! It's not every day you get to learn new stuff about how Dr. Mario works. =) Could you please explain some more about how the gravity works? Say you start at HI speed and then you drop 100 pills, if I understand things correctly you get an index of 31+10 = 41, and the corresponding number in the gravity table is 6... So what does this 6 mean? Does the speed increase by 6 units? Or is it like 1/6 = 0.1666...G? Also, perhaps I'm a bit nit-picky, and if so I apologise, but in the wiki it says: Indexes 0-25: (35 - index) * 2 - 1 and the gravity table goes to 79... Shouldn't the lowest possible index be at the start of LOW, 15+0 = 15, and the highest index be when the speed counter tops out on HI, 31+49 = 80? Anyways, really awesome work! Very interesting to read.
The entries in the gravity table are in frames per row, so 6 means the capsule will remain in the same row for 6 frames before dropping one line. I've edited the wiki page to include this little detail. I'll have to analyze Dr. Mario a bit more to figure out the maximum index, and see if 80 is the real maximum. I know the index minimum must be 15, but the game stores indexes 0-14 in ROM, so I included those values in the gravity table. And if 80 is the real maximum, then some random byte in ROM after the gravity table is the number of frames per row for index 80.
Okay, cool. So if it's frames per row and 79 is the highest index then 70 would in practice be the point were speed didn't increase furthert, since both index 70 and 79 corresponds to 1 frame per row. However, I got inspired by this and so I played 20 HI just now without clearing all the viruses, and waited till 490 pills, and I must say I definitely felt an increment in speed around that value(counted in my head while playing so I don't know about the exact value). It went from playable speed before 490 to crazy speed after 490. It felt like the game wouldn't let me move the pills fast enough to be able to continue on playing. So I got maybe 30 more pills before I died.
Hi all, Just wanted to resurrect this old thread to say "thanks" to nightmareci for the excellent work decompiling/transcribing the Dr. Mario virus generation algorithm (along with the other useful info in the wiki)! I am working on writing a Dr. Mario clone in javascript that can be played in the web browser, and this info was an indispensable part of my quest to make it loyal to the old NES original. I now have all of the basic gameplay working for one-player mode. I'm working on a network multiplayer mode as well, so you can play against others over the internet. I also need to design it, right now it's just basic colors and blocks... But once I get those parts working, I'll post a link to it in here! I can think of no better beta testers than all of you... Thanks again, -dan
I just checked back here after a long while. Please do post the link when ready! I'd love to beta test it.
Wow! This thread is a goldmine of information. I'm learning a new language so I thought dr.mario would be perfect to reimplement because of so few properly finished ones. Couple of questions though: For the virus generation, What is the purpose of this? Why not just generate a random number in range [1, Virus_Level.Maximum_Row]? Also, running test.sh gives me this... Code: ./test.sh 5,17c5,17 < B--R--BY < RYBRRBYR < RBYYBRYB < YRRBYYBB < YRB-YBRR < -BYRRBYR < BYYBRRYY < R-BBYYBB < YBRR-YBR < BBY--R-Y < RRBBYRRY < R-BRYBR- < --Y----- --- > -------- > -------- > -------- > -------- > -------- > -------- > ----B--- > -------- > -------- > --R----Y > -------- > ---R---- > -------- Is it because I'm on an x86-64 machine and this was intended for 32 bit machines? I guess it doesn't really matter since the pseudo code is available on the wiki. How does the 2p revenge system work? What I've noticed is if 2 or more lines are cleared, the opponent will receive the number of lines cleared up to 4 Most of the time, the colors cleared are going to be the same colors that appear on the opponent's side. However, this happened so that throws that theory out the window Unless it's because more than 4 consecutive cells being cleared, it takes higher precedence? The last thing(I think) is the placement of the punishment blocks... It doesn't seem to follow any pattern!? Is it really just random and I'm overthinking it? I've also noticed that if blue is cleared first, followed by a red, then blue will always be left of the red on the opponent's screen.
Sorry, I just checked out the test script, and it turns out I had defined VIRUS_LEVEL as 0, instead of 20, which was what was used when the test.txt file was generated. I've also just compiled and tested on my x86-64 system, and the test script outputs nothing (which is what should happen, if the bottle program's output is identical to test.txt). After looking over bottle.c, nothing in it looks CPU-dependent, so it should work on any platform. I've attached the same drmario.zip package as before, but VIRUS_LEVEL defined as 20. I didn't think of investigating the versus behavior, but I'll work on that.
Hello! Sorry to bump this out of nowhere, but I'm working on my own Dr. Mario clone as programming practice for a casual game jam, and happened upon the Tetris Wiki explanation of the algorithm. First of all I'd like to just say I think it's amazing that people will dive this deep and share the information, thank you so much! However, I'm having trouble implementing the algorithm myself. I looked through the C code nightmareci provided but my only experience is in self-taught C# and I have no clue about bitwise operations etc. so it is almost impossible for me to follow. The issues I'm having working from the Wiki's pseudocode explanation: 1. Treating Y=1 as bottom and Y=16 as the top (Step 4), doesn't the loop in Step 7 result in pushing things above the earlier defined maximum top row, if the Y value is indeed incremented? 2. When step 9 returns to step 7.1 specifically skipping the loop, doesn't this mean that from then on, there is no check if the new incremented cell position is filled or not? My literal implementation currently overwrites cells with already placed viruses, resulting in the wrong amount. Is there something I'm not getting here, or are there perhaps inaccuracies in the explanation? (I assume the actual code is accurate but again, I don't understand enough "real" programming to read it ...) In any case, this is already way more information than I expected to find on this very specific problem, so thanks anyway!
Here's a C# version of the virus generator, in a command line program. It's my first C# program (I learned C# just to write it), so it might be ugly, but at least there's no bitwise operations.
Hey, sorry for the bump Thanks for the information . I found this page via this paper and the code you made will be very useful to me. I'm curious about the newer versions that can safely place up to 96 viruses. After reading the paper its obvious why it can't safely generate more than 88 viruses so I wonder what improvements they made in future titles to allow the 96 viruses. However there seems to be no information on other versions. Earlier you mentioned disassembling the SNES version. Was anything discovered?
I've never disassembled the SNES version, I only said I might do so. But now that you say its randomizer could differ from the NES version, I'm more interested in investigating it. I'll get on it. It's nice to see my research came in handy for someone.
Thanks, that would be very useful I have one other question about the mechanics of Dr M. The only source I can find on how fast the player's pill drops when holding down is this page. If I'm reading that right then its basically saying the pill will move down twice as fast (1/2 Gravity). However when I implemented double-speed it feels too slow and in the original it looks like the pill is falling *much* faster. Do you know what the formula for this speed is?
No, the only analyses I've done of Dr. Mario NES are of the capsule and virus generation. But I could go back and get the drop speed formula.
TASers for Dr. Mario have worked on analysing a number of different mechanics of the game. The latest publication's submission text has a link to a Japanese article, which itself has links to some code on virus and piece generation. According to that page, soft drop is only processed on even frames, which makes it 1/2G.
I get the feeling my definition of "G" isn't the same as everyone else's (For me its the number of frames a pill stays on a row before moving down). By that do you basically mean "When Soft-Dropping, the piece falls one row every 2 frames"? And I assume if the pill start falling at 1 row every frame then we don't even bother checking the soft-drop checks otherwise that would be a way for users to "slow down" the drop speed. If so that would make sense. I'll read more into those pages tomorrow EDIT: OMG that remove glitch is insane! I guess they never intended getting such a high combo.
"G" is defined as the number of rows fallen per frame. G measures rate (how often a piece moves down a row), which is the inverse of periodicity (how long a piece stays on a row before moving down). Example: 1G = 1 row/frame 1/2G = 1 row / 2 frames 2G = 2 rows/frame.
Thank you guys for your research. I just released the initial version of my Dr Mario clone using your work https://tetrisconcept.net/threads/new-dr-mario-clone-moving-day.3895/