Sounds nice. Can you copy a 64px wide block 50 times a second or is the scrolling slower than that?

@Hrothgar: if you want to know about vdp command speed there is this http://map.tni.nl/articles/vdp_commands_speed.php
Some tricks can be done to improve speed, for example if you have a bottom area where there is score and no sprites, you can set up a line interrupt that when fired disable sprites, giving more speed to commands, (you must re-enable them on VBLANK of course).

However, there are no BIG improvement.
About the scroll, using YMMM with sprites enabled move 3360 bytes / frame (60Hz). So the scroll that metalion done could not completed in less than 5.4 frames @60hz. In terms of FPS goes about 10fps.

If instead the scroll is using vertical scroll register and you only move the rightmost 64x192 pixel area (score bar), the speed is 4 times fast, because the area is 4 times less large to move. So about 40fps.

What is unknow is the height of the score bar.

Quote:

Sounds nice. Can you copy a 64px wide block 50 times a second or is the scrolling slower than that?

The area to counter-scroll is adjusted to its content in order to avoid having to move unecessary pixels : at the moment, it is only a 64x56 area. That scroll engine works OK at 50 pixels a second but I choose to slow it down to 25 pixels a second for 2 reasons : first, 50 pixels a second was too fast in the game context and second, I still have not integrated the music replayer which will surely steal a lot of CPU time on interrupt.

With a 64x56 pixel area the copy should take 1/2 frame....

The YMMM speed with sprites and 192 lines is 4384 bytes/frame @50Hz and 3360 bytes/frame @60Hz
It means I can counter-scroll a maximum area of 64x137 pixels @50Hz or 64x105 pixels @60Hz

But it will be less than that, because first of all I have to move the clock numbers in the screen buffer.

Although as my scroll is made once every two frames, I could use one frame to move the numbers and prepare the new clock image, and the other frame to make the scroll and counter-scroll (I only just thought of that).

@Hrothgar: in the demo "almost real" there is a nice horizontal scrolling ( pseudo parallax) done in screen 7. Before the copper bars.
I'm wondering what tecnique they used. (if you have not seen this demo see it, it's very nice.)

Hrothgar, I'm still on hold waiting your graphics and level data for "our" TP engine demo

That Almost Real scroll is a two layer parallax scroll that's roughly one third of the screen height, and where the layers don't overlap (i.e. each scanline has a fixed scrollspeed). Seems done by X-smoothscroll register + 16px blockcopy for each of the two scroll layers. The text on top is sprites, IIRC I checked this in BlueMSX with the key combination ctrl+shift+s to toggle sprites. (But even without testing that, it can only be sprites as there's no way you can blit that on top of a smooth scroll.)

Another nice effect that I often see in demos is an object that turns around its center vertically, I recall more impressive examples from C64 demos than MSX. I think the main part of such effects is done by quickly altering the displayed scanline. That way you can stretch, crunch or rotate an image vertically. But what you need to make such effects convincing is also making 'deeper' parts of the rotation less wide as they're further away. Apart from pre-storing various image parts with various widths on your available VDP pages I don't know if there's a specific trick for that, or if C64 has more useful hardware tricks to achieve that easily.

Anyway I'm not sure how easy the first parallax scroll effect can be used in games (e.g. slower moving skies or mountains) if sprites can cover both layers. And the latter effect of rotation is nice but can really only be applied to the full screenwidth so I can't think of good game use cases either...

Quote:

That Almost Real scroll is a two layer parallax scroll that's roughly one third of the screen height, and where the layers don't overlap (i.e. each scanline has a fixed scrollspeed). Seems done by X-smoothscroll register + 16px blockcopy for each of the two scroll layers.

Yes, they do not overlap, and this is the reason i defined pseudo-parallax.
The fact that run on screen7 means twice the data to move, so i can imagine in screen 5 a double height. Almost a full screen....

However the point is: in parallax scrolling there is no need to overlap to 100% of height every layer. Games like moon patrol overlap for less %.

@Artrag: my graphical skills can use some training and I've started exploring that program you mentioned. As a proof of concept (and not to wait until I've actually reached the required level of designer skills to create something new) I thought it might be a nice idea to take an existing game that was derided for having a flip-screen version on MSX whereas all other platforms have smooth scrolling. I was thinking indeed of Vampire Killer / Castlevania or Contra.

Another possibility (that would be more productive in terms of tile repetition) would be a platformer à la Mario or Megaman or something. Although Screen 5 would probably have less added value for that kind of games, I think the potential for faster scrolling is better in such level designs. What do you think? I could try to make something showable out of it.

O, and no worries it is really "your" TP engine , if I recall correctly you already spent a huge amount of time on this project since 2005 isn't it?

Since 1990, TP has arrived to a first level promo in 1991 or 1992, publicly released at a Zandwoort fair, and abandoned that years.
I started almost from scratch a new TP engine with borders and parallax (TP promo had only animated background but no borders and parallax) in 2005, stopping it very soon in 2006 due to a big msx1 project (WIP).

I started for fun (now in C) a new version of the TP engine here few weeks ago, from our discussions, whose code is in this same tread.

I suggest this :
http://www.spriters-resource.com/konami/castlevania/com/display.php?file=com_undergroundgallery.PNG

Promotion can do easily color reduction with palette optimization, tile extraction and level MAPPING (!!) starting from the image you used for extracting tiles. (It saves the map data also in plain ascii !!)

Let me know

Ah thanks, I hadn't even touched those functionalities yet!

I was looking at full NES levelmaps on the web or MSX ones (the latter hardly findable, surprisingly!) due to colour restrictions but apparently that can easily be worked around. However for a demo (and also for an actual game) I think a mere horizontal level is preferrable to begin with. I'll give it a try, but don't expect miracles within a few days

Just thinking out loud, regarding horizontal scrolling in screen 5 on MSX2 (there was some discussion about that in this thread):
* A playfield of 240*160 pixels
* Scroll per 16 pixels (use H-Adjust register each frame for 1pix 'scrolling')
* Every 16 frames, flip the on/off-screen buffers
* 240*160 = 38400 pixels
* 38400 / 2 pixels per byte = 19200 bytes
* 19200 bytes / 16 frames = 1200 bytes per frame to the offscreen buffer
* Possibly copy/drawing of 160*2 pixels per frame for 'fixing' the left/right borders because of H-Adjust

Looks doable to me? Am I forgetting something?

That's indeed the 'basic scenario' of a screen 5 smooth scroller and it has been demonstrated on a *low* number of non-demo productions.

The first challenge could be to build up at least a minimum collection of software that utilizes this feasible approach.
The second challenge is to find out how far you can go with further improvements (multi-speed scrolling, extra effects such as parallax scrolling or movement besides the regular scroll) and still fit the game logic in.

I'm surprised the first challenge wasn't more extensively battled on MSX2 during its commercial years (even screen 4 smooth scrollers are rare). I'm not surprised about the second, as that's truly pinching the limits and will be difficult to balance with acceptable gameplay.

It depends on what you need to build/change in your game screen. If all you do is move a static screen, then yes: screen 5 is an option, and it's been done like that in -for instance- Manbow 2. Now, look Nemesis 123SalaParo and for sake of experimenting list everything (backgrounds, large tile enemies) that's moving on screen. Just the scars of Salamander/level1 come into mind already.