Karoshi MSX Community

What about the remake of Ghost'n'Goblins?

a lot of replyies i see!

Hey SEPPASEPPA!

...afaik these were just gfx testings to see if it was possible, but there is no plan for remaking GnG... well, unless mr. dvik gives us a big surprise  ;)

Time ago i was tempted to an msx2 port, but the work done form msx1 switched me to the first gen msx. actually i've done some exp about a generic sprite engine multiplexer, and i'm in contact to dvik. we hope this remake will be done, but i think neither me or dvik alone have time to do. So any help should be appreciated.

Well, I'm not sure yet. So far its looking good but there is still a long way to go. But as SEPPASEPPA said, we are working on it and we are making progress. We're slowly getting the structure in place. Once we have something more ready we will need help with both gfx and audio. But so far we're just prototyping and setting up the basics but we'll keep you posted.

That's great news!. Indeed there's no hurry at all :)

dvik: the game project being planned will be MSX1 compatible? ;)

Absolutely. I'm pretty much only interested in developing for MSX1. But it probably will need a 128kB or 256kB rom, at least as it looks now.

Iauh! Good news dvik. I'm sure you'll do a very good job.  :)

With your words you've just made me a happy man ^___^. If you need some help, please ask: here you'll find lots of good musicmen and gfx artists willing to give a hand, you bet!.

Well, I must say that a MSX2 version would be cool too ;), but I prefer the MSX1 by far  :D

Once I have the game engine working I'll definitely need help with gfx and music and I know this is the best place to find good artists :)

It may be possible to use the game engine for an MSX2 game as well. I'm trying to separate the gfx engines as much as possible from the game engine so it may be possible to reuse some code for an MSX2 port.

In my mind this was already planned. But first the most challenging part. the msx1 port.

maybe the msx2 port will benefit of storing all the tiles in vram and switching between tiles only via vdp registers instead of blitting from ram.
maybe also the msx2 sprites could be a bit more coloured.

The MSX2 port could and probably should also use the scroll registers so that the tiles can be used more efficiently. With more VRAM it will also be possible to do better animations.

But first an MSX1 port :)

Here you have a PT3 file for first stage.It´s not finished yet,but it gave you some ideas of what you wanted.Rename it to PT3 extension.

Hope you like it :

KNM

 :guitar:  Very good!  :god: Do you know of any pt3 player that doesn't contain self modifying code? And also if there is a pt3 player that can be combined with SFX? I've seen many discussions about this but didn't follow them too closely.

You can ask dioniso about this,because he developed de pt3 replayer.Also,WYZ can provide nice info too.I´m not good in technical aspects,sorry  ;)

Thanks for your comments  :)

KNM

Please also rename your G´n´G and get somebody "burn" it to the cartridge... I could be interested to buy one...  ;)   i suggested renaming so there would be little less trouble with (c)opyright stuff when selling it as cartridge... ;D

by the way... which music you use for GnG MSX remake?

I still love spooky tune of Commiedore 64 version, amstrad had kind-of-same-tune, but it was simpler... and not as good.

I was very disappointed when I got GnG for Amiga.... tune was completely different... and NOT spooky in any way... NES tune also sounds very different..... I suggest you music artists there should listen C64 tune first.... it´s just sooo moody´n´spooky tune!  8)

I´ve made this myself,parting from the arcade original´s theme.

KNM
old bits never die!

Are there any manufacturers that can produce 128/256kB carts with an ASCII8 mapper? If there are it would be very nice to release the game on real carts. But first it needs to be finished.

About the name, maybe: Ghouls'n Gnomes  :-\

Goblins 'n' Ghosts?

dvik, Maybe Matra? ;)

Here´s mine : Ghosts´n´Gambling  ;D ;D ;D ;D ;D

KNM
You,zombie.You owe me five bucks! ;)

Even if I suffered some of the worst part of a copyright law infringement, I would suggest to keep the original name. As far as you label it properly as a "fan version", "tribute to the original game", "derivative work", there's little chance for misunderstandings, even if you sell it.

