50/60 Hz support for modern games

Enlighted (6467)

10-01-2016, 15:36

I'm wondering on how to evolve the of the uridium 2 beta in something more complete, eventually a game rom for msx 2. As you may know, in NTSC mode the msx 2 has a significant loss of performances, there is not only less frame time (-20%) but also the VDP is slower in copy commands (not easy to say how much less, but the difference is emulated by openmsx and is visible in my tests).

Uridium 2 beta is in screen 8 and has levels 176 pixels tall. This simply too much for NTSC mode.

For a new msx2 game on rom is it relevant to support 60Hz machines ?

Supporting NTSC mode would mean to cut significatively some aspect of the game, e.g. to reduce the level height to 160 or 144 pixels (if one keeps the full frame rate) or to reduce the frame rate (e.g. 30 fps or 25 fps) if we keep 176 pixels.

On the other side, supporting only PAL would restrict the game to European users.
What are your opinions ?

ログイン/登録して投稿

By giuseve

Paladin (744)

10-01-2016, 15:48

I am not an esperti, but in my opinioni 25fps is what human eye can detech still smooth.
Anyway 160 pixels less is only 10% less. Maybe you can use this for a a better info bar on top

By Grauw

Ascended (9580)

10-01-2016, 15:54

During display area scanning the VDP commands are equally fast on 50 Hz and 60 Hz, however commands are much faster in the vertical blanking area. And at 60 Hz there’s only 50 lines worth of blanking area whereas at 50 Hz there are 101 lines worth, so that most likely explains the difference. Try to make sure the VDP is always 100% occupied in the blanking period, to not waste any of those high performance cycles.

I’ve always liked 60 Hz better than 50 Hz due to how it displayed on my CRT monitor, due to the more stable less flickering image and the nice looking scanlines. Because I’ve always used RGB connections I’ve never had trouble displaying either frequency. I hope the same applies to most (though not all) MSX users around the world.

But I tried 50 Hz on my Zemmix Neo just yesterday and my Dell VGA monitor seems to have some problems with it, so frequency dependencies on monitors haven’t entirely disappeared . My CX5MII on a Samsung TV doesn’t have a problem with it though.

I think 60 Hz would be nice to have, but I don’t think 60 Hz is essential, if it doesn’t work then too bad, it’s understandable because there’s simply less time to do things (16.7 ms in stead of 20 ms per frame). There’s been plenty of scene software which forced the display frequency to either 50 Hz or 60 Hz in the past, I think.

By Grauw

Ascended (9580)

10-01-2016, 15:55

giuseve wrote:

I am not an esperti, but in my opinioni 25fps is what human eye can detech still smooth.

It’s not true , an urban legend. There’s a giant difference between 60 fps and 30 fps. Not to say 30 fps is unplayable, but 60 definitely looks a lot better.

By ARTRAG

Enlighted (6467)

10-01-2016, 16:06

Grauw wrote:

Already there, the command is issued at vblank start and continues for the whole frame time.
I move a 16x192 area (byte copy), at 50Hz the command ends within the frame time, at 60Hz it exceeds the frame time.

PS
Note that I'm changing the code with respect the beta version. All the work for borders is on the z80 now, so the vdp has "only" to move a slice of screen at each scroll step. If you want I can share the test code.

By Hrothgar

Champion (479)

10-01-2016, 16:15

On old television sets in Europe, switching to 60Hz would simply make the screen flicker beyond recognition (three images superimposed or something) and make a game unusable. On my current tv I can still not switch my MSX to 60Hz without significant side effects.

I guess this degradation exists the other way around as well on some tv's or monitors. If it can't be done, it can't be done - but I'll never forgive the coders of Boulderdash for putting some weird switch to 60Hz in their (MSX1!) code that made the games unplayable for me in the 80s.

By syn

Paragon (2015)

10-01-2016, 16:48

Funny, I was wondering about it the other way around: "would 50hz still be needed"?

There was a poll a while ago http://www.msx.org/poll/can-display-device-your-real-msx-han...

So I thought 60hz is the way to go nowadays for maximum compatibility.

