Scroll & Sprites

Page 1/3
| 2 | 3

By thegeps

Master (254)

thegeps's picture

11-02-2019, 20:57

I managed to merge togheter both my routines. I had to doubled pixels offset (cause it was slow) and animations, in fact, are little jerky.. Here's the video:

https://youtu.be/FefkL1YDJdQ

Then I decided to put sprites routine in the ISR and something weird is happend oO

https://youtu.be/wQ7_LqRttg8

any hints?

Login or register to post comments

By Grauw

Ascended (8384)

Grauw's picture

11-02-2019, 21:05

Both sprites and scroll update access the VRAM, changing the write address. Are you dealing with this?

By thegeps

Master (254)

thegeps's picture

11-02-2019, 21:19

Nope, I found what's the matter. The scroll routine poll jiffy for vblank and sprites routine is in htimi hook, so in the vblank. Now I've avoided jiffy's polling code and I have an improvement. Now the scenario scrolls but I have some glitches (wait 5 minutes and I'll post a new video. Don't Know if I have to slow vdp access. It's a outi loop... but if I deactivate sprites routine in the ISR it scrolls fine...

By thegeps

Master (254)

thegeps's picture

11-02-2019, 21:24

Heres's updated video:

https://youtu.be/TDSEF-OOoPs

By thegeps

Master (254)

thegeps's picture

11-02-2019, 21:46

almost forgot: scrolling routine uses shadow registers. And another thing: Scrolling routine uses also I registers (as a flag for double buffering)

By santiontanon

Paladin (821)

santiontanon's picture

11-02-2019, 22:24

My first thought was also what Grauw says! If the ISR kicks in half way through your outi loop, it'll change the write address of the VDP, messing things up.

But if that's not the problem, then it might just be a case of the ISR kicking in at different points during the scrolling routine probably, causing glitches.

Also, a quick trick: you can prevent the ships from being drawn OVER the scoreboard at the top, by just placing 4 sprites exactly over the scoreboard (they can just be black sprites that would be invisible), drawn with the highest priority, and the effect would be that the ship sprites do not get drawn in that area Smile (that's what I do to protect the scoreboard in XRacing Smile).

By thegeps

Master (254)

thegeps's picture

11-02-2019, 22:52

the ISR access the VDP only to write the 128 bytes of the sprite attributes tables...
I think that it doesn't change address 'cause, as I said, the scrolling routine uses shadow registers. But if I avoid executing the sprite routine (by putting a ret as first instruction) all works fine Sad

btw I saw a video of Xracing (I hope I'll play it soon): COOL! More cool if you think that one of my favourite games of all times is ATR (all terrain racing) for Amiga, that is most like your game! Great work!

mmm, I have to use 8 sprites so the fifth sprite will not appear in both score board rows (and setting start y=0 (now I use -16), I think...

By Grauw

Ascended (8384)

Grauw's picture

11-02-2019, 23:50

thegeps wrote:

the ISR access the VDP only to write the 128 bytes of the sprite attributes tables...
I think that it doesn't change address 'cause, as I said, the scrolling routine uses shadow registers. But if I avoid executing the sprite routine (by putting a ret as first instruction) all works fine Sad

If you call your ISR from the H.TIMI hook and then return, all registers (incl. shadow registers but excl. I) are restored by the system, so you can just use all registers freely and there’s no necessity to use the shadow registers.

As for the write address, I was not referring to the memory address stored in the CPU registers, but the VDP VRAM write address (set by SETWRT or via I/O port 99H) that the VDP keeps track of. It can be difficult to manage if this is set in the main loop, and then is changed in an interrupt which can be executed at any time in the middle of the main loop.

thegeps wrote:

mmm, I have to use 8 sprites so the fifth sprite will not appear in both score board rows (and setting start y=0 (now I use -16), I think...

Don’t you mean 4 sprites? You only need to hide the top 16 lines, right?

By thegeps

Master (254)

thegeps's picture

12-02-2019, 00:18

you are right. both times.
only 4 sprites (they are 16x16 so they'll cover both scoreboard rows)
aand yes, error is generated fr sure by writing on port 99h during isr (checked 2 mins ago, before reading your last reply)
i put
pop af
ret
just before the vdp write (that is at the end of the routine) and all works fine. So I can't put sprites management in ISR to speed up it. I have to go with first solution (doubled pixel offset and slow animations, but all works fine). I will use ISR to play music.

By thegeps

Master (254)

thegeps's picture

12-02-2019, 00:26

mumble mumble
I just had a mad idea...
I'll try to implement this foolness tomorrow and if it works I'll tell you

By Grauw

Ascended (8384)

Grauw's picture

12-02-2019, 00:49

Smile

One way to put VRAM writes both in the main loop and on the ISR is as follows. By disabling interrupts in the main loop you guarantee no ISR will occur. However if you disable interrupts for too long, the ISR will be delayed by too long and no longer occur during blanking but somewhere in the middle of the screen. So what you could do in the main loop is, after every (e.g.) 256 bytes, enable the interrupts briefly (ei / nop / di), then set the VRAM write address again for the next 256 bytes, until you’re done.

An alternative approach is to put everything on the ISR, but split the work of updating the background data in chunks so that it fits within 1 frame (16.7 ms). Though you could also do this on the main loop and merely sync to the ISR (by checking H.TIMI changes at carefully chosen points in the background loop).

On MSX2 V9938 you could also use the VRAM indirect access on the ISR, and VDP commands in the main loop (or vice versa), but the TMS9918 does not have that capability. Another thing that only works on V9938 is, you could write several sprite attribute tables into VRAM several frames ahead on the main loop (so double / triple / quadruple buffer it), and on the ISR only change the SAT base address to point to the next one. However I recall now that on TMS9918 unfortunately you can’t do VDP register writes without affecting the the VRAM address as a side-effect. Maybe this affected you as well.

Some suggestions.

Page 1/3
| 2 | 3