Grauw’s RPG in development

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

By Manuel

Ascended (18730)

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

11-08-2019, 10:36

As these animations are only decoration, it is not important that they do not always work or if their performance degrades a bit with many animations visible. So, perhaps it helps to make some kind of prio-list and only animate at full frame rate the first N tiles and skip or lower the frame rate of the lower prio ones.

Just an idea, perhaps it helps.

By thegeps

Paladin (1020)

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

11-08-2019, 10:40

Cool! I like your work a lot! I like special FX (rain, sun, night and thunder's light) and flickering shadow too. I have to return coding on Freedom Fighter too (have to add score system and lives count and a proper weapon increasing system, add a main screen, a game over screen, possibly an intro, music and/or sound fx and (re)draw all the graphics and at least 5 tilemaps... AAAAAARGHH!). So seeing you coding again after some months gives me the will to do the same! Keep the good work!

By Grauw

Ascended (10565)

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

11-08-2019, 20:04

Manuel wrote:

As these animations are only decoration, it is not important that they do not always work or if their performance degrades a bit with many animations visible. So, perhaps it helps to make some kind of prio-list and only animate at full frame rate the first N tiles and skip or lower the frame rate of the lower prio ones.

So on the one hand I’ve learned my lesson from the sprite system I originally designed which was technically sound but practically unnecessarily complex and slow: KISS. So that makes me think I would rather prefer to avoid these kind of complexities, just like I plan to avoid having to implement a sprite flickering system by simply never going over the 8 sprites per line limit.

But on the other hand, IF I’m going to have to implement a draw queue system anyway, which it’s looking likely that I have to if I want more than just a couple of animating tiles on screen at a time, then adding a priority mechanism to it doesn’t sound like all that much more effort.

Animations are generally running slower than 30 fps (because who wants to draw all those frames), currently I unnecessarily update ’em every engine-frame even if they don’t change just because it keeps it simple and the timing constant. But in principle I could also just update half of the animations on the one frame, the other half on the next. However I worry a bit about things looking oddly out of sync, I guess I’d have to see how that works out in practice.

thegeps wrote:

So seeing you coding again after some months gives me the will to do the same! Keep the good work!

Thanks, seeing the stuff others are doing is definitely always motivating and inspiring!

By Grauw

Ascended (10565)

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

11-08-2019, 21:12

DarkSchneider wrote:

Dialogue box: stop all the other drawing while appearing, nobody will bother, and it is something natural.

That’s true, especially if it’s just a 1-frame delay (the dialogue clear doesn’t occur often). As long as just the animations drop a frame and the actual game and movement keep running smoothly.

DarkSchneider wrote:

Objects or tiles: if you want something specific for this game only, easy and direct to handle, tiles. In the other hand, if you plan to extend it on the future, or want something more flexible, objects. I'd go for objects directly.

Alright, thanks for the recommendation, I’ll think a bit more along that direction then.

DarkSchneider wrote:

Command queue: as it is VDP time, use VDP sync way, this is, line interrupts.

Good point Smile.

DarkSchneider wrote:

If you could measure the time required to copy a tile by the VDP in lines while rendering the display (this is, on visible area), you already have the number of lines between calls. Notice that this could be measured at start, like while showing logo or start screen. Execute a copy tile command i.e. at line 0 (so the VDP is drawing the screen) with sprites on and the other stuff you do (maybe copying with CPU at the same time), and then starting from low value check the finished command flag after that value of lines, then increase it until get the finish flag, and add 1 for safety.

I wouldn’t even need to measure anything, since I know in advance how fast things execute on the V9958 so I could just annotate every copy with how long it takes (or calculate it from the surface area).

The problem is, because I have a whole other bunch of splits going on, it’ll be difficult to splice in additional splits with variable timing. So that’s why I was thinking of sticking to a fixed interval corresponding to e.g. just enough for a 16x16 copy.

A programmable timer could be useful here! But alas, not available by default.

DarkSchneider wrote:

And concerning CPU copy to VRAM, can be OUTI in a row without glitches? I remember a recent post about having glitches when reading or writing to VRAM. What about with turbo mode?

Yes, screen 5 is fast enough for OUTIs. And all turbo circuits have a wait mechanism on VDP access. Without, too many things break (including the BIOS / Basic), so it’s simply impossible to make one without throttling in hardware.

DarkSchneider wrote:

I have been revising the documentation, and is not clear at all.

The TMS9918 documentation is pretty clear about it, it has a nice table somewhere where it amongst others says that in screen 2 VRAM access needs to be 8 µs (29 CPU cycles) apart.

The V9938 documentation is much less clear about it, it just says “Refer to the data sheet for access timings.” and I’ve never managed to locate those (if I’ve missed it, someone please point me to it!).

Luckily we have the openMSX V9938 reverse engineering documents which gives us so much insight that we could determine the timing precisely as well as know the reasons for it (where the access slots are located).

Practically speaking, from experience and knowledge about the VDPs:

  1. During blanking both TMS9918 and V9938 are fast enough to keep up with whatever the CPU does.
  2. During active display on the TMS9918 in screen 2, both back-to-back OUTI and OTIR are too fast, access must be 29 CPU cycles apart. So use OUTI / JR NZ,LOOP.
  3. During active display on the V9938 bitmap modes, it is fast enough for back-to-back OUTI.
  4. During active display on the V9938 bitmap modes, it is even fast enough for back-to-back OUT (C),r as long as no VDP commands are running.

This only applies to VRAM access (port 98h), there is no speed limit on register access.

By PingPong

Prophet (3885)

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

11-08-2019, 20:23

hey, grauw! i've done some test, by walking down (and scrolling vertically). I've noticed that there is no visible artifact in the main charater Y position due to the stupid magic Y coordinate when adjusting R24.
How you got rid of this? i can't really notice any hichup...

By Grauw

Ascended (10565)

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

11-08-2019, 20:29

Through the magic of moving the player by 2 pixels at a time! Smile

I discussed it earlier in this thread. There is only one place where I check for line 216 and offset by one, and that is in the “mana shroud” particle effect.

By PingPong

Prophet (3885)

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

11-08-2019, 20:28

Quote:

So I wonder what is the best way. I have two ideas: 1. litter non-blocking draw-from-queue calls throughout the code, or 2. make a lot of line splits (let’s say every 16 lines) and call draw-from-queue there. What do you think?

Just my two cents:
try to keep the status register containing the command execution flag as the current active one. then, periodically issue a call check_and_execute_vdp_queue or maybe a custom RST instruction that performs the same thing...

maybe this could have less overhead than a bunch of line split?
Or what to combine these two approaches?

By Grauw

Ascended (10565)

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

11-08-2019, 20:38

Yeah I have s#2 preselected since MOA suggested it earlier. I made a mistake just yesterday where I forgot to use the s#2 preselected version of the VDP command execution routine, and it disturbed the screensplits due to keeping interrupts disabled for so long!

An RST instruction is a nice idea. That would save some bytes and cycles!

I could also have a macro which does in a,(99h) ; rra ; call c,ExecuteCopy. Would be a bit faster but the RST is short and could also be considered maybe as a possible more general yield point for jobs other than VDP commands, I like that conceptually.

Indeed my worries with using splits is that they 1. have overhead, 2. are fairly complex to set up, and 3. could get in the way of other split effects I would like to do in the future.

How do you mean to combine?

By PingPong

Prophet (3885)

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

11-08-2019, 20:51

combine for me mean this:
because i'm afraid of overhead in screen split approach, i will try to keep low the number of split in a frame.
that mean a under used vdp potential that could be compensated by a more 'collaborative' approach that is using some RST calls between the game logic.
that's a matter of balance: with rare screen splits you get the possibility to keep at least the vdp busy even if not in a optimal way ensuring that at least some command will be executed even if you forgot to use the RST instructions in some part of the engine.

This mixed approach of course may have the downside of making complex your code....

basically:

vdp_screen_split_int:
RST _check_vdp_queue
ret


game_loop:
....
......
RST _check_vdp_queue
......
RST _check_vdp_queue
....
RST _check_vdp_queue
.....
.....      ; maybe here the vdp had a chance to get idle because cpu is 'hard working'..... but maybe rare screen_split_int ......    ;can supply to this issue by periodically checking.....
.....
jr game_loop

and openMSX had a nice script used to check vdp_idle_time ;-)

By Grauw

Ascended (10565)

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

11-08-2019, 21:07

Right, I see.

I don’t need VDP command usage to be optimal really, although it shouldn’t be terrible either of course. Just something so that the code can continue without having to wait for the VDP to complete, trusting that it’ll be dispatched later.

Btw I tried the openMSX VDP idle time script the other day, it didn’t really give me useful numbers, it just kept jumping up and down while I know that my VDP usage pattern is very constant. Maybe the many small 16x4 copies I make don’t mesh well with the sample resolution.

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