debugging idea for QB

[1000101]

...maybe you missed the part where I said,

You would have to modify this for your program

As in, change the locate/color/print statements to your codes SVGA routine equivalents. Anyway, that is the *exact* method I use to monitor variables while the program is running. I just hit my 'debug overlay' hotkey and it shows me all the information I specified to be displayed. Just stick the calls at the end of your display loop so that it is shown over everything else. Simple. Getting an external program to do it would be *very* hazardous.

[Hexadecimal Disaster]

What he can do is to compile his program using the /D or /Zi parameter, linking the resulting crap using /CO and then have loads and loads of fun debugging with CodeView.

BTW, I think that the previous solutions are very reasonable.

[Agamemnus]

I tried to find a download. Failed. From the few sentences I read, CodeView doesn't sound like a walk in the park.

:||

Anyways, I guess I'm too much of a slacker to make this thing a reality, so let's go on to the next topic....

[Hexadecimal Disaster]

AFAIK, CodeView comes along with PDS 7.1. And yes: for short -it's a pain in the @$$- but it may fill your requirements.

[1000101]

AFAIK, CodeView comes along with PDS 7.1. And yes: for short -it's a pain in the @$$- but it may fill your requirements.

If your requirement is to have a pain in the @$$, then yes, codeview will fill this. Personally I use Turbo Debugger since it's waaaaaaaaaaaaaaaaaaaaaaaaaaaaaay better then Codeview, not to mention...*IT* works!

[LooseCaboose]

Cannot be done. Period. Programs do not keep a "history" of where variables went during garbage collection.

Garbage collection is used to remove variables from memory that no longer have any references (pointers) to them, variables are not moved during garbage collection, they are destroyed. You cannot re-reference a variable that has been garbage collected because there is no way to know its address in memory because no pointer exists for it.

AFAIK, QB doesn't even use garbage collection. Garbage collection is fairly difficult to implement and often used in object orientated languages.

Variables can be stored in a number of ways, they can be memory addresses, hard coded in instructions, or exist only temporarily in registers. After a program is compiled it may be possible to determine (with a large amount of difficulty) what variables exist in the data segment, but determining what is in the bss segment (unitialised data) would be nearly impossible. It would be a matter of actually analysis the text segment to see how the instructions manage the programs data.

I think the best bet, is some sort of in program method for monitoring specific variables. It sounds like this is the way that the game that Agamemnus first posted about works.

[Agamemnus]

but there is one thing that's different. The game I was talking about is a windows game, and it's possible to make the computer screen huge so that the game and the variables menu don't interfere with each other.

[LooseCaboose]

but there is one thing that's different. The game I was talking about is a windows game, and it's possible to make the computer screen huge so that the game and the variables menu don't interfere with each other.

You mean that the game window and the the monitor window are separate? Thats quite possible, each window could be a separate threads of the main program, so there are two (or more) individual windows but both have access to the same data.