How to Restart a Bogged Down Program

[TerryRitchie]

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.

[NakedApe]

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.

[mnrvovrfc]

>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.

[bplus]

>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

[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 ***

[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.

[bplus]

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.

[SMcNeill]

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!

[jcm]

I thank SMcNeill I finally understood why my program was triggering the fan