2013.02.24 　　 画面的部分搞定了，下一版会支援。 Priorities, transPens, imPerfections and Performance One of the most significant improvements to the Cool Riders emulation over the last day and a bit has been the addition of Priority handling, allowing you to see most of the objects as they were meant to appear. It turns out the system uses what appears to be a 12 + 2 bit z-buffer (although it could possible be full 16-bit, and the 2 separate bits MIGHT have additional separate meaning) This is a lot more priority depth than most 2D systems have, and is actually closer to what you’d find on a 3D system. Either way, simply implementing it as a 14-bit z-buffer and doing a z-compare for every pixel write at least fixes most priorities, leaving the game mostly playable again. The other fix made over the last few days involves the transparent pens. Previously there were pixels missing from most objects (not the zoom gaps, I’ll talk about those later) This was caused by us filtering out all 0×0000 value pixels when copying our framebuffer to the screen. This was actually incorrect because 0×0000 means the pen is black, instead pens which should be (fully) transparent have a value of 0× 8000. The most significant bit also seems to have other meanings tho, and is set on some objects which should be alpha-blended, as well as the text and various other objects for reasons I don’t yet understand. We actually have a 2nd palette offset with some sprites too, although it’s usually set to the same value. Either way there are still questions to be answered, because if the 0×8000 bit specifies alpha blending, how do you blend a black pen? It could of course be additive blending, in which case a black pen would blend to the same colour as the source, but I’m not sure of this yet. At least now however objects look a bit better. There are still imperfections, other than the missing transparency effects my zoom precision is still inaccurate, this is what is causing the gaps between sprite tiles in many cases. It’s easy to understand why, each tile is 16-pixels wide, sprites can be made of multiple tiles (and usually are) The zoom value for 1:1 drawing is 0×40 (128) to draw 16 pixels, and so the lower bits of the zoom, if looked at on a per-tile scale have no effect, you’d need to span multiple tiles to see them. The problem is my zoom drawing currently only considers the current tile when drawing it, but the full zoomed width of the sprite when placing it, hence gaps. It shouldn’t be too hard to come up with a better algorithm and elimiate the gaps, but zooming in emulation is rarely perfect because the actual algorithms applied by hardware when deciding which pixels to shrink / expand vary wildly, and only in some cases is it obviously contains in a ROM table (NeoGeo being one such example) Performance is currently an issue too. For all I’ve said about this being a sprite-scaler it can throw as much at the screen as most 3D systems, make that 2 screens, each running at a medium resolution (same as Daytona etc.) with lots of scaling, z-checking, and (once implemented) blending and you can see it’s expensive. Currently for good performance you’ll need a decent i3/i5, my Core2 doesn’t quite cut it in places. I’m still trying to optimize it, and there is definitely room for improvement in some area. I was hoping that threading the sprite rendering would help some, but it doesn’t, it helps a little, but also becomes very sensitive to any other use of the 2nd core by the host PC (are MAME threads running at a really low priority or something?) so while you get some gains you can get nasty performance spikes if the PC decides to do something else in the background. I’m not out of ideas yet, but I thought it fair to warn people that in the current state it is kinda slow. Just emulating the CPUs, and sound chips alone (even with SH2 recompiler) is actually quite a drag, so I don’t have THAT much room for maneuver. There are still other missing features too, quite a few registers are ignored, and there are definitely clipping window effects I need to implement. How the tilemaps get enabled / disabled isn’t known either. http://mamedev.emulab.it/haze/pics2013/cool_single_1.png http://mamedev.emulab.it/haze/pics2013/cool_single_2.png http://mamedev.emulab.it/haze/pics2013/cool_single_3.png http://mamedev.emulab.it/haze/pics2013/cool_single_4.png http://mamedev.emulab.it/haze/pics2013/cool_single_5.png http://mamedev.emulab.it/haze/pics2013/cool_single_6.png *edit* Zoom handling has been improved, gaps (mostly) gone http://mamedev.emulab.it/haze/pics2013/coolrider_zoom_1.png http://mamedev.emulab.it/haze/pics2013/coolrider_zoom_2.png Here’s the video to go with this update, sorry for the delay, I’ve probably hit some kind of unwritten monthly upload limit because my uploads are terribly slow right now ;-) A few changes have been made since this was recorded, but they’ll have to wait. https://www.youtube.com/watch?v=xa4FUmSnb68&feature=player_embedded ______________________________________________________________________________ 来源：http://mamedev.emulab.it/haze/ -- ポーラステーション http://perryt0517.wordpress.com/ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.168.23.6