1. http://mamedev.emulab.it/robiza/?p=163 Io e Kale abbiamo notato che la palette veniva scritta 2 volte quasi consecutivamente; dato che durante la prima copia un bit di un registro era a zero e durante la seconda copia lo stesso bit era a 1 abbiamo presunto che fosse una sortas di protezione; quindi scartati i valori del bit a 0 abbiamo ottenuto colori che sembrano corretti (valido per tutto il gioco compresi gli intro) finalmente fixato? comunque qualche test sull’hw sarebbe opportuno farlo 2. http://mamedev.emulab.it/haze/2010/08/21/getting-your-priorities-right/ Getting Your Priorities Right The Toaplan 2 driver (games using the GP9001 VDP) has always been a bit of a MESS in MAME, especially the priority system in the driver. A couple of releases back I decided to start something of a rewrite of the driver, cleaning up many of the hacks that were present. I’d actually started this rewrite a long time ago, but didn’t submit it at the time because there were two games I was unable to get working properly with my new cleaner code, the dual VDP ones, namely Batsugun and Dogyuun. The problem was the old code was rendering all the layers in multiple passes (calling sprite draw functions once for each priority and such) which broke basic things like sprite-sprite priority. Each game was rendering different layers in arbitrary order depending on the specific needs of that game to compensate for this. In cleaning up the code I managed to reduce all the single VDP cases to a single call to draw all the graphics in the correct order, this however broke Batsugun and Dogyuun because the self-contained rendering function broke the hacks which were interleaving the output from each of the VDPs. Batsugun had never worked properly anyway (and had various priority glitches on certain levels and the ending), but with the new code it was completely unplayable in some levels. I originally wanted to fix this before submitting it, and it was left sitting for a while. Eventually somebody else took a hand at ‘fixing’ the Toaplan2 driver, however the fixes submitted were nothing but further hacks to the driver (checking which level was currently running and further hacking the priority of each layer based on that). The code submitted was gross to say the least, so I decided to submit my code, and demote Batsugun and Dogyuun to Non-working status instead, pending proper fixes which weren’t hacks. My new code was a lot cleaner for every other game in the driver, and I knew it would form the basis of a correct solution eventually, so this was a worthwhile step even if it meant the games were unplayable for several versions. I tried various things to get the mixing correct with very little luck, and the driver remained in the broken state for quite a few releases. In the meantime I did some further cleanups to the VDP rendering code, and converted it all to use the new C++ devices Aaron had been adding support for in the core. With the GP9001 extracted to its own file, as a proper device, I decided to take another look at the priority mixing, strongly believing that there must be some kind of PAL on the board to mix the output of the two VDPs, because it didn’t seem entirely logical. One of the big problems was I didn’t know exactly what each VDP output externally. By displaying the output of each VDP on separate screens it was clear the the individual mixing of each VDP was correct, as expected (the mixing code for single VDPs worked fine) However, I didn’t know if the VDPs output any kind of priority data externally to mix with, or just the colour data. A few more attempts later, and I was still getting nowhere with the dual mixing, and almost ready to give up. At that point Quench came forward with some information that proved to be very useful in the end. He’d managed to reverse the equations of a Pal which sat between the two VDPs on a Batsugun board. From his equations it was clear that the VDPs didn’t output any kind of priority information externally, and the mixing had to be entirely based on the palette index. I implemented his equations directly, which in theory should have worked, but the results were disappointing, the output was a mess, pixels were showing through where pixels shouldn’t have shown through, and I didn’t know why. I took a break for a week to try and figure out why this might have been, then tried re-implementing it in a slightly different way. Same result. All was not lost at this point however, because despite the equation not working directly it had provided me with some useful information. I now knew exactly which bits were being fed into the pal, and thus which bits could potentially be used to determine the mixing order, even if the given equation wasn’t working. Rearranging things a bit I came up with my own solution, making use of the same bits that Quench had figured out were being input into the PAL. The first attempt left some random black dots in the level, quickly realising that where those dots appeared should actually be showing the other VDP I amended my code and had something which worked. Testing the game from start to end showed that all the problematic test cases I’d documented were now correct. Finally. The other benefit of this mixing was that the tile number hack, which was being used to hide some garbage on the first level of Batsugun could be removed, as it happens the palette index of the garbage is set so that it appears behind the background anyway. Dogyuun was still an issue, it didn’t work with the new code, however, a bit of testing later, and I’m pretty sure that just uses a simple mixing system, with the output of one VDP appearing above the other, nothing complex. The net result of this is that for the first time Batsugun can be rendered without hacks, and looks correct on all levels. There is still room for optimization in the code (I’d made it as verbose as possible when debugging, rather than optimized, but it’s correct) The next step for Batsugun will be adding the missing opcodes and features to the V30 core so that all the V35+ features it needs are supported (register banking etc.) Currently AWJ is meant to be working on this, but I haven’t heard any progress recently. That will allow for full sound emulation in the game. I may add more technical details to this post later, but for now I have to go out ;-) 两个Wip都是很有名的stg 一个是"飞虎队"一个是移植过SS的"疯狂枪手" 又有得爽了科科 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.224.53.55 ※ 编辑: OPWaug 来自: 61.224.53.55 (08/30 16:19)