Jump to content
The Dark Mod Forums

DarkRadiant & dmap


Recommended Posts

Hopefully that can be optimized so that DR doesn't update the GUI 100 times a second :)

DarkRadiant only runs this gtk_main_iteration() if there are actually gtk events pending, so this shouldn't be so taxing. Also, increasing the interval to higher values might result in "lagging" and unresponsiveness of the other DarkRadiant windows.

 

You can play around with the values in dm.d3hook/DarkModRCFClient::executeCommand() method, be my guest. The current values have been roughly thrown in by me anyway.

 

I do have a Dual-Core CPU, but it seems linux holds both processes on one core - makes sense as they need to communicate, anyway.

Even if processes are running on different cores, this should not make any difference when they try to communicate via the network socket. Can't Linux reassign the processes to the idling core? In Windows, I always get a 50:50 split of the CPU time between DR and Doom3, the Task Manager always shows me 100% CPU usage (both cores fully working).

 

Yeah, I know, you get the mouse pointer back with "^" - would be good if that "open console" command could be issue by DR automatically, tho.

I don't see a way to do that. I couldn't find any command in the accessible D3 interface classes. If anybody has an idea of doing that, let me know.

 

Anyway, but once you switch back to doom and try to quit it, doom just hangs and when I kill it via (CTRL+ALT+F1 => killall doom.x86) I get that stuck mousepointer.

Does this also happen with vanilla Doom 3 or is this due to TDM's RCF-modded gamesys? I never ran Doom 3 in Linux before, so I assumed this was "normal" behaviour.

Link to comment
Share on other sites

Even if processes are running on different cores, this should not make any difference when they try to communicate via the network socket.

 

You mean it should be not faster due to the communication "blocking"?

 

Can't Linux reassign the processes to the idling core? In Windows, I always get a 50:50 split of the CPU time between DR and Doom3, the Task Manager always shows me 100% CPU usage (both cores fully working).

 

It can. However, I am sure it is not the CPU that is the bottleneck, but either OpenGL (contexts?) or network communication blocking etc.

 

For instance, I can run D3 and compile something in the background just fine, just not DR + D3.

 

Likewise, when D3 displays its console, it eats about 5% CPU and no more :)

 

I don't see a way to do that. I couldn't find any command in the accessible D3 interface classes. If anybody has an idea of doing that, let me know.

 

I don't know either.

 

Does this also happen with vanilla Doom 3 or is this due to TDM's RCF-modded gamesys? I never ran Doom 3 in Linux before, so I assumed this was "normal" behaviour.

 

No. When you run D3 normal, it exits normal. There was a time when it always crashed/stuck at the end, but now it works just fine.

 

But _after_ I run DR's "compile map" command once, D3 no longer exits - it just hangs.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

You mean it should be not faster due to the communication "blocking"?

Sorry, I don't get what you mean here?

 

It can. However, I am sure it is not the CPU that is the bottleneck, but either OpenGL (contexts?) or network communication blocking etc.

Possible improvements can be:

- Increase the RCF server cycle interval, both in DarkRadiant and DarkMod.

- Increase the packet size of the console redirect (currently the text is sent in 64 byte chunks).

- Interleave the GUI processing in DarkRadiant

 

Likewise, when D3 displays its console, it eats about 5% CPU and no more :)

That's not surprising, is it? Idling in the console is of course not very taxing.

 

No. When you run D3 normal, it exits normal. There was a time when it always crashed/stuck at the end, but now it works just fine.

 

But _after_ I run DR's "compile map" command once, D3 no longer exits - it just hangs.

I just checked: I disabled the RCF Server in D3 completely (by not instantiating it) and D3 still hangs when I hit the X in the upper right corner to close D3. This is independent of the dmap command (I hadn't even opened DarkRadiant before closing). Maybe this is due to other DarkMod code? I would need to revert to a previous revision to check that out.

 

However, typing 'quit' in the console quits D3 correctly. Weird.

Link to comment
Share on other sites

Sorry, I don't get what you mean here?

 

I meant that if the communication between DR and D3 is synced, then one process needs to wait for the other, and this means that things won't go faster due to the "waiting time", no matter if both process are on the same CPU or not.

 

E.g. DR can't output the console text faster than D3 provides it.

 

Possible improvements can be:

- Increase the RCF server cycle interval, both in DarkRadiant and DarkMod.

- Increase the packet size of the console redirect (currently the text is sent in 64 byte chunks).

- Interleave the GUI processing in DarkRadiant

 

I think profiling would be the first step, so we find out where the time is spent. Is it possible to run DR under some sort of profiler?

 

That's not surprising, is it? Idling in the console is of course not very taxing.

 

Well, almost any old game just burns 100% CPU anyway :) D3 is very good in this regard.

 

