Create mame2003-updates-XML.dat #3
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is @riverstorm 's updates DAT file. It will need updates from the NeoGeo driver (this will happen soon) but is otherwise up to date. @Arcadez if it's OK with you to add this here I think it will help move forward with testing to have it as part of the repository.
ghost
merged commit 
ghost
mentioned this pull request
This was referenced May 6, 2018
ghost
mentioned this pull request
This was referenced May 31, 2018
ghost
mentioned this pull request
ghost
pushed a commit
that referenced
this pull request
Oct 2, 2018
ghost
mentioned this pull request
ghost
pushed a commit
that referenced
this pull request
Jan 7, 2019
MAME WIP 0.119u3: David Haywood fixed colors in Dynamite Duke. Changed palettesize from 3072 to 2048 colors. 3rd October 2007: David Haywood - The source of most of the problems in Dynamite Duke was the strange way in which the background layer was being decoded and handled. The biggest problem is that 1 bit of data for each pixel was being completely overlooked. Dynamite Duke's background decode was 5bpp, not 6bpp. If that was all there was to it then it would have been a very simple fix, however, the problems were deeper than that. Neither of the upper 2 bits of the data are used in the traditional sense, to simply extend the available colour palette. Ignoring the 6th bit for now, the one that was being used as transparency, I started looking at the bit that wasn't being decoded, the 5th bit. There was clearly data there, it wasn't just unused rom as you'll sometimes find. Infact the data present conincided with the tiles that were being rendered with the wrong colours in the game, logically everything would suggest that the decode was simply missing a bit, and hooking that up should fix the colours as it would then be able to address the correct colours. It didn't. Usually if you increase the bpp of a set of graphics it allows the colours directly after the current palette to be addressed in addition to the ones already being used. For Dynamite Duke something different was going on. Regular System: 4bpp decode | Pal#1 Colours 0-15, Pal #2 Colours 16-31, Pal #3 Colours 32-47 and 5bpp decode | Pal#1 Colours 0-31, Pal #2 Colours 32-63, Pal #3 Colours 64-95, for Dynamite Duke however: 5bpp decode | Pal#1 Colours 0-15 & 256-271, Pal #2 Colours 16-31 & 272-287 etc. Basically the extra bit is being used by the hardware more as a palette bank bit, grabbing the extra colours from a completely different part of the palette. I needed to clean up the driver a bit, remove some palette hacks that were already in there, and rework a few things, but by implementing that logic I at least got the right colours on all the scenes, except one, the map scene. For the map scene it turns out there was another error in the driver. As the previous decode didn't allow for accessing of colours above 255 one of the layer disable bits had been incorrectly hooked up as a palette bank, probably because the map screen happened to have that layer disabled and also by chance needed the higher palette codes. An easy mistake to make. Removing that hack, and correclty hooking up the layer disables had the advantage of also getting rid of some garbage sprites left on the screen during 'continue' etc. That just left the 6th bit, marked as transparency. Finding out the use for that was pretty straightforward, it quickly became clear that it was actually a priority bit (which is basically how it was being used anyway 'transparency' was rather misleading). With everything fixed up Dynamite Duke looks better than ever, and one of the longest standing bugs that I can remember has finally been fixed. 30th September 2007: David Haywood - I've hopefully fixed the colour problems from the first boss and beyond in Dynamite Duke. Note, the background is now correct in shots 3 / 4 onwards.
mahoneyt944
pushed a commit
that referenced
this pull request
Apr 6, 2022
0.136u1: Bryan McPhail fixed Zeroize (Cassette) protection simulation in lieu of proper dongle dump. 0.109u1: David Haywood fixed Zeroize (messed up graphics/unplayable). 0.99u2: Juergen Buchmueller found bitswap for Zeroize type #3 dongle; found hack to get it running w/o the dongle ROM by debugging the game code; changed year to 1983; removed NOT_WORKING flag. Changed visible area to 240x248.
Closed
Closed
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is @riverstorm 's updates DAT file. It will need updates from the NeoGeo driver (this will happen soon) but is otherwise up to date. @Arcadez if it's OK with you to add this here I think it will help move forward with testing to have it as part of the repository.