the crappy tmd vdp is not smooth scroll friendly. you can achieve smooth scroll, but you have to paid a lot in terms of details and memory usage. this involves also to waste a lot of cpu cycles to compensate for lack of space in vram. (if you transfer tile defs from main ram to vram). and code complexity
There is non miracle you can achieve. switch to msx2 .
if msxdev only accept only msx1 entries is a msxdev problem. i think you should code for your personal pleasure doing this not for msxdev instead. be sure that if you do a good work your creation will be appreciated by all of us regardless of msxdev
I'm with Ping Pong on the last point. Tho, you can still try to mix strategies 1 and 2 and see. If it still fails you still learn something.
Also, you could consider Screen 1. You loose some color goodness, but makes this thing easier.
albs_br, it is wobbeling, it needs double buffering
Hi guys, I'm working on Pacific 2, and one of the fundamental features I wish is a rich background with islands, beachs, rivers, mountains, etc with vertical scrolling, and the scroll must be fine, 1 pixel granularity.
My first take was: to have all the tiles needed pre loaded on patterns table, and search all names table incrementing each position, also doing tile scroll on all names table each 8 frames loading the next line on top screen and restarting the process. The cost of this approach is:
- 768 bytes read, at most 768 bytes write (each frame);
- plus 768 bytes write each 8 frames
BUT: after many days and everything working fine with very good speed (I will upload a video soon) I realized something that seems obvious now: there will be space for very few tiles this way, and so the background will be very poor.
Another approach then came to me: to have all the frames on ROM and copy them to patterns table, If I had, say, 64 different tiles, then will be 64 * 8 = 512 bytes each frame, plus the regular scroll on 768 bytes of names table each 8 frames.
It's bit frustrating send to trash a good part of the work done so far (I even done a set of utilities on C# to create the tiles), but it looks like I'm on a dead end and the first strategy has no future.
(I hope the explanation is clear enough to be understood)
For vertical scrolling in screen 2, there are a number of strategies you need to blend:
1) Design carefully the level in order to reduce the tile transitions. You do not need to reduce the number of elements on the screen, but the way they are displaced. If you use Magellan (look for it on Atariage for guidance) there is an option to count tile transitions.
2) Segment the whole map and plan VRAM usage. Keep in VRAM all tiles for representing a segment of the map (with its tile transitions). Design segment transitions in order to use only a part of the tiles, so you can update the other tiles in order to accommodate tiles of the next segment. As you work on hidden tiles you can update them across multiple frames.
3) Move the screen at steps of 2 pixels. It will halve the need of tiles (even more than halve when you compute transitions).
4) Use mirroring for color tables. It will not affect sprites and will reduce the number of byte sto be copied for colors. The side effect is that Toshiba vdps will be incompatible
The best thing would be to develop an offline tool able to arrange tile transitions in VRAM but if your level is well designed manual optimization would work as well
This is a nice example
https://youtu.be/WyYmGakiyfs
You can find it on github.
Its maps are designed in Magellan and are included among the files
It is for TI99/4A
I'm sure you didn't do this with an ill motive, but this is the well known slippery slope fallacy.
Yeah, I exagerated (just a bit, kkkk) for the sake of the argument.
What I really meant is: if for each difficult I had with a given machine limitation I switch to the next generation, I will soon be with a much more powerful machine, before even use the full potential of each one.
If I have a difficult time with fine scroll on MSX 1, an then go straight to MSX 2, tomorrow I will go straight to 2+ because of the horizontal scrolling, even before try the well known strategies for horizontal scroll on MSX 2.
There is a trade off between nostagia and machine power. Today this trade off is the MSX 1. Tomorrow maybe MSX 2. :)
The background scroll is already done each 16 frames (*), thats why is so slow, and it must be. The sprites are very fast (I copy from the 128 bytes sprite attribute table buffer to VRAM each frame).
(*) The term "frame" is being misused here. It's each game cycle in reality. I have the impression that the game is runnung around 150-200 cycles per second, so the variables are updated 2 or 3 times before even be shown on screen.
I have the wish to measure the cycles per second, and maybe run code each frame (60 or 50 times per second), but I'm not sure on how to do it. Any idea?
How professional games are usually made for MSX. One game cycle after another, or one game cycle per screen refresh?
Just confirmed here using phone's stopwatch: 6400 cycles in 40 seconds = 160 cycles/sec
Am I wasting CPU for no reason? It looks like this for me.
Don't know about "professional" games, but I would dare to say that most MSX software is V-Sync'ed. Either at 1 gameloop per frame (50/60 fps) or a fraction of that (1 gameloop every 2 frames: 25/30 fps, 1 gameloop every 3 frames: 16/20 fps, etc.)
The game I'm working on does the game logic at full framerate (50/60 fps), but background tiles animation only animates a few tiles every frame:
- Top bank, first half of animated tiles
- Middle bank, first half of animated tiles
- Bottom bank, first half of animated tiles
- (no animation)
- Top bank, second half of animated tiles
- Middle bank, second half of animated tiles
- Bottom bank, second half of animated tiles
- (no animation)
That distributes the transfer to the VRAM, so no frame gets overloaded. The "padding" is because is quite faster to divide by 8 than to divide by 6. (The actual schema is a little bit different, but you get the point)
If the background scroll doesn't need to be done every frame, I would suggest a simmilar approach:
- Prepare the new CHRTBL in the first 128 characters (0-127) for the first bank
- The same, for the second bank
- The same, for the third bank
- The same, but for the CLRTBL for the first bank
- The same, for the second bank
- The same, for the third bank
- Prepare the NAMTBL buffer using the first 128 characters (0-127)
- Blit the NAMTBL: the screen will be scrolled one px
- Prepare the new CHRTBL in the last 128 characters (128-255) for the first bank
- The same, for the second bank
- The same, for the third bank
- The same, but for the CLRTBL for the first bank
- The same, for the second bank
- The same, for the third bank
- Prepare the NAMTBL buffer using the first 128 characters (128-255)
- Blit the NAMTBL: the screen will be scrolled another px
This way, you have freedom of graphics (no need to have all the pre-rotated combinations), the scroll will be smooth, and the processing is distributed between the frames (you'll blit 1024 bytes per frame at most). Preparing the CHRTBL/CLRTBL can be a complicated matter, though.
that's the question: there is a trade. i do not think the huge efforts you need to do to have a moderate results are worth
ok, if those efforts achieved a marvellous super msx1 game with enormous non flickering and colorful sprites, omnidirectional bi-layer smooth scroll, i would agree..... but, hell we are taking of getting a simple smooth scrolling screen, a thing that even a C16 can do in hw. and watch what a Vic20 can do. https://www.youtube.com/watch?v=ANJQ5tZBhAs
It is something humiliating that on msx1 we can not replicate the VIC-20 demo with a machine that have sprite support and no hw scroll support.
Honestly i find absurd that v9938 engineers did not add a horizontal scroll feature to v9938. ( I guess they where planned to do this by i suspect that time to market pressure forced them to release v9938 in an not finished form)