I just checked: I disabled the RCF Server in D3 completely (by not instantiating it) and D3 still hangs when I hit the X in the upper right corner to close D3. This is independent of the dmap command (I hadn't even opened DarkRadiant before closing). Maybe this is due to other DarkMod code? I would need to revert to a previous revision to check that out.

 

My currently compiled revision is 1848, and shutting down/closing doom works fine here, either via the menu or [X].

 

Unless I run "DR and do the dmap" - then it hangs. Maybe it is some sort of Heisenbug with something uninitialized?

 

However, typing 'quit' in the console quits D3 correctly. Weird.

 

Heisenbug :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I think profiling would be the first step, so we find out where the time is spent. Is it possible to run DR under some sort of profiler?

I'm already done with a basic profile run. On my system, DarkRadiant's dmap is now faster than calling it in the D3 console, under the following circumstances (dmap askave.map, running in Linux):

- DarkRadiant does not check for the D3 process each second, this is taxing.

- DarkRadiant decreases the server cycle interval to 0.01ms, this improves things by a dozen seconds.

- DarkRadiant does not write the output to its own console

 

The D3 process check has the most impact. Removing it improves compile time from 1:50 to 50 seconds.

Turning off the DarkRadiant console output doubles the speed, the compile time goes down to 25 seconds for askave, while D3 itself in the console takes 30 seconds.

 

I will commit some optimisations to SVN, but I will leave the DR console output active by default, I think mappers will like that. Also, I'll add an option to toggle the console output off (makes sense for large maps >= askave).

 

Heisenbug :)

Don't make me open up google again - what the heck is a Heisenbug?

Link to comment
Share on other sites

I'm already done with a basic profile run.

 

Can you please point me to some tutorial on how you did the profiling?(Or did you use windows for that?)

 

On my system, DarkRadiant's dmap is now faster than calling it in the D3 console, under the following circumstances (dmap askave.map, running in Linux):

- DarkRadiant does not check for the D3 process each second, this is taxing.

- DarkRadiant decreases the server cycle interval to 0.01ms, this improves things by a dozen seconds.

- DarkRadiant does not write the output to its own console

 

The D3 process check has the most impact. Removing it improves compile time from 1:50 to 50 seconds.

Turning off the DarkRadiant console output doubles the speed, the compile time goes down to 25 seconds for askave, while D3 itself in the console takes 30 seconds.

 

I will commit some optimisations to SVN, but I will leave the DR console output active by default, I think mappers will like that. Also, I'll add an option to toggle the console output off (makes sense for large maps >= askave).

 

Yeah, the output is nice, much easier to read than the own doom console with the limited view and scrolling awkwardness. But maybe DR can update the console only once per second, instead for every line it receives?

 

(Oh and many thanx for improving it :)

 

Don't make me open up google again - what the heck is a Heisenbug?

 

Man, don't you young kids learn nutting these days? </grumpy old programmer> :D

 

Anyway here goes:

 

http://en.wikipedia.org/wiki/Heisenbug

 

"A heisenbug is a computer bug that disappears or alters its characteristics when it is researched.

 

One common example is a bug that occurs in a release-mode compile of a program, but not when researched under debug-mode; another is a bug caused by a race condition."

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Can you please point me to some tutorial on how you did the profiling?(Or did you use windows for that?)

I just used the stopwatch of my cell phone. ;)

 

Yeah, the output is nice, much easier to read than the own doom console with the limited view and scrolling awkwardness. But maybe DR can update the console only once per second, instead for every line it receives?

It would be possible to interleave the gtk_main_iteration call, but I don't think it would make much difference. If people are concerned with performance, they should turn off the console.

 

Another approach would be to buffer the entire output locally, and then write it to the console in one large chunk, for reference.

 

Man, don't you young kids learn nutting these days? old programmer> :D

Don't forget, I'm not a real programmer, that's just my hobby. Before The Dark Mod, I hadn't touched a compiler for ten years. ;)

 

"A heisenbug is a computer bug that disappears or alters its characteristics when it is researched.

 

One common example is a bug that occurs in a release-mode compile of a program, but not when researched under debug-mode; another is a bug caused by a race condition."

*shakes head*

Link to comment
Share on other sites

I just used the stopwatch of my cell phone. ;)

 

Low-tech :)

 

It would be possible to interleave the gtk_main_iteration call, but I don't think it would make much difference. If people are concerned with performance, they should turn off the console.

 

You mean off the visible console window in DR? I am still compiling the latest version, so I can't test the performance right now, will do so soon.

 

Another approach would be to buffer the entire output locally, and then write it to the console in one large chunk, for reference.

Don't forget, I'm not a real programmer, that's just my hobby. Before The Dark Mod, I hadn't touched a compiler for ten years. ;)

*shakes head*

 

No worries, you do a fine job :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Hm,

 

the first compile did seem to go faster, but not as fast as D3 did it. However, I couldn't do exact timings, because after the first compile I get this:

 