But first, make sure that Capcom is not willing to sell an MSX2 version soon ;)

There are quite a few ports and remakes of Ghost'n Goblins already and I haven't seen problems with any of them.
Any other companies or people than matra that could potentially manufacture megaroms? Matras shockwave roms look very nice but they are limited to 48kB, right?

If I'm not wrong Matra and even Pazos will be able to make MegaROMs soon...not sure anyway...

Ok, time for a little status update. This version has the state machine for arthur in place and some not so intelligent ghosts. It would be good to hear what you think of the engine so far and if there is anything you'd like to see different (e.g. a non flickering arthur or anything else).

You can control arthur with the cursor keys. Jump with space and fire with Ctrl.

Let me know what you think. The demo is at www.bluemsx.com/demos/GnG_20070126.zip

I also found a very good map of GnG icluding bitmaps of all enemies: http://www.geocities.com/gamesterlair4/GnGHome.html

WOW!

Really nice work, dvik! :o

Just a few remarks. Imho I would leave arthur free from flickering, so the only rotating sprite layers would be enemies' ones. But still as it is right now it is really fine!. I'm quite curious, how are you planning to implement arthur's shoots?. They will be sprites or patterns?. If sprites, you'll have lots more of flicker (but easier to implement), and if patterns (nemesis-like), you'll need a more complex routine... I suggest using patterns, except for the "Torch" item, that describes a curve, and it will be more appealing to see as sprites.

Anyway, this is the way to go!. Even you can climb ladders now! :D. Congrats agan dvik, as this is a grrrreat work! 8)

This is so GREAT WORK!

Here´s my suggestions :

* I think that Arthur could move a little faster.I´ve tested the demo both 50 and 60hz,and the movement on 60Hz is closer to the original.I don´t know if this is possible,but I like to see Arthur running a bit more ;)

* the jump is great,almost matches the original. :)

* And for now...no more to say.This is AMAZING! :god: :god:

UPDATED :

* If you jump near ladders,Arthur gets hooked on it. ;D ;D ;D

KNM
woah! cmptr:)

I can't complain. Very good work!

I also had a look at the link you gave with all the maps and sprites ... you have a work there! I hope I see this game finished, dvik. Keep the good work!

Impressive demo ;)

Nice work, dvik!

A few strange things I've seen:

-When you make use of your flickering routine, Arthur flickers even if he's not in line with the other sprites flickering. I suppose this is all because of the design of Arthur... there are invisible parts of him that are really in line. For example, I've found this situation... three zombies at the upper platform, three zombies at the bottom, Arthur at a certain position on the stairs... and everybody flickering!... You shout take a look at Arthur design... maybe you can make him more compact and take out a few sprites

-Sometimes when you jump and there are some zombies around, there is some sprite corruption on Arthur.

-If you jump from the graves on the upper platform, you get lost on the top and if you continue jumping, you appear again from the bottom of the screen.

About the shoots, maybe it will be better if you use patterns instead of sprites... then you'll be able to shoot more than one shot at the same time and you'll avoid flickering.

About avoiding Arthur flickering... I prefer him to be included, because you get a more simple flickering routine and you get better general results too.

BTW, I wouldn't mind if the scroll is not pixel by pixel. Dedicate all this CPU time to improve the game itself (and improve the graphics, of course). Don't design a scroll and make a game to fit in the scroll... better design a game and make a scroll to fit in the game!  ;) This game would be cool with a 8x8 scroll too (indeed, I vote for that).

Keep on working! All we want to see this game for MSX!!

Well done dvick!! It is very impressive!!

Here my proposals:

1) You can add the mountains in backgroung and make them fixed. It should be possible to add this detail, even if I do not know how ;-)
2) You can implement the EC bit in the sprite movements (now they jump into the screen on the left)
3) The zombies have the same blue color of the fence on the background. You should change one of the two colors
4) I do not like zombies' heads. I do not know how but heads seems too large and to float.
5) You could rip some GPX from vejos' demo (with his permission).
6) IMHO the main sprite can flick if this improves the overall flickering.
7) Now there is some glitch in the flickering routing. Sprites sometimes disappear even when you don't expect, e.g. while jumping.

