WIP: Dog fight in space...sort of...

[Pete]

I've installed the grid I mentioned above. As units fly farther from, or nearer to, each other the grid will resize by factors of ten as the necessary display scale changes. It was a head scratcher, but I managed to do it in 18 lines of code, in SUB SensorScreen.

I'm pushing all changes into the original posting. I assume this is good etiquette, but correct me if I'm wrong.

I do that all the time. I think it is far better to have one posted program, edited as needed, rather than 15 ongoing posts in the same thread. I usually include a update on what I changed in the text part of the post.

Of course, doing it my way doesn't mean you're doing it the right way... just the BEST way! ;D

Pete

Pete

[OldMoses]

In trying to come up with a good way to handle planet collision, I came across the concept of ray tracing. I've never done anything like it before so I thought I'd do a test bed program just to see it in operation. More a proof of concept exercise than a WOW graphics ap. Since a similar algorithm is going in the main project, I thought I'd share my first attempt.

Now if I could just get it to work in the main project. It has not been cooperating there, so hopefully these little test programs can teach me something.

EDIT: improved loop exit handling.

Code: QB64: [Select]

1. TYPE unitpoint
2.     X AS SINGLE
3.     Y AS SINGLE
4.     Z AS SINGLE
5. END TYPE
6.  
7. DIM SHARED A&
8. DIM SHARED SS&
9. DIM SHARED EL&
10. A& = _NEWIMAGE(1200, 700, 32)
11. SS& = _NEWIMAGE(620, 620, 32)
12. EL& = _NEWIMAGE(300, 300, 32)
13.  
14. SCREEN A& '                                                     Initiate main screen
15. DO: LOOP UNTIL _SCREENEXISTS
16. _TITLE "Sphere intersection test bed"
17. _SCREENMOVE (_DESKTOPWIDTH - 1200) / 2, 1
18.  
19.  
20. DIM SHARED S_C AS unitpoint '                                   sphere center point
21. DIM SHARED V_S AS unitpoint '                                   vector starting point same as cmbtnt(x).OldXYZ
22. DIM SHARED V_E AS unitpoint '                                   vector ending point same as cmbtnt(x).AbsXYZ
23. DIM SHARED ni AS unitpoint '                                    near intersection point
24. DIM SHARED fi AS unitpoint '                                    far intersection point
25. DIM SHARED Rd AS INTEGER '                                      radius of sphere
26. DIM SHARED impact AS INTEGER
27. DIM SHARED si AS STRING * 6
28.  
29. DO
30.  
31.     COLOR , _RGBA32(50, 50, 50, 255)
32.     CLS
33.     V_S.X = 0: V_S.Y = 0: V_S.Z = 0
34.     INPUT "Sphere center X: ", S_C.X
35.     INPUT "Sphere center Y: ", S_C.Y
36.     INPUT "Sphere center Z: ", S_C.Z
37.     INPUT "Sphere radius  : ", Rd
38.     INPUT "line endpoint x: ", V_E.X
39.     INPUT "line endpoint y: ", V_E.Y
40.     INPUT "line endpoint z: ", V_E.Z
41.  
42.  
43.     dx = V_E.X - V_S.X: dy = V_E.Y - V_S.Y: dz = V_E.Z - V_S.Z
44.     A = dx ^ 2 + dy ^ 2 + dz ^ 2
45.     b = 2 * dx * (V_S.X - S_C.X) + 2 * dy * (V_S.Y - S_C.Y) + 2 * dz * (V_S.Z - S_C.Z)
46.     c = S_C.X ^ 2 + S_C.Y ^ 2 + S_C.Z ^ 2 + V_S.X ^ 2 + V_S.Y ^ 2 + V_S.Z ^ 2 + -2 * (S_C.X * V_S.X + S_C.Y * V_S.Y + S_C.Z * V_S.Z) - Rd ^ 2
47.     disabc = b ^ 2 - 4 * A * c ' if disabc <0 then no intersection =0 tangent >0 intersects two points
48.     PRINT
49.     IF disabc >= 0 THEN
50.         t = (-b - (b ^ 2 - 4 * A * c) ^ .5) / (2 * A)
51.         tf = (-b + (b ^ 2 - 4 * A * c) ^ .5) / (2 * A)
52.         ni.X = V_S.X + t * dx: ni.Y = V_S.Y + t * dy: ni.Z = V_S.Z + t * dz
53.         fi.X = V_S.X + tf * dx: fi.Y = V_S.Y + tf * dy: fi.Z = V_S.Z + tf * dz
54.     END IF
55.     short_impact
56.     MakeDisplay
57.     IF disabc < 0 THEN
58.         PRINT "No intersection"
59.         impact = 0
60.     ELSEIF disabc = 0 THEN
61.         PRINT "Tangent to"
62.         PRINT "near at: "; ni.X; ", "; ni.Y; ", "; ni.Z
63.         PRINT si
64.     ELSE
65.         PRINT "Two intersections"
66.         PRINT "near at: "; ni.X; ", "; ni.Y; ", "; ni.Z
67.         PRINT "far at:  "; fi.X; ", "; fi.Y; ", "; fi.Z
68.         PRINT si
69.     END IF
70.     PRINT: PRINT "any key to continue, ESC to quit"
71.     SLEEP
72.     IF _KEYDOWN(13) THEN a$ = INKEY$  
73. LOOP WHILE _KEYDOWN(27) = 0
74. END
75.  
76. SUB short_impact
77.     IF Pythagorus(ni, V_S) > Pythagorus(V_E, V_S) THEN
78.         si = "short"
79.         impact = 0
80.     END IF
81.     IF Pythagorus(ni, V_S) <= Pythagorus(V_E, V_S) THEN
82.         si = "impact"
83.         impact = -1
84.     END IF
85. END SUB
86.  
87.  
88. FUNCTION Pythagorus (var1 AS unitpoint, var2 AS unitpoint)
89.  
90.     'Use to find distance between two 3D points
91.     'Also calculate speed of updated vectors
92.  
93.     DIM diff AS unitpoint
94.     diff.X = ABS(var1.X - var2.X)
95.     diff.Y = ABS(var1.Y - var2.Y)
96.     diff.Z = ABS(var1.Z - var2.Z)
97.     horizontal = _HYPOT(diff.X, diff.Y)
98.     Pythagorus = _HYPOT(horizontal, diff.Z)
99.  
100. END FUNCTION 'Pythagorus
101.  
102. SUB MakeDisplay
103.  
104.     'overview plane display
105.     _DEST SS&
106.     CLS
107.     COLOR _RGBA32(0, 0, 0, 255)
108.     VIEW (1, 1)-(618, 618), _RGBA32(0, 0, 0, 255), _RGBA(0, 168, 168, 255) '                  set graphics port full image SS& w/box
109.     WINDOW (-100, 100)-(100, -100) '                        set relative cartesian coords
110.  
111.     LINE (0, 50)-(0, 25), _RGBA32(0, 168, 168, 255) '                             draw active unit reference point xhair
112.     LINE (0, -25)-(0, -50), _RGBA32(0, 168, 168, 255)
113.     LINE (-50, 0)-(-25, 0), _RGBA32(0, 168, 168, 255)
114.     LINE (25, 0)-(50, 0), _RGBA32(0, 168, 168, 255)
115.  
116.     CIRCLE (S_C.X, S_C.Y), Rd, _RGBA32(127, 127, 127, 255)
117.     LINE (0, 0)-(V_E.X, V_E.Y), _RGBA32(127, 127, 127, 255)
118.  
119.     IPoint ni
120.     IPoint fi
121.  
122.     'elevation plane display
123.     _DEST EL&
124.     CLS
125.     COLOR _RGBA32(0, 0, 0, 255)
126.     VIEW (1, 1)-(298, 298), _RGBA32(0, 0, 0, 255), _RGBA(0, 168, 168, 255) '                  set graphics port full image SS& w/box
127.     WINDOW (-100, 100)-(100, -100) '                        set relative cartesian coords
128.     LINE (-100, 0)-(100, 0), _RGBA32(0, 168, 168, 255)
129.     CIRCLE (S_C.X, S_C.Z), Rd, _RGBA32(127, 127, 127, 255)
130.     LINE (0, 0)-(V_E.X, V_E.Z), _RGBA32(127, 127, 127, 255)
131.  
132.     _DEST A&
133.     SCREEN A&
134.     _PUTIMAGE (560, 18), SS&, A& '                              update sensor screen to mainscreen
135.     _PUTIMAGE (25, 350), EL&, A&
136.  
137. END SUB
138.  
139. SUB IPoint (var AS unitpoint)
140.     IF impact THEN
141.         SELECT CASE S_C.Z
142.             CASE IS < var.Z
143.                 c& = _RGBA32(11, 127, 238, 255)
144.             CASE IS = var.Z
145.                 c& = _RGBA32(222, 222, 222, 255)
146.             CASE IS > var.Z
147.                 c& = _RGBA32(244, 6, 67, 255)
148.         END SELECT
149.         LINE (var.X - 0.5, var.Y + 0.5)-(var.X + 0.5, var.Y - 0.5), c&, BF
150.     END IF
151.  
152. END SUB
153.  
154.  
155. 'Ray - Sphere Intersection
156. 'A sphere is given by its center (cx, cy, cz), its radius R, and its color (SR, SG, SB).
157. 'A line segment (ray) is given by its endpoints: P0 = (x0, y0, z0) and P1 = (x1, y1, z1).
158. 'To find visible spheres, set P0 = viewer’s coordinates, VP = (VPx, VPy, VPz) and let P1 run through
159. 'all the points (x1, y1, 0) where (x1, y1) is a pixel in the display area.
160.  
161. 'except that OldMoses is just checking for one ray to impact the sphere's limits.
162.  
163. 'Set dx = x1 - x0
164. 'dy = y1 - y0
165. 'dz = z1 - z0
166. 'a = dx*dx + dy*dy + dz*dz;
167. 'b = 2*dx*(x0-cx) + 2*dy*(y0-cy) + 2*dz*(z0-cz);
168. 'c = cx*cx + cy*cy + cz*cz + x0*x0 + y0*y0 + z0*z0 +
169. '-2*(cx*x0 + cy*y0 + cz*z0) - R*R;
170. 'discriminant(a, b, c) = b^2 - 4*a*c
171.  
172. 'if discriminant (a, b, c)
173. '< 0 no intersection
174. '= 0 ray is tangent to sphere
175. '> 0 ray intersects sphere in two points
176. 'The intersection nearest P0 is given by:
177. 't = (-b - sqrt(b^2 - 4*a*c))/(2*a)
178. 'To find the coordinates of the intersection point:
179. 'x = x0 + t*dx y = y0 + t*dy z = z0 + t*dz
180.  

