Fast number display in Screen 12

[jcc3inc]

Gentlemen:

I have an application wherein I want to display large numbers (about 22 pixels high x 15 wide) on Screen 12 for a 3 axis PC based machine tool controller. These numbers will be 8 spaces long, being (-99.9999), and they will be for X, Y, Z axes. Since the numbers for all three axes will be updated once per second, this must take very little time as the controller's primary function is controlling the 3 axis machine motors (position display is a secondary function). I now use Screen 0 and accomplish this display in little enough time. Of course the numbers are the usual small size in that screen.

I will generate the number shape data, and can print them to screen with LINE, or PSET which would likely be slow! Could I get the best speed if the save the data with PUT, then GET each number and sequence it as required? And what approach would you suggest? Speed is Very important here!

Looking for your good ideas!

Regards,
Jack C.

 

[qbasicking]

On modern computers you can use LINE without a lot of slowdown, almost none actually. Being 22 pixils high though, you can't use LINE since the LINE format runs in loops of 15 pixils. If speed is really important (we're talking thousandths of a second here) GET and PUT would be the fastest ways to do it.
Put the numbers into 10 predrawn arrays 0-9. Then I would convert the number to a string, so that you can go through it number by number and the place the appropriate number array on the screen.

 

[CubeE101]

yes... use get and put if you can...

get and put just copy memory with no calculations...

If you are worried about a background, then there are a few alternatives, but if speed is your only concern, use Get & Put

You might also be able to come up with something using the draw command if you want to play around ;-)

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

PROGRAMMER: Red-eyed, mumbling mammal capable of conversing with inanimate objects.

 

[tsh73]

You are saying didits will be updated once per second... I do not see any possible speed issues here. I think you better try and see if time is really a problem.
Second thing:
have you tried "width" keyword on screen 0?
may be WIDTH 40, 25
will make digits just big enough for you?

 

[jcc3inc]

Gentlemen:
Here is an update to my problem. In order to measure the speed, I made a FOR - NEXT loop with 10000 cycles and measured the time for each of the following.

PUT, 22 x 15 pixels, 8.8 milliseconds each
PUT, 22 x 10 pixels, 8.8 ms each
PUT, 22 x 35 pixels, 19.5 ms each
PRINT the number 1, .328 ms each
PRINT the number -12.3456, 1.2 ms each (8) number group

From the above, I cannot use PUT to handle groups of 8 digits each as the time would be about 8 x 8.8 ms or 70.4 ms
compared to 1.2 ms. Since I have to update three axes each second, the total time would be 211.2 ms using PUT, and 3.6 ms using PRINT. Also, I got the same time using my 133MHZ and BASIC or .EXE, or a 500 MHz in DOS and .EXE.

Am I doing something wrong in my FOR - NEXT approach at measuring speed?? Always looking for good ideas!

Regards,
Jack C.

 

[SJZero]

Does it have to be Screen 12? If you chose a resolution with fewer pixels, you could probably do numbers with the same physical size with a quarter of the work (or much less, because screen 12 is a really fruity memory mode because of all the OUTs needed to plot a pixel. Screen 13, for example, requires only a calculation of where to start)



If it's absolutely nessessary to do things in screen 12, try these routines I slapped together:


DECLARE SUB drawnumbers (x%, y%, colr%, number!)
DECLARE SUB drawnumber (x2%, y%, number%, colr%)
SCREEN 12

FOR a! = 1 TO 1000000

'We draw the iteration number. Keep an eye on it.
'This is how many times it can update three numbers
'in the amount of time the program is running.
drawnumbers 1, 4, 1, a!



'here we clear the numbers we're about to get.
drawnumbers 1, 1, 0, x

drawnumbers 1, 2, 0, y
drawnumbers 1, 3, 0, z


'here we generate some random numbers.
x = RND(1) * 10
y = RND(1) * 10
z = RND(1) * 10


'here we draw the random numbers we just got.
drawnumbers 1, 1, 1, x

drawnumbers 1, 2, 1, y
drawnumbers 1, 3, 1, z

'here we clear the iteration number for the next cycle.
drawnumbers 1, 4, 0, a!

NEXT a!
'LINE (0, 0)-(320, 200), 1

DEFINT A-Z
SUB drawnumber (x2%, y%, number%, colr%)

x = (x2 * 23) + 1


'22x15
SELECT CASE number
CASE 0
LINE (x + 2, y)-(x + 20, y), colr
LINE (x + 2, y + 15)-(x + 20, y + 15), colr
LINE (x + 2, y)-(x + 2, y + 15), colr
LINE (x + 20, y)-(x + 20, y + 15), colr
LINE (x + 2, y)-(x + 20, y + 15), colr


CASE 1
LINE (x + 10, y)-(x + 10, y + 15), colr
CASE 2
LINE (x + 2, y)-(x + 10, y), colr
LINE (x + 10, y)-(x + 20, y + 7), colr
LINE (x + 20, y + 7)-(x + 2, y + 15), colr
LINE (x + 2, y + 15)-(x + 20, y + 15), colr
CASE 3
LINE (x + 2, y)-(x + 10, y), colr
LINE (x + 10, y)-(x + 20, y + 5), colr
LINE (x + 20, y + 5)-(x + 10, y + 7), colr
LINE (x + 10, y + 7)-(x + 20, y + 12), colr
LINE (x + 20, y + 12)-(x + 10, y + 15), colr
LINE (x + 10, y + 15)-(x + 2, y + 15), colr
CASE 4
LINE (x + 2, y)-(x + 2, y + 7), colr
LINE (x + 2, y + 7)-(x + 20, y + 7), colr
LINE (x + 20, y)-(x + 20, y + 15), colr
CASE 5
LINE (x + 2, y)-(x + 20, y), colr

