artrag

PS As Oscar says in the post at his link, if you stay with only two offsets (steps of 4 pixels), you can keep the two tilesets in place, (one in 0-127, the other in 128-255), and just update the PNT. With two tilesets you need only two maps from where to copy the PNT using the SCREEN command during VBLANK.

Smooth horizontal scrolling needs a little bit of work offline, using your own tools, to precompute tiles and maps. There is no HW support, so all the magic comes from your software and data. CV basic starts in "bitmap" mode (graphic 2 mode). Here the "general" solution is to precompute the tiles in all the in the intermediate positions and store them in ROM (say 4 positions if you move 2 pixels at time). At each step, you need to load the shifted definitions in VRAM on a set of hidden tiles (say e.g. 0-127), while showing on the screen tiles 128-255. When done, during VBLANK, you have to update the PNT by showing the tiles you have updated (0-127). Then you start loading the new tile definitions on the other tiles you do not display (128-255). Note that you need 4 set of tiles (up to 128), one for each "step", and 4 maps from where you need to copy the PNT on the screen, one for each step, corresponding to a given set of tiles. If your level is, say 128x24, you should store in rom 4 times, one for each phase of the scrolling. Naturally there are strategies to compact these data in one single map of "metatiles", but with CV basic the easiest thing is to deal with 4 level maps. If you try Magellan (available on this site, currently maintained by Rasmus Moustgaard) it should able to produce the data needed for smooth scrolling, but IIRC only in ASM and for TI99/A Actually, if you use screen 1 (graphic1 mode) instead of the "bitmap" mode (graphic2 mode), you have room in VRAM to store 4 (or more) complete tilesets that can be commuted by accessing to VDP(4). In this way your "only" task is to update the PNT during VBLANK. The side effect is that you can choose only two colors (foreground and background) each 8 tiles. So you can have a very light code but low color details.

In some cases it is convenient to stretch horizontally a bit the pictures to reduce the number of colors in the same line of 8 pixels. For static images the sprites can add a lot of details where you need to break the two colors rule. The converter by nanochess does an automagic placement of sprites to mask errors, anyway they are limited to 4 per line and can have a single color each. So it if matter of trade off also in this case

If you add segment management for mapped megaroms you can enable transparent cross development of large projects using colecovision Megacart mapper and ascii 8 msx mapper without changing the source code. You could also add 32kram support for colecovision (sgm) and this would make games totally portable without any effort

Awesome! I was going to ask for msx support 🤣🤣 Oscar, what about posting on msx.org the news about this new tool?

this should be shorter SAR R2, 2 ; R2 = R2/4 = R2*4/16 MOVR R2, R4 ; R4 = R2*4/16 SAR R2, 2 ; R2 = R2*1/16 SUBR R2, R4 ; R4 = R2*4/16 - R2*1/16 = R2*3/16

A nice gameplay https://youtu.be/804xXleO6YE?si=Ya4Y5quyDHS2y0ZG

Any progress on the sprites?

Very nice !

About invisible objects, the problem is that the game does sprite multiplexing to increase the number of bullets and items on the screen. On emulation, all frames appear correctly and all objects are visible. On real HW, some digital TV sets do not display odd or even frames, because they implement interlacing removal. The result is that some object does not appear or appear only in horizontal stripes. In this case try changing the settings of the TV in order to avoid interlacing removal. By trial and error I had some improvement on my Sony TV set.

Probably I should have betatested it a bit more... sorry for the inconvenience. About voices, I have decomposed the speech in tones and encoded them in data. Usually 3 tones are sufficient to get intelligible voice, but if Ecs is active, 6 tones per frame are used.

Yes! It supports both

Try OPENMSX ! It includes Colecovision and SGM

Not necessarily. Compare the asm files generated by the compier if you're curious about which solution is faster.

Note that x,y are 8 bit variables #backtab() is a 16 bit variable, its value has to be passed to a 16 bit variable unless you want to lose the upper 8 bits