summaryrefslogtreecommitdiffstatshomepage
path: root/src
diff options
context:
space:
mode:
author Nicola Salmoria <nicola@mamedev.org>2008-07-17 08:22:45 +0000
committer Nicola Salmoria <nicola@mamedev.org>2008-07-17 08:22:45 +0000
commit2381235812da7e887b97bcfc0063d87d458a6ee8 (patch)
tree91ce1e4f2ae3530523d11b351dcbcb12aafce710 /src
parentc3280d49c479b62fc33674055d4ccc390ccd0682 (diff)
changed partial refresh policy and updated comments
Diffstat (limited to 'src')
-rw-r--r--src/mame/drivers/snk68.c40
-rw-r--r--src/mame/video/snk68.c93
2 files changed, 75 insertions, 58 deletions
diff --git a/src/mame/drivers/snk68.c b/src/mame/drivers/snk68.c
index 04bac0b596d..d99c653412e 100644
--- a/src/mame/drivers/snk68.c
+++ b/src/mame/drivers/snk68.c
@@ -13,23 +13,35 @@
For some strange reason version 2 of Street Smart runs on Pow hardware!
- Emulation by Bryan McPhail, mish@tendril.co.uk
+ Driver by Bryan McPhail, Acho A. Tang, Nicola Salmoria
-Change Log:
-
-FEB-2003 (AT)
-
-- bug fixes:
-
- pow37b5yel: incorrect sprite priority
- powj36rc2gre: scrambled Japanese text in cut scenes
-
Notes:
-
- Sprite flickerings and pop-up's not fixed. They look more like
- sloppy programming than emulation issues. Also suggest redumping
- sound ROM "dg7", it might be the cause of pow060gre.
+------
+- All evidence suggests that the sprite hardware doesn't have a frame buffer
+ but just a raster line buffer, like NeoGeo (unsurprisingly). The maths
+ confirm this:
+ 384 pixels per raster line at 4 clocks per pixel = 1536 clocks per line
+ 96 sprites * 16 pixels per sprite = 1536 clocks to draw the sprites
+
+ While this board doesn't have a raster interrupt capability, the way how
+ sprites are drawn needs to be kept in consideration because at least in one
+ case the program modifies the sprite list in the middle of the frame:
+ bug 00871: pow: At 3/4 of the 1st level, there is a large pillar, which pops up too late.
+ The problem in this case is that the sprite list is built by the IRQ handler,
+ however there is code in the main loop that clears some portions of sprite
+ RAM under certain conditions. Usually, this isn't a problem, but in that
+ specific point the sprites added by the IRQ handler are erased during the
+ frame.
+ To avoid glitches in that case, we force a partial screen update every time
+ sprite RAM changes. It's possible that there are other unknown small glitches
+ fixed by this (earlier notes in this driver talked about "sprite flickerings
+ and pop-ups" but I don't know where they happened).
+
+TODO:
+-----
+- Number of raster lines unknown. Currently set to 264 which gives a 59.19Hz
+ refresh rate.
***************************************************************************/
diff --git a/src/mame/video/snk68.c b/src/mame/video/snk68.c
index 61c8d3c4de0..fdf84cce4af 100644
--- a/src/mame/video/snk68.c
+++ b/src/mame/video/snk68.c
@@ -93,26 +93,22 @@ READ16_HANDLER( pow_spriteram_r )
WRITE16_HANDLER( pow_spriteram_w )
{
- /*
- This kludge fixes bug 00871: pow: At 3/4 of the 1st level, there is a large pillar, which pops up too late.
-
- The problem: the sprite list is built by the IRQ handler, however there is
- code in the main loop that clears some portions of sprite RAM under certain
- conditions. Usually, this isn't a problem, but in that specific point the
- sprites added by the IRQ handler are erased before the screen is drawn.
-
- We could force a partial update every time the sprite RAM is modified, however
- that would hardly be more accurate since the sprite hardware most likely draws
- to a frame buffer one frame behind, so the exact timing is unknown.
- Instead, we just force a partial update before changing the RAM location that
- causes the problem.
- */
- if (offset == 0x10c/2)
- video_screen_update_partial(machine->primary_screen, video_screen_get_vpos(machine->primary_screen));
+ UINT16 newword = spriteram16[offset];
if (!(offset & 1))
data |= 0xff00;
- COMBINE_DATA(&spriteram16[offset]);
+
+ COMBINE_DATA(&newword);
+
+ if (spriteram16[offset] != newword)
+ {
+ int vpos = video_screen_get_vpos(machine->primary_screen);
+
+ if (vpos > 0)
+ video_screen_update_partial(machine->primary_screen, vpos - 1);
+
+ spriteram16[offset] = newword;
+ }
}
READ16_HANDLER( pow_fg_videoram_r )
@@ -212,47 +208,56 @@ static void draw_sprites(running_machine *machine, bitmap_t *bitmap, const recta
my = 240 - my;
}
- // every sprite is a column 32 tiles tall
+ // every sprite is a column 32 tiles (512 pixels) tall
for (i = 0; i < 0x20; ++i)
{
- int color = *(tiledata++) & 0x7f;
- int tile = *(tiledata++);
- int fx,fy;
+ my &= 0x1ff;
- if (is_pow)
- {
- fx = tile & 0x4000;
- fy = tile & 0x8000;
- tile &= 0x3fff;
- }
- else
+ if (my <= cliprect->max_y && my + 15 >= cliprect->min_y)
{
- if (sprite_flip_axis)
+ int color = *(tiledata++) & 0x7f;
+ int tile = *(tiledata++);
+ int fx,fy;
+
+ if (is_pow)
{
- fx = 0;
+ fx = tile & 0x4000;
fy = tile & 0x8000;
+ tile &= 0x3fff;
}
else
{
- fx = tile & 0x8000;
- fy = 0;
+ if (sprite_flip_axis)
+ {
+ fx = 0;
+ fy = tile & 0x8000;
+ }
+ else
+ {
+ fx = tile & 0x8000;
+ fy = 0;
+ }
+ tile &= 0x7fff;
}
- tile &= 0x7fff;
- }
- if (flipscreen)
+ if (flipscreen)
+ {
+ fx = !fx;
+ fy = !fy;
+ }
+
+ drawgfx(bitmap,machine->gfx[1],
+ tile,
+ color,
+ fx, fy,
+ mx, my,
+ cliprect, TRANSPARENCY_PEN, 0);
+ }
+ else
{
- fx = !fx;
- fy = !fy;
+ tiledata += 2;
}
- drawgfx(bitmap,machine->gfx[1],
- tile,
- color,
- fx, fy,
- mx, my & 0x1ff,
- cliprect, TRANSPARENCY_PEN, 0);
-
if (flipscreen)
my -= 16;
else