LINE (x + 2, y)-(x + 2, y + 5), colr
LINE (x + 2, y + 5)-(x + 15, y + 5), colr
LINE (x + 15, y + 5)-(x + 20, y + 6), colr
LINE (x + 20, y + 6)-(x + 10, y + 10), colr
LINE (x + 10, y + 10)-(x + 2, y + 15), colr
CASE 6
LINE (x + 20, y)-(x + 5, y + 7), colr

LINE (x + 5, y + 7)-(x + 2, y + 15), colr



LINE (x + 2, y + 15)-(x + 20, y + 15), colr
LINE (x + 20, y + 15)-(x + 5, y + 7), colr

CASE 7
LINE (x + 2, y)-(x + 20, y), colr

LINE (x + 20, y)-(x + 10, y + 15), colr

CASE 8
LINE (x + 2, y)-(x + 20, y), colr
LINE (x + 2, y + 15)-(x + 20, y + 15), colr
LINE (x + 2, y + 15)-(x + 20, y), colr
LINE (x + 20, y + 15)-(x + 2, y), colr



CASE 9
LINE (x + 2, y + 15)-(x + 20, y + 7), colr

LINE (x + 20, y + 7)-(x + 2, y), colr



LINE (x + 2, y)-(x + 20, y), colr
LINE (x + 20, y)-(x + 20, y + 7), colr
CASE 10 'decimal place
LINE (x + 9, y + 14)-(x + 11, y + 15), colr, BF



END SELECT
END SUB

SUB drawnumbers (x%, y%, colr%, number!)
a$ = LTRIM$(RTRIM$(STR$(number!)))
x2 = x
y = y * 16

WHILE a$ <> &quot;&quot;
' drawnumbers(x,y,number,colr)
' PRINT a$, LEFT$(a$, 1)


IF LEFT$(a$, 1) <> &quot;.&quot; THEN

drawnumber x2, y, VAL(LEFT$(a$, 1)), colr%
ELSE
drawnumber x2, y, 10, colr
END IF

a$ = MID$(a$, 2)
x2 = x2 + 1
WEND
END SUB

 

[jcc3inc]

Thanks SJZERO for your response. I tried your stick number fonts and have a time of 8.6 millisec per group of (3) eight digit numbers. You may compare this with the times gotten from the earlier post, above.

My objective display time for the (3) sets is to do so in < 2 millisec. The time to display the (3) sets with the ordinary PRINT command is .36 millisec (small characters). I thought of the following approach:

Suppose we could take (4) of the unused BIOS characters for each number (40 total would be required), and use four &quot;blocks&quot; for each number, two for the bottom half, and two immediately above for the top half. Fill in each quarter with pixels whose shape matches the four quadrants of the letter &quot;8&quot;, for example. Then we would need about 4x the time to do the normal printing. But we would get characters which were twice size and they would have smooth, filled shapes. My time to do the equivalent of this was 1.7 ms.

My problem is that I don't know how to replace the normal font from the BIOS with 40 replacement shapes! I have done
one number with somebody's bios font changing routine but don't know enough to make this work right! It ends up changing my Screen 12. Big lack of knowledge on my part!

Thanks for your interest in this.

Regards,
Jack C.

 

[fancom]

hey try the %ha000 the start of the screen (i think)
In the bmp loaders you can find it with the speed of assembler language.. So you can draw your pixels so fast. for example in screen 13 full screen is able to be updated 25 times for each seconds...
For your qb graphics expriences those links would be so usefull i think..

http://sys.blissdev.com/dav/?programs

http://www.antonigual/qbasic.html

[COLOR=aa8811]
Shakespare says &quot;To be or not to be&quot;
And we say &quot;I/O&quot;

 

[agual]

Jack:
Screen 12 is the slowest of all VGA modes, because every pixel must be divided in it's primary colors and each color must be written to the appropiate pixel plane.
Rapid writes to screen 12 must be done by using the VGA logic, by filing masks and latches and other weird things.
This online book is the only one I have found explaining that.

http://www.byte.com/abrash/

The relevant chapters are nr. 24 and above. All examples are in assembler...

Can you use a SVGA (VESA) mode? mode 101h is 640X480x256 colors, linear!! You could use Zephyr (professional), Future, or UGL (gaming) librairies, all of them coded in assembler.

If you want to stick with screen 12 I can suggest you doing your programming in a Borland language, turbo C or tutbo pascal. Borland had a fairly fast DOS graphics library (BGI).All of them are free nowadays. The resulting code is much faster than QB's, and you have unsigned integers to play with...

Let me suggest also a &quot;smart&quot; approach, redraw only the figures that must change.

The code of mine fancom suggests is at:

http://www.geocities.com/antonigual/qbsource/scaltxt.zip

(Right-click & save as). It will not solve your problem in screen 12 because I optimized it for SCREEN13 and VESA modes, all of them are linear, not pixel planed.

Hope it helps...






Antoni

http://www.geocities.com/antonigual/index.html