New Patch 592 - Input/ObjectPool

Dec 18, 2007 at 10:00 PM
I've uploaded a new patch for the Input/ObjectPool, please review.
Dec 18, 2007 at 10:29 PM
But you're the code review master! :)

I'll take a look at it tonight after I merge in the new graphics system to LordIkon's terrain patch.
Dec 19, 2007 at 11:57 AM
An additional thing, if you are looking for the thread safety, it's not implemented yet. it'll be part of my next checkin
Dec 19, 2007 at 5:21 PM
Ill pretend its thread safe in the meantime then :)
Dec 20, 2007 at 1:56 AM
I'm reading a significant garbage footprint from the new messaging system coming from keyboard messages. Holding down movement keys over the course of about 5 seconds generated 27 MB of garbage.
Dec 20, 2007 at 2:42 AM
Auch, I'm going to look into that.
Jan 4, 2008 at 6:47 AM
I've uploaded a patch for this issue (654) can you verify that the issue has been resolved Shaw?
Jan 4, 2008 at 3:57 PM
I'll check it out this evening.
Jan 4, 2008 at 10:15 PM
Looks good! CLRProfiler isn't registered any allocations for it, meaning the memory footprint is very small. Compared, for example, with LordIkon's terrain processing code that spikes around 311 MB of memory usage. ;)

NProf shows the object pool using about 0.23% of the CPU when holding down 3-4 keys per frame at 1100 FPS for 15-20 seconds. Definitely not likely to become a bottleneck anytime soon.

Xbox data to follow shortly, if I can build the project. A note about the Xbox version, if we plan on at least having an Xbox version (unsupported), we can't use any override of Activator.CreateInstance. I had to comment out the Configuration code that uses the override that specifies a type and constructor paramaters:
                BaseManager manager = Activator.CreateInstance(type, new object[] { game }) as BaseManager;
                if (manager == null)
                {
                    throw new Exception(string.Format("Manager type '{0}' was not found", typeName));
                }

On Xbox, only the default Activator.CreateInstance(Type) method exists. Lame, I know, but we can't do anything about it. :(
Jan 4, 2008 at 10:35 PM
I'm going to have to sort out the Xbox problems later. It's just not a priority at the moment, and quite frankly I'm not sure if the problems are in our code or the XNA code. Especially the "vertex/pixel shader must be bound to device" error when rendering the terrain.

By the way, I would like to suggest that not finding the configuration XML file should just log a debug message or something and not throw an exception. I know we don't have a real logging system in place yet, but if I see another Xbox crash, or have the test game crash in the profiler one more time due to not finding the configuration XML file, I think I'm going to go punch something! :)
Jan 4, 2008 at 11:06 PM
The problem is what to do if there isn't a configuration file.

I'm totally alreight with using Console to write any message if this is available on the XBox. I'm planning on using Console for the slash command and "Quake console".
Jan 5, 2008 at 2:19 AM
Writing to System.Console won't do anything on Xbox, I don't think. I would just get some defaults in there, so the game can run without the configuration file. I know it's not a huge deal, but until we get the error logging in place a standard Windows crash dialog isn't very informative.
Coordinator
Jan 5, 2008 at 7:13 AM
Edited Jan 5, 2008 at 7:13 AM
If you guys want a quick and easy logging system I can pull the one from v0.182b, not sure if you've seen it yet, but its pretty simple. If you want to test it, just run 0.182b once, and it'll put the log file your debug/release directory (whichever you're running in). It could be temporary if needed of course.
Jan 5, 2008 at 12:03 PM
Sturm, how will you tie it to the console? I havent done much work with the console, so Ill be interested to see how you code it.
Jan 5, 2008 at 2:04 PM
The Ingame console or the .net console class?
Jan 5, 2008 at 3:32 PM
Right now we just need something simple so get the interface sorted. Once all of our code uses the same error-logging logic, we can worry about how to render that to a file or something on-screen later.
Jan 5, 2008 at 3:41 PM
I went ahead and committed your patch.