[OldMoses]

With temperatures being pretty stiff today, the most strenuous thing I'm doing is typing.

In attempting to craft a stable ray tracing algorithm (found in SUB ColCheck) to compute spherical intersection given vast distances represented by kilometers stored in _INTEGER64 variables, and vector speeds that could potentially exceed thousands of kilometers per second over 1000 second turns, it became apparent after several days of working with the equations that _FLOAT values were the only option. Many of the calculations involve adding and multiplying together squares of millions and billions in all three axes, for which even _INTEGER64's range is inadequate. Until I converted to _FLOATs the algorithm simply refused to work, it wasn't until I monitored certain key variables for value that I realized this, I found them to be pegged to the minimum floor of _INTEGER64 (i.e. -9.223372 x 10^18) for relatively short range tests. All just to see if one smacks a ball...

The other issue I encountered after fixing this was that it seemed to matter if the ship hit the planet or if the planet hit the ship. That is, if I flew into it, or if I parked in its path and allowed it to plow into me. The bandaid for that was to test if the ship ended its turn within the sphere, but I suspect that would not yield an impact point without going through the calculations. Planet moves occur after ship moves so this is not surprising.

At any rate, it's working better than it was, and it's been an interesting education. I also added a random ship placement routine to mix up the scenarios a bit. It was getting boring starting out at the same point near the sun. Now there's no telling where you'll end up.

