Proof of Concept - Soccer game

Pagina 2/2
1 |

Van wimpie3

Champion (366)

afbeelding van wimpie3

04-02-2021, 07:22

Nice VRAM drawing BTW. I like it when someone pays attention to details.

Van AnsiStar

Expert (77)

afbeelding van AnsiStar

04-02-2021, 11:17

Please go on! I can`t wait for a good soccer game! MSX or MSX 2 does not matter! I thank you so much for doing this! I guess I`m not really able to code this as professional as you could do! The same for mzoran! Please go on! Many Greetings! Wink

Van aoineko

Master (160)

afbeelding van aoineko

04-02-2021, 22:29

@Grauw Thank you for these ideas

Grauw wrote:

To avoid the back-up copy of the background for each sprite, you could use a third, clean copy of the background which is never drawn onto as the source. This would not fit into VRAM, however since the background has a lot of repetition and the sprites are not tall, the restore-source can be compacted into much less lines so that it will fit in the space around the BG-Backup area. This way the nr of copies per sprite is reduced from three to two.

I need to keep room in VRAM for other graphic assets (goal keeper anim and some FX).
And what I like with the current method is that I can have a very detailed terrain, or even make it evolve with players who leave marks in the grass.

Grauw wrote:

If you know in advance the sprite is not walking across a line or another sprite, then you can draw them with a HMMM copy (if green = color 0). You could use a look-up table to check if this is the case, marking where the lines and other players are in an 8x8 grid. If you make the assumption that they move only by a few pixels at a time, if you increase their size with some padding you could even avoid the background restore copy.

That would be a good optimization. But 1) I have two green backgrounds and 2) there's a lot of line and overlap so it would be very punctual optimization. Not sure it's worth it.
That said, I plan to check players overlap to know which players I need to sort before drawing (for now, I sort all players).

The optimizations I plan to make are :

  • Don't draw the players we can't see! (yes, it's basic, but I haven't done it yet ^^)
  • Do not erase/draw players who do not move
  • Get rid of the default interrupt handler (have something lighter; and allow a 48K cartridge on page 0 to 2)
  • Rewrite in assembler some sensitive code (the rendering routines are already well optimized thanks to a very good site with "grauw" in the URL Wink )

But anyway, I don't plan to speed up the display a lot because I'm going to need a lot of CPU for the gameplay so ~3 v-blank per gameplay frame seems a good base.

EDIT : I forgot to mention it, but I use the technique I call "the sandwich" by inserting CPU computation between VDP commands execution. I don't have tools to analyze if it has a lot of downtime, but I guess not.

Van sd_snatcher

Prophet (3450)

afbeelding van sd_snatcher

04-02-2021, 23:37

Just as a curiosity, I enabled the R800 on the TR and the speed got considerably better. So you might still have some optimisations to do CPU wise.

Another tips:

  • Use a line-interrupt to disable the sprites just after the score bar is drawn. This will free a lot of VRAM bandwidth without having to sacrifice more screen area.
  • You don't have to sacrifice the whole BIOS interrupt handler. Most of the MSX games just disable the part that comes after the hook processing. This is very easy to do: just clear the frame interrupt flag before you return the processing from the hook to the BIOS

Van aoineko

Master (160)

afbeelding van aoineko

05-02-2021, 00:17

sd_snatcher wrote:

Just as a curiosity, I enabled the R800 on the TR and the speed got considerably better. So you might still have some optimisations to do CPU wise.

You are all right! I'm just tracking what's taking so much time on the CPU side.
My gameplay frame take 6 VDP frames; if I disable all bitmap sprites, I still have 4 VDP frames per gameplay frame.
I'm not supposed to do anything so CPU-intensive!
Do you know any tools to profile MSX program?
Sometime ago I read something about undocumented Z80 instruction that emulators use for profiling.
Any info?

sd_snatcher wrote:

Another tips:

  • Use a line-interrupt to disable the sprites just after the score bar is drawn. This will free a lot of VRAM bandwidth without having to sacrifice more screen area.
  • You don't have to sacrifice the whole BIOS interrupt handler. Most of the MSX games just disable the part that comes after the hook processing. This is very easy to do: just clear the frame interrupt flag before you return the processing from the hook to the BIOS

I plan to use HW sprites for player selection icons, kick direction and bottom goal posts, so I can't disable them.

For the BIOS interrupt handler, as I don't use any of the data that it compute, I will necessarily gain by replacing it with code that only handles H/V-blank interrupts I need for my game. All the PPI, PSG and VDP interaction are done with direct I/O port access (I don't use any BIOS routines).

Van aoineko

Master (160)

afbeelding van aoineko

05-02-2021, 00:32

I'll try the Grauw's profile.tcl to try to figure out what is going on.

Pagina 2/2
1 |