MSX2 - 8 ways smooth scrolling SCREEN 5

Página 1/8
| 2 | 3 | 4 | 5 | 6

Por slumpmax

Rookie (26)

Imagen del slumpmax

18-03-2014, 21:28

20+ years ago I developed full screen smooth scroll routine for MSX2 and I lost all my diskette.

Today I develop it again and this is it.
http://tom.lookupdesign.co.th/dl.php?file=SLIDE

SLIDE.BAS - Main program
DQ2PAT.SC5 - Pattern for map (Use page 2), 256x212 for testing
DQ2MAP.SC5 - Map data (Use page 3), 128x128 for testing (8x10 scene)

- Screen 5 full screen (240x212 pixels)
- 8 directions
- USR0 for first draw.
- USR1(way) for scroll. (simple use U=USR1(STICK(0))
- USR2(pg) for SETPAGE pg (do not use SETPAGE because it make a sprite gitch)
- Can scroll faster by 2X, 4X, 8X, 16X (in progress)
- Sprite in progress

On running
- ESC for END
- Key "1" Display back page
- Key "2" Display page 2 (Pattern)
- Key "3" Display page 3 (Map data)
- F1 redraw (for testing)

Here is a video
http://www.youtube.com/watch?v=JgZSuzVcuiY&feature=youtu.be

MSXSee for View Graphics and DSK, XSA image file
http://tom.lookupdesign.co.th/dl.php?file=MSXSee

Login sesión o register para postear comentarios

Por Grauw

Ascended (10148)

Imagen del Grauw

18-03-2014, 21:49

I made a smooth scroll routine in screen 5 as well a long time ago… I would use the adjust register for horizontal scrolling, copying 1/16th of the screen to a back buffer every frame, and covering the flipping borders with sprites. To reduce the horizontal height I had a screensplit (I think at line 160) and showed a status display below. Is that the approach you used as well?

My main problem was that, at 60Hz it would scroll at a smooth 60 pixels per second, but it only left enough time to draw one 16x16 software sprite. So I discarded the idea, as it wasn’t good enough for the RPG engine that I wanted to make at the time. Though if you use hardware sprites, you can do more…

Por slumpmax

Rookie (26)

Imagen del slumpmax

18-03-2014, 22:57

In my old program I used adjust register for both h and v scrolling.
In new program I used adjust register for h, line offset register for v.
It can help to switch direction with no delay.

copy 1/16th to back buffer from left to right for scroll right
copy 1/16th to back buffer from right to left for scroll left
no need to reduce any height, lost only 16 pixels for horizontal scrolling
It fast enough for draw 5-10 software sprite at 16x16 or 32x32 from my testing
because each scroll need to draw a little line about 1-2 / 16 of the screen.
hardware sprite is easy to apply by relocation all sprites every scrolling. (use sprite in page 2)

I used HMMM of V9938 for optimized and it can optimize to faster than this.
(Sorry for my english, I can read english because I read "Daewoo CPC300 MSX2 User Manual" for 20+ time)

Por Grauw

Ascended (10148)

Imagen del Grauw

18-03-2014, 23:13

Still, 1/16th of the screen is 16 x 212 = 3392 pixels, and HMMM VDP commands can only move 2784 pixels per 60Hz interrupt (with sprites enabled). Are you scrolling at 30fps perhaps?

Your English is fine btw :).

Por Grauw

Ascended (10148)

Imagen del Grauw

18-03-2014, 23:15

Grauw wrote:

Still, 1/16th of the screen is 16 x 212 = 3392 pixels, and HMMM VDP commands can only move 2784 pixels per 60Hz interrupt (with sprites enabled). Are you scrolling at 30fps perhaps?

Mmh, actually that is 2784 bytes per interrupt (5568 pixels)… Sounds like quite some room left…

I wonder why I had such problems. Need to dig up my old code I guess :).

Por Grauw

Ascended (10148)

Imagen del Grauw

18-03-2014, 23:41

Grauw wrote:

Mmh, actually that is 2784 bytes per interrupt (5568 pixels)… Sounds like quite some room left…

I did some more calculations:

So the HMMM uses 60% of VDP command execution time (3392 / 5568). Then, to draw a single 16x16 software sprite means to use:

  1. an HMMM to back up the background behind it (128 / 2784 = 5% VDP time);
  2. an LMMM to draw the sprite (128 / 976 = 13% VDP time);
  3. an HMMM to restore the background behind it (again 5%)

That’s 23% in total, leaving just 17% VDP time remaining, not enough to draw another software sprite…

In fact, by those numbers even without scrolling background only four 16x16 software sprites can be drawn each interrupt. Maybe my expectations were too high Smile.

And maybe I was too quick to dismiss the test. If you use only hardware sprites for the characters, and use the remaining VDP time for e.g. animations, that’ll get you pretty decent results. Just characters walking behind objects will be a bit tricky with those, and of course you are limited in colour usage and the nr. of sprites on screen.

Or, render at 30fps. But I think 60fps is nicer user experience.

Por slumpmax

Rookie (26)

Imagen del slumpmax

19-03-2014, 00:52

amazing information

Por slumpmax

Rookie (26)

Imagen del slumpmax

19-03-2014, 01:55

I got idea for sprite.

does not back up but draw pattern background directly to it's position before redraw it.

Por Hrothgar

Champion (479)

Imagen del Hrothgar

19-03-2014, 09:53

Grauw wrote:
  1. an HMMM to back up the background behind it (128 / 2784 = 5% VDP time);
  2. an LMMM to draw the sprite (128 / 976 = 13% VDP time);
  3. an HMMM to restore the background behind it (again 5%)

That’s 23% in total, leaving just 17% VDP time remaining, not enough to draw another software sprite…

Some ideas:

  • You don't have to restore backgrounds first for areas where a solid sprite part will be drawn. Many sprites have large solid parts, see e.g. Core Dump that uses this technique.
  • Sprites will often only move 1 or 2 px in a direction each interrupt so only a fraction of a 16×16 area has to be restored, unless again you have very transparent sprites.
  • No need to 'back up', all parts can be restored by HMMM from your page containing all tiles, or even by YMMM from a corresponding tile in the same or the alternate swap page in at least 50% of cases, often more.
  • Depending on the level design, a great part of the screen might also be restored by a fill command (not in this particular demo with more elaborate tiles, but certainly in a MegaMan or Mario-kind of levels).
  • Again, depending on the surrounding background, you might be able to move the entire sprite by one copy command including a slice of its homogeneous background. That eliminates all separate restoring by issuing one copy command of e.g. 18×16 px for horizontal movement.
  • Much of the background shouldn't need wholesale copying by 16px if you have many repeating tiles, which is the case in a vast majority of games. This take a lot of VDP burden away (by adding some CPU burden).

This all will require some checks for each copy instruction. But comparing games such as Blade Lords or Core Dump, it seems you can achieve quite high frame rates with these tricks.

Quote:

And maybe I was too quick to dismiss the test. If you use only hardware sprites for the characters, and use the remaining VDP time for e.g. animations, that’ll get you pretty decent results. Just characters walking behind objects will be a bit tricky with those, and of course you are limited in colour usage and the nr. of sprites on screen.

Or, render at 30fps. But I think 60fps is nicer user experience.

I'd love to see demos of both. Combining (relatively) smooth scrolling and many characters could give an awesome game, even at 30 fps. Many blocky scrollers on MSX had much lower frame rates than 30fps and were deemed acceptable.

Por gasparrini

Champion (325)

Imagen del gasparrini

19-03-2014, 10:31

@ slumpmax

Congratulation for this your new programm scrolling map in all direction for SCREEN-5.
but, I however I would like know, if I can have got your editor of MAP in SCREEN5.

If you want, send me please at this my address private to gamecast@libero.it
my web site: http://www.gamecast.es

Good day and happy MSX !!
(^_^) AG.

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

19-03-2014, 11:35

@Hrothgar
At some point you're spending so much CPU time on optimizing the screen rendering, you're gonna need an R800 to actually manage a somewhat demanding game. And then you realise V9958 has hardware scrolling and you go lol

Página 1/8
| 2 | 3 | 4 | 5 | 6