Where are the bigger smilies?

Keep on Dvik! you can reach the best on MSX1.

:o :o :o :o :o :o :o :o :o :o :o :o :o :o :o
 ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D ;D

IMPRESSIVE!!

Really good work, Dvik! Come on, we are waiting... :D

Thanks for the comments and feedback :)

I've been thinking about that too. One option is to keep the gray part of Artur fixed but let the red part rotate. I haven't tried it but that may work.

I haven't decided but its leaning towards using sprites. From the beginning I wanted to use tiles but it won't work as well as in e.g. nemesis because the background has more details so it won't look as good. Then the handling would be different for the torch and axe since they have the curve. The biggest drawback with sprites is that it really limits arthur to fire one shot at the time. This is maybe not such a big deal, the C64 version does that too.


I think that's doable I'd guess that the original arcade was 60Hz. Its no problem to scroll 2 pixels every 5 pixels.

I did this on purpose (you need to push the up button while jumping if you want him to stick to the ladder. But I think the original doesn't so I should probably change that.


Arthur is indeed bigger than what's visible. He is 32 pixels high. Now when you mention it I think I did the bmp to sprite conversion a bit wrong so there will be some extra sprite hiding (think on the bottom part of arthur). But the ladder thing is sortof in the design. The reason is that all scanlines has 5 sprites and then all will participate in the flickering. This can probably not be avoided entirely but it can certainly be minimized by better positioning of the sprites.

You may be right but I think its an illusion. The jumping arthur has three sprites per scanline and they flicker independently of each other so sometimes the left part of arthur is shown and sometimes the right. This makes it look like corruption. All sprite updates are made in back buffers or offscreen (I use two SATs and three SPTs) There can of course be a bug as well ;)

Probably not, because I don't have many tiles to spare ;)

Absolutely. Just haven't gotten to it yet

The zombies are definately not production quality :) Some (or actually most) gfx is ripped from vijeos demo :)

Yes I've seen it too and the reason is that my sprite tool isn't aligning the sub sprites correctly. Its a very easy fix.

Why not using sprites? They are taller than the height of the jump of the main character so they does not disturb wrt the 4th sprite limit.
And you can have a sort of parallax :)

Vau!   :D  Looks and plays very good so far! Even I didn´t like this arcade soundtrack on Amiga, I do like MSX arrangement very much!!!

dvik: In my opinion, you must keep on working with the smooth scroll. Yes, it is GFX restrictive, but the playability of the game will be FAR better!  ;)

Jon, I think you're wrong. Those are different issues... a game scrolling 8x8 can be as playable as a game scrolling 1x1. Do you think all shooters from Konami have a bad playability because they scroll 8x8??

I'm not against 1x1 scroll... I just don't want to loose playability (and graphical quality) because of 1x1 scroll.

Well Imanok, *again, in my opinion* a 8x8 scrolling shooter (or puzzle, or strategy, or RPG) is not the same as a 8x8 scrolling platform game. Perhaps it is just me, but I can't imagine Alex Kidd in Miracle World or Super Mario Bros with a 8x8 scroll and giving the same playability to the gamer...

I respect your opinion, of course... I just think it's not correct.  ;)

I suppose you have played MSX 'Adventure Island'... this is one of my favourite MSX1 games and I thing it's
playability is great. The same goes for the horizontal cave zones of 'Golvellius', for example.

Anyway... G'n'G is not the kind of platform game SMB o Alex Kidd are. The real challenge of the game are not the platforms.

Of course, if a group makes two versions of the same game with 8x8 scroll and 1x1 scroll, and the playability is the same in both versions, I will prefer the 1x1 scroll version.

