diff options
| author | 2008-07-17 08:22:45 +0000 | |
|---|---|---|
| committer | 2008-07-17 08:22:45 +0000 | |
| commit | 2381235812da7e887b97bcfc0063d87d458a6ee8 (patch) | |
| tree | 91ce1e4f2ae3530523d11b351dcbcb12aafce710 /src | |
| parent | c3280d49c479b62fc33674055d4ccc390ccd0682 (diff) | |
changed partial refresh policy and updated comments
Diffstat (limited to 'src')
| -rw-r--r-- | src/mame/drivers/snk68.c | 40 | ||||
| -rw-r--r-- | src/mame/video/snk68.c | 93 |
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 |
