Chibi Akumas Episode 2: Confrontation! [game for CPC then MSX2]

Página 6/9
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9

Por keith56

Master (162)

Imagen del keith56

06-12-2017, 00:25

Yes I've already considered that, but it's not really possible, I've split the background drawing into two parts, to try to get more efficiency, I do the first half, then calculate the game event while its drawing, then I do the second half, then start reading the keys etc... I can't really say I noticed a difference.

A lot of the work is updating the bullets and objects, and calculating their collisions, I do the calcuation for one object, then draw it and repeat

If I split the job of bullet/Object work into two, and did all the calculations while the background was drawing, then did all the drawings, it would mean I was doing two loops over the data, more data reading, more calculations and I suspect this could make it actually slower. and of course, If I draw all the bullets one after the other, there's more chance Ill be waiting for for the VDP while the bullet drawing happens... where as at the moment, the VDP has time to finish while the next bullets new position and collision detection is occurring.

Really though, if using the R800 offers no noticeable speed increase (which seems to be the case - I could not tell if it was working at all, even running two copies of the game side by side on a Hitbit+Turbo-R emulatior), it seems to me that no re-organization of the code will make a difference - because however you cut it, the CPU is going to spend most of it's time waiting for the VDP...

Por PingPong

Prophet (3898)

Imagen del PingPong

06-12-2017, 01:07

keith56 wrote:

I've got the game running on the MSX2 now in an early state.
Chibi Akumas uses two screen buffers, and redraws the whole screen every frame. it seems the CPC is much faster at 'flood filling'

msx2 have more vram to manage, plus if you use logical fill operations it is slow as a snail

Por sd_snatcher

Prophet (3517)

Imagen del sd_snatcher

06-12-2017, 01:38

Some quick tips to speed up the VDP blitter:

- If you're not using the hardware sprites, disable them
- Reduce the vertical resolution to 192 lines
- Change the frame rate to 50Hz (PAL)

Quote:

the MSX2 is too slow for the gradient

Tip: The gradient can be easily implemented as a raster effect using the line interrupts and changing the palette of the background color, with minimal CPU cost.

Consider using the offset registers to scroll the screen, so you'll only have to blit the backgrounds once in a while. Another idea would be to move the requirement to MSX2+ and just use the horizontal scroll. Since you're already supporting the V9990, why not support the V9958? Smile

Por ARTRAG

Enlighted (6846)

Imagen del ARTRAG

06-12-2017, 09:56

@keith56 if you do not want to spread the vdp copy commands across the main loop, you could try to put in parallel the vdp fill with the cpu fill. Instead of waiting for the end of the previous vdp fill, start the second fill using the cpu i/o.
Cpu i/o is as fast as vdp copy, and you can manage to minimise the waiting time.
If things are well balanced the result will be almost equivalent to skip half of the copy commands.

Por Grauw

Ascended (10605)

Imagen del Grauw

06-12-2017, 11:07

Note that the VDP command execution slows down while the CPU accesses the VRAM (since they need to share access slots), so the net effect is not doubling the speed. However the combined effort should still give a little higher performance, especially during vertical blanking.

Por keith56

Master (162)

Imagen del keith56

06-12-2017, 12:05

ARTRAG wrote:

@keith56 if you do not want to spread the vdp copy commands across the main loop, you could try to put in parallel the vdp fill with the cpu fill.

Now that I hadn't thought of, interesting - I'll have to think if I can use it.

I've had a look at the bullet routine, I was wrong, the bullets are finished drawing by the time the next call occurs, so maybe it's worth splitting the job into two.

Por keith56

Master (162)

Imagen del keith56

09-12-2017, 03:43

ARTRAG wrote:

@keith56 if you do not want to spread the vdp copy commands across the main loop, you could try to put in parallel the vdp fill with the cpu fill. Instead of waiting for the end of the previous vdp fill, start the second fill using the cpu i/o.

OK, I've made a 'quick and dirty' implementation of this, and it seems to already give a 5% or so speed increase - one thing that's surprising me, is that the Z80 seems to do better than the Turbo-R's R800... meaning the slower processor can do more filling than the faster one?

Now I wouldn't be surprised if the R800 couldn't do more, but seeing as they have the same GPU performance (and I assume the same time to fill memory), I don't understand why the R800 is achieving less? can someone explain it???

Por ARTRAG

Enlighted (6846)

Imagen del ARTRAG

09-12-2017, 08:08

The r800 halts at each second I/O towards the vdp within a given amount of time
This makes its overall bandwidth worse than the z80

Por keith56

Master (162)

Imagen del keith56

09-12-2017, 09:30

I've rewritten the background code - the standard MSX2 now has the gradient effect, as I'm doing the gradient fill with the CPU while the VDP is busy with flood fill and tile areas - I think the game is faster too now even though it looks better!!!

Por Manuel

Ascended (18876)

Imagen del Manuel

09-12-2017, 11:32

Why not use a raster effect for the gradient, as sd_snatcher suggested?

Página 6/9
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9