help optimizing my blits in my program

[jotd]

Something is seriously wrong with my Xevious project (https://github.com/jotd666/xevious)

With fast memory, code is running OK, but as soon as I'm using only chipmem + cycle exact the game crawls and flickers despite double buffering

I've watched DMA debugger in this video on Project X (guys who know what they're talking about!)

[ Show youtube player ]

and indeed there's a lot of green, indicating that a lot of blitting is taking place.

In my game, here's the result



I'm using the blitter to blit enemies, and that doesn't show on the debugger

using "v -4" with FMODE=0xF

bitplane fetch looks different, copper yellow occurrences are expected (there's dynamic color on the text bitplane), there's a sprite (the ship) which expains the pink, background tiles are copied using CPU (8x8...) but even when only BOBs are active the game crawls.

Compared with Banshee on same config, Banshee flies. What I'm doing wrong? (Banshee shows the same blue -bitplane- pattern because of fmode probably, but a lot of greenish colors, not a lot of brown like in my case)

On my previous arcade projects, I had very few blits. Maybe 1 or 2. Here, lots of 16x16 enemies, small shots... Using dual playfield so no background restore. Lots of CPU also wasted refreshing text, but even without it it crawls...

dma debugger looks like a wonderful tool but I'm not getting it...

[roondar]

It doesn't appear from the screenshot you've shown that the Blitter use is the problem. Looking at the Visual DMA Debugger output you've shared, it's almost all CPU (the brownish colour you're referring to). The amount of Blitter time shown here doesn't seem to be much more than 10% or so of the total.

I'd check if there's something wrong with your main loop or if you accidentally do some stuff non-optimally with the CPU (or perhaps running some stuff too often?), because that's where your problem seems to be.

[paraj]

Yes, most of that is CPU activity. Here's an updated legend for the DMA debugger (hopefully without mistakes):


EDIT: Looked at the test you posted from a week or so ago, and it seems like all branches are word-sized even if they could be short. Maybe you're missing some optimization flags when assembling (that won't fix everything, but it certainly won't hurt)?

[a/b]

Yup, blitter is somewhat active in the top ~10% and then a decent amount of the 2nd quarter. Not much of a problem.
Lots of cpu activity, I'd guess the instruction cache is not utilized sufficiently. Also lots of unused slots in the cpu heavy parts (dark dots between purple and brown).

@paraj: Yeah, colors look OK. Just did one for myself since I never know what is what ;p.

[jotd]

Originally Posted by a/b

Lots of cpu activity, I'd guess the instruction cache is not utilized sufficiently. Also lots of unused slots in the cpu heavy parts (dark dots between purple and brown).

thanks.

I don't get the "lots of unused slots" part.

The fact that the game is a transcode from Z80 is probably the issue. It was designed for the NeoGeo where 68000 runs at 12MHz probably without bus cycles stolen by the dma.

The good point is: I could apply several micro optimizations and find one bug where the blitter was used to erase where a hardware sprite was (lol). But now I'm running out of ideas. Maybe my game will required fastmem (which a lot of A1200 owners have)

Here's dma debug with fastmem, A1200 cycle exact A1200 approx speed. CPU instructions don't even appear. Only CPU data appears and there's plenty of time to do everything... sob... (also runs great on 68060 ... unless I'm running the game in chipmem)

Running with CACHE on real machine slightly improves speed & flickering. Hope is not lost yet

[paraj]

This is clearly showing that you're limited by the CPU. If there's still graphical issues that aren't handled by double buffing you have to work on that. Are you only updating things in vblank interrupt or outside as well? Is that properly syned?

[a/b]

If would also check if it's possible to split larger routines so that they can fit into a 256b icache, or maybe do some reordering for better icache utilization. That's a huge factor if you only have chip memory, especially with so many slots taken up by cpu instruction fetch as seen on the first picture.
There is a section at ~20% with a lot of unused slots, are you doing muls/divs there or do you know what exactly is happening? Would it be possible to sync that with blitting so blitter can eat up those cycles?

[jotd]

There seemed to be a big issue on Mark's end. He did whatever magic he did, and the flickering is almost GONE now. dma debug is also different (I still have issues interpreting it but the bottom seems to indicate fewer cpu activity)



now time to optimize some heavy remaining parts.