Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 15:49 29 Mar 2024 Privacy Policy
Jump to

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 States
Posts: 187
Posted: 06:23am 23 Oct 2020
Copy link to clipboard 
Print this post

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 States
Posts: 187
Posted: 03:56am 24 Oct 2020
Copy link to clipboard 
Print this post

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: Canada
Posts: 1081
Posted: 05:01am 24 Oct 2020
Copy link to clipboard 
Print this post

  NPHighview said  My request: alter the assembly code to terminate when an off-screen coordinate is encountered.

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 States
Posts: 187
Posted: 04:03pm 24 Oct 2020
Copy link to clipboard 
Print this post

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: Canada
Posts: 1081
Posted: 05:43pm 24 Oct 2020
Copy link to clipboard 
Print this post

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: Australia
Posts: 5867
Posted: 07:57pm 24 Oct 2020
Copy link to clipboard 
Print this post

  Quote  MATH ADD in(), num, out()
This adds the value 'num' to every element of the matrix in() and puts the answer in out(). Works for arrays of any dimensionality of both integer and float and can convert between.
Setting b to 0 is optimised and is the fastest way of copying an entire array

MATH SCALE in(), scale ,out()
This scales the matrix in() by the scalar scale and puts the answer in out(). Works for arrays of any dimensionality of both integer and float and can convert between.
Setting b to 1 is optimised and is the fastest way of copying an entire array.


Put those two together and I think you have what you are after.

Jim
VK7JH
MMedit   MMBasic Help
 
NPHighview

Senior Member

Joined: 02/09/2020
Location: United States
Posts: 187
Posted: 09:19pm 24 Oct 2020
Copy link to clipboard 
Print this post

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 States
Posts: 187
Posted: 10:20pm 25 Oct 2020
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 8516
Posted: 10:41pm 25 Oct 2020
Copy link to clipboard 
Print this post

  Quote   got this on the screen (note jaggies whereas previous was very smooth):


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 States
Posts: 187
Posted: 11:07pm 25 Oct 2020
Copy link to clipboard 
Print this post

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: Australia
Posts: 5867
Posted: 11:25pm 25 Oct 2020
Copy link to clipboard 
Print this post

This one is the latest (I think)
https://www.thebackshed.com/forum/uploads/matherp/2020-10-26_052139_CMM2V1.5.zip

Jim
VK7JH
MMedit   MMBasic Help
 
NPHighview

Senior Member

Joined: 02/09/2020
Location: United States
Posts: 187
Posted: 01:21am 26 Oct 2020
Copy link to clipboard 
Print this post

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

Senior Member

Joined: 08/05/2020
Location: United States
Posts: 296
Posted: 01:43am 26 Oct 2020
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 8516
Posted: 08:59am 26 Oct 2020
Copy link to clipboard 
Print this post

  Quote  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


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 States
Posts: 187
Posted: 05:40pm 26 Oct 2020
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 8516
Posted: 05:48pm 26 Oct 2020
Copy link to clipboard 
Print this post

Great many thanks

Please try the attached

CMM2V1.5.zip
 
NPHighview

Senior Member

Joined: 02/09/2020
Location: United States
Posts: 187
Posted: 05:56pm 26 Oct 2020
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 8516
Posted: 06:48pm 26 Oct 2020
Copy link to clipboard 
Print this post

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 States
Posts: 187
Posted: 07:32pm 26 Oct 2020
Copy link to clipboard 
Print this post

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 States
Posts: 187
Posted: 07:45pm 26 Oct 2020
Copy link to clipboard 
Print this post

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
© JAQ Software 2024