Grauw’s RPG in development

Страница 19/25
12 | 13 | 14 | 15 | 16 | 17 | 18 | | 20 | 21 | 22 | 23 | 24

By Grauw

Ascended (10329)

Аватар пользователя Grauw

30-08-2019, 23:51

Today I tried to make the overscan work at 50 Hz, which currently visibly wraps around. The idea was to disable the screen at line 226, and then re-enable it again at line -14, giving a total display height of 240 lines. Because I can not set line -14 as a split line, I wanted to set a split on line 255 and then poll the HR flag for 44 lines. The polling would of course block the game loop, but that’s fine since it’s made for 60 Hz speeds anyway.

Unfortunately this didn’t work (it hung on a black screen). I thought a-ha! This must be an openMSX bug. Let’s try it on my real turboR. But it didn’t work there either. Turns out that both on the real MSX as well as in openMSX (props!) this only works if I disable the overscan.

As I previously explained, at 60 Hz the maximum interrupt line is 234 (for height 192) and 244 (for height 212). At 50 Hz the maximum interrupt line is 255. So this should work, right? Well, the overscan is achieved by having a split on line 211 which changes the screen height to 192, and sets it back to 212 on line 213. It turns out that this toggle also makes the maximum interrupt line go back to 234 just like it would be in 60 Hz height 192 mode.

I don’t really understand the logic behind this, but it’s unfortunate nevertheless. Even though especially PAL could really use the extra height, if I would start the HR polling at line 234 instead of 255 it would eat 3192 cycles (5%) off my frame budget and I’m not prepared to pay that price.

So I’m currently debating two options:

  1. Disable overscan at 50 Hz.
  2. Force the VDP to 60 Hz.

Disabling overscan is the most compatible option of course. But since all MSX2+ machines are Japanese, and the OCM generally runs at 60 Hz as well, surely these are connected to monitors capable of displaying 60 Hz. So forcing 60 Hz would really only affect European MSX2-with-V9958 users who are connected to a monitor without 60 Hz support (typically via composite video).

So I wonder which is the best option. The latter would keep things simple, and it’s how the game is meant to be played (also music and gameplay speed-wise). Given that it’s an MSX2+ only game I think no user will have problems in practice, but it still feels a bit principally wrong. What do you think?

By sd_snatcher

Prophet (3498)

Аватар пользователя sd_snatcher

31-08-2019, 00:43

Have you tried to flip to 192 then 212 lines for a second time in that frame some lines after? Does it flush the maximum interrupt line counter?

PS: Does it really still exist monitors/TVs that only support 50Hz these days?

By thegeps

Paladin (954)

Аватар пользователя thegeps

31-08-2019, 01:04

Why don't you out both option in a settings menù in the game? So users can select :
1 disabile overscan (50Hz monitor)
2- Force VDP to 60Hz
Then you can handle the choice with a flag

By DarkSchneider

Paladin (942)

Аватар пользователя DarkSchneider

31-08-2019, 15:32

Force to 60Hz. No need to make 2 speeds for a game as it is extra work. And the MSX 50Hz are false, with incorrect pixel aspect ratio.
Also have you though about removing the overscan? If it is not mentioned on documentation you enter in a gray area of unexpected behavior.

By Grauw

Ascended (10329)

Аватар пользователя Grauw

01-09-2019, 14:45

If this was an MSX2 game I would want to support 50 Hz out of principle, just because many MSX2s are 50 Hz and people do still use composite video. And really 50 Hz is superior in many ways, more frame time and higher display resolution (esp. with overscan: 512x294).

But because it’s MSX2+ I’m like, should I really spend effort on something that 95% of players would never even see, and then of the remaining players most (all?) would still want to always play in 60 Hz too, so an option would be annoying for them (and I do think less options is better @thegeps).

Anyway I’ve decided; I will focus on 60 Hz only for now. Later if someone requests it I can add minimal 50 Hz support, adding a boot key and disabling the overscan, nothing more.

@sd_snatcher I tried but no dice.

@DarkSchneider Overscan is a simple trick, and if it doesn’t work the game will still play perfectly fine since the overscan area isn’t to be used for anything essential.

And really there are many more things unspecified or not specified in enough detail by the Yamaha manuals, e.g. that enabling blanking takes effect on the next line (important for a tight screen split). If you would avoid everything not documented then for sure you should never use screen splits either, or mirror the pattern table, or make any assumption about minimum command execution speed, actually don’t use neither commands nor the adjust register because it’s not specified that they conflict, also never use direct VRAM access because the wait time is unspecified, etc. Programming for the VDP means making assumptions left and right.

Luckily the community has worked hard over the course of the years to better specify the VDP. Today MSX is a stable platform (like a console), and we can rely on this information that’s missing from Yamaha’s manuals.

By DarkSchneider

