deadlydog

Members
  • Content count

    446
  • Joined

  • Last visited

Community Reputation

170 Neutral

About deadlydog

  • Rank
    Member
  1. I have posted a response to your question at [url="http://dpsf.freeforums.org/can-t-see-any-smoke-using-dynamic-particle-system-framework-t159.html"]http://dpsf.freeforums.org/can-t-see-any-smoke-using-dynamic-particle-system-framework-t159.html[/url].
  2. Recommended particle engine?

    Check out [url="http://www.xnaparticles.com"]DPSF (Dynamic Particle System Framework)[/url]. It's free, actively maintained, has great help docs and support, tutorials, and is super easy to integrate into any XNA project. Also, it supports both 2D and 3D particles, and works on Windows, Xbox 360, Windows Phone, and the Zune.
  3. Hmmmm, yes, I tried creating a new test XNA 3.1 Game project, and it compiled and serialized fine. So the problem does seem to be specific to my one project. ....aahhhh, I just figured it out. I didn't notice, but in the compiler warning it says it is for the XBox 360 project. I have the compiler set to mixed mode, so it builds both the Windows and XBox 360 copy of the project, and it is only the XBox 360 copy the rejects the serializable attribute. I'm not sure why they wouldn't define the NonSerialized attribute and Formatters namespace for the XBox 360 assemblies, as I'm sure they could be used to transfer data to XBox Live and whatnot, but that was my problem. If I just do a Windows build then everything works perfectly. Thanks.
  4. Hi there, I'm having 2 problems trying to get serialization working in C#, both of which are compile time errors: 1 - The first problem I'm having is I'm trying to make my C# class serializable. I have put the [Serializable] attribute in front of my public class declarations, and in front of all the classes/enumerations defined within them. If I do this alone, everything compiles fine. However, I store a handle to an XNA graphics device which I do not want serialized, so I have put the [NonSerialized] attribute in front of it, but when I compile it says "The type or namespace name 'NonSerialized' could not be found (are you missing a using directive or an assembly reference?)" and "The type or namespace name 'NonSerializedAttribute' could not be found (are you missing a using directive or an assembly reference?)". I have tried using [NonSerialized], [NonSerialized()], and [NonSerializedAttribute], but they all give me the same error. Here is a sample code snippet: using System; using System.Collections.Generic; using System.Diagnostics; // Used for Conditional Attributes using Microsoft.Xna.Framework; using Microsoft.Xna.Framework.Graphics; using Microsoft.Xna.Framework.Content; using System.IO; using System.Runtime.Serialization; namespace MyNamespace { ... [Serializable] public class MyClass : MyInterface { ... [NonSerialized] private GraphicsDevice mcGraphicsDevice = null; // Handle to the Graphics Device to draw to ... } } I have also included the System.Runtime.Serialization and System.Runtime.Serialization.Formatters.SOAP .dlls in my project, but it does not seem to make any difference. Also, I'm not sure if it makes a difference or not, but I'm compiling this project into a .dll, not an executable. 2 - My second problem is that when I try to test out serializing and deserializing, the compiler complains that it cannot find the System.Runtime.Serialization.Formatters namespace, it just gives me the error "The type or namespace name 'Formatters' does not exist in the namespace 'System.Runtime.Serialization' (are you missing an assembly reference?)". I get this error whether I try and include System.Runtime.Serialization.Formatters.SOAP or .Binary in the using statements at the top of the file, or if I declare the full namespace path when declaring my variables. Again, I have included the System.Runtime.Serialization and System.Runtime.Serialization.Formatters.SOAP .dlls in my project but it doesn't seems to make a difference. Here's a sample code snippet of this problem: using System; using System.Collections.Generic; using System.Linq; using Microsoft.Xna.Framework; using Microsoft.Xna.Framework.Audio; using Microsoft.Xna.Framework.Content; using Microsoft.Xna.Framework.GamerServices; using Microsoft.Xna.Framework.Graphics; using Microsoft.Xna.Framework.Input; using Microsoft.Xna.Framework.Media; using Microsoft.Xna.Framework.Net; using Microsoft.Xna.Framework.Storage; using DPSF; using DPSF.ParticleSystems; using System.IO; using System.Runtime.Serialization; //using System.Runtime.Serialization.Formatters; //using System.Runtime.Serialization.Formatters.Binary; //using System.Runtime.Serialization.Formatters.Soap; namespace TestNamespace { public class Game1 : Microsoft.Xna.Framework.Game { ... protected override void Initialize() { // TODO: Add your initialization logic here mcParticleSystem = new DefaultPointSpriteParticleSystemTemplate(null); mcParticleSystem.AutoInitialize(this.GraphicsDevice, this.Content); base.Initialize(); Stream stream = File.Open("ExplosionFlash.dat", FileMode.Create); System.Runtime.Serialization.Formatters.Binary.BinaryFormatter bformatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); bformatter.Serialize(stream, mcParticleSystem); stream.Close(); mcParticleSystem = null; stream = File.Open("ExplosionFlash.dat", FileMode.Open); bformatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter(); mcParticleSystem = (DefaultPointSpriteParticleSystemTemplate)bformatter.Deserialize(stream); stream.Close(); } } } Any help or suggestions would be greatly appreciated. Thanks in advance. [Edited by - deadlydog on March 7, 2010 3:32:53 PM]
  5. I know this topic is pretty old, but if you're looking for a particle system framework to use instead of creating your own, check out DPSF (Dynamic Particle System Framework) at http://dpsf.danskingdom.com. It's for creating particle systems in C# and XNA.
  6. XNA Redistribution / Packaging

    If you want to put the game on your laptop (not the source code), then you can package your game into a self-installing package that will also install the XNA redistributables if required. To do this, from Visual Studio go into the Build menu and select Publish [application name]. This will create a folder, an .applicationdata file, and a .exe file in the destination you specify. Just zip those up, copy them to your laptop, and then run the .exe file and it will install your game for you. Not sure about your question 2. I haven't heard anything before about being able to run XNA apps on the web. You might have more luck posting your XNA questions on the XNA Creators Club Forums.
  7. Quote:Original post by Adam_42 Quote:So as the particle system simulation runs you can notice that particles suddenly jump to the front of the array and are drawn on top of other particles. The standard way of making particles look right regardless of rendering order is to use additive blending instead of standard alpha blending. How well this works depends on what the particles look like. It's best for bright particles on a dark background. If you don't do that you probably need to depth sort, because when the camera moves round the particle system it will usually make the draw order look wrong. Yeah, I'm designing a general purpose particle system framework so I would like it to be able to display both alpha-blended and non-alpha-blended particles correctly. Turning on depth sorting (i.e. RenderState.DepthBufferWriteEnable = true) fixes the problem for opaque particles, but introduces a new problem for semi-transparent ones; the world is shown through the transparent part of the particles, instead of showing the other particles behind it. See a screenshot of the problem here. And this is what it should look like (depth sorting disabled) (still has original problem of particles being suddenly drawn overtop of other particles though). I don't think this problem is related to my issue of the particles being moved around in the array and hence being drawn in a different order (since we have depth sorting enabled here), but I'm not sure what is going on. I'm hoping it's something simple like an additional renderstate property needs to be set or something. If anybody has any ideas why this is happening or how to fix it I would appreciate any suggestions. Thanks [quote]Original post by Antheus Quote: Quote: Original post by deadlydog Can anyone think of a simple solution to this problem? For rendering optimizations, read this. Thanks for the tips. nice article. [Edited by - deadlydog on May 7, 2009 10:28:29 AM]
  8. Quote:Original post by deadlydog But now that I've implemented method 4 it seems to be the all around winner, winning with both static and random lifetimes for all active particle amounts almost every time. Number 4 is definitely wins when it comes to performance, but after actually implementing it in a real particle system I've realized one thing that I overlooked with this approach. When a particle dies it gets moved to the end of the list and the position in the array where that particle was gets replaced with the last active particle in the list, and the total number of Active particles is decremented. When the particles are copied into the vertex buffer, I loop over all of the active particles, starting from the end of the Active Particles section of the array to the start of the array (newest particles are drawn first so that older particles are drawn over top of them). Also, most particle systems have the RenderState.DepthWriteEnabled set to false to avoid sorting thousands of particles by depth, saving on execution time and increasing performance. The problem is that since depth sorting is not enabled, the particles are drawn in the order that they appear in the vertex buffer. So when a particle dies it's position in the array is replaced by the newest particle added to the particle system (since new particles are added to the end of the Active particles list). When this happens that new particle which used to be behind most of the other particles is suddenly drawn on top of all of the particles, since its position in the array moved from the end to (possibly) near the start of the array. So as the particle system simulation runs you can notice that particles suddenly jump to the front of the array and are drawn on top of other particles. Can anyone think of a simple solution to this problem? One approach would be to resort the active particles based on age after each update. However this would kill performance and I would be better off just using approach number 8, which gave the 2nd best average performance. Any ideas on how to solve this problem easily would be appreciated. If I can't find any I will likely end up sticking with approach number 8. Thanks.
  9. Quote:Original post by KulSeran Have an array of MAX particles. When you need a particle grab par_array[count]. Increment count. When a particle dies decrement count, swap the particle with par_array[count]. Update only count particles. Yup, I actually just implemented this method last night and it seems to give the best performance all around on average, for both static and random lifetimes. In total I implemented 8 different methods. 1 - Active Linked List with no pre-allocated memory. Just add particles to the linked list when they are needed, and delete them when they die. 2 - Array with linear search for inactive particles. Process entire array. 3 - Array with circular search for inactive particles. Process entire array. 4 - Array with swapping dead particles to the end of the active particles (method mentioned by KulSeran). Process only active particles. 5 - Array with an inactive queue to hold the inactive particle indexes. Process entire array. 6 - Array with an inactive queue and active list. Process only active particles. 7 - active LinkedList and inactive LinkedList holding the particle instances (no array, but memory is still pre-allocated since the linked list nodes are never "deleted", they are just moved back and forth between the linked lists). Process only active particles. 8 - Array with an active LinkedList and inactive LinkedList, where the linked lists hold pointers to the particles in the array. Process only active particles. Before implementing method 4 last night, method 8 performed best with static lifetimes (but not very well with random lifetimes), method 1 with random lifetimes, and method 5 for both static and random lifetimes (but only when the number of active particles = the number of particles allocated in memory). Approach 1 was the best happy medium, however, like it was mentioned since my program isn't allocating / deallocating memory for other application resources at run-time, as would happen in a real application, this methods memory was staying sequential, where in a real application it would likely become fragmented and not perform as well. But now that I've implemented method 4 it seems to be the all around winner, winning with both static and random lifetimes for all active particle amounts almost every time. Quote:Original post by raigan I might be really confused, but in C# don't structs become read-only when you store them in an array/list? For instance the following code doesn't actually do anything to the ith particle: particles[i].x = 20; The value of particles[i].x will remain unchanged, because indexing into a list of structs returns the value and not a reference to the object that's in the list. Yup, you're right; which is why I use a Particle class, not a struct. If you used a struct you would need to do something like: Particle sTempParticleStruct = particles[i]; // Copy values into a new struct sTempParticleStruct.x = 20; // Update values particles[i] = sTempParticleStruct; // Replace old particle with updated one
  10. Quote:Original post by Antheus The reason for your results sounds like you're using classes, in which case there would be no difference Yes, my Particle objects are classes, not structs
  11. I'm doing some performance tests on different particle system memory management techniques in C#. I've created a particle simulation (no rendering though) to see how many times each different approach is able to update all of the particles. Three of the approaches I'm using are: 1 - Use a linked list to hold the active particles. When a new particle is required I create a new instance of the Particle class (allocates memory at run-time) and add it to the linked list. When a particle dies remove the particle from the linked list (de-allocated from memory). To update the active particles just update all of the particles in the linked list. 2 - Create a pool of particles in memory using an array of Particle instances and store the inactive particle indexes in an inactive queue. When a new particle is needed grab the next index from the inactive queue, and when it dies return it to the inactive queue. When updating particles loop through the entire particle pool array and update the active particles. 3 - Create a pool of particles in memory using an array of Particle instances and use both an inactive queue and active particle list. When a new particle is needed grab the next index from the inactive queue and add it to the active list, and when it dies remove it from the active list and return it to the inactive queue. To update the active particles just update all of the particles in the active particle list. I test the approaches both with static particle lifetimes (all particles have the same lifetime) and with random lifetimes. I do two tests, the first where 10,000 particles are allocated in memory (for approach 2 and 3) and I test with 10, 100, 1000, 5000, and 10000 active particles. For the second test I allocate 100,000 particles in memory, and test with 10, 100, 1000, 5000, 10000, 50000, and 100000 active particles. Also, I run these tests 5 times and then take the average of the results. I implemented approach #1 just as a simple baseline for comparison (100%). I thought it would be the slowest since it allocates and de-allocates memory at run-time, which I've always heard is expensive and a no-no in particle systems. However, it turns out that this approach gives the best results in the average case (static and random lifetimes, and when some particles are active, and many particles are active). Approach #2, which seems to be the most popular from the particle systems I've downloaded, gives the best performance (~150%) when all of the allocated particles are active, but gives the worst performance when less than half of the particles are active (10% - 50%). Approach #3, which I thought would be the fastest, gives about 90% - 100% performance on average using static particle lifetimes, but around 60% - 70% using random particle lifetimes. So if you know how many particles your effect will require (and allocate only that much memory), and that number remains constant through out the entire effect (which is not always the case), then approach #2 is the best. However, approach #1 seems to give the best performance in the average case. I tested this with a small Particle class (6 floats and 5 ints) and with a large particle class (36 floats and 5 ints), but it did not make much of a difference. So is there something I am missing here? How come approach #1 isn't horribly slow like most people say it should be? My only guess is that it's because I'm using C# and it must be handling the memory management like a champ hehe. Any thoughts?
  12. What is a casual game

    To me a casual game should be one that players don't have to commit to for long periods of time. Players should be able to pick it up and play for only 5 or 10 minutes if they want, and have their progress saved. So if your game requires users to play for half an hour or an hour before reaching the next "save" point, I wouldn't consider it a casual game.
  13. GDI + XNA

    Do you just want to draw text to the screen, or are you trying to draw text onto a texture wrapped around a 3D object? If you are just trying to draw text to the screen it is pretty easy in XNA,and there are lots of tutorials. Basically you will create a new SpriteFont and draw it using a SpriteBatch. Here is the MSDN tutorial of how to do it. http://msdn.microsoft.com/en-us/library/bb447673.aspx
  14. calculating Framesper seconds

    If you want you can use fraps to display the frames per second of your game. Just open up fraps and then run your game and it will display the FPS in your game screen.
  15. Why choose; Why not offer both of them. Just have a boolean/enumeration indicating what should happen when the last frame is reached (i.e. wrap, reverse, etc.). The more flexible your classes are the better in my opinion. I like your second suggestion as well. I can't believe I never thought to include that in my animation class :)