| Author |
Message |
chris
Regular Member
Joined: 24/08/2020
Location: United KingdomPosts: 56 |
| Posted: 11:19pm 29 Oct 2020 |
 Copy link to clipboard |
 Print this post |
|
Hello,
I was thinking that a performance bottleneck of the current firmware of the CMM2 might be tile rendering in tight loops.
For example, if you have an 640 x 480 screen, and you have 8 x 8 tiles, then you have 4,800 tiles to blit per frame, and if you are aiming for a 60 frame per second lock (which is to be honest what you would expect from the hardware), then you have to blit 288,000 tiles per second, presumably the tiles are in a loop, which means that there would be 3 lines of BASIC code to be executed per tile (for line, blit, next line), which is taking up approaching a million lines of BASIC code, just to render the tiles per frame.
And that is just for tiles on one layer, and it may be that you want to render tiles on other layers too. Of course, the problem is lessoned if the resolution is much lower, but it's still a massive overhead even at 320 x 200.
Tile rendering is such a common problem it seems like the actual iteration over tiles, offetting, etc, could be handled in a BASIC instruction operating on carefully structured data.
I was wondering if a tile engine had been considered in the past, or if you might consider adding one if someone contributed the code and / or design?
Chris |
| |
NPHighview
Senior Member
Joined: 02/09/2020
Location: United StatesPosts: 213 |
| Posted: 12:27am 30 Oct 2020 |
Copy link to clipboard |
Print this post |
|
Chris - I highly recommend Michael Abrash's wonderful book, Graphics Programming Black Book, Special Edition, available online for some reason at https://www.jagregory.com/abrash-black-book/
Michael Abrash is now Chief Scientist at Oculus, working with John Carmack (of iD / Doom / Quake fame) on virtual reality and "artificial general intelligence." Abrash wrote this book a couple of decades ago, and published it through Coriolis Group. Hard-copy used versions are very expensive these days (up to $500 on Amazon), as no one wants to let their copy slip away from them.
Abrash uses Conway's Game of Life as an example, and your tiles are analogous to the cells in Game of Life. Abrash proposes a number of optimization techniques, including developing a list of changes (not all cells / tiles change at every iteration), making the playing field dimensions integral powers of 2 (sacrificing generality for performance), etc. Since he wrote his book, other concepts have emerged, including "memoized" calculations, that may help you.
On the CMM2, Peter has very kindly implemented some very fast graphics routines based on arrays. I've written a version of one of Abrash's optimized Game of Life programs for the CMM2 that loads these arrays (x(), y(), color()) only for changed cells, and very rapidly draws the field after each generation is evaluated to determine which cells are changing. There are issues with this approach (see discussions elsewhere), particularly having to do with redimensioning arrays in mmBasic based on the number of changes (for instance, after 200 generations, a 500x250 playing field in Game of Life may only show a couple hundred changes, or well under 1%) whereas a 500x250 field has 125,000 cells. The fast graphics routines have to run through the entire set of arrays each generation, and (so far) don't terminate on "odd" values like off-screen coordinates or unsupported colors.
The best I've been able to get in mmBasic so far is about 14 seconds per generation for a 500x250 cell (i.e. pixel) playing field. There may be "secret" routines that Peter is aware of that would make surveying neighbors faster, or CSUBs that I could conceivably eventually write that could do so, but I'm not there yet.
- Steve "NPHighview" Johnson
Edited 2020-10-30 10:35 by NPHighview
Live in the Future. It's Just Starting Now! |
| |
MauroXavier
Guru
Joined: 06/03/2016
Location: BrazilPosts: 303 |
| Posted: 01:35pm 30 Oct 2020 |
Copy link to clipboard |
Print this post |
|
Hi, Chris!
You don't need to recreate all the tiled blocks on the screen in each frame. In GAUNTLET I used tiles in another way that you have described, something similar to the NES.
You can put all the tiled scene in a frame buffer (using FRAMEBUFFER command) only one time, that can be at maximum 1600x1200 pixels, but if you need to have more pixels than that, you need only to make a frame buffer at screen resolution adding the size of two columns and two lines of tiles, for example:
If your tile is 8x8 and resolution is 320x240 then your frame buffer would be at 336x256 (320+8x2 and 240+8x2).
After this, make the first scan for all tiles for one scene, and after this moment you only need to write tiles offscreen on the sides according to the scroll when reaching the limit of the 8x8 size (considering the tile size of the example above).
You can use the PAGE SCROLL command or BLIT to make the screen move very fast, easily reaching 60 FPS.
In the early versions of GAUNTLET, the firmware doesn't have the FRAMEBUFFER command, then I used 16x16 tiles in the sides of the screen and used blit to scroll it only in the necessary portions.
PS.: Get an NES emulator and remove the border cut then get the "Super C" or "Super Mario 3" games, you will see something similar when scrolling the screen, but in that case, the tiles are on the main screen and these glitches do not appear on the television because it cut the scene as it's after the CRT safe zone.
Edited 2020-10-30 23:44 by MauroXavier |
| |
Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.