Paladin (942)

Аватар пользователя DarkSchneider

02-09-2019, 08:58

I'd forget the 50Hz even on MSX2. The MSX has no real but a fake 50Hz mode. It draws the same lines number into a higher resolution display. Then, what we have are terrible margins and incorrect aspect ratio. Sprites and tiles goes to hell, and only bitmaps could be adapted using more VRAM area creating taller bitmaps (that for pixel art could not be easy) but then we could not use the full pages for 60Hz as we need the taller ones to use the full page. And in any case we would have a smaller gameplay/visible area.
It is the same than for japanese consoles.

So, don't do the job that even the own designers or manufacturers didn't take care about. They did the computer for 60Hz and the 50Hz is only a forced mode for compatibility, that's all.

Then, because is for compatibility, you could add a special boot mode i.e. pressing SELECT while booting to force 50Hz mode instead 60Hz, but doing nothing special to handle it.

By inchl

Resident (48)

Аватар пользователя inchl

02-09-2019, 11:08

Fun to read this post while dealing with the same problem in our latest development (NOP MicroMirrorMen2019). We tried to use the overscan trick to enlarge the screen to 240 scanlines. However we reduced it back to 224 scanlines because any connected monitor only displayed 224-228 at most -and- using 224 lines gives space for an additional 512x32 pixels vram storage per page for sprite and animation gfx. To center the screen (in overscan) we needed to set vdp23 to the value 6. So far so good,... one thing left to do: prevent lines 224-256 from being displayed (in openMsx these lines are visible and some monitors display a small part of it). We turned the screen off at line 224 and enabled it again at 255 (but the enable doesn't work as you described in this post). We finally came up with a solution that is not that pretty but good enough: at scanline 224 we disable the screen and start doing all required game stuff like (soft)sprite management, joystick and mouse reads. These routines are perfectly timed and are completed just before scanline 0 is about to be displayed. Then we enable the screen (just in time) and the next frame is about to be rendered...

By Grauw

Ascended (10329)

Аватар пользователя Grauw

02-09-2019, 12:54

Interesting! Smile

My Dell PC monitor (turboR via the OSSC->HDMI) displays 240 lines at 60 Hz, and somewhere around 290 at 50 Hz. OpenMSX always shows 240. Out of the 243 lines I think those omit two lines at the top and one at the bottom. The OCM shows 240 lines on VGA output @ 60 Hz, iirc it omits one line at the top and two at the bottom Hannibal. WebMSX shows around 224 lines orso. How much my CRT monitor shows depends on the adjust knob on the back, up to all 243. Just using all the 243 lines I don’t have to bother with manually blanking (well if I disregard 50 Hz), so that’s what I’m going for atm.

Good point about spending the time working on something rather than just polling. Only thing I don’t like is to rely on the CPU timing, so I would still want to poll some value (and HR requires so much CPU attention that it can barely do anything else). If it’s line 0 I can just set an interrupt, but in my 50 Hz case I would need to know when is line -14. Indeed if you are using 224 lines it’s only 12 lines more so you can compensate for that e.g. with set adjust -6 to recenter.

Unfortunately the V9938 doesn’t have a usable v-counter (I’ve tried to get something usable out of status register 5 but haven’t managed to). I can’t use a sprite collision to give me a line interrupt MSX1-style either because the screen is blanked.

By inchl

Resident (48)

Аватар пользователя inchl

03-09-2019, 18:26

Counting status register#2 HR toggles from 1->0 to count the number of scanlines rendered and still having time left for other things is possible (using very smart code), however I don't think it will work. I expect the HR bit to remain at value 1 during the rendering of the vertical border as well. So counting offscreen scanlines then is impossible using the HR bit. Still wondering: does the set adjust have some effect on the max possible line interrupt? Relying on cpu timing is ok I think, but you should make separate versions per cpu that is being used...

About the monitor issue. My old msx monitor had some buttons on the backside that could change the height and width of the screen making the entire overscanned scanlines to come into view. However,... my current monitor does have those buttons, so any game that uses the overscan area to an extreme will cause the player to miss parts of the game. I think 224 is the max you should go for.

By Grauw

Ascended (10329)

Аватар пользователя Grauw

03-09-2019, 19:07

HR bit keeps flipping during vertical border, it is a reliable 15.7 kHz timer!

Adjust does not affect maximum interrupt line, I've tested this and emulator bugs were fixed.

About overscan, I think it's best to use all 243 lines for background graphics, it is the easiest to use and the background nicely scrolls into the screen edges. But of course the overscan area should not be used for essential information (like dialogue boxes with text), I position them within the original 212 line area. Maybe up to 224 would be ok too but I'm staying on the safe side.

Страница 19/25
12 | 13 | 14 | 15 | 16 | 17 | 18 | | 20 | 21 | 22 | 23 | 24