inverting the maximite screen

Author Message
BobDevries

Senior Member

Joined: 08/06/2011
Location: Australia
Posts: 266
Posted: 02:55am 08 Jun 2011      

I just wrote a few lines of BASIC to invert the screen using Geoff's new pixel() command. It takes over two minutes to do it this way:

10 PRINT TIME$
20 FOR x=0 TO 480
30 FOR y=0 TO 432
40 z=PIXEL(x,y)
50 IF z=0 THEN z=1 ELSE z=0
60 PIXEL(x,y)=z
70 NEXT y,x
80 PRINT TIME$

Rearranging the order of the FOR-NEXT loops actually makes it slower!

Regards,
Bob Devries
Dalby, QLD, Australia
RossW
Guru

Joined: 25/02/2006
Location: Australia
Posts: 495
Posted: 07:49am 08 Jun 2011      

  BobDevries said   I just wrote a few lines of BASIC to invert the screen using Geoff's new pixel() command. It takes over two minutes to do it this way:


I don't (yet) have one of these beasties, and it's a LONG time since I was forced to endure BASIC, but surely the if-then-else test is hideously inefficient. Doesn't the basic include an XOR?

replace lines 40, 50 and 60 with
pixel(x,y)=pixel(x,y) XOR 1

Edited by RossW 2011-06-09
BobDevries

Senior Member

Joined: 08/06/2011
Location: Australia
Posts: 266
Posted: 07:54am 08 Jun 2011      

As far as I can see in the manual, the only XOR is a logical operator. I'll try that to see if it's suitable.

Regards,
Bob Devries
Dalby, QLD, Australia
BobDevries

Senior Member

Joined: 08/06/2011
Location: Australia
Posts: 266
Posted: 07:59am 08 Jun 2011      

Indeed, the XOR example works (thanks, RossW) and reduces the execution time to just over 1 minute; better, but still painfully slow.

Regards,
Bob Devries
Dalby, QLD, Australia
Gizmo

Admin Group

Joined: 05/06/2004
Location: Australia
Posts: 5186
Posted: 08:19am 08 Jun 2011      

Another way is

pixel(x,y)=not(pixel(x,y))

testing and writing to each pixel is a lot of work ( 207360 pixels all up ), and I doubt the Maximite MMBasic is optimised for fast video processing, plus its a interpreted language, so thats a lot of processing. A fill

line (0,0)-(480,432),1,"BF"

takes 141 milliseconds, cause its a single command that is run once, but thats not what you want.

Glenn
The best time to plant a tree was twenty years ago, the second best time is right now.
JAQ
BobDevries

Senior Member

Joined: 08/06/2011
Location: Australia
Posts: 266
Posted: 08:47am 08 Jun 2011      

Yes, the NOT function works too (thanks, Gizmo), and its time is 1 minute 10 secs.

Regards,
Bob Devries
Dalby, QLD, Australia
RossW
Guru

Joined: 25/02/2006
Location: Australia
Posts: 495
Posted: 10:11am 08 Jun 2011      

  BobDevries said   Yes, the NOT function works too (thanks, Gizmo), and its time is 1 minute 10 secs.


Does that mean the XOR is faster ("slightly over 1 minute") than NOT ("1 minute 10 sec")?

Can you read the video memory a byte-at-a-time, XOR with 255 (0xFF), write it back, and step a byte? That'd reduce the for-next loop 8-fold which should be almost an order of magnitude faster. (We're still talking about many seconds though).
BobDevries

Senior Member

Joined: 08/06/2011
Location: Australia
Posts: 266
Posted: 09:31pm 08 Jun 2011      

  RossW said  
Does that mean the XOR is faster ("slightly over 1 minute") than NOT ("1 minute 10 sec")?

Can you read the video memory a byte-at-a-time, XOR with 255 (0xFF), write it back, and step a byte? That'd reduce the for-next loop 8-fold which should be almost an order of magnitude faster. (We're still talking about many seconds though).


The NOT version is slightly faster.

No only one pixel is accessible at a time using the pixel() function. There's no other way to access the screen RAM (or any other RAM).

Regards,
Bob Devries
Dalby, QLD, Australia
stuarts

Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 199
Posted: 01:00pm 15 Jun 2011      

Sounds like its time for Peek() and Poke()
BobDevries

Senior Member

Joined: 08/06/2011
Location: Australia
Posts: 266
Posted: 10:17pm 16 Jun 2011      

I'd be happy to see the following additions:

DRAW
GET
PUT
LOADBMP

Regards,
Bob Devries
Dalby, QLD, Australia