But basically even now, software need to support both?

By ARTRAG

Enlighted (6467)

10-01-2016, 17:01

Amazingly the msx2 in PAL mode is more or less the 25%-30% more powerful than in NTSC mode.

In order to safely develop for NTSC systems a real game with software bidirectional scrolling at full rate (like Uridium beta) one should go for a reduced game area.
By "safely develop" I mean that you have to keep some margins in order to do not drop everything when you try to add background animations or dynamic sprite management.
On Uridium for msx1 levels were 128 pixels tall, on NTSC I would go for that very same size, even if the system could go for level height of 160 or 144 pixels.
On PAL, the system can manage levels 192 pixels tall, but to keep margins for a game I would use 176 or 160 pixels.

By Sandy Brand

Master (215)

10-01-2016, 19:13

Grauw wrote:

giuseve wrote:

I am not an esperti, but in my opinioni 25fps is what human eye can detech still smooth.

It’s not true , an urban legend. There’s a giant difference between 60 fps and 30 fps. Not to say 30 fps is unplayable, but 60 definitely looks a lot better.

Exactly, the lower bound for your brain to interpret something as 'moving' on the screen instead of just a rapid succession of individual images is around 25 fps. The quality or smoothness of the movement is greatly enhanced though with higher frame rates.

Think of it like this: at 60 fps, your brain has 'twice' the amount of information available compared to 30 fps to estimate movement directions and speeds of individual objects on the screen. This means you can subconsciously make much more accurate guesses on what is happening on the screen and how to timely respond to certain events.

So the actual question you need to ask yourself is: what type of game am I making, and how can I match the game-play rules to technical limitations?

This highly depends on your game of course, but as a fictional example: if your game is an action game where one hit will instantly kill the player, 60 fps is probably desired. If you can't maintain 60 fps, then maybe a life-bar is much more forgiving and you can get away with less fps.

By hit9918

Prophet (2899)

11-01-2016, 08:27

When PAL seems more than 6/5 faster, then that's because of the different layout that grauw mentioned. When coming from a PAL bias then NTSC feels double strange.

Theory: when set adjust changes by only 1 pixel, then maybe it doesnt wreck the blitter.
Change horizontal adjust maximum by 1 pixel every rasterline.
In max 15 rasterlines one can step the adjust to any position.

If that works out, one can throw away the whole stripe copy business and copy the background in one single blit!

e.g. first attempt to do something about NTSC would be skip every 6th frame and see whether blitter is fast enough to finish. It would throw away so many problems that it is worth trying out on real machine.

I assume the write to set adjust register takes effect in hsync. It loads a delay counter. One can write it midscreen. Trying to make the code with syncing to hsync would make jitter ado and open a can of worms. The loop shall take say minimum 228 + 5 cycles and things are safe.

loop:	set adjust(X)
	INC X or DEC X
	wait to make the loop > 228 + 5 cycles.
	djnz loop

The blitter did make sparcles not regular but only sometimes, that was the jump from adjust 15 to adjust 0!
An INDICATION that 1 pixel adjust change is safe.

By ARTRAG

Enlighted (6467)

11-01-2016, 09:47

I cannot see why your theory would be correct, but in the end, if I understand what you say, this basic test should be sufficient to see if you were right

10 screen 8
20 set page 1,1
30 for i=0 to 255: line (i,0)-(i,211),i:next
40 set page 0,0
50 '
60 copy (0,0)-(255,211),1 to (0,0),0
65 for j=0 to 100
70 for i=-7 to 8
80 set adjust (i,0)
90 next
100 for i=8 to -7 step -1
110 set adjust (i,0)
120 next
125 next
130 goto 60

The code moves the screen one pixel at time never crossing the 0-15 boundary.
If on real HW you get black or misplaced dots after a couple of frames this means that your theory was wrong.
If not, it is worth to try a more accurate tests.
Anyone willing to try on real HW (better if with xbasic _run) ?

If it works I could rearrange the scrolling code with one copy each 16 frames (I see some contraindications, but it is worth to try if this avoids the copy corruption)