Is more than probable that several things according to playability will have to be sacrified to get the 1x1 scroll in a game (and much more if it's a conversion of an existing game).

Wow, then it must be just me, as I think MSX's Adventure Island is a real pain in the ass, comparing it to the enjoyment of the SMS or Gamegear version of Wonderboy ;) . And please note that I love both Wonderboy and Adventure Island games! (that last one has a really brilliant NES version!). The MSX one is, by far, the worst conversion of all systems... and that's not for the gfx, that are btw really cool, but for the scrolling, that takes playability to a lower level.

In the other hand, there are nice MSX games with 8x8 scroll that really rock, due to its speedy scroll: games such as Road Fighter, Magical Tree (that has a really nice vertical scrolling routine in which several lines are scrolled at a high speed when needed, instead of doing it line by line)... Magical Kid Wiz is another 8x8 scroller that looks pretty nice, as the scroll is kinda speedy too... so, ok, a G'n'G with an 8x8 scroll would surely rock too, but I wouldn't lose the oportunity to give a try to a smooth-scrolling project, just to enhance gamer's experience with the platforms and the whole game too... another option would be to scroll 8x8 several columns in a speedy way when a certain xpos is reached... but my best option is 1x1 scroll, that's for sure  ;)

I think that the preview of the project is really promising, Dvik! I'd say: GO FOR IT!  :D

Or, quoting a real MSX classic, GO FOR THE PUNKTE! ;)

Btw, Mr. Imanok, there was a nice project we were talking about long ago, where 8x8 horizontal scroll would fit really well... are you still considering that project or not? :)

 ;D ;D ;D

I haven't played those versions, so I can't tell you if the MSX one is the worse or not... I only say I really enjoyed it although it has 8x8 scrolling. Anyway it was just an example.

You're right.

You know perfectly the CPU cost of the 1x1 scroll and I think G'n'G has A LOT of things to move and to control. It will be really hard to get something similar to the original (talking about playability).

Btw, it would be really nice if the difficulty level is a bit adjusted, because the arcade is really hard.

I know it for sure!  ;D

Of course I'm considering it  ;)

Yay! :D

I´m with Jon.Scroll 1x1.It´s a challenge but worths it,sure!

KNM
smooth talktoomuch  ;D

I think same... in 8x8 scrolling shooter screen is scrolling anyway, even if you don´t move and your movement doesn´t affect scrolling at all... 

in 8x8 scrolling platform  your movement controls scrolling... Adventure Island/Wonderboy is one good example of horrible result using 8x8 scrolling... I have never completed second stage just because it is impossible to jump over certain water area..... probably someone can do it.. but i can´t .... it´s good game, but i can´t stand it because it is so hard to time your jumps as screen scrolls in 8x8 blocks...

I mean... in Nemesis and other 8x8 scrolling shooters scenery is scrolling SLOWLY... blocky scrolling doesn´t spoil gameplay as you have enough time to see what is coming to you.... 

But in 8x8 scrolling FAST platform games, you really don´t have time to see everything as screen scrolls so fast and it is much harder to calculate exact position of you hero for correct jumps as it would be in 1x1 scrolling platforms...


SuperBoy with it´s 8x8 scrolling is playable thought... but there surely are many places where jumping is much much much MUCH harder than it should be just because of 8x8 scrolling....

I guess you got my point.. :)

If you keep pressed certain key (can't remember now) you can run faster and jump longer.

Maybe it's me, then...

Ok, you don't like Wonderboy example... let's look some more games with 8x8 scroll controlled by the player (both MSX1 or MSX2):

Thexder, Firehawk, Ys 3, Akin, ... do you miss 1x1 scroll in those games?


This is not because of the 8x8 scrolling... it's because of scroll speed.

SuperBoy games are really crappy... and they would with 1x1 scroll too.

For me, TAKAHASHI NO BOUKEJIMA is one of the best MSX games. It's amazing to consider that such a long game can be packed in a 32 KB ROM with no advanced compression (Huffman, etc). Block scroll is not a problem if you keep moving, as you should, because the scroll is fast enough to give a smooth finish. I must agree that this changes when you have to move step by step.

Just in case, Masaxi, the keyboard controls are Z and X. Keep one pressed and jump with the other one: you'll get further!

Of couse, for more platform based games, smooth scroll can help. But, once again, design is everything in MSX development.

I'll go further: design is everything in game development ;)

I'll go even further: in game development, design is everything ;D (Dupont et Dupont may say it)

Once you decide to use some technical feature like the smooth scroll, you must adapt to that constrain all the other features of the game.

It is mastery of the programmer make that this choice does not affect the playability of the whole game.

This is the main difference between a demo (solely aimed to the technical issue) and a game.

I'm sure dvick will be able to keep the correct blend of all the ingredients (nice technical effects, playability, durability, etc.)
 ;)

