 No.04734
Tafoid Administrator
Jul 30, 2009, 19:06
edited on: Jul 30, 2009, 19:10
|
High CPU usage itself isn't considered a MAME bug. There may be ways to implement a portion of emulation which doesn't hit resources quite as hard but as long the emulation is being presented properly - execution speed doesn't matter. I can confirm with your example it takes a mighty hit in performance. |
|---|---|
 No.04736
Haze Senior Tester
Jul 30, 2009, 21:29
|
in this case the hit is so extreme I'd be willing to consider it an actual bug, I imagine it's marking lots of big tilemaps as dirty, or there is some really inefficient code being called every scanline. |
|
No.04737
Tafoid Administrator
Jul 30, 2009, 22:35
|
Given Haze's feedback, I'll set this to confirmed. Thanks. |
|
No.10592
AWJ Developer
Apr 19, 2014, 10:11
edited on: Apr 19, 2014, 10:43
|
Haze's first guess is correct. The C45 road generator these games use is a very large tilemap (1024x8192 pixels) with RAM-based tiles. RAM-based tiles are kind of an afterthought in the MAME tilemap system; they are handled by invalidating (=redrawing) the entire tilemap whenever the RAM containing the tile data is written to. To make matters worse the C45 is a zooming tilemap, so the tilemap system can't redraw just the part that is onscreen; it has to draw the whole 1024x8192 pixels every time. Improving the performance of RAM-based tilemaps would require substantial changes to drawgfx.c and tilemap.c and might make everything else that uses tilemaps slower (which is just about all the "classic" 2D raster games in MAME) A drastic solution would be not to use the tilemap system at all for this chip and use full custom drawing code instead, but IMO it isn't worth doing because the slowdowns occur only briefly during attract mode, and not while you're playing. This is the same reason Fighter & Attacker takes a lot more CPU power than the other namcona1.c games (it constantly writes to character RAM during gameplay, requiring all the tilemaps to be redrawn every frame), and why Sega CD in MESS can't use the tilemap system (it's the absolute worst-case scenario, the framebuffer that the tilemaps are drawn into is in the same RAM that the tile data comes from, so the whole tilemap would have to be redrawn every pixel of every frame. I think Haze tried it and it ran at about 1% speed) |
|
No.10593
Haze Senior Tester
Apr 19, 2014, 12:04
edited on: Apr 19, 2014, 12:04
|
Custom code isn't really unwarranted for cases like this, the tilemap system has limits, maybe a secondary system with a different optimization point would help here (and would avoid quite so many drivers requiring 100% custom handling) that kinda seems logical enough, but in the end you're always going to need to fall back to custom code if things get too complex or you require more precise control over things (saturn etc.) and yeah, I tried a tilemap in MegaCD, the result wasn't pretty although MegaCD is a bit different anyway, you never actually SEE the tilemap onscreen, but the 'blitter / roz blitter' source data is stored in ram as one giant tilemap and I was hoping to utilize that fact, too slow tho, and performance on MegaCD with the tight sync already stresses MAME/MESS. |
|
No.10594
AWJ Developer
Apr 19, 2014, 12:39
|
I have some ideas for making RAM based tilemaps more performant, but they'll have to wait until some of the other things on my todo list are done. Cases like megacd, or like snes or psikyosh where the tilemaps can be freely moved around in RAM, are hopeless though, custom tile-by-tile drawing is the only way to go. |