Now to let the smoke clear from all that demolition...imagine the joules I've unleashed. ;)

[OldMoses]

What a difference a long hiatus makes.

A persistent bug that involved the program bogging down when one tries to zoom in to closer detail was deviling me to the point that I threw up my hands and went to another project. I tried reviewing the math procedures, optimizing and changing parameters or variable types. Everything. I gave up and shelved the project indefinitely.

Something made me start tinkering with it again yesterday. After fiddling around with various bits of flotsam and nybbles of jetsam, there came the "DOH!" moment.

It was the circle fill routine, that was being called from SUB SysMap to fill the circles of stars and planetary bodies. Even those that weren't being rendered to the viewscreen, as they were too far away to be displayed, and yet the processing time was being used to do so. The fix was a simple IF...THEN block to encompass the planetary draw routine and reject distant objects.

It wasn't a big deal when zoomed out, as the celestial bodies were small and quickly filled, but upon zooming in, the program was filling enlarged circles of planets, gas giants, moons and sun that were no where near the display area. It only took four months vacation for it to occur to me, and that is why I would never dare try to program for a living. ;)

[Dimster]

Eureka Moments - Priceless

[OldMoses]

Added a few new toys to this. Two of the simpler ones are an orbit track toggle "O", in the spirit of reduced clutter, and the ability to place the active unit anywhere on the sensor screen via a right click of the mouse.

