Video: Lesson P31 - Hardware Sprites on the MSX1!

MSX & MSX2 including the V9990 GPU (V9K)
Posts: 28
Joined: Tue Mar 24, 2020 1:18 am

Re: Video: Lesson P31 - Hardware Sprites on the MSX1!

Post by John » Fri Jul 17, 2020 11:46 am

"Unless you have some clever ideas to exploit this (like objects that move with the screen - staying in their 3rd)"

I have though about this again. I do not think you need clever ideas to do vertical scrolling if that is what you meant in your video lesson P52 ( you ask "how are you going to make your game scroll vertically?" near the end of that video or your quote above-, you can do vertical scrolling with unique tiles everywhere as I describe an outline of the method below. I think it is a generic method that can apply to a lot of games.
I think I was wrong before to think that it was important to swap tiles between the 1st and 3rd bank to get a vertical scrolling effect.
The important thing is that there is a way to show 768 unique tiles on screen and that is all you minimally need for vertical scrolling in 8 pixel increments. To do vertical scrolling with 3 tile banks you just need to swap the tiles where the cut off points are at each third of the
screen. For example if we have 768 unique tiles on screen and want to scroll upwards 8 pixels then in the first third of the screen we just need to shift the characters that make of that first third up 1 character, i.e. shift the character of rows 2 to 8 to 1 to 7. but at the 8th line of that first third we need to redefine (equivalent to a swap) 32 characters so it contains the adjacent 32 characters from the first line of the second bank, similar idea for where the second third of the screen meets the last third at the bottom of the screen.
Then we need to redraw a new line of characters right at the bottom of the screen-the bottom line maybe loaded from a game ROM. So for vertically scrolling the screen you need to redefine 24*3 characters over all the tile banks, or 96 characters at a time, this would be a minimum of 96*8*2=1536 memory locations updates in VRAM or RAM, including colour information, to update for every 8 pixel scroll upwards-using screen1 instead of screen 2 will need less updates because there is less colour information. A smaller game area screen will need less VRAM updates. If you use some of the tiles for game fonts e.g. to simply write a 3 digit score number using one line at the top of screen (instead of not using sprites for fonts), then that still means you can display 736 tiles for the game graphics (excluding top line for score)-which is most of the screen; writing a score with a custom font takes 10 tiles -one for each digit. Initially the screen will start with up to 768 unqiue tiles.

User avatar
Posts: 455
Joined: Mon Apr 22, 2019 3:19 am

Re: Video: Lesson P31 - Hardware Sprites on the MSX1!

Post by akuyou » Sat Jul 18, 2020 1:09 pm

I believe your theory is sound.

The question is, can you code it up and make it work in a game? ... I look forward to seeing your project.
Chibi Akuma(s) Comedy-Horror 8-bit Bullet Hell shooter! // 「チビ悪魔」可笑しいゴシックSTG ! // Work in Progress: ChibiAliens

Interested in CPU's :Z80,6502,68000,6809,ARM,8086,RISC-V
Learning: 65816,ARM,8086,6809

Posts: 28
Joined: Tue Mar 24, 2020 1:18 am

Re: Video: Lesson P31 - Hardware Sprites on the MSX1!

Post by John » Sat Jul 18, 2020 4:21 pm

The problem I am having for completing a game is making Arkos Tracker 2 work properly
I mention the problem at the page
Video: Lesson P35 - Playing Digital Sound with WAV on the AY!

I guess the issue is CBIOS differs from the real MSX 1 BIOS in a way that makes Arkos tracker 2 fail on a real MSX 1 (actually we can use catapult in Open MSX to emulate specific machines and it also fails on emulation of specific machines in catapult).Arkos Tracker 2 will add professional quality music to a game because it can use MIDI of professional public domain songs. Using Arkos Tracker 1 cannot add professional quality music to a game.

Post Reply

Return to “MSX & MSX2 Assembly Programming”