[Danukem]

Forge, are you mapping with models and hires textures? I know that Sobek is. None of the other mappers I know of (WG, and the AMC gang) are having problems like you guys, but then again those mappers are all using only 8-bit resources.

[TerminX]

How much RAM do you guys have? I guess the unlimited undo/redo could cause this on systems with very little RAM, but I only have 2 gigs and I never had any problems with memory usage or program speed while developing and testing the feature. That's why it has no limit...

As for fullscreen... eh, I dunno, I have half a mind to remove fullscreen from the UI entirely and leave it up to end users to enable it via the .cfg and deal with whatever strange problems show up due to its use on different system configurations, at least until an OpenGL based 2D mode is available. I think the constant mode switching when changing from 2D to 3D mode in fullscreen is horrible and recommend everyone use windowed mode instead. It just works better.

[Sobek]

 TX, on Oct 29 2009, 05:05 PM, said:

How much RAM do you guys have? I guess the unlimited undo/redo could cause this on systems with very little RAM, but I only have 2 gigs and I never had any problems with memory usage or program speed while developing and testing the feature. That's why it has no limit...

The system I map on here has 1gb of ram. I get the same results on my PC at home, which has 2gb of ram. Would that undo/redo code cause the problem even if I didn't use it? Because recently I've just been adding polymer lights and it still happens.

 TX, on Oct 29 2009, 05:05 PM, said:

As for fullscreen... eh, I dunno, I have half a mind to remove fullscreen from the UI entirely and leave it up to end users to enable it via the .cfg and deal with whatever strange problems show up due to its use on different system configurations, at least until an OpenGL based 2D mode is available. I think the constant mode switching when changing from 2D to 3D mode in fullscreen is horrible and recommend everyone use windowed mode instead. It just works better.

The only reason I want to use fullscreen 2d/3d is because Mapster operates smoother that way. 3d mode not so much, but 2d mode for sure. In windowed 2d mode, the mouse has a noticeable 'chop' while in motion, while conversely it is perfectly smooth in fullscreen. I'm not sure why this is, but it's something I've always noticed (even with other games). I'm sure there's a technical reason for that, I just don't know what it is.

But otherwise I do agree that swapping between 2d and 3d modes for mapster is a bit... harsh.

*edit* That choppy feeling I mention isn't anywhere near as obvious on an LCD. Just figured I'd state that in case anyone looks for evidence of what while using one and doesn't really notice it. The effect is reduced, but still apparent.

[Forge]

 DeeperThought, on Oct 29 2009, 12:10 AM, said:

Forge, are you mapping with models and hires textures? I know that Sobek is. None of the other mappers I know of (WG, and the AMC gang) are having problems like you guys, but then again those mappers are all using only 8-bit resources.

Mapping in 32 bit. No models, no HRP. I didn't have this problem with the pre-polymer release snapshot, but I think I like the extra zoom in too much to switch back.

 TX, on Oct 29 2009, 12:35 AM, said:

How much RAM do you guys have? I guess the unlimited undo/redo could cause this on systems with very little RAM, but I only have 2 gigs and I never had any problems with memory usage or program speed while developing and testing the feature. That's why it has no limit...

As for fullscreen... eh, I dunno, I have half a mind to remove fullscreen from the UI entirely and leave it up to end users to enable it via the .cfg and deal with whatever strange problems show up due to its use on different system configurations, at least until an OpenGL based 2D mode is available. I think the constant mode switching when changing from 2D to 3D mode in fullscreen is horrible and recommend everyone use windowed mode instead. It just works better.

I have 4 gigs ram. I'll try mapping in windowed mode and see if I still have the same problems. Is there a setting in the cfg to adjust the size of the windowed box? Mapster is kinda small on my screen in that mode.

Windows XP 64bit
2.0 dual core
4 gig ram
Nvidia Geforce 7100

[Mark]

Mapster shuts down for me also after running a while when I switch from 2d to 3d or 3d to 2d. I do not use the T test mode or undo command( I forgot it was there). I do use HRP and models. I run Vista and 4gigs ram. It shuts down less when I use a windowed resolution but it still randomly shuts down. I've just been living with it.

[Sobek]

Mind if I ask what this 'T Test Mode' is?

[Forge]

(T) Test is part of the menu when you hit "esc". It replaces ctrl + p.