Also implemented, is a sensor occlusion routine, where the active unit will not be able to "see" units obscured by celestial bodies. Using the same ray tracing routine used for collision checks, it was found to fail to work around the outer planets, while working fine near the inner ones. It had to be the large coordinate numbers, and so implementing a relative coordinate system with the active ship as origin 0,0,0 fixed the problem just as expected.

It also improved the left mouse button selection of the active ship in the sensor screen, which was also found to have more problems in the outer reaches than in the inner. Still chasing a bug with that one, where any unit closely aligned on x or y axis can't be chosen.

[romichess]

I'm in awe! If you are a 10 on the QB64 programmers scale I might be a 3 if I am lucky.

[OldMoses]

I'm in awe! If you are a 10 on the QB64 programmers scale I might be a 3 if I am lucky.

Thank you, but if you look over the code for a while you'll see the marks of a number of others here who've made my education possible in the last year or so, particularly in graphics/image manipulation, of which I've only scratched the surface of what's possible. It's kind of like sitting on the shoulders of giants, but if it gets the job done...

As for me, I generally approach a project with the attitude that I'm too stupid to realize I can't do it, and if I bumble around with it long enough, it eventually works. Sorta like 1000 monkeys banging on typewriters. I also tend to program like Arnie Cunningham fixing "Christine", I put brand new windshield wipers on busted windshields.

I started this over 20 years ago with the idea to take some of the tedium out of an old table top RPG game and a half baked Trig approach to the problem, but the old QBasic and QB45 just couldn't handle the range of computations that I needed. Now QB64 has me covered on that front. I never dreamed I'd get it to this point.

The fascinating thing about programming is that the "10" guys can sometimes find new things in the "3" guy's approach.

[OldMoses]

Added some visual bling to, hopefully, make this more user friendly. I'm becoming a little more used to working with images.

[OldMoses]

