 No.01647
Tafoid Administrator
Jul 16, 2008, 04:18
|
I just tried the game and it seemed to look ok and respond ok. Is it possible to record a small movie to show the PCB action so the devs can get a better idea what might be the issue? |
|---|---|
 No.01648
Kold666 Developer
Jul 16, 2008, 04:46
|
Nicola knows the problem as he asked me to check it. Since there is no sprite lag I decided to post a bug in the case there is no immediate solution. |
 No.11413
abelardator2 Tester
Jan 27, 2015, 10:15
edited on: Jan 27, 2015, 10:34
|
When we set a "Overclock MainCPU" for example 160%, no there loss of sprites, when overload them sprites on screen. I uploaded a recording of the actual PCB game. www.youtube.com/watch?v=F27UuDkzKtw I have also seen that the set aliensa (Asia), the sprite of player and enemies is completely broken (0.157) |
|
No.11418
Haze Senior Tester
Jan 27, 2015, 13:12
|
aliens (asia) sprite bug was a silly rom load problem. |
 No.15982
MetalGod Senior Tester
Jan 2, 2019, 22:46
edited on: Jan 2, 2019, 23:33
|
Abelardator video here with no need to go to youtube: Mame full gameplay here: |
 No.20902
Alex7 Tester
Dec 3, 2022, 21:37
|
another real arcade video |
|
No.20954
Haze Senior Tester
Dec 13, 2022, 18:50
|
this seems to be somewhat improved with hap's recent changes, however the driving sections still flicker because MAME doesn't give the CPU enough time to prepare the spritelist before drawing the screen with it. the vblank interrupt is being triggered by the sprite device TIMER_CALLBACK_MEMBER( k051960_device::scanline_callback ) but the draw frame happens on the same line, meaning sometimes you get an incomplete spritelist, or one partially from a different frame. the code there can also only cope with 255 scanlines, so if the real frametiming has more that would be an issue. |
 No.20964
hap Developer
Dec 17, 2022, 13:53
edited on: Dec 17, 2022, 16:47
|
I guess spriteram could be buffered. *edit* Furrtek is researching this sprite chip (051960+051937), maybe what he finds out can solve it. |