Grauw’s RPG in development

Страница 14/25
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19

By Grauw

Ascended (10564)

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

17-04-2018, 22:04

Hmm, I guess it’s due to how they bend? I’ll pay extra attention to the arm (and leg) movement in the future.

By Sandy Brand

Champion (277)

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

17-04-2018, 22:12

Nice!

By JohnHassink

Ambassador (5601)

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

17-04-2018, 22:22

Yes, it's because they move in the same direction, while when walking normally, your arms will alternate between the opposite directions.
I love the weather control effects by the way!

By hit9918

Prophet (2921)

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

18-04-2018, 00:00

and the arms are too short
they reach the belly when normaly they reach the middle of the leg bone
while when the hands touch the belly, then the arms angle is 90 degree

By hit9918

Prophet (2921)

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

18-04-2018, 00:09

ah, there are weather buttons to walk on Big smile

By Grauw

Ascended (10564)

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

07-05-2018, 22:59

Been a while since my last update but I’ve been slowly chugging away at stuff… A bunch of code improvements, mainly to do with screensplits, but also some visible improvements:

  • Dialog only shows while standing on a trigger.
  • Dialog animates in and out.
  • Dialog renders text. Press space/fire to speed up.
  • Dialog has its own palette, so doesn’t fade with the background.

The WebMSX link is still active in case you want to see.

Meanwhile I’ve also found some emulator bugs, or maybe I should rather say, very specific VDP behaviour details… Interesting stuff happens when you’re on the edge :).

OpenMSX:

  1. Sprites should disable at the end of the line rather than immediately (bug);
  2. Sprites should check for display end (overscan) one line sooner than the background does (bug).

WebMSX:

  1. Toggling display height for overscan shows a wrong part of the background (bug);
  2. Sprites should check for display end (overscan) one line sooner than the background does;
  3. Sprites should enable with one line delay (I mentioned earlier).

I’m a bit afraid to try it on the Zemmix Neo! -_-;;

The sprite overscan not working on real hardware gave me a bit of a scare when I tried it on my turboR today, luckily I remembered quite clearly that it had worked before, and after I found that I had to do the overscan trick one line sooner it is working again. Phew.

Another thing I found out is that, as you might know line interrupts can be set well beyond the bottom display line, up to line 234 at 60 Hz and 255 at 50 Hz. But the actual limit depends on the vertical adjust register. At 50 Hz, this actually means that an interrupt on line 255 does not fire if the user has adjusted the screen too far upwards. Must also be a little bug in VGMPlay then.

By DarkSchneider

Paladin (942)

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

08-05-2018, 09:35

Grauw wrote:
  • Dialog has its own palette, so doesn’t fade with the background.

Is fast enough to write the 32 values (OTIR I suppose) on the fly without consequences? I am interested too because having another different palette for top overlay and for gameplay would be a great advantage. It would be good having a base address like with other data, but for palette we have to write the registers.

Grauw wrote:

Meanwhile I’ve also found some emulator bugs, or maybe I should rather say, very specific VDP behaviour details… Interesting stuff happens when you’re on the edge Smile.

Well you know that it happens http://map.grauw.nl/articles/vdp-vram-timing/vdp-timing.html
Be careful when doing things at the edge. Much more in an open system like MSX. As you notice, an example could be the Zemmix, that could be perfectly another MSX model. Another example is using the Z80 undocumented instructions, it works, but then when executing on a R800...
So sometimes would be good to think about those things and set preference if "could" vs "should".

Grauw wrote:

Another thing I found out is that, as you might know line interrupts can be set well beyond the bottom display line, up to line 234 at 60 Hz and 255 at 50 Hz. But the actual limit depends on the vertical adjust register. At 50 Hz, this actually means that an interrupt on line 255 does not fire if the user has adjusted the screen too far upwards. Must also be a little bug in VGMPlay then.

That is really a bug in VDP documentation, as I don't remember to read anything about that. They should have warned. How exactly is affected the line interrupt?, it is 1:1?. Because I suppose it would be the same if adjusted to bottom, the most upper ones (like line interrupt at line 0-1) would not work.
Also, it "moves" the line interrupt? It that is the case, maybe we should add or substract the adjust value to the line value for drawing operations (i.e. drawing a top or bottom layout).

By Grauw

Ascended (10564)

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

08-05-2018, 14:07

DarkSchneider wrote:
Grauw wrote:

Dialog has its own palette, so doesn’t fade with the background.

Is fast enough to write the 32 values (OTIR I suppose) on the fly without consequences? I am interested too because having another different palette for top overlay and for gameplay would be a great advantage. It would be good having a base address like with other data, but for palette we have to write the registers.

I currently only modify 6 colours, two for the first two lines, then the remaining four, and then I restore the first two colours. I could go into detail about the reasons for this. But there would be time for me to update the remaining 12 colours across two lines orso if I’d want to put a full-colour graphic inside the dialog (like a character portrait).

The math is simple; an OUTI to the VDP takes 18 cycles normally, 19 or 20 cycles on MSX models with a Toshiba T9769 MSX-Engine (most MSX2+ & tR), and 27 cycles cycles on R800. So a full palette update takes between 576 and 640 cycles on Z80, and 864 cycles on R800. Divided by 228 cycles per line, that’s 2.5-2.8 scan lines on Z80 and 3.8 scan lines on R800. So you need to either blank for several lines, or limit the use of colours in the first couple of lines (which is what I do).

