Forums

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

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.

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

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.

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

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

Yes, that's another way of doing it (so long as you have no line interrupts).

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

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).

I see. I did wonder what you meant by "behaves differently between PAL and NTSC" - thank you for the explanation.

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).

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_001.png (2.05 KB)

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

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

The card animation, at least in my opinion, is too slow in Fusion. It is much faster (and much more enjoyable) in Dega.

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.

Author	Message
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	MEKA / Fusion differences in sprite movement speed Posted: Wed Aug 24, 2011 11:12 am
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14732 Location: London	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.

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Wed Aug 24, 2011 11:33 am
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14732 Location: London	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.

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Wed Aug 24, 2011 12:36 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Wed Aug 24, 2011 2:01 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14732 Location: London	Posted: Wed Aug 24, 2011 2:56 pm
	Yes, that's another way of doing it (so long as you have no line interrupts).

RetroSpark Joined: 08 Dec 2005 Posts: 488 Location: Melbourne, Australia	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

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14732 Location: London	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).

RetroSpark Joined: 08 Dec 2005 Posts: 488 Location: Melbourne, Australia	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.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	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).

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Fri Aug 26, 2011 11:53 am
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	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_001.png (2.05 KB)

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Fri Aug 26, 2011 12:11 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Fri Aug 26, 2011 1:12 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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

Tom Joined: 16 May 2002 Posts: 1356 Location: italy	Posted: Fri Aug 26, 2011 2:37 pm
Tom Joined: 16 May 2002 Posts: 1356 Location: italy	The card animation, at least in my opinion, is too slow in Fusion. It is much faster (and much more enjoyable) in Dega.

Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	Posted: Fri Aug 26, 2011 3:23 pm
Sket Joined: 03 Aug 2011 Posts: 39 Location: NW England	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.

Forums

View topic - MEKA / Fusion differences in sprite movement speed