Grauw’s RPG in development

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

By DarkSchneider

Paladin (942)

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

04-09-2019, 08:59

Do you think is really worth the overscan for 60Hz? I am testing on my display and I have very little margin. Screenshot attached.
https://1drv.ms/u/s!AhQqCoPY5hXqjswOZcw7I5B-n8QRgQ?e=wmT7nw
Not overzoomed as I can (barely) see also the side borders if I change the border color.
Not sure if depending the display the margin could be larger, but is minimal.

Is there a demo version to try on my set to look difference?

By Grauw

Ascended (10329)

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

04-09-2019, 10:21

Yes. On my screen the difference is massive, extending to the edge of the screen really opens things up visually instead of being boxed in. In openMSX you basically see what I see.. It really depends on your monitor but on most the border is normally visible and this gets rid of it. It looks really nice, and I'm not going to remove it, it's a USP Wink. Too bad it can't overscan horizontally too like the V9990 can.

Test ROM here:

http://www.grauw.nl/etc/msx/tiletile.rom
http://webmsx.org/?ROM=http://www.grauw.nl/etc/msx/tiletile....

Does your monitor have vertical stretch controls and have you adjusted it to the MSX display area?

By DarkSchneider

Paladin (942)

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

04-09-2019, 10:22

It's a Samsung 25" CRT TV using RGB-Scart cable. If it has controls they should be internal requiring to open the TV. But it is well ajusted by default, as I can see well any machine, like consoles and old computers.

I'll try the ROM to comment about it.

By DrWh0

Paladin (835)

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

04-09-2019, 11:15

Grauw it is cool!

Everything moves (scroll and character) swiftly and softly.

I am anxious to see it finished Smile

Here you have my +100 points Smile

By Grauw

Ascended (10329)

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

04-09-2019, 11:55

Cool!

Vertical resolution of different consoles: MSX 212, NES 240, SNES 224 or 239, SMS 224, MegaDrive 240. From what I read a typical NTSC TV shows about 224 lines, so there’s about 6 lines of border visible for MSX on the top and the bottom, but there’s variation. HDMI displays connected through the OSSC show 240 lines, 1chipMSX VGA shows 240, openMSX shows 240, and WebMSX shows 228. For MSX, 243 lines overscan is the simplest, so there is not much benefit in going through the extra effort to manually control blanking at 224 lines.

By DarkSchneider

Paladin (942)

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

04-09-2019, 12:06

This is the visible area for 212 lines:
https://1drv.ms/u/s!AhQqCoPY5hXqjswm6makCTk-hwVELw?e=w38TLI
Not over-zoomed, as when anything involving horizontal scroll I already can see some side border (the same at left):
https://1drv.ms/u/s!AhQqCoPY5hXqjswnL5YiBLmIUenDOQ?e=0yyF2u

In this case, if setting the border black, I'd barely notice the difference, but the overscan get the curious effect of watching the TV border curve instead a straight line, that is the most remarkeable difference I think.

And yes most modes show like this, but the SMS and MSX1 with their 192 lines have some more margin and that cannot be shown taller or the aspect ratio would be affected. When tested the consoles at 60Hz they usually show a minimal margin like in the picture.

About overscan, if I readed correctly, there is need to poll the HR bit, but many lines? If not it would take much CPU time maybe?

By Grauw

Ascended (10329)

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

04-09-2019, 12:16

Looks like about 6 lines of border in your first pic indeed, so your TV probably shows 224 lines as expected.

Note my background is purple because I don’t have a pure black in my palette. I need every colour Smile.

The basic method to enable overscan is to set a line interrupt on line 211, and on that interrupt 1. select 192 lines mode, 2. wait to get past line 212 (poll HR briefly), 3. select 212 lines mode again. That’s all there is to it.

The stuff about polling HR for many lines is about the case when you want to artifically reduce the overscan by blanking on a certain line and then unblanking at another (the latter requires the polling). Imo it just makes things unnecessarily more complicated, that’s why I say it’s better to just stick to 243 lines. For me it came into play because PAL overscan shows 294 lines which is "too good" Smile.

By DarkSchneider

Paladin (942)

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

04-09-2019, 12:42

OK I think now I understand the why about overscan. This TV switchs the resolution when working on PAL-50, and changes when working on PAL-60 or NTSC (this supports anything even SECAM) to the corresponding lines. But I remember to have had a TV that didn't, it was not bad as it supported 60Hz by RF, but it didn't switch the resolution lines, so it showed the same margins that at 50Hz as it always showed PAL-50 resolution.

By Grauw

Ascended (10329)

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

05-09-2019, 21:09

It’s very simply about this / versus: (openMSX)

This / versus: (LCD monitor via OSSC)

This / versus: (CRT monitor)

It’s like the difference between playing a game in full screen and in a maximised window. You can play the game with borders, but it’s nicer in full screen, and since it’s simple to do, that’s what I present.

By Grauw

Ascended (10329)

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

05-09-2019, 21:52

Yesterday night I had a nice new idea about optimising the sprite updates.

Currently the sprite update takes 22293 cycles per 30Hz frame (18.7% CPU time). This is quite significant and the second-most time intensive task. This consists of 13292 cycles to update the sprite colour table (SCT), and 9001 cycles to update the sprite attribute table (SAT). As I explained before, I update the SCT at a 30 Hz rate and the SAT at 60 Hz, so these numbers include one SCT update and two SAT updates. Also note I always update all SCT and SAT entries, so these are the worst-case numbers.

I started with the idea to optimise the SCT update by using HMMM copy commands instead of writing to VRAM with the CPU. However doing small 16-byte copies is very inefficient, so how do I make them bigger?

I got the idea of dividing the 32 sprites into eight priority groups of four sprites, and treat them as a unit. Groups of four are pretty good for single 15-colours/line sprites, two 3-colours/line sprites stacked on top of each other, or particle effects consisting of four sprites. Additionally looping over these groups for things like sprite sorting requires just 8 loops rather than 32, so that also performs better.

This game also suits this grouping well; the player character is two full-colour sprites on top of each other (8 total), the rain effect is also composed of 8 sprites, and the mana shroud effect is currently two sprites but I could also make it four, sure why not. It seems quite a logical unit.

With this I can update the SCT with eight 64-byte HMMM copy commands, a decent size. I did some pen-and-paper maths and this should take about 1250 cycles per copy, give or take 10000 cycles in total, so already a small performance win.

But then in-between commands the CPU is mostly idling, waiting for the VDP to complete. What could we do during that time? Update the SAT with direct VRAM access! This’ll give great CPU-VDP parallelism, and where I currently update the SAT first and then the SCT so I need to visit objects twice, with this the two table updates are done in tandem which is both more logical and simpler.

So, I’ll be giving this a try. If all goes well, I hope that this will cut the time spent updating sprites in half. I’ll keep you posted on the final numbers Smile.

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