(WIP) David Haywood's Homepage - 模擬器

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.

http://www.youtube.com/watch?v=xa4FUmSnb68&feature=player_embedded
______________________________________________________________________________

來源：http://mamedev.emulab.it/haze/

--

ポーラステーション
http://perryt0517.wordpress.com/

--