Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - MEKA / Fusion differences in sprite movement speed

Reply to topic
Author Message
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
MEKA / Fusion differences in sprite movement speed
Post Posted: Wed Aug 24, 2011 11:12 am
Whilst testing my Video Poker homebrew project on both the above emulators, I have come to notice quite a big difference in sprite movement speed:

The card deal routine is basically a big meta sprite made up of 35 sprites to form the big 5 x 7 card, the difference in time it takes the card to move from the deck to its dealt position is considerable MEKA doing it roughly twice as fast as Fusion does.

As I don't yet have a real SMS/Everdrive combo to test it on the real thing - my question is which one is performing nearest to the real thing?

I much prefer MEKA over Fusion - got some really great features in there - but felt I should ask about this so as to get as good a feel of how my homebrew stuff runs on the real thing (until I get an Everdrive cart).



Richard / Sket
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11903
  • Location: London
Reply with quote
Post Posted: Wed Aug 24, 2011 11:25 am
What timing mechanism are you using? If you poll the scanline counter, you can end up triggering twice per frame. It's better to use VBlank interrupts if you can, as that's the most emulator-compatible way.
  View user's profile Send private message Visit poster's website
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
Post Posted: Wed Aug 24, 2011 11:33 am
Maxim wrote
What timing mechanism are you using? If you poll the scanline counter, you can end up triggering twice per frame. It's better to use VBlank interrupts if you can, as that's the most emulator-compatible way.


Hi Maxim

At the moment I'm using the following code (came from some source I downloaded from the site) :

;==============================================================
; V Counter reader
; Waits for 2 consecutive identical values (to avoid garbage)
; Returns in a *and* b
;==============================================================
.section "Get VCount" free
GetVCount:
    in a,($7e)  ; get VCount
  -:ld b,a      ; store it
    in a,($7e)  ; and again
    cp b        ; Is it the same?
    jp nz,-     ; If not, repeat
    ret         ; If so, return it in a (and b)
.ends

.section "Wait for VBlank without interrupts" free
WaitForVBlankNoInt:
    push bc
    push af
      -:call GetVCount
        cp 192
        jp nz,-
    pop af
    pop bc
    ret
.ends



Richard / Sket
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11903
  • Location: London
Reply with quote
Post Posted: Wed Aug 24, 2011 12:09 pm
Last edited by Maxim on Thu Sep 15, 2011 7:00 am; edited 1 time in total
Yes, that code has a bug whereby it will trigger twice per frame if the per-frame code runs quite quickly. You can also find that it behaves differently between PAL and NTSC systems. It used to be part of my tutorials but I removed it and haven;t got around to writing the replacement yet...

As a quick fix, you can move to something like:

; destroys a
WaitForVBlankNoInt:
-:  in a,($bf)
    and $80
    jr z,-
    ret

but you also have to make sure to configure the VDP in the right way, I don't recall exactly what right now. I'm not sure how many emulators this works with because I think not many games do it.

The better solution, as I mentioned before, is to use proper interrupt-driven timing, whereby the code at $0038 executes once per frame because you've enabled frame interrupts in all the necessary places.
  View user's profile Send private message Visit poster's website
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
Post Posted: Wed Aug 24, 2011 12:36 pm
Thanks for the heads up on this Maxim.

It's a bit of an advanced topic (for me at least) - so I shall go off and have a read / tinker about and see if I can enlighten myself on the ins/outs of interrupt driven timing.


Cheers


Richard / Sket
  View user's profile Send private message
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
Post Posted: Wed Aug 24, 2011 2:01 pm
Ok I have come up with this for now:

.org $38
.section "VBlank handler" force
   push af
    in a,($bf) ; satisfy interrupt
   pop af
   ei
   reti
.ends


I enable the VBlank INT in VDP using Reg 1/Bit 5 & Reg 0/Bit 4 along with an EI to enable CPU INT.

In place of the code I listed in my initial code I simply put a "HALT" - now both MEKA and Fusion perform at the same speed (the Fusion speed - slower).

It's a quick/dirty way but it serves my purpose for now - whilst I get my head around this topic a bit more.