By the way, I was originally trying to support R800 mode even though it has no benefit for my 60 fps vsynced game. But due to the excessively slow VDP access throttling I could only do three VDP operations in-between HR polls (as opposed to four in Z80 mode), which was too limiting if I wanted to keep the splits as minimal as possible.

DarkSchneider wrote:
Grauw wrote:

Meanwhile I’ve also found some emulator bugs, or maybe I should rather say, very specific VDP behaviour details… Interesting stuff happens when you’re on the edge Smile.

Well you know that it happens http://map.grauw.nl/articles/vdp-vram-timing/vdp-timing.html
Be careful when doing things at the edge. Much more in an open system like MSX. As you notice, an example could be the Zemmix, that could be perfectly another MSX model. Another example is using the Z80 undocumented instructions, it works, but then when executing on a R800...
So sometimes would be good to think about those things and set preference if "could" vs "should".

As for V9958 emulations (including FPGA ones), I’m going to do my best to make it work, but in the end it is the emulation that needs to be fixed, not my code. Yes MSX is an open system, but the VDP simply needs to be compatible. I do have leniency with CPU speeds etc., I take care to test various things, but when doing extremely timing-sensitive things like (tidy) screensplits you’re simply going to have to make some assumptions on the hardware.

Fortunately indeed a lot of details are known, but many very specific behaviours really need software to use it before the emulator developers can discover them, simply because they can’t exhaustively make test cases for everything. But as a base rule for emulations, as much as possible MSX developers should be able to assume that the emulation matches real hardware, so it’s important the issues are reported and the emulation gets fixed.

DarkSchneider wrote:
Grauw wrote:

Another thing I found out is that, as you might know line interrupts can be set well beyond the bottom display line, up to line 234 at 60 Hz and 255 at 50 Hz. But the actual limit depends on the vertical adjust register. At 50 Hz, this actually means that an interrupt on line 255 does not fire if the user has adjusted the screen too far upwards. Must also be a little bug in VGMPlay then.

That is really a bug in VDP documentation, as I don't remember to read anything about that. They should have warned. How exactly is affected the line interrupt?, it is 1:1?. Because I suppose it would be the same if adjusted to bottom, the most upper ones (like line interrupt at line 0-1) would not work.
Also, it "moves" the line interrupt? It that is the case, maybe we should add or substract the adjust value to the line value for drawing operations (i.e. drawing a top or bottom layout).

Well a bug, a bug... It’s not documented to that level of detail. The exact range of line interrupts is affected 1:1, but the line interrupt number counts from the first display line, so the upper lines work fine. It just caps out after the sync signal, and if the screen is adjusted downwards that occurs sooner relative to the first display line.

Based on my findings the VDP works something like this:

  • The VDP keeps a line counter, initialised to a negative value at the start of the erase period.
  • The initial value depends on display frequency (*NT), vertical adjust (V0-V3) and display height (LN).
  • When the counter reaches 0, display is enabled.
  • When the counter reaches 192 or 212 (depending on LN), display is disabled.
  • The specified interrupt line (IL) is offset by display offset (DO) as (IL + DO) % 256.

The trick to overscan is to switch LN from 212 to 192 lines after it’s reached line 192.

By the way, I really don’t know why they chose a display height of 212 lines. Seems like they could’ve just as easily supported a height of 240, or at least 224 if they wanted to keep the vertical adjustment.

By DarkSchneider

Paladin (942)

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

08-05-2018, 15:15

Indeed 212 seems a bad joke, it doesn't fit with anything. Even you have 4 lost pixel of what-to-do-with-this-sh*t. I see even better to put a display off at line 208. No one will ever notice.
Well, that's not completely true, we put those 4px at the top layout, so maybe it could be used as working margin between the layout and the gameplay area. Display off, change display mode, change palette, base address registers, enable sprites, maybe other stuff, display on. Maybe not everything fits into 4 lines, but then simply put some more in "black" between areas, but those 4px are exploited for that purpose in any case.

Thanks for the info about the vertical adjust.

By Grauw

Ascended (10564)

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

08-05-2018, 19:12

Well I tried the Zemmix Neo… Splits are stable at all three CPU speeds and overscan works, however there seems to be some issue with sprites; they disable and enable two lines too late, so at the top of the dialog the sprites are still visible after the first blanked line, and at the bottom they miss the top three lines rather than just the one.

Also I note a frame skip when a dialog pops up (a VDP-heavy clear command occurs); I guess this is due to the HMMV command speed being a bit too slow, I hope KdL’s upcoming firmware will improve this.

Finally the screen is shifted down by one line compared to openMSX and my turboR with OSSC. Because the 60 Hz display area is 243 pixels high (16 border + 212 display + 15 border) but they show only 240 pixels (480p), so a few pixels need to be cut off. OpenMSX and the OSSC cut off two pixels at the top and one at the bottom, the Zemmix Neo omits one at the top and two at the bottom. A little bit of a shame that it isn’t consistent.

Страница 14/25
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19