Pinned Darius Gaiden EXTRA: Missing Background Layer on Zone D

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Only an issue on the multi: honestly, that was my impression too when I first had a quick look on this thread a few weeks ago. Came back recently and TMF68k's posts stood out to me. They seem to have a game cart very similar to mine; you can see the toggle switch that's used to switch between Gaiden and Gaiden Extra. "No, that can't be?" was my initial thought - went to check and yup, the bug is there, on a real cart (well, sans the changed ROMs due to it being a conversion). TMF68k also talked about how Extra always had bugs because it was rather unfinished and never an officially released game.

      Here is a video from my F3 system showing the spot where it happens:
      Darius Gaiden Extra ~ Stage D Bug ~ real hardware
      (missing background and water surface)

      Neither my Framemeister nor my OSSC were able to capture the F3 (an often discussed problem I'm sure you know of already, but not relevant here...). So a camera recording shall suffice for now.

      Furthermore, while I'm still baffled why it is that way, I've figured out how to make use of the patch (throw away every even byte). The filenames to overwrite I posted earlier were correct.
      Was curious to see what happens at the beginning of Stage D in MAME (I used the current version, 0.215), and tried four different configurations (see below).

      It's almost funny, because each configuration produces their own unique incarnation/appearance of the bug; the real hardware one is unique too, so that's five!

      Behind each link is a corresponding video capture (sorry for the missing audio). It has taken me some time to prepare all this ^^'
      1. Release MAME 0.215 build with official dariusgx romset
        (missing background)

      2. MAME 0.215 with the MAME workaround active, official dariusgx romset
        (meaning, commenting out the #ifdefs here, and adding "int m_f3_skip_this_frame;" here)
        (background appears, but the water surface is missing)

      3. Release MAME 0.215 with the patch from this thread applied to
        (missing background, missing ocean ground and extreme slowdown as soon as the ship goes underwater)

      4. MAME 0.215 with the patch applied *and* the MAME workaround active
        (background appears, missing water surface, the extreme slowdown returns, and part of the water surface pops up at the upper edge of the screen)

      So yes, the game technically works in MAME, but the bug still appears (at least in the current version, which should be the benchmark).

      Edit: that would mean that the patch is effective on real hardware, but only makes things worse on MAME?
      Well, MAME emulation certainly is not the best :) Look at the boss explosion, the smaller orbs are definitely behind/much more covered up by the bigger explosion. On real hardware they're clearly in the foreground.

      For confirmability, here are the sha1sums of the dariusgx romsets I used.

      Unpatched (official MAME):
      Display Spoiler

      802e91695a526f665c7fd261f0a7639a0b883c9e d87-01.bin
      07cae8edbc3cca0a95022d9b40a5c18a55350b67 d87-02.bin
      35ba7bcf29ec7a8f8b6944ee3544693d4df1bfc2 d87-03.bin
      003f98b740a697274385b8da03c78f3c6f7b5e89 d87-04.bin
      fd08d848079841c9237fa359a850980fd00114d8 d87-05.bin
      72cdeffedeab0c1bd0e47f03172085390a2be393 d87-06.bin
      ca53ea6641182c44a4038bbeaa5effb1687f1980 d87-08.bin
      28692b731ae98a47c2c5e11a8a71b61a813d9a64 d87-13.bin
      6eb238e47bc7bf635ffbdbb25fb06a37db980ef8 d87-14.bin
      256a6aeb5633fe1db407fad567169a9d0c911219 d87-17.bin
      402e26a05f1c3162fa3a8d3fcb81ef334b733699 dge_mpr0.bin
      841396911d26ddfae0c9863431e02e0b5e762ac6 dge_mpr1.bin
      4764355f51e207f4538dd753aea59bf2689835de dge_mpr2.bin
      eafde331c3be5be55d0d838a84017f357ff92634 dge_mpr3.bin

      Patched with files from this thread:
      Display Spoiler

      Only these are different:
      9d02e56e2cd2df9e9a9dadaf08016620ee1efa5b dge_mpr0.bin
      66da29d6c66c0f34362a2f1dcfc62ae68304ea55 dge_mpr2.bin

      The post was edited 1 time, last by 6t8k ().

    • @6t8k great analysis. As you can see the error is a bit complicated to find and troubleshoot. Luckily we have a working version for both the multi and original cart as was confirmed by @TMF68k.

      I'm not sure what else is to be fixed in the original.
      * Arcade-projects, the site where you get the most of your arcade games.
      * If you want Drama go to Neo-Geo forum ---Darksoft
    • The beginning of Zone X in Player 2 mode would come to mind. Let me quickly pick up on this past post as an entry point:

      maldoror68 wrote:

      Darksoft wrote:

      TMF68k/maldoror68: [...] black surfaces in Zone X in player 2 "marathon" mode [...]

      were these errors happening before?
      i don't know, someone must check on the "unfixed" version on the F3 darksoft, and play the marathon mode (it's long takes 1h30 ) until the X level.

      It happens without the Multi as well, as can be seen e.g. in the Wasshoi in Tokaigi 2015 stream.
      So I'd be very surprised if the Multi fixes it "unintentionally".
      In other words, the Zone X bug was there in the game from the beginning, was not introduced by your Zone D patch from this thread, and is as of yet not fixed anywhere (to my knowledge) :)
      MAME playthroughs show it as well, e.g. here

      A quick digression back to the Zone D bug; as it's easily confused (at least I struggled with it at first): the Zone D bug only happens when playing as player 1 ("normal" Extra mode). The Zone X bug only happens when playing as player 2 ("marathon" mode).
      What would be the Zone D of the player 2 mode (namely Zone P), is fine there. And conversely, Zone X, (and what can be seen of the actual player 2-Zone X graphics) in the player 1 mode, is fine there as well.

      When looking for MAME gameplay of the player 1 mode, I'm currently only able to find videos where Zone D looks fine (barring mine I posted above). That's what @djsheep meant I suppose.
      To me it looks like the MAME devs have introduced a regression recently.

      Back to the player 2 Zone X bug, following the comments of @maldoror68, I think it's kind of a philosophical question if Extra should be patched further, it's just what the game is.
      Seeing that Zone X is nothing as bad as the near-gamebreaking darkness that haunted Zone D, maybe it just adds to the charme. :)

      I myself don't mind it, but other opinions could prefer it to be further polished.

      As I understand it, there might also be something wrong with the BGM as per @maldoror68's reportings, but I would attribute that to the note above.

      Addendum: and as goes without saying, none of this is has to do with yer olde, standard Darius Gaiden ;)

      Addendum 2: OK, this is riddling me again. Player 1 mode. Zone X is completely different in TMF68k's video than in this one. Why is this so complex :'D
      Well, the above is still correct, Player 1 Zone X is fine in any case (as opposed to Player 2).

      e: TMF68k's video (this post) is normal Darius Gaiden - demonstrates how it *should* look in Extra. All A-ok.

      The post was edited 6 times, last by 6t8k ().

    • New

      Today I finally got around trying the patch on my F3 system with EPROMs (pic attached).

      Surprisingly, it does not work (video). I must be missing something, since apparently, it did work for @TMF68k?

      Like real hardware with unpatched ROMs, the background and water surface are missing.
      With the patch, the ocean ground is also missing and the extreme slowdown happens on the real hardware. Before, I attributed that to some MAME glitch.
      So this is another unique variation of this bug.

      Genuinely puzzled at the moment. Any ideas on what could be causing it?

      Supposing the ROMs are bad, I'd assume seeing all sorts of glitches or even a failure at boot time.
      Could my conversion cart / the other ROMs be different from TMF68k's?

      • dgx_cart_afterpatch.jpg

        493.64 kB, 900×600, viewed 5 times

      The post was edited 1 time, last by 6t8k ().

    • New

      6t8k wrote:

      Could my conversion cart / the other ROMs be different from TMF68k's?
      that would be my assumption. How different is the code that was on that Eprom from the one that you replaced. IIRC there is like 3-4 bytes difference.
      * Arcade-projects, the site where you get the most of your arcade games.
      * If you want Drama go to Neo-Geo forum ---Darksoft
    • New

      Right, 3 bytes are different overall.

      Attached two xxd | vimdiff screenshots (dge_mpr0 and dge_mpr2).
      On the left is the patch, on the right is the original ROM.

      Another theory that came to mind later is:

      I have read somewhere that the Multi does something with the addressing of the games (I could err on that). The aforementioned "bytes in between" could have something to do with it.
      These bytes are missing in the ROM files when making them usable on a real cart in the daredevil way I did.
      Could it be that the patch is actually not designed to run in a non-Multi scenario?
      The question remains, though, how TMF68k got it to run on their cart.
      The only explanation I have is that they developed their own patch based on the info available up until that point without explicitly telling so.

      But given your answer, that theory does seem to be disproven.
      • diff_mpr2_cropped.png

        61.1 kB, 1,800×300, viewed 3 times
      • diff_mpr0_cropped.png

        60.09 kB, 1,800×300, viewed 4 times
    • New

      6t8k wrote:

      Right, 3 bytes are different overall.
      Can you change ONLY those 3 bytes on the eproms that you have replaced? The 3 bytes can be in 1, 2 or 3 different eproms. Sometimes the files can be splitted differently depending on the PCB that you have.
      * Arcade-projects, the site where you get the most of your arcade games.
      * If you want Drama go to Neo-Geo forum ---Darksoft