I re-read the last part of your Tutorial/Lesson 2 on VBlank - understand whats happening there - just not sure about the code in the actual handler side of things yet (if that makes sense).


Richard / Sket
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11903
  • Location: London
Reply with quote
Post Posted: Wed Aug 24, 2011 2:56 pm
Yes, that's another way of doing it (so long as you have no line interrupts).
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2005
  • Posts: 476
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Fri Aug 26, 2011 5:24 am
Would this work as a simpler fix?

.section "Wait for VBlank without interrupts" free
WaitForVBlankNoInt:
    push bc
    push af
      -:call GetVCount
        cp 191
        jp nz,-
      -:call GetVCount
        cp 192
        jp nz,-
    pop af
    pop bc
    ret
.ends
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11903
  • Location: London
Reply with quote
Post Posted: Fri Aug 26, 2011 9:47 am
No. Charles' doc says the VCounter values are "00-F2, BA-FF" on a PAL regular-size screen, so 191 and 192 both appear twice during the run. There's no safe way to watch the number as you can't tell which 192 you're seeing. On an NTSC system, you don't get this problem (192 only appears once).
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2005
  • Posts: 476
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Fri Aug 26, 2011 11:18 am
I see. I did wonder what you meant by "behaves differently between PAL and NTSC" - thank you for the explanation.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 7721
  • Location: Paris, France
Reply with quote
Post Posted: Fri Aug 26, 2011 11:39 am
Can you post a ROM with the bug? I would like to check it on real system and compare NTSC/PAL and emulators, to check if MEKA was correct (it looks like it should be but i'm happy to double check).
  View user's profile Send private message Visit poster's website
  • Joined: 16 May 2002
  • Posts: 1088
  • Location: italy
Reply with quote
Post Posted: Fri Aug 26, 2011 11:53 am
I just downloaded the current 0.7 build from the homebrew page. It's fast in Dega, and very slow in Fusion. To be honest I hope the intended speed isn't Fusion's one because that's painfully slow.

Since I bought a GG Pro I'd gladly test it on my Game Gear, too, but I've yet to perform the capacitor fix :(

EDIT:
I tested this in Gens+ for the lulz (I haven't used that emulator since... 6 years ago maybe, I know it's broken and inaccurate as hell, but I thought it was good to have one more test case)... Results are hilarious:


That's a nice title screen...


No card animation at all (cards just appear in place), but that's the last of the problems...

I confirm: Gens+ is broken and inaccurate as hell :P
Now I can stop using it for 6 more years...
vpoker_000.png (472 B)
vpoker_000.png
vpoker_001.png (2.05 KB)
vpoker_001.png

  View user's profile Send private message Visit poster's website
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
Post Posted: Fri Aug 26, 2011 12:11 pm
OMG Tom that looks like something exploded :-o

I use MEKA / sometimes Fusion - appears fine on both those.

I have just acquired my first real SMS today - but still need to get my hands on an Everdrive cart to test my work on the real thing - as I need to know they work correctly on the real thing at the end of the day.



Richard / Sket
  View user's profile Send private message
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
Post Posted: Fri Aug 26, 2011 1:12 pm
Tom wrote
I just downloaded the current 0.7 build from the homebrew page. It's fast in Dega, and very slow in Fusion. To be honest I hope the intended speed isn't Fusion's one because that's painfully slow.


I find that the game runs at pretty much the same speed in MEKA (v0.73) and Fusion (v3.64) - neither of which I would call painfully slow - could you elaborate a bit more and this - ie which part(s) appear very slow?


Thanks

Richard / Sket
  View user's profile Send private message
  • Joined: 16 May 2002
  • Posts: 1088
  • Location: italy
Reply with quote
Post Posted: Fri Aug 26, 2011 2:37 pm
The card animation, at least at my opinion, is too slow in Fusion. It is much faster (and much more enjoyable) in Dega.
  View user's profile Send private message Visit poster's website
  • Joined: 03 Aug 2011
  • Posts: 39
  • Location: NW England
Reply with quote
Post Posted: Fri Aug 26, 2011 3:23 pm
I tried running it here on DEGA both v1.09 and v1.12 and I don't see any sprites at all - just the end result where the card is drawn after the dealt card has reached it's destination - nothing in between.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!