Ran mapster in windowed mode with pretty much the same results. I also had the task manager up and to the side so I could see what was going on. The ram load never changed, stayed around 24 mb, but the cpu load shot up to 94% and fluctuated between the low 90s to the mid 40s.
The freezing was less dramatic in windowed mode, but it still did it. I don't mind windowed mode, but that sector/wall info box in the bottom left has got to go because it takes up too much screen. I just need to figure out how to get rid of it.

[Mark]

GADZOOKS. I just ran task manager along side mapster in I think it was 1280x960 windowed mode, and in mapster 2d mode cpu usage started at 50 percent. I switched to 3d mode and usage jumped to solid 100 percent. Going back to 2d mode it stayed around 90 percent. Are others out here getting such high numbers?

[Spiker]

Yes, we do:(

[Mark]

With the 100 percent usage maybe my Mapster shutdown problem is just heat related and not much anyone else can do.

[TerminX]

100% CPU usage is to be expected from a game... and from the engine's standpoint, Mapster32 is no different than any other BUILD game: you probably want as high of a framerate as possible, and that requires using all the CPU time to redraw everything as fast as it can, especially since 2D mode is CPU-bound software rendering. Newer versions might be a little slower since now it has to draw to that area that was previously covered by that ginormous status bar in previous versions, and because the status display that's there now has to be redrawn every frame, but the difference shouldn't be too great. I guess I could throw in a frame limiter or something for 2D mode.

[Mark]

I did a little research after my previous post and found out that my duo core CPU running at 50-52C temps should not be causing any shutdown problems. When messing with Mapster I save often,so when it occasionaly shuts down I can deal with it.

[Forge]

TX, on Oct 30 2009, 05:01 PM, said:

100% CPU usage is to be expected from a game... and from the engine's standpoint, Mapster32 is no different than any other BUILD game: you probably want as high of a framerate as possible, and that requires using all the CPU time to redraw everything as fast as it can, especially since 2D mode is CPU-bound software rendering. Newer versions might be a little slower since now it has to draw to that area that was previously covered by that ginormous status bar in previous versions, and because the status display that's there now has to be redrawn every frame, but the difference shouldn't be too great. I guess I could throw in a frame limiter or something for 2D mode.

I never had any problems with the snapshots prior to the polymost release. I'm using mapster in the same way, so the main difference between the current one and the previous one is that "status display". I think that's the culprit that's causing the problems.

Personal preference is that it also gets in the way when I'm drawing and moving vertices so it's annoying anyway.

[Helixhorned]

Forge, on Oct 29 2009, 02:34 PM, said:

Is there a setting in the cfg to adjust the size of the windowed box? Mapster is kinda small on my screen in that mode.

Yes, at the top of mapster32.cfg, or "vidmode xres yres" at the console.

Marked, on Oct 30 2009, 01:21 AM, said:

GADZOOKS. I just ran task manager along side mapster in I think it was 1280x960 windowed mode, and in mapster 2d mode cpu usage started at 50 percent. I switched to 3d mode and usage jumped to solid 100 percent. Going back to 2d mode it stayed around 90 percent. Are others out here getting such high numbers?

TX, on Oct 31 2009, 01:01 AM, said:

100% CPU usage is to be expected from a game... (...)

The strange thing here is that it appears to be use both cores (since you started out at 50%, I assume that this is one core at the max.). I've also observed this when running under Polymer in Windows. Ideally though, the editor should run at the minimum framerate IMO, i.e. only respond to events.

[Plagman]

Some OpenGL drivers offload their overhead to another thread, which is why you can end up with two cores maxed out running Polymer.

[Mark]

That must be the case with my system. Even before the CPU usage jumps up to 100 percent both processors are already sharing the load. Most areas of the map I'm working on show framerates of 90-220 FPS. But a few areas slow down to 30-40 FPS. If a speed governor were put on Mapster I'd probably complain of the slowdowns and stuttering.

[Forge]

Helixhorned, on Nov 1 2009, 02:56 PM, said:

Yes, at the top of mapster32.cfg, or "vidmode xres yres" at the console.

Basically the same settings that are in the drop down box when mapster first launches. Even manually adding the numbers into the config file won't let me get a resolution over 1064 X 600. Still too small of a windowed box when zooming in close to move vertices and having that sector/wall info pop up box appear over what I'm trying to work with and blocking my view.

So assuming that the previous versions of mapster also used 100% of my CPU (since it's to be expected), why then is this one bogging my system down?

Plagman, on Nov 1 2009, 03:25 PM, said:

Some OpenGL drivers offload their overhead to another thread, which is why you can end up with two cores maxed out running Polymer.

Not using polymer.

Marked, on Nov 1 2009, 04:54 PM, said:

Most areas of the map I'm working on show framerates of 90-220 FPS. But a few areas slow down to 30-40 FPS.

My system bogs even if I'm getting a high frame rate.

Marked, on Nov 1 2009, 04:54 PM, said:

If a speed governor were put on Mapster I'd probably complain of the slowdowns and stuttering.

Me too.

[Sobek]

Mmm, ok, definitely something a bit off with Mapster. Originally I didn't think it was using up too much memory, but I just had task manager open in parallel (for other reasons) and noticed that it started out using about 90mb of ram and perhaps 50 or 60% CPU usage (constant) while I fooled around in 3d mode. I switched to 2d mode, then back to 3d mode just ONCE, and suddenly it was a constant 99% CPU usage, with a constantly increasing RAM usage. It jumped to 250mb used as soon as I returned to 3d mode, so I just let myself sit there, not looking around, not doing anything at all... It reached about 700mb RAM usage inside of a minute (with me doing NOTHING) and proceeded to start thrashing my hdd and bringing everything to a halt. Task Manager even stopped responding to the point where it took a minute to acknowledge my click & 'redraw' the task manager window. Mapster didn't crash, but it took me forever just to kill it.

Had to restart to get everything running smooth enough just to use a damn web browser. And it's not like this system is in shit shape either... It may only have 1gb of ram & a 160gb hdd, but I maintain it as good as new, same as all my systems.

[Stabs]

are you running rendermode 4, because it just runs like shit
switching 2d to 3d takes alot longer and its more prone to crashing

my biggest problem at the moment is when i use shift + numpad to move a texture it has a high chance of crashing with some c+ 2008 error BS, rendermode 3 & 4 but rendermode 3 will last alot longer than r4 when resizing

so annoying, i have to save like crazy when texturing.

[Forge]

DanM, on Nov 2 2009, 08:10 PM, said:

are you running rendermode 4, because it just runs like shit
switching 2d to 3d takes alot longer and its more prone to crashing

my biggest problem at the moment is when i use shift + numpad to move a texture it has a high chance of crashing with some c+ 2008 error BS, rendermode 3 & 4 but rendermode 3 will last alot longer than r4 when resizing

so annoying, i have to save like crazy when texturing.

I've always used rendermode 3. I move my textures with my mouse and align them with "." and that hasn't really given me too many problems. But I do get some serious bogging when I use my keypad + or - to adjust my shading, or when I copy a wall texture with the tab key and start pasting it to new walls.

Funny thing is, I can switch to 3d mode and cruise back and forth in the map all day long with no problems, but once I start adding or removing things (in 2d or 3d), that's when I start encountering lag.

[Sobek]

I normally run rendermode 4 (sometimes with or without the lighting preview, it depends on what I'm doing). But for what I just posted above, I was strictly running rendermode 3 the whole time, so no Polymer at all.

[Stabs]

hnmmm iam starting to think it might be something to do with it making a buggy backup.map, i usually use backup.map to get back from a crash but sometimes when i use that map all it does is produce a crash.

maybe something to do with undo?

that mapster tex shift with mouse is nice, i can see that being very useful

[Forge]

DanM, on Nov 3 2009, 01:57 AM, said:

hnmmm iam starting to think it might be something to do with it making a buggy backup.map, i usually use backup.map to get back from a crash but sometimes when i use that map all it does is produce a crash.

maybe something to do with undo?

I make a habit of saving my map as soon as I open it in mapster as "mapname_backup.map". That way if mapster crashes or corrupts the map, I may lose some work, but it's not so devastating that I can't recover. I've found that the backup.map and autosave.map may get corrupt if a mapster crash is caused by the main map getting corrupt. Sometimes the "map_crash.map" in the hard drive's topmost directory is saveable, but I wouldn't depend on it.


As far as mapster crashes and lags, I haven't used the undo/redo option once so that shouldn't be causing me any problems. I think it has something to do with how the program uses resources to redraw the screen. I can switch from 2d to 3d and back all day long, I can zoom around the map in 2d or 3d all day long with virtually no problems, but as soon as I add to, take away from, or modify the map in any way then I experience the lag. I finally got a crash the other day when I was pasting wall textures. It didn't just shut down mapster, it rebooted my entire system.

[TerminX]

If your entire system reboots, sorry to say you have a hardware or driver problem. Modern protected memory models completely prevent something like Mapster from overwriting the areas of memory needed to cause a spontaneous reboot, even if it wanted to. Driver problems are usually bluescreens, though... it's really rare for a bad driver to cause a reboot like that (unless you have the BSOD displays disabled in the OS, as they are by default).

If you're still getting reboots like that after making sure BSOD displays are enabled, I would look at the power supply first.

Anyway, as for the lag... yeah, if undo/redo was causing it when you started to modify the map is when you would start seeing the lag. What are your system specs? Does the lag only happen when you make the changes to the map, with everything being fine while you're only looking around? Does the lag get progressively worse as you make more and more changes? The undo/redo feature works by creating an extra copy of specific parts of the map structure in memory every time things are altered. I guess I need to implement a maximum memory usage for the feature but I need more information on the problems first.

[Forge]

TX, on Nov 3 2009, 11:53 AM, said:

If your entire system reboots, sorry to say you have a hardware or driver problem. Modern protected memory models completely prevent something like Mapster from overwriting the areas of memory needed to cause a spontaneous reboot, even if it wanted to. Driver problems are usually bluescreens, though... it's really rare for a bad driver to cause a reboot like that (unless you have the BSOD displays disabled in the OS, as they are by default).

If you're still getting reboots like that after making sure BSOD displays are enabled, I would look at the power supply first.

Anyway, as for the lag... yeah, if undo/redo was causing it when you started to modify the map is when you would start seeing the lag. What are your system specs? Does the lag only happen when you make the changes to the map, with everything being fine while you're only looking around? Does the lag get progressively worse as you make more and more changes? The undo/redo feature works by creating an extra copy of specific parts of the map structure in memory every time things are altered. I guess I need to implement a maximum memory usage for the feature but I need more information on the problems first.

As an afterthought; the reboot only happened once and I was pasting textures when it occurred. Since I was hitting the enter button it's possible that my firewall or antivirus updated and asked for the system to be restarted. The reboot never happened before and hasn't happened since.

System:
2.0 dual core
windows xp 64
4 gig ram
Nvidia geoforce 7100

The lag only happens when I make changes to the map. Everything is fine if I'm only looking around. Switching back and forth between 2d and 3d does not cause lag. The frequency of the lags are directly related to the amount of changes made. The duration of the lags appear to remain within a constant range (5 to 15 seconds).

[Spiker]

I think something is wrong with aiming again! This was fixed by hunter_rus ages ago but now it seems to happen again. Also it would be nice if mapster could render a delicate frame around a currently active sector. This would help a lot! (especially when the aiming is broken).

[Helixhorned]

Which renderer? And what are the symptoms?

[Spiker]

3d mode at default mapster settings. The problem is that when you aim with the cross usually you have to aim much lower that the current sector/sprite to make it active. It is very imprecise

[Sobek]

Spiker, on Nov 28 2009, 10:27 AM, said:

3d mode at default mapster settings. The problem is that when you aim with the cross usually you have to aim much lower that the current sector/sprite to make it active. It is very imprecise

It's been this way for me for a long long time now. I seem to recall it having being brought up in some old thread and someone said it was a known issue, so I assumed a fix was in the works. Guess I just adapted to it since then and 'forgot'.

I also noticed that it's sometimes impossible to target a sprite with your cursor under the Polymer rendering path in Mapster32 (it acts as if there's nothing under your cursor). If you change setrendermode back to 3, you can instantly target the sprite and everything is as it should be.

[TerminX]

The problem is compounded by the fact that each rendering mode has its own method of detecting what you're aiming at. Classic mode is pixel perfect because it's intertwined with the renderer itself so that it knows exactly what object was drawn on a specific pixel.

The selection in Polymer is also somewhat integrated into the renderer and is something Helixhorned came up with that also works very well most of the time. Polymost, however, is where things get iffy, as it uses simple hitscan() functionality to try and determine what is being aimed at.

As you guys have noticed, this is not fantastic, but it's about as good as Polymost is ever going to get. It was a lot worse before Hunter_rus messed with it so at least you have that. Polymer will eventually get a reworking of its selection system to make it work about as well as classic does.