MSX2 - 8 ways smooth scrolling SCREEN 5

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

Por tonigalvez

Champion (310)

Imagen del tonigalvez

11-07-2014, 20:23

Please people, open your mind on a new scroll era for MSX2. See the Green Beret demo for MSX2.

Por ARTRAG

Enlighted (6828)

Imagen del ARTRAG

11-07-2014, 20:29

Flyguille are you sure you do not want to better elaborate your point?
Question

Por flyguille

Prophet (3028)

Imagen del flyguille

11-07-2014, 20:49

no, my point is correct and is an answer to that guy that wrote a lot of idea of only updating background pixels that will be uncover in the next movement about the topic of software sprites.

well, if one have the pattern in bits like vdp does, it can use bit shifting to align and few XORs, but then , is not the best way to have it coded one bit per pixel like VDP (if doing software sprite better do it colourful).

Por ARTRAG

Enlighted (6828)

Imagen del ARTRAG

11-07-2014, 21:31

I simply do not get your point.

Por AxelStone

Prophet (3093)

Imagen del AxelStone

11-07-2014, 22:25

tonigalvez wrote:

The Artrag technique for the horizontal scroll on MSX2, is the best I saw on SC5 and SC8, the smoother, the less CPU consuming, no Sprite waste to mask the border shaking...

Now, MSX2 can be much powerfull than AtariST, because the ST do not have SETADJUST or HW sprites.

Shocked! Shocked! Shocked!

We want that Green Beret Wink

Por flyguille

Prophet (3028)

Imagen del flyguille

11-07-2014, 23:27

ARTRAG wrote:

I simply do not get your point.

The point is don't overload the z80 just for save some VDP writes.

And was a reply to this post.

Hrothgar wrote:
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 ARTRAG

Enlighted (6828)

Imagen del ARTRAG

12-07-2014, 08:24

hrotgar puts many thing of the floor, but many points that he proposes are valid and usually exploited in games based on tiles like ys or coredump
Terror revelation too tries to avoid undue vdp work and to use block fill any time it is possibile
http://youtu.be/RypGMBsO540

Probably you cannot make many elaborate tricks in case on fine scrolling, but also there using the cpu in parallel to the vdp to trace borders is a winning choice

Por hit9918

Prophet (2921)

Imagen del hit9918

12-07-2014, 18:46

Terror Relevation: add set-adjust action to it and it is 9938 with
60 fps scroll
+ software sprites
+ screen 5 tile mode
Big smile

Main differences versus beret columncopy is:
the screen is not copied, but rendered new.
the bitmap work happens in smaller pieces, not a fix workload "1/16 screen per frame".

Scroll is 60 fps, above the speed limit things not halt but drop to animation fps.
To get animation fps, the screen needs to be smaller.
But maybe with bigger tiles and cpu rendering every second tile in parallel one can get big screen size.

Por hit9918

Prophet (2921)

Imagen del hit9918

12-07-2014, 19:07

p.s. oh and with "render new" scroll, sprite background restore is not needed.

It has loads advantages, except the cpu cost.
But the typical big sprite game has little amounts of object to calculate.

Por ARTRAG

Enlighted (6828)

Imagen del ARTRAG

12-07-2014, 19:41

Awesome, when do you release it ?

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