First of all I must say that I'm really impressed with the actual status, now this is far from a tech demo!, it's starting to look like a real prototype of game, very promising at all!. Nice work Dvik! :D

Now, my opinions about some questions I've seen exposed in the thread:

- Sprite/character shots: I slighty prefer the character option, it's colourful, fast and has no number constraints. The drawback is how to manage weapons like fire, they could look strange due the 8x8 movement. :(

- IMHO the use of a smooth scroll (ss) or a blocky scroll (bs) leads obviously to a very different graphic approaches, without the ss constraints (resources and complexity) we can focus on the design of GFX full of SC2 color and diversity, also the sprites can even be replaced by character created sprites. The result will be more MSX in the way we're used to; but, as the GnG demo has born as a tech project to show how far the MSX1 can reach, I say go for the 1x1 scroll!.

You're totally right.

I don't doubt about dvik capabilities... I only say this may be a great handicap.

Thanks! I never tried to press BOTH z and x...  :D  I quickly tried game to see longer jump in action and it worked!! Thanks! Must try game some day again when I know this "secret" !  ;)  Ok... so 8x8 scrolling was not causing unplayability to Takahashi... it was just that i didn´t know "the secret" ! ;)

Games you mentioned imanok... Thexder is only game I have played... 8x8 scrolling didn´t bother me in that game. :)

 

Any news about this remake?

No, nothing new. I've been busy with the Utopia demo and the emulator. Hope to get back to the GnG port soon.

Great news!  :D

Yeah!A game like this on our MSXs worths it! ;)

KNM
Zombie Killer

I'm excited with this project!

Can't wait to play it on my MSX2 :D

Although don't forget it's for MSX1 computers... ;)

I know, I know ;) I'll use my MSX1 instead :D

any news about G´n´G project? hopefully it isn´t dumped yet...  ???

I'm almost changing my mind about using mirrored tiles which has a big impact on the GnG game. My main issue is that my favorite MSX CX5M does not support it correctly. And if I can't run the game on my favorite MSX I need to think of alternative ways of designing the game. But until I have a good solution the project is somewhat on a hold.

 :(

The CX5M must build the in-famous T6950 VDP...

IMHO you should use mirrored modes
Think to msxdev competition:

the rules say :

"VDP: TMS9918/TMS9928 or compatible video processor"

and the T6950 is not compatible with the TMS9918/TMS9928 processors
because only the TMS's allow mirrored modes
 ;D ;D ;D ;D

Thats a good point ARTRAG :) I suppose I could also buy another VDP and replace the one in my CX5M. That would also solve my problems.

I'm in no way related to the MSXDEV TEAM, but AFAIK the rules try to state that the game should work in *ANY* MSX machine. Therefore, if the mirrored tiles is an undocumented feature of the TMS, it cannot be asumed as a part of the MSX standard. Other MSX(1) machines use VDPs that do not support this mode, but they are certified MSX machines.

For MSX2 and higher there isn't any problem, 'cause all V9938/V9958 do support mirroring.

Actually the rules doesn't say it should work on any MSX. Here are the compability rules:


Games that uses 64kB ram will for example not run on my CX5M which only has 32kB ram. So I think ARTRAG is correct that mirrored modes are allowed without any penalties. But in the end its of course up to the judges to decide and to interpret the rules.

@Dvik: if using vdp tricks is not a clean job, why not halfing frame rate (25/30 fps) and scrolling at 2pix per frame?.
I've built some demo on disk and if you want i can send you a quick and dirty example of the scrolling to give you an idea.

