It seems that the problem is that certain walls and doors are stuck. In map 26 of Armadosia, when I got the blue key and tried to opened the first blue key door (the one near that key), I could hear it open but it didn't move at all.
That isn't a bug in Dday. The door relies on behaviour ZDoom altered compared to Vanilla Doom, to work.
Well, maybe Doomsday can become more compatible so it works with this wad correctly, or is that not possible anytime soon?
Revisiting the Shotgun Guy dropping multiple Shotguns issue, I haven't encountered it since my last post, even though I've been going through several maps where there are Shotgun Guys (E1M3, E1M7, E2M1, E2M5 are the maps I check on some rotation).
When I have the thinker-ids turned on, how will the numbers look if there are objects that occupy the same exact point, thus overlapping each other? Maybe in some instances when a Shotgun Guy dies, he drops multiple Shotguns (seeing as it can get me from 0 to 50 shells, it would be at least 13 Shotguns), which looks like the case in my E1M3 pic, or killing a Shotgun Guy produces multiple Shotguns and a Shotgun to go with each Shotgun Guy (my E1M7 pic earlier).
If anyone else wants to help produce this, I'd be super glad.
That is precisely why I wanted to see the thinker ids - I can't say what is happening based on my understanding of the code and your description. There are at least two possible situations a) multiple shotgun sprites, one thinker id b) multiple shotgun mobjs, multiple thinker ids.
It seems that the problem is that certain walls and doors are stuck. In map 26 of Armadosia, when I got the blue key and tried to opened the first blue key door (the one near that key), I could hear it open but it didn't move at all.
That isn't a bug in Dday. The door relies on behaviour ZDoom altered compared to Vanilla Doom, to work.
Well, maybe Doomsday can become more compatible so it works with this wad correctly, or is that not possible anytime soon?
I argue that if ZDoom has changed how it interprets the game data in such a way that results in users producing maps that are incompatible with the original game, that it is ZDoom that has the issue. I don't believe we should be adopting the same behaviour simply because that is what ZDoom does. This should be implemented as a "ZDoom quirks" compatibility mode, with appropriate user notifications when enabled.
Request: Is it possible to get the dedicated server to have a name when chatting. Currently it just shows as ":insert message here"
it would be better if it said "Admin:Insert message here"
Request: also allow scrolling up through the dedicated console.
Bug: In Ubuntu when people send chat messages in multiplayer. It does not show on the screen, you have to open the console to be able to see what was said.
The thing is, players don't want one or the other; they are not interested in a version of Doomsday which can play every mod they throw at it, if it cannot also achieve the same level of visual fidelity in the process. I can personally say that this is absolutely my main motivation for working on Doomsday, i.e., finding a way to achieve the best of both.
I am confident that we'll achieve this goal sooner or later, however a complete technology overhaul was necessary before we could really even begin down that road. This is the whole purpose behind the 1.9.x series - to stabilize the foundation so we can move forward and build upon it. We are doing a lot more than simply tweaking a few things
While I'm still trying to produce the Shotgun Guy issue, I also wanted to point out that every time this occured my Shotgun was empty. I have tried walking over Shotguns produced from Shotgun Guys to pick it up (and maximize ammo) and see if there are leftover Shotguns, but I haven't gotten that once yet. So hopefully that can be a starting point.
Latest crash report. I was playing E1M7, going to the Blue Key and it froze.
Problem signature:
Problem Event Name: APPCRASH
Application Name: Doomsday.exe
Application Version: 1.9.7.0
Application Timestamp: 4f44bfcc
Fault Module Name: WINMM.DLL
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7ba42
Exception Code: c0000005
Exception Offset: 0001fdb8
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Heh, yeah, still want to use my AWE32 soundfont, lol (1mgm.sf2).
Then your report is not useful. It's the infamous SDL_mixer bug manifesting on multiprocessor systems. All ports using it are affected. If you absolutely must use SDL_mixer for music, set the doomsday process processor affinity to a single processor.
Even with the latest build, loading upon game start up is no faster than it was since the ringzero merge at #365, despite it almost being considered stable.
almost being stable has nothing to do with how long doomsday takes to start up, that would be more under the term "optimisation" Also it will take longer to start up when you are also loading add-ons.
Well, Dani said it is supposed to load faster than it was before the ringzero merge (currently is slower than before)and the reason it is currently slower is because there are still some fixes that need to be done before the final stable release to make it as fast is it is supposed to be. Even Lightning Hunter said so, though it takes longer for him to load than for myself.
Ok, I tested build 397 just now. Here are the problems:
-The game takes much, much longer to load now than in build 364. The screen stops for quite a while on "starting game". It takes about a full minute or longer to start the game, whereas previously it was about 5 seconds. I'm using all the same addons as I was in the old build.
And Dani's comment to me a while ago on February 9th:
Load performance in general has improved considerably since the ringzero merge. There are however a few known configurations which are presently under performing. These edge cases are currently being addressed.
Is engine start up notably 'pausing' at a specific point, or it is slower all round in the last few builds?
The newest builds do seem to be a bit slower than the old ones at engine startup; pausing for a few seconds on the last segment, where as previously, it would fly through.
Well, I notice that the load circle fills in most of the way, then for about 5 to 10 seconds, one bar of the circle remains unfilled before it finally fills in and the game menu is loaded. The time of loading where all but one bar on the circle is loaded is the point where the loading speed is slowest.
The pauses in loading seem to be to do with the intial opening of various container formats; wad, pk3 etc.
Once it's opened the wad, pk3 etc, it extremely quickly loads the resources from them.
One imagines that Dday is mostly opening wads and pk3 right at the end of the loading (the last segment); this is where all add-ons, such as the JDRP, which contains a load of pk3, is loaded.
Of course, wheter this is something that can be optimized; any program needs to pause to open a container...
There are presently several known performance issues with Doomsday's memory zone implementation. These issues have been around for quite a while and are much older than the ringzero branch. The difference is that the ringzero branch exacerbates the problem due to the fact it does a considerable number of small memory allocations during the startup process. Due to the issues in the zone memory management, this results in an extensively fragmented zone when it comes time to start allocating the larger regions of memory needed for stuff like models. This also happens to be the reason why performance degrades so considerably after extended play.
We are well aware of the issue and skyjake has been working on addressing the problems we've found over the course of this week. These changes will most likely feature in Monday's build.
We are well aware of the issue and skyjake has been working on addressing the problems we've found over the course of this week. These changes will most likely feature in Monday's build.
The memory zone changes made it to today's build 420.
The aforementioned startup-time memory fragmentation was fixed. It was causing Doomsday to allocate excessive amounts of memory because it couldn't find large enough contiguous empty space, so it had to expand the zone. Also, once the zone was expanded, the previously used areas of memory were being badly underutilized.
The real performance issues started when the zone became too full. That would potentially cause each memory allocation (and there are lots of them during map loading) to scan through all the previous allocations, making things very slow indeed. This is no longer happening; allocations will skip past fully utilized areas of the zone. For example, the Whitemare map15 that was previously the cause for some super-long loading times is now loading in quite a reasonable time for a map of its size.
These changes may or may not help you in your particular configurations' performance bottlenecks -- be sure to let us know if something changes in the startup/loading times after switching to build 420+.
I'd say that for me, game searching during engine startup isn't noticibly if at all faster in the new build (420); it's notably quicker at starting the game though, but for me that was pretty much always fast anyway.
There is still a notable pause right at the end, with the add-on loading section though (i.e post font loading) where loading seems to pause for a second or so, even if you aren't loading any add-ons.
I'd say that for me, game searching during engine startup isn't noticibly if at all faster in the new build (420); it's notably quicker at starting the game though, but for me that was pretty much always fast anyway.
The "game search" won't be noticeably quicker no. Its the second phase, the actual game startup which should be noticeably quicker for most configurations.
As skyjake mentioned, gigantic maps such as Deus Vult's MAP05 now take relatively no time at all to load (approx 30 seconds on my system). Considering Doomsday is doing a complete nodebuild, generating a blockmap, etc..., thats not bad IMO.
There is still a notable pause right at the end, with the add-on loading section though (i.e post font loading) where it seems to pause for a second or so, even if you aren't loading any add-ons.
That is most likely caused by the uploading of textures to the GPU.
Usually when uninstalling an older build and then installing a new build, I don't delete the frontend. Is that the correct way to do a complete install? I also notice that saved games are stored in the frontend, but saved games aren't an issue since I can use the warp command and I don't usually use quick save (usually just save at the beginning of each map) and I always use the suicide command at the beginning of each map since it otherwise feels like cheating and makes it too easy.
Edit: And even with memory improvements, I just don't get what is supposed to be different with loading speed. What has become faster? I thought the point was to make game loading time faster, so don't these (what you call) memory improvements defeat the purpose? I just don't get it. Also, maps still take longer to load. It might make maps faster, as long as I keep dynamic lights off, but I'm not sure if the particular map is faster because of the memory fixes or just because of how the map is constructed.
And even with memory improvements, I just don't get what is supposed to be different with loading speed. What has become faster? I thought the point was to make game loading time faster, so don't these (what you call) memory improvements defeat the purpose? I just don't get it.
If you read back a little you'll see posts from both skyjake and myself which detail the issues and how they affected performance.
Also, maps still take longer to load
I don't know which maps you have tested but every one I have personally tried has loaded significantly faster with the new build than previously on my system. In general, maps which used to take several minutes to load are now ready to play in under a minute.
If there is a particular map which you think isn't loading as quick as it should please let us know.
It might make maps faster, as long as I keep dynamic lights off, but I'm not sure if the particular map is faster because of the memory fixes or just because of how the map is constructed.
These memory zone fixes address the gradual performance degradation that would occur after extended play sessions.
Your confusion over the situation and the fact you say you haven't noticed any change, leads me to think there is something peculiar with your configuration that is causing additional slowdown. Also, lets not confuse in-game performance with that of game startup or map loading.
Have you tried disabling add-ons? As has been previously discussed; broken add-ons presently have a significant impact on in-game performance.
I doesn't take that long to load a map (seconds), and even before, I never had a situation where it took minutes to load like you are describing. The first time of loading a map seems slowest (seconds) but faster if I die and do it again (maybe 3 seconds) probably because of it being cached into my physical memory. I also notice that saving is much quicker and perhaps loading is too. Also, I'm playing Armadosia map 28.
But I thought the main issue, besides the performance degradation you brought up, was to make game start up loading faster. You said that was what is being addressed soince it takes longer now than before ringzero.
I'm guessing any slowdown, load time, or other performance issues I have is purely from the fact that D Day is not optimized for modern hardware since I'm confident that my hardware could easily load everything in a game like this instantly otherwise. I do have a Phenom II x4 965 black edition and Radeon HD 6870 after all along with 4GB 1333MHz DDR3 system RAM and Win7 64 Home Premium. So whatever memory or speed problem there is can't have anything to do with physical memory; just D Day can't take advantage of my resources.
Yes, I know the point of 1.9.0 isn't to optimize performance, but you did say that the issues with loading time on start up were being addressed and I thought it would be before the final 1.9.0 release. Maybe I misundestood and it is planned for a later time after 1.9.0.
There are two distinct phases which occur during startup. The first is game resource location (Locating resources...) and the second is game startup (Starting game...). Which part of the process are you saying is slow? (rough times would help, or better yet a copy of your doomsday.out from a run with greater log verbosity)
I'm guessing any slowdown, load time, or other performance issues I have is purely from the fact that D Day is not optimized for modern hardware since I'm confident that my hardware could easily load everything in a game like this instantly otherwise.
You are assuming that all Doomsday is doing is loading data that is otherwise ready to use. This is rather far from the reality of what is going on. The original game(s) store their data in formats wholly unsuited for use in a (relatively) modern engine with hardware accelerated rendering. Pretty much every resource must first be translated into something we can actually use. Depending on the resource this can take more or less time according to what needs to be done.
The original map data for example is little more than a template for what the engine actually needs. We first have to reconstruct the geometry, subdivide the world into structures suitable for rendering, etc...
Similarly, textures cannot be used as-is. These must be converted, possibly resized and then various analyses ran on them to determine the properties we need for lightsourcing, shadowing and more.
You are correct that in-game rendering does not take full advantage of your hardware but that is another issue entirely.
Weird thing about the doomsday.out (I noticed in the command line) is that it says certain defs and pics are missing, though when playing the game, all models and stuff appear just fine. This forum won't let me upload doomsday.out since it doesn't support the extension 'out'. It isn't accepting it as a txt or doc either.
As for whether it loads a little faster at game startup without addons, not much difference, but maybe 2 or 3 seconds difference with the last bar on the circle at the end of the loading process. The last bar in the loading circle stays unfilled for at least 4 seconds no matter what before fully loading.
Edit: Actually, the startup time, which is the 2nd step of loading, seems to be 'at least' a little faster than before. I just realized that when the last bar is unfilled, the writing says 'starting game' but it is very small writing. That part takes about 5 seconds. Yeah, I notice overall speed improvements. Maybe one day it will be optimized to the point to where startup and all other forms of loading are almost instantaneous, including large map loading. Is that possible someday?
Going back to the soundfont issue, I tried to configure Doomsday to use a soundfont using FMOD. I tried converting my soundfont from .sf2 to .dls, and then placed it in my C: drive. I used the command "music-soundfont C:\1mgm.dls", but I only seem to get sound effects and no music from this. I even made sure to make sure Doomsday was configured to use FMOD.
I used Extreme Sample Converter to convert the .sf2 to .dls, but I don't know if it worked properly. Can anyone help me out here? Or should I wait until Doomsday does support .sf2? Would that be a 1.9.8 or later thing at this point?
Yeah, I notice overall speed improvements. Maybe one day it will be optimized to the point to where startup and all other forms of loading are almost instantaneous, including large map loading. Is that possible someday?
This forum won't let me upload doomsday.out since it doesn't support the extension 'out'. It isn't accepting it as a txt or doc either.
I've added .out to the allowed extensions, however, it is not a good idea to be filling up our board attachment quota with log files that are only relevant for a limited period of time. I would urge you to prefer using something like http://pastebin.com/ instead as this is what it is designed for.
Actually, the startup time, which is the 2nd step of loading, seems to be 'at least' a little faster than before. I just realized that when the last bar is unfilled, the writing says 'starting game' but it is very small writing. That part takes about 5 seconds.
And there was me thinking this was a significant issue. 5 seconds is definitely within "tolerable", its not something we are going to lose sleep over.
Yeah, I notice overall speed improvements. Maybe one day it will be optimized to the point to where startup and all other forms of loading are almost instantaneous, including large map loading. Is that possible someday?
We can always improve load performance and we strive to do so. However instantaneous is a tall order indeed.
Comments
Well, maybe Doomsday can become more compatible so it works with this wad correctly, or is that not possible anytime soon?
When I have the thinker-ids turned on, how will the numbers look if there are objects that occupy the same exact point, thus overlapping each other? Maybe in some instances when a Shotgun Guy dies, he drops multiple Shotguns (seeing as it can get me from 0 to 50 shells, it would be at least 13 Shotguns), which looks like the case in my E1M3 pic, or killing a Shotgun Guy produces multiple Shotguns and a Shotgun to go with each Shotgun Guy (my E1M7 pic earlier).
If anyone else wants to help produce this, I'd be super glad.
it would be better if it said "Admin:Insert message here"
Request: also allow scrolling up through the dedicated console.
Bug: In Ubuntu when people send chat messages in multiplayer. It does not show on the screen, you have to open the console to be able to see what was said.
As for the zdoom comment, I thought the main goal of Doomsday was to increase compatibility with wads + improve everything else. See:
http://imageshack.us/photo/my-images/703/heretic.jpg/
http://imageshack.us/photo/my-images/542/hexen.jpg/
Windows 7 x64 sp1
Latest crash report. I was playing E1M7, going to the Blue Key and it froze.
Comment left on February 2nd:
And Dani's comment to me a while ago on February 9th:
The newest builds do seem to be a bit slower than the old ones at engine startup; pausing for a few seconds on the last segment, where as previously, it would fly through.
Once it's opened the wad, pk3 etc, it extremely quickly loads the resources from them.
One imagines that Dday is mostly opening wads and pk3 right at the end of the loading (the last segment); this is where all add-ons, such as the JDRP, which contains a load of pk3, is loaded.
Of course, wheter this is something that can be optimized; any program needs to pause to open a container...
We are well aware of the issue and skyjake has been working on addressing the problems we've found over the course of this week. These changes will most likely feature in Monday's build.
The aforementioned startup-time memory fragmentation was fixed. It was causing Doomsday to allocate excessive amounts of memory because it couldn't find large enough contiguous empty space, so it had to expand the zone. Also, once the zone was expanded, the previously used areas of memory were being badly underutilized.
The real performance issues started when the zone became too full. That would potentially cause each memory allocation (and there are lots of them during map loading) to scan through all the previous allocations, making things very slow indeed. This is no longer happening; allocations will skip past fully utilized areas of the zone. For example, the Whitemare map15 that was previously the cause for some super-long loading times is now loading in quite a reasonable time for a map of its size.
These changes may or may not help you in your particular configurations' performance bottlenecks -- be sure to let us know if something changes in the startup/loading times after switching to build 420+.
There is still a notable pause right at the end, with the add-on loading section though (i.e post font loading) where loading seems to pause for a second or so, even if you aren't loading any add-ons.
As skyjake mentioned, gigantic maps such as Deus Vult's MAP05 now take relatively no time at all to load (approx 30 seconds on my system). Considering Doomsday is doing a complete nodebuild, generating a blockmap, etc..., thats not bad IMO.
That is most likely caused by the uploading of textures to the GPU.
Edit: And even with memory improvements, I just don't get what is supposed to be different with loading speed. What has become faster? I thought the point was to make game loading time faster, so don't these (what you call) memory improvements defeat the purpose? I just don't get it. Also, maps still take longer to load. It might make maps faster, as long as I keep dynamic lights off, but I'm not sure if the particular map is faster because of the memory fixes or just because of how the map is constructed.
I don't know which maps you have tested but every one I have personally tried has loaded significantly faster with the new build than previously on my system. In general, maps which used to take several minutes to load are now ready to play in under a minute.
If there is a particular map which you think isn't loading as quick as it should please let us know.
These memory zone fixes address the gradual performance degradation that would occur after extended play sessions.
Your confusion over the situation and the fact you say you haven't noticed any change, leads me to think there is something peculiar with your configuration that is causing additional slowdown. Also, lets not confuse in-game performance with that of game startup or map loading.
Have you tried disabling add-ons? As has been previously discussed; broken add-ons presently have a significant impact on in-game performance.
But I thought the main issue, besides the performance degradation you brought up, was to make game start up loading faster. You said that was what is being addressed soince it takes longer now than before ringzero.
I'm guessing any slowdown, load time, or other performance issues I have is purely from the fact that D Day is not optimized for modern hardware since I'm confident that my hardware could easily load everything in a game like this instantly otherwise. I do have a Phenom II x4 965 black edition and Radeon HD 6870 after all along with 4GB 1333MHz DDR3 system RAM and Win7 64 Home Premium. So whatever memory or speed problem there is can't have anything to do with physical memory; just D Day can't take advantage of my resources.
Yes, I know the point of 1.9.0 isn't to optimize performance, but you did say that the issues with loading time on start up were being addressed and I thought it would be before the final 1.9.0 release. Maybe I misundestood and it is planned for a later time after 1.9.0.
You are assuming that all Doomsday is doing is loading data that is otherwise ready to use. This is rather far from the reality of what is going on. The original game(s) store their data in formats wholly unsuited for use in a (relatively) modern engine with hardware accelerated rendering. Pretty much every resource must first be translated into something we can actually use. Depending on the resource this can take more or less time according to what needs to be done.
The original map data for example is little more than a template for what the engine actually needs. We first have to reconstruct the geometry, subdivide the world into structures suitable for rendering, etc...
Similarly, textures cannot be used as-is. These must be converted, possibly resized and then various analyses ran on them to determine the properties we need for lightsourcing, shadowing and more.
You are correct that in-game rendering does not take full advantage of your hardware but that is another issue entirely.
As for whether it loads a little faster at game startup without addons, not much difference, but maybe 2 or 3 seconds difference with the last bar on the circle at the end of the loading process.
Edit: Actually, the startup time, which is the 2nd step of loading, seems to be 'at least' a little faster than before. I just realized that when the last bar is unfilled, the writing says 'starting game' but it is very small writing. That part takes about 5 seconds. Yeah, I notice overall speed improvements. Maybe one day it will be optimized to the point to where startup and all other forms of loading are almost instantaneous, including large map loading. Is that possible someday?
I used Extreme Sample Converter to convert the .sf2 to .dls, but I don't know if it worked properly. Can anyone help me out here? Or should I wait until Doomsday does support .sf2? Would that be a 1.9.8 or later thing at this point?
And there was me thinking this was a significant issue. 5 seconds is definitely within "tolerable", its not something we are going to lose sleep over.
We can always improve load performance and we strive to do so. However instantaneous is a tall order indeed.