- Forum
- General C++ Programming
- Visual Studio 2019: How do I see code wo
Visual Studio 2019: How do I see code work in real time
Wasn't sure where to post this. It could fall under Windows Programming or Lounge but since I've been getting all my help for this project in this forum I decided to post it here.
You guys have been helping me get a game (a MUD specifically) up and running. Now that I have it working I want to see the code execute in real time while I'm playing so I can see how everything works. However, the way it's played right now is via an executable. I compile the code, open a DOS prompt, navigate to the folder with the .exe file, and run the file. The game runs in the background as long as the DOS window is open. And then log into the MUD using a client (MUSHclient).
What I'd like to do is play the game and watch the code execute in Visual Studio as I'm playing. Do you guys know of a way to do this?
You guys have been helping me get a game (a MUD specifically) up and running. Now that I have it working I want to see the code execute in real time while I'm playing so I can see how everything works. However, the way it's played right now is via an executable. I compile the code, open a DOS prompt, navigate to the folder with the .exe file, and run the file. The game runs in the background as long as the DOS window is open. And then log into the MUD using a client (MUSHclient).
What I'd like to do is play the game and watch the code execute in Visual Studio as I'm playing. Do you guys know of a way to do this?
It's impossible. Just how fast do you think the code is executing while you play? If you were able to see something comprehensible in the code window the game would be running unplayably slowly. The best you can do is step through the code in the debugger (while you're stepping through it the game will basically be completely paused), or insert print statements at the start of some functions to keep track of where the control flow is. This will work:
You'll have to pick the functions to print carefully or, again, you'll just see a bunch of text woosh by the console.
|
|
Last edited on
An alternative to helios's very good suggestion is to direct you debugging print statements to a file and analyze the output after the fact.
The advantage is that you can save more output than if it were directed to the console. The disadvantage is that analysis is after the fact.
Again, be careful about how much output you generate. It's easy to generate more than you can possibly analyze.
The advantage is that you can save more output than if it were directed to the console. The disadvantage is that analysis is after the fact.
Again, be careful about how much output you generate. It's easy to generate more than you can possibly analyze.
Ok I think I could have been more clear about the ask.
helios
I'm not wanting to view the code like your suggesting. My thinking was along the lines of this:
say I cast a spell using the command "cast invis". I want put a break point where ever the code starts handling that command and then step through the code line-by-line to see what happens and still be able to see the output in my client. I don't want to "play" the game but rather slowly step through the code and see the output as I'm doing that. I realize I might have to step though 80 lines of code to see a single output in the client but that's the point. I want to see the game executing, line-by-line. Does that make more sense?
helios
I'm not wanting to view the code like your suggesting. My thinking was along the lines of this:
say I cast a spell using the command "cast invis". I want put a break point where ever the code starts handling that command and then step through the code line-by-line to see what happens and still be able to see the output in my client. I don't want to "play" the game but rather slowly step through the code and see the output as I'm doing that. I realize I might have to step though 80 lines of code to see a single output in the client but that's the point. I want to see the game executing, line-by-line. Does that make more sense?
Debugging in Visual Studio
https://docs.microsoft.com/en-us/visualstudio/debugger/
https://docs.microsoft.com/en-us/visualstudio/debugger/
I want to see the game executing, line-by-line. Does that make more sense?Simply place breakpoints in those places in which you're interested.
If you want to break on every spell cast, set a breakpoint in
void SpellCast() or what ever the function is called, then step into to see calculation etc...
| I want put a break point where ever the code starts handling that command and then step through the code line-by-line to see what happens and still be able to see the output in my client. |
That's exactly what the Visual Studio debugger is designed to do.
Set your breakpoint(s) and then step through the code.
You can step into called functions, or step over them if you don't want to step through the called function.
I still don't think I'm explaining what I want very well. Here's is how the games creator describes how it works:
"The player types "cast 'acid blast' target", game_loop() recognises that there is input waiting from the player connection, it redirects the input to interpret() which finds there is a cast command... it then executes the function for this command - do_cast(). do_cast() redirects to do_newcast() which searchs skill_table[] for a spell called "acid blast", after finding it and confirming it has a spell function set, it then executes the spell function (Which is called spell_acid_blast() in this case), and that function does what it is supposed to do."
I want to be able to see the code execute this process, line-by-line, and see how it outputs to the screen as it's doing it. I don't know how to "cast 'acid blast' target" in debug mode. I would have to do that "in-game". I've seen this done before using a DOS prompt to input commands but that was like 15 years ago before MUD clients existed.
"The player types "cast 'acid blast' target", game_loop() recognises that there is input waiting from the player connection, it redirects the input to interpret() which finds there is a cast command... it then executes the function for this command - do_cast(). do_cast() redirects to do_newcast() which searchs skill_table[] for a spell called "acid blast", after finding it and confirming it has a spell function set, it then executes the spell function (Which is called spell_acid_blast() in this case), and that function does what it is supposed to do."
I want to be able to see the code execute this process, line-by-line, and see how it outputs to the screen as it's doing it. I don't know how to "cast 'acid blast' target" in debug mode. I would have to do that "in-game". I've seen this done before using a DOS prompt to input commands but that was like 15 years ago before MUD clients existed.
Last edited on
debug runs the game. you put in a break point, say where the handler for the user input to cast the spell is located. It chugs along until you cast the spell, then it stops right there and lights up the code, where you can step through it. Depending on the type of code, this can be hard to watch in a game -- if it is multi-threaded or the graphics card is doing something for you ... but normal code works like that.
if you can't use the debugger, sometimes the only way is to make a log-file or screen dump of where it is and what it is doing. this means adding a bunch of prints to your code.
you can also make a minimal main program that does nothing BUT the thing you want to look at, and run that instead of the normal code. This is a critical technique for testing code...
if you can't use the debugger, sometimes the only way is to make a log-file or screen dump of where it is and what it is doing. this means adding a bunch of prints to your code.
you can also make a minimal main program that does nothing BUT the thing you want to look at, and run that instead of the normal code. This is a critical technique for testing code...
| I've seen this done before using a DOS prompt to input commands but that was like 15 years ago before MUD clients existed. |
yea I noted that too. there were muds in 1994(best guess) -- I remember briefly doing that but they were boring. I also remember doing somewhat similar stuff in 88 or 89 over a modem to dial up "bulletin board" sites. I hit those to get free games back in the freeware/shareware days.
Last edited on
Topic archived. No new replies allowed.