 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. |
Forum Index : Microcontroller and PC projects : Graphics Commands, Arrays, and Terminating Conditions
Page 1 of 2   |
|||||
| Author | Message | ||||
NPHighview Senior Member  Joined: 02/09/2020 Location: United StatesPosts: 202 |
Folks - I'm writing a CMM2 implementation of Conway's Game of Life using some of the techniques from Michael Abrash's excellent Graphics Programming Black Book - Special Edition. Since many of the graphics operators in MMBasic can use arrays, I'd like to set up a draw list for cells in Game of Life that are changing (dead --> alive, or alive --> dead). This would be in the form of change_x(~10,000), change_y(~10,000) and change_color(~10,000), something like ... PIXEL change_x(), change_y(), change_color() ... It's not clear to me whether the graphics operators will march unconcernedly through the arrays, heedless of value, or whether there is some "go no further" value that the operators will detect, and stop. I could conceivably release and re-dimension the arrays each generation, but unfortunately, I won't know just exactly how many cells are changing state until the entire field is evaluated, and I'd rather not have to go through the same process twice to build the lists to pass to the PIXEL command. Help please?!? (Right now, I've got the program working, finding changes and immediately drawing or erasing pixels. For a 500x250 field, this is 16-17 seconds per generation, even with Peter's excellent recent hashing-based Release Candidate.)  Edited 2020-10-23 16:40 by NPHighview Live in the Future. It's Just Starting Now! |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
OK - I've rewritten the Life program to clear and use a change list. As I mentioned above, the list is composed of three arrays, draw_x(), draw_y(), and draw_c(), and each is (x-extent * y-extent) in size. So, for the field shown in the drawing above, 500x250, that's 125,000 elements each (huge!!). I use the MATH MAP function to rapidly clear the list after each generation. Also, as I suspected, the PIXEL command happily zips through the list, drawing all of the changed pixels. Unfortunately, my first attempt puked when I filled the list arrays with "-99" values, in hopes that the code would stop when it encountered an out-of-bounds value (can't use -99 as a color). Unfortunately, it errored out, and "ON ERROR SKIP" skipped the entire PIXEL command, drawing nothing. The actual number of changing cells, which, when randomly filled at a 10% probablility, goes something like this: Out of 125,000 cells, Gen 1: ~15,000 change, or 12% Gen 2: ~ 5,000 change, or 4% Gen 3: ~ 2,500 change, or 2% after that: ~3,500 change, or ~3% after ~450 generations, the amount of change is negligible:  So, for a huge fraction of the time, 95+% of the array extent is not used. I don't exactly know what the PIXEL assembly code does when it finds coordinates off the screen, but it wasn't any faster than traversing the list step by step myself. Unfortunately, both approaches turned out to be about a second slower than just setting the pixels as soon as the change was detected. My request: alter the assembly code to terminate when an off-screen coordinate is encountered. Live in the Future. It's Just Starting Now! |
||||
vegipete Guru  Joined: 29/01/2013 Location: CanadaPosts: 1122 |
Eeek, no! :-) An off-screen coordinate is, in my view legitimate and quite valuable. Instead, a 'silly' value makes more sense, such as the value "10000" used in some of the sprite functions. Visit Vegipete's *Mite Library for cool programs. |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
That works for me! I could initialize the arrays with the silly value, then populate the arrays from 0 on up (sorry, non-C coders!), leaving only silly values after the "legit" list. If I'm dreaming, I could also wish for a "linear transform" MATH function that applies both slope and intercept to an array of values (a current MATH function will only multiply, not add a value). It would look like this: MATH LINEAR a, b, old_array(){, new_array()} where each element of new_array(i), if specified, is set to b + a*old_array(i). That would allow me to apply scales and offsets to my floating-point values for X and Y and map them into a region of the integer coordinates of the physical screen. (Maybe I can do this with quaternions - I'll have to check it out) And if I'm really dreaming... clipping windows!  Edited 2020-10-25 02:48 by NPHighview Live in the Future. It's Just Starting Now! |
||||
| vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1122 |
I was dreaming about clipping regions too. Most of the clipping effect can be accomplished by drawing on a different page and then blitting the region of interest into view. The only part that doesn't work with this method is printing text. Clipping would force the text to wrap and scroll inside the region but for now, we dream, and code it in basic. I like your MATH LINEAR dream. Let's go nuts with our dreams and have a MATH ROTATE that takes as input theta, x() and y(). Visit Vegipete's *Mite Library for cool programs. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6223 |
Put those two together and I think you have what you are after. Jim VK7JH MMedit |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
MATH ADD, MATH SCALE, and BLIT will do the trick - thanks to VegiPete and TassyJim (I'm going to have to find some catchy two syllable / one syllable nickname for the forum!) - Steve "NPHighview just doesn't scan" Johnson Live in the Future. It's Just Starting Now! |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
OK - strange stuff! I first tried doing all of the plot graphics off-screen (to Page 1), and got weird artifacts when blitting from Page 1 to Page 0 to display. Instead of this:  I got this on the screen (note jaggies whereas previous was very smooth):  and this is what the SAVE command produced (note the excursions beyond the plot area; I expected this, as I was using Blitting to copy just the plot area to screen 0):  So, I tried using the framebuffer instead. This got even weirder, resulting in this:  which I got both using the "normal" PAGE WRITE FRAMEBUFFER syntax and the otherwise documented FRAMEBUFFER WRITE syntax. Oh - I'm using Screen Mode 9, and Peter Mather's recent "hashing" firmware 5.0506RC5 Insights? Suggestions? Edited 2020-10-26 08:33 by NPHighview Live in the Future. It's Just Starting Now! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10075 |
Please try the very latest experimental version. Another user found an issue when both the display page and Blitting page are in SDRAM and the copy involved non-word-aligned memory copies. This seems to be a H/W limitation that I've tried to code round Edited 2020-10-26 08:42 by matherp |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
I just tried yesterday afternoon's firmware ("lots of diagnostic messages"), no joy, same jaggies, same System fault message when I tried using framebuffer. The sign-on message still shows 5.05.06RC5, though; is there a different one I should try? - Steve Live in the Future. It's Just Starting Now! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6223 |
This one is the latest (I think) https://www.thebackshed.com/forum/uploads/matherp/2020-10-26_052139_CMM2V1.5.zip Jim VK7JH MMedit |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
With the latest pointed to by TassyJim (above), trying BLIT commands, * works: 2, 4, 6, 7 but too coarse to be useful * fails: : 1, 8, 9, 10, and 13 shows jaggies, and doesn't draw vertical lines (width=1) * fails: 11, 12 no extra video pages * too coarse to tell: 3, 5 Or, if you prefer: 1 : Jaggies, vertical width=1 lines not drawn, text OK 2 : Works fine (but too low resolution to be useful) 3 : Too coarse to tell 4 : Works fine (but too low resolution to be useful) 5 : Too coarse to tell 6 : Works fine (but too low resolution to be useful) 7 : Works fine (but too low resolution to be useful) 8 : Jaggies, vertical width=1 lines not drawn, text OK 9 : Jaggies, vertical width=1 lines not drawn, text OK 10 : Jaggies, vertical width=1 lines not drawn, text OK 11 : Fails due to no extra video page(s) 12 : Fails due to no extra video page(s) 13 : Jaggies, vertical width=1 lines not drawn, text OK Live in the Future. It's Just Starting Now! |
||||
Sasquatch Guru Joined: 08/05/2020 Location: United StatesPosts: 376 |
Warning - Long I2C timeout (i.e. 1000ms) can cause the dreaded system fault. Update: sorry wrong thread! Edited 2020-10-26 11:44 by Sasquatch -Carl |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10075 |
Please post simplest possible test code showing the issue. I think I have a fix but need to test properly. Please particularly try and demonstrate the crash when trying to use the framebuffer Thanks Edited 2020-10-26 20:52 by matherp |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
Here you go: ' blit_artifacts.bas - Demonstrates BLIT issues with mmBasic 5.05.06RC5 ' Steve "NPHighview" Johnson October 2020 OPTION Y_AXIS UP ' Note upright Bitmap capture requires v.5.0506RC4 and up. DIM INTEGER vres%, hres% DIM INTEGER x%, y% DIM INTEGER h0min%, h0max%, h0ctr%, h1min%, h1max%, h1ctr% DIM INTEGER vmin%, vmax%, vctr% DIM STRING key$ FOR Vmode% = 1 to 10 FOR Cdepth% = 8 to 16 STEP 8 Mode Vmode%,Cdepth% ' Set video mode and color depth hres% = MM.hres : vres% = MM.vres h0min% = 0 : h0max% = hres%/2-5 : h0ctr% = h0min%+(h0max%-h0min%)/2 h1min% = hres%/2+5 : h1max% = hres% : h1ctr% = h1min%+(h1max%-h1min%)/2 vmin% = 16 : vmax% = vres%-15 ' leave room for text boxes PAGE WRITE 1 : CLS ' Clear the slate for blitting PAGE WRITE 0 : CLS ' OK - write to left half of screen directly. BOX h0min%, vmin%, h0max%-h0min%, vmax%-vmin%, 4, &H7F7F00, &H400000 ' dark grey background FOR x% = h0min% to h0max% STEP 10 : LINE x%, vmin%, x%, vmax%, 1, &H606060 : NEXT x% FOR x% = h0min% to h0max% STEP 40 : LINE x%, vmin%, x%, vmax%, 2, &HA0A0A0 : NEXT x% FOR y% = vmin% to vmax% STEP 10 : LINE h0min%, y%, h0max%, y%, 1, &H606060 : NEXT y% FOR y% = vmin% to vmax% STEP 40 : LINE h0min%, y%, h0max%, y%, 2, &HA0A0A0 : NEXT y% BOX h0min%, vmin%, h0max%-h0min%, vmax%-vmin%, 4, &H7F7F00 TEXT h0ctr%, vres%, STR$(Vmode%)+":"+STR$(Cdepth%)+" Page 0", CT, 1, 1, RGB(yellow), -1 PAGE WRITE 1 : CLS : BLIT h0min%, 0, h1min%, 0, hres%/2-5, vmax%, 0 ' BLIT the graph TEXT h1ctr%, vres%, "BLIT 0->1->0", CT, 1, 1, RGB(yellow), -1 ' Add Right Hand title PAGE WRITE 0 : BLIT h1min%, 0, h1min%, 0, hres%/2-5, vres%, 1 ' BLIT the right side back BOX 0, 0, hres%, 15, 1, &H808080, &H808080 TEXT 0, 0, "[p] print, [q] quit, any other advances mode", LB, 1, 1, &H000000, -1 key$ = inkey$ : DO WHILE key$ = "" : key$ = inkey$ : LOOP SELECT CASE key$ CASE "q" : CLS : END CASE "p" PAGE WRITE 0 : SAVE IMAGE STR$(Vmode%)+"x"+STR$(Cdepth%)+"_Page0.BMP" PAGE WRITE 1 : SAVE IMAGE STR$(Vmode%)+"x"+STR$(Cdepth%)+"_Page1.BMP" END SELECT NEXT Cdepth% NEXT Vmode% Pressing "p" after each mode will save bitmap files from both page 0 and page 1. Now that I can sequence through the modes and depths, it seems that it's in 16-bit color mode (I didn't run any tests at 12-bit). In 16-bit Page 9, here are the two captured pages: Page 0 (after blitting the left half to page 1 and then back)  and Page 1 (after blitting the left half of page 0 to the right half of page 1)  Edited 2020-10-27 03:46 by NPHighview Live in the Future. It's Just Starting Now! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10075 |
Great many thanks Please try the attached CMM2V1.5.zip |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
Just altered the program to cycle through 8, 12, and 16 bit color depths (except for mode 9, of course), and had to change explicit color values to RGB() values. Problems not exhibited in 8-bit modes, but 12 and 16 bit in high resolution modes. Party colors! ' blit_artifacts.bas - Demonstrates BLIT issues with mmBasic 5.05.06RC5 ' Steve "NPHighview" Johnson October 2020 sfjohnso@gmail.com OPTION Y_AXIS UP ' Note upright Bitmap capture requires v.5.0506RC4 and up. DIM INTEGER vres%, hres% DIM INTEGER x%, y% DIM INTEGER h0min%, h0max%, h0ctr%, h1min%, h1max%, h1ctr% DIM INTEGER vmin%, vmax%, vctr% DIM STRING key$ FOR Vmode% = 1 to 10 FOR Cdepth% = 8 to 16 STEP 4 IF Vmode% = 9 AND Cdepth% = 12 THEN Cdepth% = 16 Mode Vmode%,Cdepth% ' Set video mode and color depth hres% = MM.hres : vres% = MM.vres h0min% = 0 : h0max% = hres%/2-5 : h0ctr% = h0min%+(h0max%-h0min%)/2 h1min% = hres%/2+5 : h1max% = hres% : h1ctr% = h1min%+(h1max%-h1min%)/2 vmin% = 16 : vmax% = vres%-15 ' leave room for text boxes PAGE WRITE 1 : CLS ' Clear the slate for blitting PAGE WRITE 0 : CLS ' OK - write to left half of screen directly. BOX h0min%, vmin%, h0max%-h0min%, vmax%-vmin%, 4, RGB(red), RGB(gray) ' dark grey background FOR x% = h0min% to h0max% STEP 10 : LINE x%, vmin%, x%, vmax%, 1, RGB(black) : NEXT x% FOR y% = vmin% to vmax% STEP 10 : LINE h0min%, y%, h0max%, y%, 1, RGB(black) : NEXT y% FOR x% = h0min% to h0max% STEP 40 : LINE x%, vmin%, x%, vmax%, 2, RGB(magenta) : NEXT x% FOR y% = vmin% to vmax% STEP 40 : LINE h0min%, y%, h0max%, y%, 2, RGB(magenta) : NEXT y% BOX h0min%, vmin%, h0max%-h0min%, vmax%-vmin%, 4, RGB(white) TEXT h0ctr%, vres%, STR$(Vmode%)+":"+STR$(Cdepth%)+" Page 0", CT, 1, 1, RGB(yellow), -1 PAGE WRITE 1 : CLS : BLIT h0min%, 0, h1min%, 0, hres%/2-5, vmax%, 0 ' BLIT the graph TEXT h1ctr%, vres%, "BLIT 0->1->0", CT, 1, 1, RGB(yellow), -1 ' Add Right Hand title PAGE WRITE 0 : BLIT h1min%, 0, h1min%, 0, hres%/2-5, vres%, 1 ' BLIT the right side back BOX 0, 0, hres%, 15, 1, RGB(white), RGB(white) TEXT 0, 0, "[p] print, [q] quit, any other advances mode", LB, 1, 1, RGB(black), -1 key$ = inkey$ : DO WHILE key$ = "" : key$ = inkey$ : LOOP SELECT CASE key$ CASE "q" : CLS : END CASE "p" PAGE WRITE 0 : SAVE IMAGE STR$(Vmode%)+"x"+STR$(Cdepth%)+"_Page0.BMP" PAGE WRITE 1 : SAVE IMAGE STR$(Vmode%)+"x"+STR$(Cdepth%)+"_Page1.BMP" END SELECT NEXT Cdepth% NEXT Vmode% Edited 2020-10-27 04:12 by NPHighview Live in the Future. It's Just Starting Now! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10075 |
Sorry - not sure what I'm looking for seems to work fine for me. There will be subtle colour differences between the modes because they use different mappings onto RGB565 but I'm not seeing anything else. I've attached the firmware again here in case the last post was the wrong version somehow CMM2V1.5.zip |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
Yup, our postings crossed paths. I've updated the firmware to your experimental version, and saw that the vertical line drawing now works in all modes and depths - thanks! I'm afraid I can't characterize the color changes as subtle, however. My 3D lissajous plot uses X, Y, and Z coordinates to create an RGB value; about one run in three, these are waaaaay off, as are the various shades of gray (now green or red) in the graph background and minor / major axis lines, and reds where there should be whites, and blues where there were cyans. Here's how I get this behavior (behaviour - sorry!): * Power on the CMM2 (often takes two switch throws to get video & the banner) * Use Files command to select and immediately run the blitting Lissajous program (it has a CONST that is used to determine whether or not to use Blitting). It uses mode 9 by default. * The program runs - all is fine; colors look good. This is true whether or not blitting is turned on. Generally I lose patience and [ctrl]-[c] out, but sometimes I'll let it complete. * Edit the program to "flip" the CONST - in the editor, the usually vibrant keyword coloration is muted. * F1 to exit, F2 to run. I get this on-screen; the captured bitmap file looks fine. (I did check my VGA cables to make sure I didn't have any loose connections)  and  I'll poke around my little demo program to see if I can get it to do the same. - Steve Live in the Future. It's Just Starting Now! |
||||
| NPHighview Senior Member Joined: 02/09/2020 Location: United StatesPosts: 202 |
More info: * Repeating the steps above gets me the weird colors. * Then, I exit, use Files to find my little demo program, run it through its modes (all look fine), then go back to the Lissajous plotter, and it looks fine. * Wait until it's done, then enter editor (colors show muted). Exit with no changes. * Run - colors are completely messed up again. Hope this helps. Sorry, I haven't got to the Framebuffer issues yet :-) Live in the Future. It's Just Starting Now! |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