In this way you can gain:
- two independent char sets (but you need to reduce the height of the game area from 160 to 128, not a big problem i think), this allow you more freedom in design of charsets.
Actually, using the bitmap you've used for GNG demo i see only 80 different patterns on each frame, and you do not use at all color attributes. this means that you can blit the entire pattern table with 640bytes only.
- the smoothness does not suffer from this and you can split CPU power in two frames.
- all msxes (included you beloved  ;D can run safely this sw)

If you want to take a look of a quick demo tell me, i've send you a .dsk with the binary...

Hi SEPPASEPPA,

I beleive that Malaika does something similar. The GnG demo is scrolling less than 128 already and this is not a problem, especially if the game can use a 128kB or 256kB megarom. then the tiles can switch to a new set of tiles half way through a level without affecting performance.

If you send your demo I'll send you something in return. But its too early to share that here on the forum but I'm sure you are interested in it.

dvik: Malaika does not change patterns or color definitions during ingame stage, as every possibilities for each tile are pregenerated and preloaded to VRAM pattern and color definition before the stage starts, independly for each bank, in order to use different "tilesets" in different banks at the same time. At Malaika, just the name table and the sprite atribute data is transferred during the ingame... this way every time I make a transfer to vram I transfer the same amount of data no matter the frame.

Your GnG approach can't work that way, as you have lots of more tiles out there: so I guess you redefine patterns while the ingame, and at each 8 frames you really scroll the name table too. What I can't imagine is how you can transfer that much data into the vram every frame: and moreover, how don't you get a slower frame each 8 frames, because of transferring the name table definition each 8 times?  ???, and how you still have room for the game and enemy logic for every frame?. Man, your code should be really efficient in order to work that way! :god:

Ah yes, I forgot that Malaika uses 4 pre-programmed sets of 64 tiles and then updates the bgmap to do a smooth2-pixel scroller, right?

The more of the cpu that goes to the scroll engine the fewer are left for game logic. The GnG demo has enough cpu cycles left to do the game I think. It has decent movement, sound and some super basic enemy ai and still has around 20-25% cpu left. If thats enough for full enemy ai and game logic, I'm not sure.

Updating the bgmap every 8 pixels is very easy, I just don't do as much game logic that frame :) I think the only thing I do in the demo during that frame is playing music and running the sprite engine. But dedicating 1/8 of the frame to this won't be visible to the gamer.

Actually, 8 pre-programmed sets of 32 tiles for a smooth1-pixel scroller. The thing is that each bank has an independant definition, that's why there are more than 32 tiles there (for example, those tiles being a cloud in the upper banks are the green grass at the bottom bank). Remember that this is not a mixed mode, but normal SCREEN2, so I have independant bank definition for my tricks' pleasures ;)

I hope I can give new life to this Ghost´n´Goblins project. :)

What is today´s situation for MSX G´n´G?

I surely hope you still like to finish your game, as your scrolling demos two years ago were REALLY IMPRESSIVE!!!!!!!! Something NEVER SEEN BEFORE on MSX-1!!!!!!!! :)

Please please please please please please please please continue programming Ghost´n´Goblins!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :)

(and ask matra to put it into cartridge form!:D)

Veijo, does, your original concept about GNG , use screen 2 or as dvik one are you using a hybrid mode?

My initial scrolling concept demo was an early implementation of Malaika's engine and, as Malaika, it uses a pure 3-banks Screen 2 mode: the basis is to have all tile possibilites predefined in the tile table and just change the name table. Dvik's implementation was far better and afair it was based on real-time tile redefinition, a different approach from mine: as he needed to redefine tiles, a single bank mode was really a must for avoiding 3x transfers.

OK, i've done some experiments about scrolling. Let's me explain.
I start with pure screen 2 and i have all the tiles loaded, changing only the name table.
I start in the leftmost position say, x=0 (charater position,not pixel position)
Every 8 pixels scroll (my example is only forward scrolling but can be adapted), i reload the same table as in position x=0, only shifted 1 char left. Plus i redefine the changing tiles (because of the scroll the in-going tiles from right maybe are new shapes).
With the dvik patterns i've found that during scrolling only 1 to 5 tiles must be redefined, and some tiles became unused because they go out of screen.

