Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Infinite Loop crash.

Author
Message
GunnerWolf
6
Years of Service
User Offline
Joined: 21st Apr 2013
Location:
Posted: 2nd May 2013 01:04
For some reason, I get an infinite loop crash with my game if I attempt to close the game at a certain point.
Here's the code at fault:
Rudolpho
14
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 2nd May 2013 03:04
That's a nice example of why people have a pretty negative attitude towards using labels and goto/gosub commands.
It is pretty hard to follow your code with the arbitrary jumps. I would suggest rewriting it using loops instead and the problem should likely become apparent.


"Why do programmers get Halloween and Christmas mixed up?"
TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 2nd May 2013 12:10
You shouldn't let subroutines call themselves. This can cause a stack overflow over time.

I'm not sure what the problem is, but the way you've structured your subroutines should be improved on.



TheComet


Level 91 Forumer - 9600 health, 666'666 keystroke power (*2 coffee)
Abilities: sophisticated troll, rage
GunnerWolf
6
Years of Service
User Offline
Joined: 21st Apr 2013
Location:
Posted: 2nd May 2013 18:59
I'm not sure at all what you mean, let me clarify a little bit:

If I attempt to close the game at this point:

The game will for some reason think that the enter key has been pressed, and will attempt to verify the input (To make sure it's a valid answer) in this section of code:

Meaning if the input isn't "1" or "2" then it counts it as an invalid input and goes here:

the keycont sub simply prints a message saying press any key to continue
however, when I close the game, and it registers an input, and finds that the input is not 1 or 2, it goes to that screen, then registers another key press, and returns to the question, and so on so forth until I have to end the process
Kevin Picone
17
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 8th May 2013 02:29
There does seem to be a likely stack overflow. Every time you call GOSUB, this places a chunk of data on the stack (the return location). So when we call RETURN, this instruction pops the previously pushed gosub data from the stack, keeping the stack in balance.

What can happen though, is a program can miss this closing RETURN call, leaving these bread crumb data on the stack. Sooner or later the stack will overfill and the program with most likely die/hang.


Eg (>>>>DONT RUN THIS<<<)



This program never reaches the RETURN statement.

29 games
14
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 9th May 2013 23:42 Edited at: 9th May 2013 23:46
Quote: "That's a nice example of why people have a pretty negative attitude towards using labels and goto/gosub commands.
"


If this was done in functions it would still be a mess. The use of functions isn't a cure all if you have no idea what you're doing.

@GunnerWolf, sorry for my bluntness but I think you haven't really understood how to construct the flow of you're code properly. When I say flow, I mean how to get the code to go from one part to the next without the code turning into a confusing mess.

I don't know why you're getting an infinite loop error and I don't think it's worth nit picking through the code to find out. It would be better to rewrite it from scratch.

I think I understand what you are trying to do so I had a go at rewriting it.



The way I've constructed it is that each section of the story has its own sub-routine.

Each sub-routine contains: the story element, the choices the player needs to make and then code to deal with those choices. Once the player has made their choice the sub-routine then returns to the main loop.

Rather than using the INPUT command I'm using the INKEY$ command and then wrapping it in a loop until the player makes a valid choice. I've also used the SELECT... ENDSELECT and CASE... ENDCASE commands rather than IF THEN ELSE as this make it easier to have multiple choices. You don't need to call multiple RETURNS within the one sub-routine.

The code should be easily expandable to add more sections of the story.

One problem I can foresee with this method is that it probably won't be very good if the want to allow the player to back track in the story. It's basically set up as a one way journey (if that makes sense).

I hope you can make sense of the code and that it gives you some ideas.

one of these days I'll come up with a better signature
CSL
10
Years of Service
User Offline
Joined: 22nd Mar 2009
Location: USA
Posted: 18th May 2013 19:24
I understand that the code snippet provided is only part of your code, not the full program. After I commented all gosubs and references to getEquip(), the code compiles, runs and correctly stops and waits for user Input. What may be happening to you is that the input buffer at some point is not clean when it gets there. You may want to try a CLEAR ENTRY BUFFER before the input. This may or may not be the solution, but it's the only thing that occurs to me based on the information you provided.

CSL

Login to post a reply

Server time is: 2020-01-19 16:07:28
Your offset time is: 2020-01-19 16:07:28