Ouch! As I guessed, it's too much. Thanks for the calculations, dvik.

By the way, Daniel, have you visited fMSX official page lately? Marat claims BlueMSX to be a fMSX port. A long time ago it was a Windows port of fMSX, but AFAIK it does not use fMSX code nowadays. Am I right?

I'm sure the code can be optimized a bit. Not sure how little CPU usage is acceptable.

Yes I've seen that he still writes that blueMSX is an fMSX port. I haven't asked him to change it. After all blueMSX started as an fMSX clone. It may be a bit strange to call it a port though since blueMSX never was an fMSX port, it was more like a clone with quite big differences already from the start. And of course nowdays it doesn't have any fMSX code so its a bit of a stretch to call it a port

Regarding CPU usage:

The ZX Spectrum Vram is not pattern based so the process should rewrite the entire vram when do the scrolling (in the worst case) that is 6144 bytes long.

Now, even if msx1 had a more slower vram access, i think in this case this is not a limiting factor because basically vram writes are sequential and you can do out's without the need of address setting.

Plus using patterns the msx had only 768 bytes to write not the entire 6144*2 bytes.

So my guess is: if this game was possible on ZX should be possible in msx1. The cpu time wasted in vram management should not be the key problem.

PingPong: of course it can be done, but using 8x8 pixels scroll --> blocky!!!!

I also think its doable but the slow vram access is a quite big problem. The thing is that you need to update the patterns every 8th frame and the tiles every frame to do the smooth scrolling. So although you don't need to rewrite the entire 6144*2 bytes, its a lot more than just the 768 byte pattern table.

I've been doing calculations on a similar scrolling engine and if I did my math right it should be possible to use about 100 scrolling tiles and still have about 50% of the cpu time for game logic, ai, pattern table, ...

So most likely plenty of CPU to do a GnG port as well. It does require pretty good optimizations though.
A small side note: if you look closely at viejo_archivero's drawing, you'll see that all tiles can be scrolled without any updates to the color table, even the ladder with the green surrounding is nicely scrollable.

That's why I said that all credits should go for him! I just coded a small engine (using BIOS functions!)

I've just uploaded another scrolling demo here.

Whoooa! That's a real demo, man. Congrats!

Quote:

PingPong: of course it can be done, but using 8x8 pixels scroll --> blocky!!!!

Quote:

I also think its doable but the slow vram access is a quite big problem. The thing is that you need to update the patterns every 8th frame and the tiles every frame to do the smooth scrolling. So although you don't need to rewrite the entire 6144*2 bytes, its a lot more than just the 768 byte pattern table.

I cannot see the point.


see the zx version:

does not scroll at 8x8 pixels. this means that in the worst case the entire 6144 bytes of vram should be written.
And this is done at each frame!, because there are no tiles and the scrolling is NOT at 8 pixel steps.
Plus consider that in ZX the cpu also have to do sw sprite management.

So for example if a game do 10fps in msx1 this means: 768x10=7680 bytes per second managed
For the zx this may be:

6144*10 fps = 61440 bytes x second

a huge difference!


OK, in the ZX the z80 could thread vram as normal RAM because is mapped in z80 address space, and this is a huge advantage if we do random vram access, but not so uge if we update the entire screen in a sequential way. So teoretically
the msx have a small disadvantage in vram access but a huge advantage because it only manage 768 tiles.


IMHO the real problem is the number of tiles available

If there are too less tiles available maybe it's possible to use 4 pixel scrolling. If done at a sufficient speed appear smooth.

I modified viejo's gfx a bit and added it to my scroll engine. It works the same as viejo's demo, move with the cursor keys. If you go too far left or too far right you'll get corruption.
This demo is a 50Hz 1-pixel scroller with 100 tiles. Its plenty of time to do other things as well. So it scrolls one pixel every frame if you move left or right. It doesn't work yet in 60Hz but that shouldn't be too hard to fix. I added some gfx from the c64 version which I like quite a lot. Not sure how well it works with ghosts and stuff but in this demo it looks pretty good.

you can get it at http://www.bluemsx.com/demos/gngdemo.zip

Indeed it looks pretty good!
But you use a hybrid vdp mode. It works fine in my HB-75P but I heard that mode doesn't work on all MSX1 models

So, why didn't Konami use those techniques in their Nemesis saga shooters?

Because it limites severely the number of colors managed in the tiles. Only the foreground can be changed for every 8x1 pixels. Also the number of different tiles is dramatically reduced, so the backgrounds are simpler.
IIRC there's one game from Gremlin that uses a smooth scroll like that, Desolator, maybe this scroll could be used in a sequel!

Erm...not really 8x1, it's more 24x1 pixels or something like that
I guess that every 3 chars a scrolling tile is defined...

Quote:

IIRC there's one game from Gremlin that uses a smooth scroll like that, Desolator, maybe this scroll could be used in a sequel!

As far as I remember, Desolator just scrolls little zones of the screen (top and bottom), and the rest was sprites.