I've never been too skilled at cutting out stuff... I've traditionally been a champ at overdraw. So I guess that'll be an adjustment I'll need to make, because I'm currently doing some overdraw.TmEE co.(TM) wrote: ↑Sun Jan 02, 2022 6:49 pmThere is only enough fill rate to cover all of the screen once while using all of the CPU power, due to all the wait states on VRAM access. If you want 60FPS you need to limit amount of stuff that gets drawn, both in area and definitely in overdraw. It is faster to check what has to be drawn and cull out pixels that will not be seen, not unlike a 3D engine has to do with its polygons.
Maybe 30 FPS is a more reasonable approach to this. It's just not what I had in mind originally.
I'm definitely using 256 color mode. Speed, lines of resolution, and the convenience of palette shifting/cycling/swapping are all attractive things to me. So far, I've made good use of the pixel shift register and line table, although I was not aware of the 0xFF bug. That's... really interesting, and I might have to make a few adjustments. I assume that's a bug not emulated in Fusion or Gens (or at least I haven't noticed it yet). Is the shift ignored for *all* lines in that scenario, or just the individual lines that end with 0xFF?Chilly Willy wrote: ↑Mon Jan 03, 2022 3:08 pmIf you want a scrolling layer on the 32X, you need to use 256 color mode, then use (nearly) all the vram, the pixel shift register, and the line table in vram to scroll the screen, only changing newly displayed areas of the screen. Beware of a bug with the shift bit: if a line table entry ends in 0xFF, the shift bit is ignored. That makes it really "fun" trying to make a generalized scroll layer as you need to keep any line in the view area from ever becoming xxFF.
As far as using most of VRAM, I had not anticipated I'd need to use more than ~70+KB. And maybe that highlights some flawed thinking on my part. Let me take a stab at explaining my approach:
What I have done up to this point is draw within a 328x232 area (8 additional pixels for both X and Y). I leave that extra wiggle room on the right and bottom edges for a little overdraw as needed. It is redrawing every tile for every frame, but the tile values used to locate pixels to be plotted are saved off in SDRAM. It takes a max of 41x29 tiles (each one is 8x8 pixels) to cover the entire screen, I have reserved double that amount for tile value storage and update the list of tiles each time new tiles need to come into view. I'm leaving the tiles I've already put into the table and *only* adding the new ones. So if I shift the screen to the right by 8 pixels, there will be 29 new tiles added to the end of the list. I will *also* put those same 29 tile values at the beginning of each row in the table. I have an index value for setting an origin point in the table from which tiles will be grabbed and drawn to the screen. If the screen has shifted a total of 82 tiles to the right, then the index value will wrap around to the beginning of the table. Since I put the new tiles at both the end and very beginning, wrapping is seamless as the tiles it needs are already in place.
I had thought originally that I was being a little clever (at least by my own standards), because it cuts out nearly all of the tile value calculating/fetching and mostly just has to grab the pixels it needs given the X and Y offset within each tile, and of course the tile value itself as a base offset for the art stored in SDRAM. But then I tested the final result, and I wasn't really impressed with myself anymore. Likewise, as I read more on these forums, I more and more realize that I'm not even close!
But back to what you stated... when you mention "use (nearly) all the vram", I assume you mean plot all those pixels ahead of when they'll even be needed and scroll. Makes sense to me, until I consider the fact that I will eventually need to draw sprites. Wouldn't I then have to basically redraw everything again anyway? So why use all of that VRAM? Unless there's an aspect of this I'm just not understanding...