How to Restart a Bogged Down Program - Printable Version +- QB64 Phoenix Edition (https://staging.qb64phoenix.com) +-- Forum: QB64 Rising (https://staging.qb64phoenix.com/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://staging.qb64phoenix.com/forumdisplay.php?fid=3) +---- Forum: Help Me! (https://staging.qb64phoenix.com/forumdisplay.php?fid=10) +---- Thread: How to Restart a Bogged Down Program (/showthread.php?tid=1634) Pages:
1
2
|
RE: How to Restart a Bogged Down Program - TerryRitchie - 04-21-2023 (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. RE: How to Restart a Bogged Down Program - NakedApe - 04-21-2023 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. RE: How to Restart a Bogged Down Program - mnrvovrfc - 04-21-2023 >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. RE: How to Restart a Bogged Down Program - bplus - 04-22-2023 >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 RE: How to Restart a Bogged Down Program - NakedApe - 04-22-2023 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 *** RE: How to Restart a Bogged Down Program - NakedApe - 04-22-2023 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. RE: How to Restart a Bogged Down Program - bplus - 04-22-2023 (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. RE: How to Restart a Bogged Down Program - SMcNeill - 04-23-2023 (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 . . . 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! RE: How to Restart a Bogged Down Program - jcm - 04-23-2023 I thank SMcNeill I finally understood why my program was triggering the fan |