On 11/02/2011 07:44, Plastic wrote:
Hi all,
1. I would like to be able to identify the hardware and OS my timing
critical programs are running on.
To this end, I can use ver$ to identify the QDOS version. However, what
ver$
returns do Minerva and SMSQ/E give?
Is there a surefire way to identify if the execution environment is a QL,
Gold Card, Super Gold Card, Aurora, Q40, Q60, etc? This would allow me to
create fast, integrated speed-matching code for as many environments as I
can get information for.
Yes, PRINT VER$ on Minerva returns 'JSL1', and 'HBA' on SMSQ/e
Be careful - do not test ver$ directly as it has issues on some ROMs - do
a$=ver$
if a$='HBA' or a$='JSL1' THEN.....
There is also the MACHINE and PROCESSOR function under SMSQ/e.
MACHINE returns:
0 - Atari ST/STM/STF/STFM
2 - MEGA ST or ST/STM/STF/STFM with real-time clock
4 - Atari Stacy
6 - Atari STE
10 - Gold Card
12 - Super Gold Card
16 - Falcon
17 - Q40/Q60
24 - Atari TT 68030 processor
28 - QXL
30 - QPC
31 - QLAY
PROCESSOR returns: a two digit value - first digit indicates chip type,
second digit indicates if a maths co-processor is attached
Processor value is:
0 - 68000/68008
1 - 68010 or Intel chip under QPC
2 - 68020
3 - 68030
4 - 68040
6 - 68060
Co-processor value is:
0 - No FPU
1 - An internal MMU
2 - External 68851 MMU fitted
4- Internal FPU fitted
8 - External 68881 or 68882 FPU fitted.
Unfortunately, I don't think anyone has released these as a separate
toolkit, which would be useful for non-smsq/e systems!
2. I need to collect input to a variable$ while a wider program loop is
running. I'm not sure how to approach this. INKEY$ can tell me what key
is
pressed, but then I am faced with somehow debouncing the input, and also
knowing when someone says "flight blah, turn to heading 222 degrees"... I
don't want to pause the aircraft just to take input. I'm a little stuck
on
this.
Use a timeout on the INKEY$ - eg, INKEY$(#3,20) will wait 20 frames for
you to press a key - use INKEY$(#3,1) and you will hardly notice it -
INKEY$(#3,0) will give an immediate return...
3. I need to be able to draw data blocks to the screen. The data blocks
would look something like this:
AAL3251
030^24
.
/
That data block means flight AAL3251 is at 3,000 ft, climbing, at 240
knots.
Below it there is a blob for the plane, with a trail that shows by angle
the
direction it came from, and the speed (faster = longer trail)
I have two problems to solve here: ONE: when aircraft approach the edge
of
the screen, the dot and line can go off, but the text cannot and will
generate an error. TWO: I have to often plot these labels overlapping
each
other. They will also overlap the runways and beacons. I can't avoid the
need to redraw the airport and beacons occasionally, but I would like to
do
so without flicker. It seems the plan will be to draw the positions,
store
them in "old" variable copies, do the math, then overdraw the moving tags
in
black, redraw the fixed items, then plot the new positions, rinse and
repeat. This seems wasteful. Is there a smart technique I am missing? (It
must apply to SMSQ/E, Minerva and QDOS, so the second screen isn't,
unfortunately, an option.)
This is achieved by using your own print routine - I used something in
Q-Route - this is how I did it as this may help others trying to get the
text in graphics co-ordinates to work... (following on from our earlier
discussion about the scaling factor). Hopefully, I have picked up all the
code you need here....
20 REMark To start, some QL dependent variables
21 char_width0%=6: REMark value for csize 0,0
22 char_width1=8.45: REMark value for csize 1,0
23 char_height%=10: REMark height in pixels
112 graf_scale=256: REMark resolution used for graphics
114 SCALE graf_scale,0,0
116 buff%=400:mscale=1:rounds%=FALSE
120 windowx=0:windowy=0:window_sizex=512:window_sizey=256
122
wind_scalex=(1/window_sizex)*(graf_scale*(100/window_sizey*window_sizex/135.5))
124 wind_scaley=(1/window_sizey)*graf_scale
1784 DEFine PROCedure printat (x1,y1,s$)
1788 atx=tw*(x1-1)
1792 aty=(y1-1)*char_height%
1796 ATEXT atx,aty,s$
1800 END DEFine
1804 :
3448 DEFine PROCedure ATEXT(linex1,liney1,txt)
3452 LOCal pos%
3454 IF liney1<0 OR linex1>window_sizex:RETurn
3456 IF liney1+char_height%>window_sizey:RETurn
3460 txt$=txt
3464 len_txt=LEN(txt$):IF len_txt=0:RETurn
3468 IF linex1+len_txt*char_width0%<0:RETurn
3472 txt_x%=linex1:pos%=1
3476 pos%=pos%+(-linex1/char_width0%)*(linex1<0):IF pos%>1:txt_x%=0
3480 RFCURSOR txt_x%,liney1
3484 FOR txt%=pos% TO len_txt
3488 IF txt_x%+char_width0%>window_sizex:EXIT txt%
3492 PRINT#2,txt$(txt%);
3496 txt_x%=txt_x%+char_width0%
3500 END FOR txt%
3504 END DEFine
3508 :
3512 DEFine PROCedure RFLINE(linex1,liney1,linex2,liney2)
3516 LINE #2,linex1*wind_scalex,(window_sizey-liney1)*wind_scaley TO
linex2*wind_scalex,(window_sizey-liney2)*wind_scaley
3520 END DEFine
3524 :
3528 DEFine PROCedure RFCURSOR(linex1,liney1)
3532 CURSOR #2,linex1*wind_scalex,(WINDTAB(2,5)-liney1)*wind_scaley,0,0
3536 END DEFine
3540 :
3544 DEFine PROCedure RFPOINT(linex1,liney1)
3548 POINT #2,linex1*wind_scalex,(WINDTAB(2,5)-liney1)*wind_scaley
3552 END DEFine
3556 :
4. I need to detect proximity violations (three miles.) I have this
cracked.
A simple reducing nested loop minimises work:
FOR first = 0 to (high_slot-1)
FOR second = (first+1) to high_slot
_proximity (first, second)
END FOR second
END FOR first
This compares each pair of planes just once. Thus, with 4 planes, it will
compare:
0 to 1, 0 to 2, 0 to 3, 0 to 4
1 to 2, 1 to 3, 1 to 4
2 to 3, 2 to 4
3 to 4
Sweet!
The _proximity() procedure simply sets the color of close plane tags to
red,
and non-close tags to green.
5. Currently, I am estimating that on an unaccelerated QL each loop
through
the calculations will be SIX+ SECONDS. This is obviously unacceptable.
Given
this horrifying realization, I will have to supply the game Turbocharged,
and include the source. I have downloaded Turbo, and will be reading
ASAP,
as I would like to incorporate any special coding at writing time, rather
than editing later. What kind of speed-up factor might I obtain by
Turbo-ing
vs. Supercharging?
Turbocharged will be fine with this - especially if you use integer loops
for some things as well.
Not sure what speed up factor you can expect - 8 times sounds about right,
but some things it can optimise much more.
Avoid supercharge - programs compiled with it have issues on modern
systems.
8. I have decided to allow people to choose from different airports, not
just the default one.
I could implement this by reserving lines 30000 - 32767 for DATA
statements
and create a format. Then, I could have many airport files on the storage
device, and MERGE the necessary one in. Alternatively, I could create a
data
format, and load/save the bytes as needed - much more compact, but less
friendly to future airport additions by others. I fully intend to allow
anyone to read the data format and create/share their own airport
description files. I'd simply check them then add them to the program.
Yes you could do this, but not if it is compiled!!
9. Network play. How cool would it be to have 3 or 4 QLs playing a grid,
and
passing off aircraft to each other? I recall the inbuilt NET ports were
just
slightly better than useless, but I've seen them work, so...
Actually, if you wanted to go down this route, why not have each QL
controlling a different area, with overlaps, as you would with real air
traffic control?
--
Rich Mellor
RWAP Services
http://www.rwapsoftware.co.uk
http://www.rwapservices.co.uk
-- Try out our new site: http://sellmyretro.com
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
