Qbasicnews.com

I was reading "Game Developer" magazine, and there was an article about "Rise of Nations". In case you didn't know, "Rise of Nations" is an RTS (real time strategy) / turn-based hybrid created over the span of 3 years (I think) by Microsoft.

In that article, they described one of the tools that was used to create this massive program. The tool made a menu within the game with a list of all the game variables. The variables were continuously updated from the game and they could also be changed! A great debug tool.

Now, maybe it could be done for QB? I'm envisioning a separate program running alongside the program-to-be-tested, and that separate program spies at the memory segment of the first program. Before the first program is run, the second program reads the first program and finds all the variables (and possible recursive variables)..

What do you think? :|

1. Press F8 to step through your program.
2. While doing so, click the debug menu.
3. See those "watchpoint" options in the menu? They're useful, learn to use them! They do exactly what you just described. They can evaluate an expression for you using the program's current variables.

They aint so helpful. Atleast not while using SVGA =(

And not as friendly as the method aga describes. Why don't you have a go and see what you can do, aga?

Problem:

I'll need to know what memory area a variable is going to. I have no idea how to do that.

I also suspect I'll need to write a few bits after variable access to tell the other program what variable changed, what location it went to, and to what value.

So the entire BAS file will have to both be scanned and modified..

BC.EXE can give you a listing for each bas file... is that enough info?

.....a listing of what?

EDIT: No, I was wrong. Neither the .lst file BC can generate, nor the .map file from LINK seem to have an info on variables used in the program.

What you need to do is scan memory for specific values, and then track changes to those values. The biggest problem in QB (and many other BASICs as well) is that garbage collection can move a variable's physical location in memory.

Quote:What you need to do is scan memory for specific values, and then track changes to those values. The biggest problem in QB (and many other BASICs as well) is that garbage collection can move a variable's physical location in memory.

... you're repeating me?