The point is that instead of redefine 100 char tiles, i only redefine the new tiles that are from right to left.
In the worst case an entire column of tiles (24) need to be redefined, however pratice showed me that only 5 tiles can vary between physical name table scrolls.


The z80 have all the info to quicly modify only the tiles needed, because the work of determine witch tiles change is done on a PC that takes a full map bitmap image, scan this and generate tiles info.
Thus every name table scroll, the z80 overwrite the unused tiles patterns and colors with the new from right, and do also the name table scroll

There is an advantage:
You do not need to keep all the tiles of an entire map to a maximum of 64 different tiles. Only at a specific x charater value you are costrained to 64 tiles. when the screen scroll, new incoming tiles (24) will substitute the tiles that are unused.
Of course the n. of tiles on every screen *must be* less or equal to 64, but the number of tiles in the global map is unlimited.

Pratically, during scrolling, when a tile is unused, is replaced by a new tile that comes on screen because of the scroll.
In my example, because of the limited amount of tiles involved i also change colors, not only patterns.

There is a diadvantage:
When designing the map you must ensure that the number of different tiles never exceed 64.
For example if you use all 64 tiles at x=0 and for x=1 you have 3 tiles that become unused and 5 that became new, you end up with 64 - 3 + 5 =66 tiles. Not good. However this was (with dvik tiles) never happened.

I did not fully understand you idea.

Each new 8x8 object that enter on the screen needs up to 2 tiles shifted in 8 positions, i.e. 16 tiles (actually 15).
Basically, if the object is not already in the tileset I need to find a position for it (i.e. 16 tiles, even if 15 should be ok).

Using pure screen 2, you have 16 "slots" of 16 tiles each in each bank, thus the total number of objects
on the screen at the same time is 16 per bank (i.e. 48 in total on 3 banks).

How do you get 64 ?

AR

64 are the 256 tiles available on msx1 divided by 4 (assuming 2 pixel smooth scroll) different tile versions, one for each 2 pixel scrolled tile.

the idea is simple: look at this nametable layout:
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBC
.....

say for example that the tilenumber of 'A' is 0
and tilenumber of 'B' is 1

when x = 0 you only have tiles 'A' and 'B' on screen, because 'C' is on immaginary column 33.
when you scroll one charather left, the entire column of 'A' disappears and the tile pattern for 'A' is changed to reflect the image of the pattern 'C'. Plus the nametable is also updated. The tilenumber of 'B' does not change between scrolls is always 1. Instead the tilenumber of 'A' is 0 and is overwritten by the pattern of 'C' when the scroll takes place.


Problems arise when you have, for example one disappearing tile and two new incoming tiles and you have already used all 64 tiles. You will end up with 65 but is not possible because 65*4=260, that is greater than 256.

Hope is clear now,

Totally, it was clear also before, but without the info you plan to scroll with 2pixels steps it was impossible to get your numbers.
 
Assuming 2pixels steps, you get that each 8x8 object needs 2*4=8 tiles (or better 7 if we do not count the blank tile)

This means that each bank can represent 256/8 = 32 objects, or better 256/7=36 plus some spare tiles (among them one is the common blank tile).

Thus in total you can have 32*3 = 96 objects on the screen (or better 108)

Why 64 ?

Sorry, i've forgot to mention this.

64 x bank, assuming 2px scroller, (256/4) or in your example that is 1px scroller (as you said) 256/8 = 32 x bank. (not considering the blank tile, for simplicity)
anyway if you want (and i find it) i can send you a small demo.

Well, an object of 8x8 needs TWO tiles while scrolling.
This is why I say that an object needs 2*4 = 8 tiles (7 with the blank reuse).
For the same reason I say that each bank can hold up to 32 (or better 36) objects, thus having 32*3 (or 36*3) total objects on the screen.