Posts: 593
Threads: 44
Joined: Apr 2022
Reputation:
43
(04-21-2023, 08:08 PM)NakedApe Wrote: Thanks for the quick responses. I'm using real SUBs not GOSUBs. The subroutine in question creates a moving star field at warp, so there's a lot going on, but the sub has no parameters. It uses 3 large shared arrays of star TYPEs (x,y,z,vector,color) with about 7000 total array elements in play. The sub terminates when the user goes back to the beginning. I have a SYSTEM statement at the end of my main loop. There are a lot of flags to track events, but it all runs fine till after that warp sub. I was inspired by Terry's tutorial, so I've worked hard to do everything the right way and avoid spaghetti coding. I do load fonts, but learned to use ones that don't bog everything down too much with onscreen displaying and moving. I'm not using any virtual screens. I am at a high resolution of 1600 x 900, but again it works fine till after the warp sub. Thnx
Can we see the code? This would help greatly.
Software and cathedrals are much the same — first we build them, then we pray.
QB64 Tutorial
Posts: 14
Threads: 4
Joined: Mar 2023
Reputation:
0
Thanks for the feedback. I think my biggest issue is the overhead created by having two different fonts loaded and displayed onscreen while moving a lot of stars around. Small changes made a big difference so far. I'm exploring more on the slow-down with your comments in mind.
Posts: 1,510
Threads: 53
Joined: Jul 2022
Reputation:
47
>sigh< Someone will have to play Daniel toward Nebuchadnezzar II, according to the Old Testament.
Have others fix it although it's closed source! Where have I heard/seen that before?
NakedApe this might be the last post on this thread unless you show the source code, or at least provide it into a ZIP file as attachment so one of the "coding wizards" could look at it and show how to help you.
Posts: 2,700
Threads: 124
Joined: Apr 2022
Reputation:
134
>sigh< Someone will have to play Daniel toward Nebuchadnezzar II, according to the Old Testament.
I have read the writing on the wall:
Code: (Select All) _Title "Even More Better Stars - try arrow keys" 'b+ 2022-09-21
' Even Better Stars 2 Arrow Steering" 'b+ 2021-11-23 try with arrow steering
' Better Stars.sdlbas (B+=MGA) 2016-05-16
' odd or even number of point, fat or skinny, better fills
Const Pi = _Acos(-1) 'cute way to get pi
'Print (Pi) 'check pi
'End
Const Radians = Pi / 180 'to convert an angle measured in degrees to and angle measure in radians, just mutiply by this
Const Xmax = 700
Const Ymax = 700
Const Cx = Xmax / 2
Const Cy = Ymax / 2
'setdisplay(xmax, ymax, 32, 1)
Screen _NewImage(Xmax, Ymax, 32)
_ScreenMove 300, 40
'setcaption("Better Stars demo")
'autoback(-2)
'main
Const NS = 100
Dim Shared x(NS), y(NS), dx(NS), dy(NS), ri(NS), ro(NS), p(NS), a(NS), turn(NS), fill(NS), c(NS) As _Unsigned Long
loopcounter = 0
For i = 0 To NS
NewStar i
Next
While _KeyDown(27) = 0
If _KeyDown(19200) Then ' turn left
For i = 0 To NS
x(i) = x(i) + 2 * ri(i) ^ 2
dx(i) = dx(i) + 1
Next
End If
If _KeyDown(19712) Then ' turn right
For i = 0 To NS
x(i) = x(i) - 2 * ri(i) ^ 2
dx(i) = dx(i) - 1
Next
End If
If _KeyDown(18432) Then ' turn up
For i = 0 To NS
y(i) = y(i) + 2 * ri(i) ^ 2
dy(i) = dy(i) + 1
Next
End If
If _KeyDown(20480) Then ' turn down
For i = 0 To NS
y(i) = y(i) - 2 * ri(i) ^ 2
dy(i) = dy(i) - 1
Next
End If
Line (0, 0)-(Xmax, Ymax), _RGB32(0, 0, 0, 10), BF
For i = 0 To NS
If x(i) > 0 And x(i) < Xmax And y(i) > 0 And y(i) < Ymax Then
'ink(colr(c(i)))
Color c(i)
Star x(i), y(i), ri(i), ro(i), p(i), a(i), fill(i)
x(i) = x(i) + dx(i)
y(i) = y(i) + dy(i)
ri(i) = 1.015 * ri(i)
ro(i) = 1.015 * ro(i)
a(i) = a(i) + turn(i)
Else
NewStar i
End If
Next
'screenswap
_Display
_Limit 100
'wait(50)
loopcounter = loopcounter + 1
Wend
Sub NewStar (nxt)
angle = Rnd * 2 * Pi
r = Rnd * 6 + 1
dx(nxt) = r * Cos(angle)
dy(nxt) = r * Sin(angle)
r = Rnd * 300
x(nxt) = Cx + r * dx(nxt)
y(nxt) = Cy + r * dy(nxt)
ri(nxt) = Rnd
ro(nxt) = ri(nxt) + 1 + Rnd
p(nxt) = 3 + Int(Rnd * 9)
a(nxt) = Rnd * 2 * Pi
turn(nxt) = Rnd * 6 - 3
fill(nxt) = 0 'Int(Rnd * 2)
c(nxt) = rndColor~&
End Sub
Function rndColor~& ()
rndColor~& = _RGB32(Rnd * 255, Rnd * 255, Rnd * 255)
End Function
Sub Star (x, y, rInner, rOuter, nPoints, angleOffset, TFfill)
' x, y are same as for circle,
' rInner is center circle radius
' rOuter is the outer most point of star
' nPoints is the number of points,
' angleOffset = angle offset IN DEGREES, it will be converted to radians in sub
' this is to allow us to spin the polygon of n sides
' TFfill filled True or False (1 or 0)
p_angle = Radians * (360 / nPoints): rad_angle_offset = Radians * angleOffset
x1 = x + rInner * Cos(rad_angle_offset)
y1 = y + rInner * Sin(rad_angle_offset)
For i = 0 To nPoints - 1
x2 = x + rOuter * Cos(i * p_angle + rad_angle_offset + .5 * p_angle)
y2 = y + rOuter * Sin(i * p_angle + rad_angle_offset + .5 * p_angle)
x3 = x + rInner * Cos((i + 1) * p_angle + rad_angle_offset)
y3 = y + rInner * Sin((i + 1) * p_angle + rad_angle_offset)
Line (x1, y1)-(x2, y2)
Line (x2, y2)-(x3, y3)
x1 = x3: y1 = y3
Next
If TFfill Then
'Circle (x, y), 2, &HFFFFFFFF
Paint (x, y), _DefaultColor, _DefaultColor
End If
End Sub
b = b + ...
Posts: 14
Threads: 4
Joined: Mar 2023
Reputation:
0
04-22-2023, 10:28 PM
(This post was last modified: 04-22-2023, 10:28 PM by NakedApe.)
Well, I think I discovered the issue. I tried running my program on a newer computer on QB64 version 3.6.0 instead of version 2.0.2 on the older machine and, voila, no more sluggishness after the warp sub. Here's the sub that was causing issues before . . .
SUB warpTravel () ' *** WARP TRAVEL EXECUTABLE LOOP ***
DIM AS INTEGER speed, warp
DIM i AS STRING
DIM warpSound AS LONG
DIM back2SubSound AS LONG
speed = 15: warp = 4:
warpSound = _SNDOPEN("going.wav")
IF warpSound = 0 THEN SOUND 120, 1 ELSE _SNDLOOP warpSound
DO UNTIL i = "b" ' escape from warpTravel and back to sublight by hitting back ("b") button - for now
i = INKEY$
CLS
_LIMIT speed
moveFarStars: drawFarStars '
moveMidStars: drawMidStars '
moveNearStars: drawNearStars '
drawViewScreen
_DISPLAY ' *** TEMP USER INPUT ***
IF i = "p" THEN WHILE INKEY$ = "": WEND ' pause
IF i = "f" AND warp < 8 THEN speed = speed + 3: SOUND 650, .8: warp = warp + 1 ' faster
IF i = "s" AND warp > 0 THEN speed = speed - 1: SOUND 960, .5: warp = warp - 1 ' slower
IF i = CHR$(27) THEN SYSTEM
LOOP ' warp value to be used for displaying speed...
_SNDCLOSE warpSound
back2SubSound = _SNDOPEN("back2SubLight.wav")
IF back2SubSound = 0 THEN SOUND 100, 1 ELSE _SNDPLAY back2SubSound '
_AUTODISPLAY ' needed for speedy lightening effect
lightning
_SNDCLOSE back2SubSound
END SUB ' *** END WARP TRAVEL EXE LOOP ***
Posts: 14
Threads: 4
Joined: Mar 2023
Reputation:
0
04-22-2023, 10:44 PM
(This post was last modified: 04-22-2023, 10:46 PM by NakedApe.)
BTW I'm just trying to learn here and was told that this was a friendly place for asking questions. "bplus" and "mnrvovrfc," your attitudes towards a newbie like me could use some work.
Posts: 2,700
Threads: 124
Joined: Apr 2022
Reputation:
134
04-22-2023, 11:10 PM
(This post was last modified: 04-22-2023, 11:14 PM by bplus.)
(04-22-2023, 10:44 PM)NakedApe Wrote: BTW I'm just trying to learn here and was told that this was a friendly place for asking questions. "bplus" and "mnrvovrfc," your attitudes towards a newbie like me could use some work.
What?
BTW you coulda mentioned you were using sound stuff with the main sub.
b = b + ...
Posts: 1,507
Threads: 160
Joined: Apr 2022
Reputation:
116
(04-22-2023, 10:28 PM)NakedApe Wrote: Well, I think I discovered the issue. I tried running my program on a newer computer on QB64 version 3.6.0 instead of version 2.0.2 on the older machine and, voila, no more sluggishness after the warp sub. Here's the sub that was causing issues before . . .
SUB warpTravel () ' *** WARP TRAVEL EXECUTABLE LOOP ***
DIM AS INTEGER speed, warp
DIM i AS STRING
DIM warpSound AS LONG
DIM back2SubSound AS LONG
speed = 15: warp = 4:
warpSound = _SNDOPEN("going.wav")
IF warpSound = 0 THEN SOUND 120, 1 ELSE _SNDLOOP warpSound
DO UNTIL i = "b" ' escape from warpTravel and back to sublight by hitting back ("b") button - for now
i = INKEY$
CLS
_LIMIT speed
moveFarStars: drawFarStars '
moveMidStars: drawMidStars '
moveNearStars: drawNearStars '
drawViewScreen
_DISPLAY ' *** TEMP USER INPUT ***
IF i = "p" THEN WHILE INKEY$ = "": WEND ' pause
IF i = "f" AND warp < 8 THEN speed = speed + 3: SOUND 650, .8: warp = warp + 1 ' faster
IF i = "s" AND warp > 0 THEN speed = speed - 1: SOUND 960, .5: warp = warp - 1 ' slower
IF i = CHR$(27) THEN SYSTEM
LOOP ' warp value to be used for displaying speed...
_SNDCLOSE warpSound
back2SubSound = _SNDOPEN("back2SubLight.wav")
IF back2SubSound = 0 THEN SOUND 100, 1 ELSE _SNDPLAY back2SubSound '
_AUTODISPLAY ' needed for speedy lightening effect
lightning
_SNDCLOSE back2SubSound
END SUB ' *** END WARP TRAVEL EXE LOOP ***
All bplus and mnrvovrfc were pointing out was the basic futility of trying to help someone blind. Without sharing the code, how is anyone supposed to know that you're using sound statements? Is the forum community just supposed to guess like throwing darts in the dark, hoping that they can hit some strange behavior?
The main issue here, as it looks to me, would be in the constant opening and closing of a sound file inside an inner loop, as well as the innate pause that SOUND natively generates.
QB64PE v 3+ has had work done to help load sound files faster, and thus it appears as if by upgrading you've fixed the issue, but you've only minimized it somewhat. Any time you have to access a file, it takes time to load and unload that file from memory. Since this sub is constantly calling two sounds over and over, I'd simply make those two global sounds and load them once at the start of my program, and then leave them in memory until my program finished running.
In the main program, I'd have:
DIM SHARE AS LONG warpsound, back2SubSound
warpSound = _SNDOPEN("going.wav")
back2SubSound = _SNDOPEN("back2SubLight.wav")
And then in the sub itself, all you'd need is the soundplay statement, and instead of a _SNDCLOSE at the end, use a _SNDSTOP to simply stop the sound from playing.
Second point is the SOUND statement itself. SOUND, from what I remember from using it waaay back in the day, tends to pause a program until its completion.
SOUND 100, 1 and SOUND 120, 1 both take 1/18th of a second to start, play, and complete, with the program doing nothing else while they're processing. Combined, that's 1/10th of a second for a pause if warpsound and back2SubSound can't find the wav files properly. At most, if this routine is called repeatedly, you'd only run at a limit of about 8-9 loops per second -- depending on if there was anything else inside the subs that it calls which might increase that processing time considerably, or not.
Third thing which I'd watch for, that stands out to me, is the endless pause loop.
IF i = "p" THEN WHILE INKEY$ = "": WEND ' pause
While INKEY$ = "": WEND <-- This little snippet is going to use 100% of a CPUs processing power and almost instantly turn the fan on for cooling purposes with the laptop/PC which you're running it on. It's trying to use ALL your computer's resources to check for a keypress every 0.000000001 seconds, or some such insane rate.
Fix for this? Add a DELAY into that loop so it doesn't process so recklessly.
IF i = "p" THEN WHILE INKEY$ = "": _DELAY 0.1: WEND ' pause
You probably won't notice any change whatsoever in how the program responds, but you sure will notice the difference in how much processing your CPU will be doing on it!
Posts: 5
Threads: 0
Joined: May 2022
Reputation:
1
I thank SMcNeill I finally understood why my program was triggering the fan
|