Ok, so now I'm calling this version 0.31, this is where I put new hubcaps on the flat tire. I also swatted numerous bugs that various playtesting runs revealed.

Still trying to nail down a control and display layout, but at least I've got it so it's far easier to modify things as I need to with respect to colors, positions, etc. Hopefully, it's becoming moderately more intuitive to use. I'm starting to gain a better understanding of how to work with images. God, I love this language!

Now new ships can be added, old ones can be deleted and those destroyed by planetary collision can be "purged" from the data array. Probably the flashiest addition is a graphics based vector input routine, allowing thrust, azimuth and inclination to be entered via the mouse after clicking the "Vector" button. I've retained the old hotkey "V" text input routine for those who want more precise control of the numbers.

Playing around with button "dimming" so that the user has some idea that something happened, though I'm still retaining hotkeys as they run much faster in certain situations by not having the imaging overhead of mouse clicks. This is particularly true of turn advances.

It's certainly come a long way from the old STARRUTR.BAS

[OldMoses]

For version 0.33 I gave myself the Christmas present of center display that shows ship orientation, thrust status and stars panning to indicate direction of movement. It's a little bit gimpy, speeds up and slows down, doesn't always match exactly to the actual direction, but gives a general idea.

Also added a Z rotation "slider" along the right side to aid the user in viewing the 3D environment, especially useful in determining where other ships fall with respect to ranging when they are out of the Z plane of the active unit. Clicking in and/or dragging along the slider changes the viewing angle. The upper and lower blocks of the slider 'zero' on the Y plane and the center one zeros on the default Z plane.

It is constrained to pivoting around the Y axis. I don't know if the math is technically correct, but it looks relatively convincing. The little vector tails displayed with moving ships need to be altered to reflect the perspective change, but I'll get around to that at some point.

[OldMoses]

Version 0.34 has been a hoot. {eyeroll here}

It seemed like everytime I fixed something or added something, I would break something else.

I've attached it, in the original post, as a zip file with a new directory structure and executable of the latest source. Source code update is still posted in the code window, but you'll need the directory structure for it to do anything other than error out. It's dependent upon various image and setup files.

Alternate star systems can be loaded, though Sol is still included as a default for practice and/or those not familiar with the game conventions of system creation. I still need to write an input ap for installing new systems. A date input handles ephemeris details, IOW, if you leave a system and come back months or years later the planets will have moved accordingly.

I've been boning up on coordinate transformations and added some improvements in that vein.

Ship placement via right mouse button clicks now places vessels according to the plane of rotation around the X axis. It's now possible to place a vessel in another Z position without resorting to text editing input. I think I've also gotten the coordinate transformation equations corrected. It "looks" right at any rate. Red and blue shift of displayed ships now reflects the relationship to the "plane of view" rather than the absolute Z position. I'm still on the fence as to whether to try adding multi-axis rotations.

On that subject, rotating to negative angles is almost indistinguishable from positive ones and I added a goofy orienteering visual. At negative angles the planet names are displayed inverted. Yes, it is weird. :D

Added a target lock feature with two different target lock ranges to reflect difference between civilian and military vessels. Target locks may be acquired at 1/2 light second or 2 light seconds, respectively. When range exceeds 3 light seconds the lock is lost. The padlock icon in the ship data display acquires the lock if the icon is in red. If it is grey, then target lock is not yet possible.

Thanks to Steve for his MEM tutorials, I've been using the ap to play with it some. I've also implemented $NOPREFIX, bit operations and SUBed out some image stuff to reduce computation times. It will need QB64 version 1.4 to run now. I took out most of the underscores, apologies to anyone who hasn't upgraded yet.

Fixes:
left mousebutton ship selection in the "astrogator" screen is now easier and more reliable.

Vector "tails" corrected for viewing plane transformations.

Present issues:
Ships will sometimes spontaneously be destroyed under extreme outsystem maneuvers. Now there's a headscratcher...