ok, so this isn't a code problem, since there's absolutely no actual code that creates/affects this problem, but this still seemed the most appropriate forum.
so i noticed that whenever any mob moves in my game, CPU usage in task manager spiked from 0-1% usage to 24-30% usage and stayed there while any movement occurred; once all movement stopped, it steadily (over about 3-4 seconds) went back down to 0-1% usage. i tore through all my code and even created a totally sterile DM environment and continued to look for the problem, until i found out that it's the interface that's causing it.
if you take a fresh DM environment and plug my interface into it, it will cause the increased CPU during movement. it's also worth mentioning that creating and using a fresh, custom interface does not cause the CPU usage to hit 30 when moving.
i haven't been able to isolate what specifically in my interface causes the issue-- however it appears as though chopping out portions of it lowers the CPU usage during movement by equal amounts. in addition, this issue occurs on two different projects- the current one, and one that's about 2 months old. the only similarity between the two is that their interfaces are custom, using multiple windows (2-3) and heavy use of labels and some bars. one is 14kb, the other 27kb
should i just post the entire .dmf?
ID:157569
 Feb 12 2010, 5:14 am
|
|
Off the top of my head, maybe you have a lot of transparent windows? Graphics rendering complications and all that?
| |
Do you have any interface controls over the map?
| |
Zaole wrote:
ok, so this isn't a code problem, since there's absolutely no actual code that creates/affects this problem, but this still seemed the most appropriate forum. Code Problems is only appropriate when there is a code snippet in the post. Otherwise the post goes in Developer How-To. so i noticed that whenever any mob moves in my game, CPU usage in task manager spiked from 0-1% usage to 24-30% usage and stayed there while any movement occurred; once all movement stopped, it steadily (over about 3-4 seconds) went back down to 0-1% usage. i tore through all my code and even created a totally sterile DM environment and continued to look for the problem, until i found out that it's the interface that's causing it. The key things to look for would be any controls overlapping the map, or any windows that use the transparency or alpha features. Window transparency or alpha is incompatible with DirectX, so if those are present in the skin then the game will force itself into software rendering mode. Usually the map being stretched is what causes the most significant bottleneck in software mode. If neither of those things is the case, we'd have to see your skin file to know more. Lummox JR | |
DarkCampainger wrote:
Do you have any interface controls over the map? yeah, and reducing the size of the map in the interface (for the purpose of keeping the interface controls from being on the map) reduced the size of the CPU spikes to ~15% does this mean it's simply not reasonable at all to have interface controls over the map? and what is causing the other 15%? Kaichao wrote: Off the top of my head, maybe you have a lot of transparent windows? Graphics rendering complications and all that? one of my windows used transparency at one point, but i removed the transparency when looking for the problem, and it didn't help (nor did completely chopping out the window that used transparency) EDIT: resizing the map so it's not stretched served to eliminate the unnecessary CPU usage. this means it's still running the game in software mode instead of using DirectX? unless i'm mistaken, all reasons to resort to software mode are gone (no transparency in any interface elements). is there a way to manually check if it's running in software mode? what can i do to ensure it utilizes DirectX? | |
Zaole wrote:
does this mean it's simply not reasonable at all to have interface controls over the map? and what is causing the other 15%? In one of my games, I have had over 15 controls over the map, including bars, labels, and semi-transparent windows. I've never had any problem like the one described in this thread. | |
Zaole wrote:
yeah, and reducing the size of the map in the interface (for the purpose of keeping the interface controls from being on the map) reduced the size of the CPU spikes to ~15% Limiting the map area such controls cover would be ideal. For some cases it's probably not an issue because of the way Windows handles clipping, but a control like a bar might care more. For the other 15% I'm just not sure without more information. Kaichao wrote: If you didn't completely remove that window from your skin or completely set all windows to fully opaque, using no transparent color, then your game is still being forced into software mode. Lummox JR | |
Lummox JR wrote:
If you didn't completely remove that window from your skin or completely set all windows to fully opaque, using no transparent color, then your game is still being forced into software mode. it turns out i was mistaken and one of my windows was still using transparency; fixing that has allowed me to keep my interface controls on the map without the CPU issues. Limiting the map area such controls cover would be ideal. For some cases it's probably not an issue because of the way Windows handles clipping, but a control like a bar might care more. indeed; i have quite a few labels and 4 bars over the map, and i still get up to 5 or so CPU usage, but it appears to be static-- it doesn't increase with more mobs moving, so i'm going to be happy with it. thanks for the help guys | |
No, just half of it, preferably the lower half cut along 135 degrees.
Seriously, now. I don't see why not, unless you're afraid someone is going to steal it, but considering that it uses 24-30% CPU I don't see who would.