no entities in map that use aas100
DarkMod reported: Command is done
DarkRadiant RCF Server stopped.
Starting DarkRadiant RCF Server.
Caught exception:
Type: N3RCF9ExceptionE
What: [31: client read failed][1: Operating system][104: Connection reset by peer][What: ][Context: plugins/dm.d3hook/RCF/TcpClientTransport.cpp(284): void RCF::TcpClientTransport::bsdRecv(const RCF::ByteBuffer&, size_t): : Thread-id=1099555632 : Timestamp(ms)=45608048: THROW : N3RCF9ExceptionE : [31: client read failed][1: Operating system][104: Connection reset by peer][What: ][Context: ]: bytesToRead=4, err=104, 
]
DarkRadiant RCF Server stopped.

 

Another try, same result:

 

Starting DarkRadiant RCF Server.
Caught exception:
Type: N3RCF9ExceptionE
What: [31: client read failed][1: Operating system][104: Connection reset by peer][What: ][Context: plugins/dm.d3hook/RCF/TcpClientTransport.cpp(284): void RCF::TcpClientTransport::bsdRecv(const RCF::ByteBuffer&, size_t): : Thread-id=1099555632 : Timestamp(ms)=45616353: THROW : N3RCF9ExceptionE : [31: client read failed][1: Operating system][104: Connection reset by peer][What: ][Context: ]: bytesToRead=4, err=104, 
]
DarkRadiant RCF Server stopped.

 

Maybe this is related to the hang of doom at exit.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Maybe this is related to the hang of doom at exit.

Most probably.

 

On a related note, I "updated" my darkmod_src repository to revision 1800 (which is before I introduced the RCF library) and Doom3/DarkMod still hangs when clicking on the X. Has this ever been working, I wonder?

Link to comment
Share on other sites

Most probably.

 

On a related note, I "updated" my darkmod_src repository to revision 1800 (which is before I introduced the RCF library) and Doom3/DarkMod still hangs when clicking on the X. Has this ever been working, I wonder?

 

It definitely works in linux. There was a time when it didn't exit properly, and this was fixed (I forgot how and by whom, tho)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I don't see a way to do that [open the D3 console from DarkRadiant]. I couldn't find any command in the accessible D3 interface classes. If anybody has an idea of doing that, let me know.

In Windows, you could possibly send a keystroke event to the D3 window. But I'm not sure whether this can be done in Linux or not; and besides, different people will have different keys mapped to the console. e.g. For me it's Ctrl-Alt-~ (or just ~ with developer mode on), and you said that it's Ctrl-^ for you. Probably due to a difference in keyboard layouts. There might be a way of figuring out what the correct keystroke is, but I'm not sure how. It doesn't seem to be listed in DoomConfig.cfg for example. Maybe it's hard-coded depending on the keyboard layout.

 

It definitely works in linux. There was a time when it didn't exit properly, and this was fixed (I forgot how and by whom, tho)

Are you thinking of the time when joebarnin's FM loader code just exited the process instead of calling the "quit" command, thus causing the gamma and mouse settings to not get restored properly?

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

In Windows, you could possibly send a keystroke event to the D3 window. But I'm not sure whether this can be done in Linux or not; and besides, different people will have different keys mapped to the console. e.g. For me it's Ctrl-Alt-~ (or just ~ with developer mode on), and you said that it's Ctrl-^ for you. Probably due to a difference in keyboard layouts. There might be a way of figuring out what the correct keystroke is, but I'm not sure how. It doesn't seem to be listed in DoomConfig.cfg for example. Maybe it's hard-coded depending on the keyboard layout.

I think it is hardcoded to the key in the upper left (next to the 1 and above tab), which is ~ for english/american keyboards, but for us it is ^. This is not so much fun, because this key waits for another one pressed after it, so after getting the console down we always had to press a key and hit enter before we could start using it. :rolleyes: Pressing Ctrl + ^ solves that problem.

Link to comment
Share on other sites

In Windows, you could possibly send a keystroke event to the D3 window. But I'm not sure whether this can be done in Linux or not; and besides, different people will have different keys mapped to the console. e.g. For me it's Ctrl-Alt-~ (or just ~ with developer mode on), and you said that it's Ctrl-^ for you. Probably due to a difference in keyboard layouts. There might be a way of figuring out what the correct keystroke is, but I'm not sure how. It doesn't seem to be listed in DoomConfig.cfg for example. Maybe it's hard-coded depending on the keyboard layout.

 

I think it is always the same scancode, just that on European keyboards "^" is the key what american ones have as "~".

 

Are you thinking of the time when joebarnin's FM loader code just exited the process instead of calling the "quit" command, thus causing the gamma and mouse settings to not get restored properly?

 

I dunno, when I first started to use TDM, the doom process always hung at exit instead of ending properly. my memory is already that bad :D

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I think it is hardcoded to the key in the upper left (next to the 1 and above tab), which is ~ for english/american keyboards, but for us it is ^. This is not so much fun, because this key waits for another one pressed after it, so after getting the console down we always had to press a key and hit enter before we could start using it. :rolleyes: Pressing Ctrl + ^ solves that problem.

 

The "wait for another key" is caused by "dead keys" not being ignored - or not, depending on your settings. See here:

 

http://en.wikipedia.org/wiki/Dead_key

 

When dead keys are supported, you can press "^" followed by f.i. "e" and get "ê".

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...