Video: Lesson P31 - Hardware Sprites on the MSX1!

MSX & MSX2 including the V9990 GPU (V9K)
John
Posts: 40
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 (https://youtu.be/pobGYc2iPfE) 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.
Right?

User avatar
akuyou
Posts: 489
Joined: Mon Apr 22, 2019 3:19 am
Contact:

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

John
Posts: 40
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.

John
Posts: 40
Joined: Tue Mar 24, 2020 1:18 am

Re: Video: Lesson P31 - Hardware Sprites on the MSX1! . Sprites in Dynamite Go! Go!.

Post by John » Mon May 31, 2021 3:27 am

Hi Keith,

There is a new MSX1 bullet hell game -Dynamite Go!Go!.

https://www.youtube.com/watch?v=Sl1aauVxmYM

How do you think it get so many large and colourful multiplexed sprite on the screen with out any flickering? Does anyone know what trick it is using? It's an impressive effect.

User avatar
akuyou
Posts: 489
Joined: Mon Apr 22, 2019 3:19 am
Contact:

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

Post by akuyou » Tue Jun 01, 2021 1:16 pm

That's not really bullet hell, I think 'Bullet hell' games typically require large numbers of bullets on screen, to the extent they are practically covering the entire screen (https://www.youtube.com/watch?v=Inq1LYYxyt0). Chibiakumas had up to 255 enemy bullets onscreen during the main levels, and over 1000 during the last boss battle.. of course I do understand that the term is subjective.

Anyway... on to the game in question.

They're using the tilemap for the big explosions and background, so they do not count towards the sprite count.

If my memory serves me correct the MSX1 can have up to 4 16x16 sprites on a line, and in theory the limit is 32 onscreen, It's possible they are 'repositioning these sprites during the screen redraw, so that they are breaking the 32 sprite limit - that's common on the C64 and CPC+...

Pause the video a couple of times - I doubt you'll find a frame where there's more than 4 hardware sprites on a single horizontal line. (It looks like they may be switching enemy bullets to tile graphics when needed - I see some change from white to green from time to time)

That's not to say that the game isn't technically impressive, because it clearly is, and pushing the hardware to the limit like that is a royal pain! just that, as far as I can see from the limited viewing of the video, that they are using techniques other games have used very well, not that they've found some new way to break the limits of the MSX.
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

Post Reply

Return to “MSX & MSX2 Assembly Programming”