Possible to tell if game is running on a real Jaguar?

[+Sporadic]

Hi,

 

I was wondering if there is a way to tell if my game is running on a real Jaguar or emulated in software such as VJ.

 

The reason I ask is because part of my game now runs perfect on my actual Jag but is too fast in VJ.

 

If there was a way to tell then I could slow it down based on that condition so people can play it either way.

 

Thanks

[sh3-rg]

Using VSYNC and keeping away from that RUPDALL() business would be a start to having things run more similarly :0)

 

There's no direct way to tell if you're under emulation as far as I know, but there's no doubt some tricks you could try to work it out, but I suppose that would be more searching out emulation inaccuracies and those could get righted at any time.

[ggn]

Hi,

 

I was wondering if there is a way to tell if my game is running on a real Jaguar or emulated in software such as VJ.

 

The reason I ask is because part of my game now runs perfect on my actual Jag but is too fast in VJ.

 

If there was a way to tell then I could slow it down based on that condition so people can play it either way.

 

Thanks

IMO it's an emulation fault. The emulators just have to get better and not be the programmers responsibility .

 

That said it might be possible to detect emulation if you do something that the hardware and emulator react different to. Now this is something completely untested but maybe writing to addresses from 2 to 8 megs and reading that back as the same value is allowed in emulation (hint: in real hardware you're most likely not going to get the same value). Shamus might be of help here!.

 

Of course "tricks" like these are most probably going to get fixed at some point so you're probably better off not relying to them. Just do what we did with SFDX and provide a second binary for emulators, I think it's less hassle for everyone.

[+Sporadic]

Using VSYNC and keeping away from that RUPDALL() business would be a start to having things run more similarly :0)

 

There's no direct way to tell if you're under emulation as far as I know, but there's no doubt some tricks you could try to work it out, but I suppose that would be more searching out emulation inaccuracies and those could get righted at any time.

 

Yes, I've had to remove the RUPDALL from the main loop as weird crap started happening since changing to the particle field. Probably because things are running quicker now.

I'm going to try vsync in the part of game in question in the actual Jag now and see how it runs. Hopefully like you say, it will be a closer match.

 

IMO it's an emulation fault. The emulators just have to get better and not be the programmers responsibility .

 

That said it might be possible to detect emulation if you do something that the hardware and emulator react different to. Now this is something completely untested but maybe writing to addresses from 2 to 8 megs and reading that back as the same value is allowed in emulation (hint: in real hardware you're most likely not going to get the same value). Shamus might be of help here!.

 

Of course "tricks" like these are most probably going to get fixed at some point so you're probably better off not relying to them. Just do what we did with SFDX and provide a second binary for emulators, I think it's less hassle for everyone.

 

I did of think the same about discovering if you are under emulation. But yes, the fundamental point of emulation is that it matches the hardware and could be fixed etc.

I was hoping there would be some flag or something that VJ adds somewhere.

 

I think I might just do as you suggested and create separate binaries for now.

EDIT: Or punish people for using an emulator and leave it quicker

 

Cheers

Edited August 2, 2015 by Sporadic

[Zerosquare]

Even if you made a separate "Virtual Jaguar" version, the speed probably depends on how fast the computer is, so it wouldn't be a solution. I second sh3's recommendation: use VSYNC (but don't forget the frequency difference between NTSC and PAL consoles).

 

And I've got plenty of ideas to detect whether the code is running in an emulator, but I'm not disclosing them publicly since Shamus would fix them

[+Sporadic]

Even if you made a separate "Virtual Jaguar" version, the speed probably depends on how fast the computer is, so it wouldn't be a solution. I second sh3's recommendation: use VSYNC (but don't forget the frequency difference between NTSC and PAL consoles).

 

And I've got plenty of ideas to detect whether the code is running in an emulator, but I'm not disclosing them publicly since Shamus would fix them

Haha excellent, no problem. I'm vsyncs all the way now

 

As a follow up question, should I be detecting for NTSC/PAL and can that be done?

 

I heard there isn't a massive difference, maybe 10% in real world tests.

 

I know its 50 vs 60 hz etc but not sure if people really bother when doing fairly straight forward 2d stuff.

[sh3-rg]

Here's my 50/60 check from cwacom:

 

DIM donkey% : donkey=LPEEK(0xF14002) ' read video signal; 60Hz: -8388609, 50Hz:-9437185

 

50 vs 60 can make a difference to your game beyond just making it 20% faster or 20% trickier, there will be differences in what you can get away with on screen as you reach the limits, stuff like tearing appearing in one and not the other. There's differences in screen real estate possibilities where someone playing at 60Hz might have the top or bottom missing from their view. There's the Checkered Flag lap timer kind of issue where they didn't calculate their timings based on screen refresh rate, meaning people in the US posting their lap times are always at an advantage (noticed under emulation thanks to the possibility of completing flying laps without once bumping, the timing differences were exactly the same ratio as 50Hz vs 60 Hz for the same flawless laps).

 

It's simple to add a switch to your Jaguar to be able to test PAL 50 vs PAL 60.

[+CyranoJ]

RAPTOR has a flag for refresh rate but it isn't exposed. I'll add it in the next release of the API.

[+Sporadic]

I hadn't heard of that Chequered Flag timing issue before. I guess they didn't expect anyone to actually get flying laps?

 

Yeah I'd like to get the switch added but would rather get a spare Jag for that first.

 

Nice info though cheers

[Shamus]

One thing you might look at is that if your Jaguar is a PAL version, you might want to run VJ in PAL mode as well, to get a good comparison between the two. I noticed on your screenshot that it was running in NTSC mode.

[+Sporadic]

One thing you might look at is that if your Jaguar is a PAL version, you might want to run VJ in PAL mode as well, to get a good comparison between the two. I noticed on your screenshot that it was running in NTSC mode.

Ah, I hadn't even noticed! Thank you for pointing that out.

 

PAL mode engaged...

[Zerosquare]

DIM donkey% : donkey=LPEEK(0xF14002) ' read video signal; 60Hz: -8388609, 50Hz:-9437185

This reads plenty of other bits, not just the NTSC/PAL flag, so there's no guarantee the values will always be the same (for example, they could be different if you happen to press some buttons on the pad).

 

Use this instead:

DIM donkey% : donkey=DPEEK(0xF14002) AND 0x10 ' zero for PAL consoles, non-zero for NTSC consoles

[ggn]

It's all donkey code anyway

[sh3-rg]

It's all donkey code anyway

 

[ggn]

 

 

Do I have to go back to dark place?