Jump to content

Kiwi's Blog

  • entries
    92
  • comments
    70
  • views
    87,937

I worked on smooth scrolling today.


Kiwi

696 views

I keep finding work around this little glitch. It scrolls smoothly. With screen mode 2 without masking, the part of the tree start to lag back for one bit, then corrects itself in the next frame. With screen mode with masking, the top shows the same error. I am writing directly the tile directly to the pattern table every frame, I tried every other frame.

 

blogentry-24767-0-73609800-1368659827.gif

 

I used three 40 bytes to pull the original image from the pattern table. Then 32 bytes table copied from 40 byte table with one variable for off set, to my write tables. Then the write tables get written to the hot tiles to make an illusion that the tree is scrolling with put frame updating it position every 8 frames.

 

I probably did what nanochess might have done for his MSX version of Princess Quest. Take one tile, and make 8 copies of the trees in RAM. Then just write it to pattern table. Same result. I even ran out of RAM, but enough RAM for the tree tables. The screen was scrolling as intended. The Megaman sprites and some of it bubbles was laying on the screen. Pressing the fire1 button makes the program reboot. \^o^/

 

Only if I knew how much I am doing in one frame before vertical retrace occurs, I think I could nail the tree scrolling. I will eventually work on learning the assembly later. For now, I need to get my other few games worked on.

2 Comments


Recommended Comments

There is a trick to know how much time are you wasting inside vertical retrace interrrupt.

 

At start of interrupt (after saving the register and everything) load border register with white color, and at end of interrupt reload border with black.

 

The white color will show you how much screen time are you using inside interrupt.

 

Typically the white color should not exceed the first 32 lines, but that depends on your game.

  • Like 1
Link to comment

This is very interesting trick. I tried it with 3 different game loops with 3 different results. I used it like so.

paper(2);Set the background color by using the VDP register 7
delay(1);wait specified VBLANKs
paper(14);I used dark green and gray to keep from having a seizure. 

 

1st result, This part of the game uses heavy bgtile updates. I think it takes about 2-4 frames to update the entire screen. The player controls are in the NMI loop so they can move and jump when the screen get complicated when there's a lot of tiles to be update at a time. The result using the border trick, the screen flashes back from green and gray rapidly while the 4 top pixel remains green, about 4-16 pixels are gray. The graphic does occasionally corrupt part of the pattern table.

 

The next stage uses sprite majority. I did try to keep the bg scrolling to the minimum in this stage and used sprite majority for the objects. The border is solid gray and maintain full framerate. Only when the game is updating the bgtile scrolling at 1 per 3 frame, the enemy sprites movement are halved. I'm thinking when the border is solid gray is when there is just about to do a 2nd retrace.

 

In this project with 20 double sized sprite trees scrolling along with the grass. Majority of the border is green. The gray border is about 32 pixel tall reside on the top of the screen.

 

This is very interesting and useful. Thank you for letting me know about this trick.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...