Maidens of the Kaleidoscope
~Hakurei Shrine~ => Rika and Nitori's Garage Experiments => Topic started by: WriggleNightbug on November 17, 2010, 03:48:17 AM
-
So I spent the last week or so quickly scripting a touhou clone in Game Maker trough GML, and even at a main frame-rate of 50 there was still slowdown with the simplest of patterns, it seems that 3D and bullet spam doesn't do it for game maker...
So anyways I found out that game maker is a little slow, and that my clone just won't work to its full potential in game maker...and if I really want to make a good touhou clone I need to look higher, well I think I came to the right place to ask for advice, I need something:
-- something with scripting, I'm willing to learn a new language if I have to
-- something fast ((Bullets, lots of bullets, and effects))
-- something fully customizable ((I don't like danmakufu for big projects because of its permanently built in bits))
-- 3D backgrounds enabled, but 2D for everything else ((like touhou))
and really those are pretty much the things I need, maybe stuff like vertex primitives for certain effects and stuff, sound enabled of course.
-
There are multiple options:
First you can make your own danmaku engine using any programming language (C++, Java, C#, Python, etc.) and a graphic API (DirectX or OpenGL)
Or you can make it using a library/framework like SDL (http://www.libsdl.org/) or XNA Game Studio (http://create.msdn.com/en-us/resources/downloads) (C# only)
Then there are premade engines like Unreal Engine 3 (http://www.udk.com/) and Unity Engine (http://unity3d.com/), but this is probably overkill to make simple danmaku
I personally suggest C#+XNA if you don't mind developing for Windows only (or Xbox 360 / WP7) because it's really easy to learn, it has good documentation and resources, and C#'s syntax is similar to Danmakufu (and every other C-based language)
-
Well, all engines I found so far are not done.(including Danmakufu btw...newest released version: 0.12m...)
Well, there are some other engines that are actually useable, as far as I know and there are lots of people who work on their own one.
This one looks quite neat and (mostly) finished to me, but I never tried it:
http://www.shrinemaiden.org/forum/index.php/topic,6623.0.html
Some other unfinished ones are "Musuu no Danmaku" by Nuclear Cheese and something called "Danmagine" by Mjonir.
You can find the threads here:
1.http://www.shrinemaiden.org/forum/index.php/topic,2129.0.html
2.http://www.shrinemaiden.org/forum/index.php/topic,6089.0.html
Also there is one Blargel and his brother were working on, but it looks pretty much abandonned to me:
http://www.shrinemaiden.org/forum/index.php/topic,3367.0.html
Also I heard about one made in flash and one made with .NET-Framework and even homebrew-engines for Nintendo DS and Wii(!)...just look for them on the board...
I can't tell if you will like one of these, I actually never tried them out, but I agree with your opinion about Danmakufu. It is hard to make a REAL game with it, because you are never independent from the engine.(But that is probably the case in most of these engines...except maybe Danmaku Time...at least it says different things)
Well, if you really want to create your very own game and if you really want to make it independent and in one piece without having trouble with Applocal or something else, you should consider making it from scratch. Obviously that is freaking hard!(I couldn't do it...)
I'm just listing things you could look at, because I think you know what you want ;3
-
There are multiple options:
First you can make your own danmaku engine using any programming language (C++, Java, C#, Python, etc.) and a graphic API (DirectX or OpenGL)
Or you can make it using a library/framework like SDL (http://www.libsdl.org/) or XNA Game Studio (http://create.msdn.com/en-us/resources/downloads) (C# only)
Then there are premade engines like Unreal Engine 3 (http://www.udk.com/) and Unity Engine (http://unity3d.com/), but this is probably overkill to make simple danmaku
I personally suggest C#+XNA if you don't mind developing for Windows only (or Xbox 360 / WP7) because it's really easy to learn, it has good documentation and resources, and C#'s syntax is similar to Danmakufu (and every other C-based language)
Writes like Danmakufu...I'm pretty interested! As I've already made quite a bit of stuff with Danmakufu before, I'l look into setting it up tonight, is it hard to set up by any chance?
-
By "similar syntax" I mean it uses the
keyword morestuff(para, meters)
{
stuff();
that();
should();
happen = true;
}syntax that you find in every C-based language (C++, Java, C#, JavaScript, Danmakufu script, etc) so it should be easy to understand if you were fine with Danmakufu. However, C# is not "written like danmakufu code".
C#+XNA is not that hard to setup, but it requires a lot of download. (.NET framework 4.0, Visual C# 2010 Express, XNA Game Studio, etc.).
And I advise you don't go making games as soon as you get it. Learn the language before attempting a large project. Once you'll get to XNA, start by small programs that read input, draw textures, play sounds and music, etc. before making a game. And make 2D games before getting into 3D. You can get pretty far into a danmaku engine without ever playing with things other than a SpriteBatch for drawing in XNA.
-
Just thought I'd share my two cents here.
C# is a general purpose programming language, over a specialized one such as Danmakufu. It doesn't run on an engine (well, the .NET Framework sort-of counts but it's a multipurpose do-everything kind of thing). There is a lot of work in learning C#, since you must first learn how to program in an object-oriented way.
You'll have to manually create a lot of things you take for granted (XNA doesn't even have a basic sprite class; you'll have to write your own, encapsulating texture swapping and all that; and, if you really really want to use C and, to an extent, C++, you're in for a world of pain there).
So, just a heads up -- coding your own engine from scratch is not an easy road, but, once you gain the knowledge, you'll be able to do a lot more than you ever could with Game Maker.
-
Just thought I'd share my two cents here.
C# is a general purpose programming language, over a specialized one such as Danmakufu. It doesn't run on an engine (well, the .NET Framework sort-of counts but it's a multipurpose do-everything kind of thing). There is a lot of work in learning C#, since you must first learn how to program in an object-oriented way.
You'll have to manually create a lot of things you take for granted (XNA doesn't even have a basic sprite class; you'll have to write your own, encapsulating texture swapping and all that; and, if you really really want to use C and, to an extent, C++, you're in for a world of pain there).
So, just a heads up -- coding your own engine from scratch is not an easy road, but, once you gain the knowledge, you'll be able to do a lot more than you ever could with Game Maker.
Well it's worth trying, the harder it is the more you get out of it I suppose. ^^
-
i'm going to have to quote wikipedia because i can't rephrase it any other way: (and i'm very pessimistic)
If it's not 2D oriented, it's that the 3D engine doesn't have features especially made for 2D games ; they could make them but would likely require more work than those oriented that way.
-- something fully customizable ((I don't like danmakufu for big projects because of its permanently built in bits))
fully customizable + someone else's engine isn't such a great idea (Game Maker is fully customizable)
if you think GameMaker is too slow, try the more expensive game rapid prototyping engine: Torque
(3d and 2d versions)
Note i haven't even touched it, but looking at its previews it feels similar to GM. Oh and they say something about it being faster because it's compiled (unlike GM's interpreted language)
Also note if you ever make the jump from using someone's engine to coding your own, it'll take *quite* some time before you can see any *significant* result.
Assuming you don't know both GM and C++:
A (crappily made) game can be done in a day on GM, while the same crappy game will take more than a week on C++
(probably a month even, depending on what you can achieve on GM in the first day)
i dunno how making your own engine was ever introduced to this thread, but i like pointing that out :3
-
(XNA doesn't even have a basic sprite class; you'll have to write your own, encapsulating texture swapping and all that [...])
I think you're mistaking XNA for straight-up DirectX there...
It's possible to achieve pretty good results (http://dl.dropbox.com/u/3185156/STGEngine/Rebirth/pauseMenu.png)* by simply loading Texture2D (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.texture2d.aspx) objects with the default ContentManager (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.content.contentmanager.aspx) and drawing them with the default SpriteBatch (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.spritebatch.aspx) that is placed in every new XNA game project.
The only reason you should mess with vertices is when you want to draw 3D or for special-er effects.
* screenshot of my own danmaku engine made in C#+XNA
-
Since I was mentioned above I thought I'd add a word: My engine called Damagine (http://www.shrinemaiden.org/forum/index.php/topic,6089.0.html) would be what you are looking for (easily scriptable, optimized for danmakus, should have 3D backgrounds in the future and is programmed in the objective of making full games entirely customizable as long as it's a shmup)... but it's unfinished unfortunately. I'm working hard on it, tonight I just finished the first really stable release (no more known bug!) and made conceptual improvements, but I don't think it'll be able to do everything you're asking before a few months (I'm adding new features every day, but it'll take a while before I can provide everything a scripter might want nicely and easily). If you're not in a hurry to make your game you could try it (I'd of course appreciate :p) but otherwise you'll have to find another solution, and perhaps make an engine yourself (you can always come back and have a look at my Danmagine later if you give up :p).
Have a look at other danmaku engine projects of course, I haven't tried them all, but I'm not sure there's a finished project with what you want (and it's even less likely to find a project that's still alive for support if you need it).
So, about making an engine yourself: It looks like you don't know appropriate programming languages yet, if it's the case you'll first have to learn one which can take some time depending on your general knowledge of algorithmic and object-oriented (if you already have some knowledge and experience and learn fast, you could learn the essential in about two weeks). After that however the real work begins. There'll be a lot of work and a lot to learn especially if you haven't made games before. Depending on the complexity of your project, and if you want something single purpose or not, it'll take from a long time to a very long time. Nevertheless, if you feel like you can handle it and you've got enough time to put into it, then go for it. If you keep up, it'll be a lot of fun and you'll learn a lot. If you're in computer-related studies, it'll be a really good thing to do.
I guess it's up to you. It looks like you'll have to chose between being patient or being brave :)
-
I think you're mistaking XNA for straight-up DirectX there...
It's possible to achieve pretty good results (http://dl.dropbox.com/u/3185156/STGEngine/Rebirth/pauseMenu.png)* by simply loading Texture2D (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.texture2d.aspx) objects with the default ContentManager (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.content.contentmanager.aspx) and drawing them with the default SpriteBatch (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.spritebatch.aspx) that is placed in every new XNA game project.
The only reason you should mess with vertices is when you want to draw 3D or for special-er effects.
* screenshot of my own danmaku engine made in C#+XNA
I'm learning the ropes of XNA but one thing that's confusing to me is how I'm supposed to draw all the bullets, as the examples I found tell you to make a limited array for the bullets and draw them if active and such, but let's say you limited yourself to 1000-1500 bullets wouldn't it be strainful on the computer to do a check for all of them every frame? wouldn't it be faster to have each separate bullet class instance draw itself? which Ive been trying to do but it hasn't been working too well X3
-
Since I was mentioned above I thought I'd add a word: My engine called Damagine (http://www.shrinemaiden.org/forum/index.php/topic,6089.0.html) would be what you are looking for (easily scriptable, optimized for danmakus, should have 3D backgrounds in the future and is programmed in the objective of making full games entirely customizable as long as it's a shmup)... but it's unfinished unfortunately. I'm working hard on it, tonight I just finished the first really stable release (no more known bug!) and made conceptual improvements, but I don't think it'll be able to do everything you're asking before a few months (I'm adding new features every day, but it'll take a while before I can provide everything a scripter might want nicely and easily). If you're not in a hurry to make your game you could try it (I'd of course appreciate :p) but otherwise you'll have to find another solution, and perhaps make an engine yourself (you can always come back and have a look at my Danmagine later if you give up :p).
Have a look at other danmaku engine projects of course, I haven't tried them all, but I'm not sure there's a finished project with what you want (and it's even less likely to find a project that's still alive for support if you need it).
So, about making an engine yourself: It looks like you don't know appropriate programming languages yet, if it's the case you'll first have to learn one which can take some time depending on your general knowledge of algorithmic and object-oriented (if you already have some knowledge and experience and learn fast, you could learn the essential in about two weeks). After that however the real work begins. There'll be a lot of work and a lot to learn especially if you haven't made games before. Depending on the complexity of your project, and if you want something single purpose or not, it'll take from a long time to a very long time. Nevertheless, if you feel like you can handle it and you've got enough time to put into it, then go for it. If you keep up, it'll be a lot of fun and you'll learn a lot. If you're in computer-related studies, it'll be a really good thing to do.
I guess it's up to you. It looks like you'll have to chose between being patient or being brave :)
I'll definatly take a look if things get rough ^^ I'm gonna give XNA a chance for now though =3 thanks for the advice. ^^
-
I'm learning the ropes of XNA but one thing that's confusing to me is how I'm supposed to draw all the bullets, as the examples I found tell you to make a limited array for the bullets and draw them if active and such, but let's say you limited yourself to 1000-1500 bullets wouldn't it be strainful on the computer to do a check for all of them every frame? wouldn't it be faster to have each separate bullet class instance draw itself? which Ive been trying to do but it hasn't been working too well X3
Your computer is designed to perform hundreds of thousands, if not millions of floating point operations every second. Unless you're on an Apple ][ or a Commodore 64, your computer will cope just fine (if you really want to, you could make use of the thousands of stream processors on your GPU with CUDA or OpenCL, but that's very extremely completely overkill and, more importantly, hard).
Having a separate bullet drawing itself is more or less the exact same has having the Draw call draw each and every one; it only makes for better semantics and cleaner code. As they both run in the same thread, it doesn't matter where you handle the drawing or updating, but logically separating them into individual classes is good practice.
I think you're mistaking XNA for straight-up DirectX there...
It's possible to achieve pretty good results (http://dl.dropbox.com/u/3185156/STGEngine/Rebirth/pauseMenu.png)* by simply loading Texture2D (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.texture2d.aspx) objects with the default ContentManager (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.content.contentmanager.aspx) and drawing them with the default SpriteBatch (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.spritebatch.aspx) that is placed in every new XNA game project.
The only reason you should mess with vertices is when you want to draw 3D or for special-er effects.
* screenshot of my own danmaku engine made in C#+XNA
No, not at all. A Texture2D is exactly that -- a texture. A sprite implies that positional information and possibly animation is stored with the data structure, and it's not simply an image. Of course, you could write your own simple class to encapsulate all that, but it's just another (albeit small) hurdle.
-
Your computer is designed to perform hundreds of thousands, if not millions of floating point operations every second. Unless you're on an Apple ][ or a Commodore 64, your computer will cope just fine (if you really want to, you could make use of the thousands of stream processors on your GPU with CUDA or OpenCL, but that's very extremely completely overkill and, more importantly, hard).
Having a separate bullet drawing itself is more or less the exact same has having the Draw call draw each and every one; it only makes for better semantics and cleaner code. As they both run in the same thread, it doesn't matter where you handle the drawing or updating, but logically separating them into individual classes is good practice.
No, not at all. A Texture2D is exactly that -- a texture. A sprite implies that positional information and possibly animation is stored with the data structure, and it's not simply an image. Of course, you could write your own simple class to encapsulate all that, but it's just another (albeit small) hurdle.
Well when you put it that way it does make more sense, I'm trying to think of how to arrange it though, when the bullet go off-screen they become inactive, maybe the lowest numbered instance that's inactive becomes the next bullet, then perform a while i < max_bullet_num to draw every bullet that's active or something, don't see a big flaw with this system yet XD
-
Well when you put it that way it does make more sense, I'm trying to think of how to arrange it though, when the bullet go off-screen they become inactive, maybe the lowest numbered instance that's inactive becomes the next bullet, then perform a while i < max_bullet_num to draw every bullet that's active or something, don't see a big flaw with this system yet XD
You could just set any bullets that become inactive to null, then let the garbage collector sweep those away. Of course, you would need to have a reallocation algorithm to ensure that you don't plonk a new bullet over whatever.
Bullet[] bullets = new Bullet[1000];
for(int i = 0; i < bullets.Length; ++i)
{
if(bullets[i] == null)
{
bullets[i] = new Bullet();
break;
}
// unable to allocate bullet
}
Be aware, though, that such an algorithm is O(n), meaning that the time taken to run it increases linearly with collection size. Then again, it's probably more efficient than using a linked list (System.Collections.Generic.LinkedList) which, even though it allocates in O(1) constant time, it takes longer on average to allocate it and is probably less efficient.
I haven't done any benchmarks, though, so don't take my word for it :V
-
Well when you put it that way it does make more sense, I'm trying to think of how to arrange it though, when the bullet go off-screen they become inactive, maybe the lowest numbered instance that's inactive becomes the next bullet, then perform a while i < max_bullet_num to draw every bullet that's active or something, don't see a big flaw with this system yet XD
You can do that, but it depends on the complexity of your bullet. With very simple bullets, it'll be the best thing to do. However in my Danmagine, every object can be very, very complex so I've got to keep a versatile structure. An inactive object has to be re-initialized before it can be used, with complex objects it'd take way too much time. What I do is flag what you call inactive objects as "out", they are ignored and eventually garbage-collected later.
Moreover, by using the recycling method, you're keeping a lot of stuff in memory. If there are objects you won't use again, or if you had a huge number of bullets at one point, you'll keep all of that in memory. Even if memory isn't an issue in itself in modern computers, what will be an issue is that you're probably keeping them in some kind of arrays, and it'll take a long time to treat all of it (because you can have an active object at the end of the array, so you've got to check everything). You might build a workaround and sort your array by swapping inactive elements with active ones at the end of the array, but I think it'd become too complex, and less efficient than simply deleting and re-creating.
It's just a general opinion though, recycling might be more efficient in your specific case, but you've got to keep in mind that even if it looks like a good idea, it might do more harm than good in the end.
-
You can do that, but it depends on the complexity of your bullet. With very simple bullets, it'll be the best thing to do. However in my Danmagine, every object can be very, very complex so I've got to keep a versatile structure. An inactive object has to be re-initialized before it can be used, with complex objects it'd take way too much time. What I do is flag what you call inactive objects as "out", they are ignored and eventually garbage-collected later.
Moreover, by using the recycling method, you're keeping a lot of stuff in memory. If there are objects you won't use again, or if you had a huge number of bullets at one point, you'll keep all of that in memory. Even if memory isn't an issue in itself in modern computers, what will be an issue is that you're probably keeping them in some kind of arrays, and it'll take a long time to treat all of it (because you can have an active object at the end of the array, so you've got to check everything). You might build a workaround and sort your array by swapping inactive elements with active ones at the end of the array, but I think it'd become too complex, and less efficient than simply deleting and re-creating.
It's just a general opinion though, recycling might be more efficient in your specific case, but you've got to keep in mind that even if it looks like a good idea, it might do more harm than good in the end.
So your engine doesn't keep your bullets in an array? How does the engine know what to draw? is there a way for the main game class to access all instances of the bullet class? You said you flagged inactive bullets to use them again later, but wouldn't that require an array to access them?
I ask so many questions when I'm new to something XD
-
Nah, you got it all wrong :p
I keep them in a std::map. The difference is that once an object (bullet, or anything else except the player actually) is dead for any reason, including exiting the playing area (and can't come back to life, there are specific commands if you want un-killable objects, or objects that can come back to life) I flag it as "Out". Technically every entity has a "bool m_out" attribute. If this attribute is true, the object is now completely ignored by the engine and it'll be garbage collected as soon as possible (i.e. it'll be properly deleted elsewhere in the code, preferably in another thread).
As I said earlier, I think than generally speaking, it'll be more efficient than recycling, or at least it is in my case.
-
Nah, you got it all wrong :p
I keep them in a std::map. The difference is that once an object (bullet, or anything else except the player actually) is dead for any reason, including exiting the playing area (and can't come back to life, there are specific commands if you want un-killable objects, or objects that can come back to life) I flag it as "Out". Technically every entity has a "bool m_out" attribute. If this attribute is true, the object is now completely ignored by the engine and it'll be garbage collected as soon as possible (i.e. it'll be properly deleted elsewhere in the code, preferably in another thread).
As I said earlier, I think than generally speaking, it'll be more efficient than recycling, or at least it is in my case.
I don't particularly see how using a map over a fixed-size array would be faster. Since iterating through both is O(n) (though searching is O(log n) for a map, you'd have to search many times over and it would still be more efficient to iterate), and you have the added overhead of dynamically expanding storage per insertion, wouldn't it perform a little worse?
Also, you don't particularly need to worry about explicit garbage collection in C#, since you can just set it to null and the garbage collector with automagically free it from memory -- in effect, that works just as well as having a member named m_out (also, ew, Hungarian notation).
-
I don't particularly see how using a map over a fixed-size array would be faster. Since iterating through both is O(n) (though searching is O(log n) for a map, you'd have to search many times over and it would still be more efficient to iterate), and you have the added overhead of dynamically expanding storage per insertion, wouldn't it perform a little worse?
I'm using a map because I need all objects to be associated with their id as key for improved performance everywhere else where we're not iterating over tables, but accessing specific objects. You can only do transversals for mandatory tests which are drawing, collisions, stuff like that, everything else is done by directly accessing elements, and especially all the scripting of the objects. O(log n) helps a lot in the scripting part of the engine. I think the added overhead is worth it since the danmakus which would really need that kind of performance would also need complex patterns with many bullets, and the shorter search really compensates there :)
Also, you don't particularly need to worry about explicit garbage collection in C#, since you can just set it to null and the garbage collector with automagically free it from memory -- in effect, that works just as well as having a member named m_out (also, ew, Hungarian notation).
As I told you earlier, it is not at all "garbage collection" in the way a programmer would understand in, but in the general meaning :p
I can't just delete my object, I also have to delete it from the collision layers, properly handle its termination in Lua, delete its sprite and then only after that I can erase its instantiation in C++, and outside any transversal of the array. That's what I mean by garbage collection.
-
Using a generic list really is fast enough for bullets EXCEPT if you intend to develop for Xbox360 or WP7.
Since they use the compact version of the .NET framework, their garbage collection takes much more time and it can be enough to lag your game.
A solution I heard is using a fixed length array of bullets (you shouldn't ever get over 5000 bullets onscreen at one time in a real game) and adding an "alive" flag. This way you can cycle through each bullet and only update and draw those with "alive" set to true. To make a new bullet, you'd have to cycle through the array and find the lowest "alive == false", give it a position, and set alive to true for that bullet.
-
I told you earlier, it is not at all "garbage collection" in the way a programmer would understand in, but in the general meaning :p
I can't just delete my object, I also have to delete it from the collision layers, properly handle its termination in Lua, delete its sprite and then only after that I can erase its instantiation in C++, and outside any transversal of the array. That's what I mean by garbage collection.
Yes, I know, but that's what an IDisposable implementation is for in C# :3
-
A solution I heard is using a fixed length array of bullets (you shouldn't ever get over 5000 bullets onscreen at one time in a real game) and adding an "alive" flag. This way you can cycle through each bullet and only update and draw those with "alive" set to true. To make a new bullet, you'd have to cycle through the array and find the lowest "alive == false", give it a position, and set alive to true for that bullet.
It's what we discussed earlier when talking about "recycling" bullets, as I said it'll be more efficient but only if your bullets are not too complex. When I started programming my engine, it was my first idea to recycle objects, but I gave up when I saw that I got to the point where my objects were becoming so complex that'd just be faster to delete and re-create them.
The only case I see where it'd really work well is something that's used very exactly the same way, like player shots, but in damakus in general I think it's a very specific case, and it can always be implemented as such (have some kind of scripting option that tells the engine that this specific type of object will be simple enough and used often enough that'd need to create X basic items and recycle them).
To sum it up, it's something you can do, but I don't think it'd work well as the basis for the whole engine, only as an option.
Yes, I know, but that's what an IDisposable implementation is for in C# :3
Uh, sorry, I don't know any C#, you lost me there :p
-
It's what we discussed earlier when talking about "recycling" bullets, as I said it'll be more efficient but only if your bullets are not too complex. When I started programming my engine, it was my first idea to recycle objects, but I gave up when I saw that I got to the point where my objects were becoming so complex that'd just be faster to delete and re-create them.
The only case I see where it'd really work well is something that's used very exactly the same way, like player shots, but in damakus in general I think it's a very specific case, and it can always be implemented as such (have some kind of scripting option that tells the engine that this specific type of object will be simple enough and used often enough that'd need to create X basic items and recycle them).
To sum it up, it's something you can do, but I don't think it'd work well as the basis for the whole engine, only as an option.
Uh, sorry, I don't know any C#, you lost me there :p
Well I like the idea of flat out deleting them and creating new ones, which is what I wanted to do but when I tried to get other classes to draw themselves it didn't work, the only way I thought of making it work was to make a set array, but then is there a way to scroll trough all the instance of the class Bullet and draw them in the main Draw method? there doesn't seem to be a "Draw all instances of class" option somewhere, but being new I wouldn't know about all the methods just yet...
-
Well I like the idea of flat out deleting them and creating new ones, which is what I wanted to do but when I tried to get other classes to draw themselves it didn't work, the only way I thought of making it work was to make a set array, but then is there a way to scroll trough all the instance of the class Bullet and draw them in the main Draw method? there doesn't seem to be a "Draw all instances of class" option somewhere, but being new I wouldn't know about all the methods just yet...
I'll be lazy and just copy some code:
for (map<unsigned int, Object*>::iterator it = begin(); it != end(); it++)
{
if (it->second->is_alive() && !it->second->getNoImg())
{
m_sprite_manager.position(it->second->getSprite(),it->second->getCoord(true),it->second->getSpriteId());
m_sprite_manager.display(it->second->getSprite(),it->second->getSpriteId());
}
}
Oh, and if you wanted to control the different types of objects individually, which I did before so here is an old code of mine:
for (Object_table::iterator it = begin(); it != end(); it++)
{
for (Object_items::iterator item = --it->second.items.end(); item != it->second.items.begin(); item--)
{
if (item->second->is_alive())
{
m_sprite_manager.position(item->second->getSprite(),item->second->getCoord(alpha),item->second->getSpriteId());
m_sprite_manager.display(item->second->getSprite(),item->second->getSpriteId());
}
}
}
-
I'll be lazy and just copy some code:
for (map<unsigned int, Object*>::iterator it = begin(); it != end(); it++)
{
if (it->second->is_alive() && !it->second->getNoImg())
{
m_sprite_manager.position(it->second->getSprite(),it->second->getCoord(true),it->second->getSpriteId());
m_sprite_manager.display(it->second->getSprite(),it->second->getSpriteId());
}
}
Oh, and if you wanted to control the different types of objects individually, which I did before so here is an old code of mine:
for (Object_table::iterator it = begin(); it != end(); it++)
{
for (Object_items::iterator item = --it->second.items.end(); item != it->second.items.begin(); item--)
{
if (item->second->is_alive())
{
m_sprite_manager.position(item->second->getSprite(),item->second->getCoord(alpha),item->second->getSpriteId());
m_sprite_manager.display(item->second->getSprite(),item->second->getSpriteId());
}
}
}
Here's a C# simplification, with more C#-ish code, for your benefit:
foreach(var pair in bullets)
{
// you probably don't need accessors like Mjonir has done, since C# supports properties
if(pair.Value.Alive && pair.Value.Image != null)
{
// likewise, you probably won't need getter calls here
_spriteManager.Position(pair.Value.Sprite, pair.Value.Position, pair.Value.Sprite.Id);
_spriteManager.Display(pair.Value.Sprite, pair.Value.Sprite.Id); // ditto
}
}
As for IDisposable, it's more or less the same as C++'s destructor (~Bullet), which frees any resources when it's collected by the garbage collector. Why write your own garbage collector when you already have one? :3
Moving sideways a little, you should know that in C# you are responsible for managing your objects. Objects don't automatically attach themselves to a big database of objects which you can just call Draw on. You have to manage them in an array of objects, as you've mentioned earlier, and draw them individually.
-
As for IDisposable, it's more or less the same as C++'s destructor (~Bullet), which frees any resources when it's collected by the garbage collector. Why write your own garbage collector when you already have one? :3
That's because in my object destructor, I'd need to access Lua, the sprite manager... and the object manager itself. I can do this with 3 calls to singletons, but it's a bit counter-productive, looks dirty and mostly it'd create more intricacies than I already have (I'd need to remove some to decrease compilation time btw, but it's not an easy thing to do).
-
Never optimize before designing, building, and profiling first.
In my project, I store my bullets in a tree structure. Works fine. System runs at 45fps with 2000+ bullets (6000+ structures) and I've done very little to optimize. Running gprof gives me this output:
[5] 93.5 2.10 1.98 3792+7313950 particle::go(unsigned int) [5]
0.58 0.33 2409200/2409200 p_bullet::execute(unsigned int) [6]
0.41 0.00 2481650/2481650 p_transTrans::update(int) [7]
0.25 0.00 2410464/2423778 p_transRot::update(int) [8]
0.00 0.16 415/415 brain::doCallback(particle*) [12]
0.15 0.00 4897168/7316478 particle::execute(unsigned int) [9]
0.06 0.00 2409200/2409200 p_bullet::runNaturalEvents(unsigned int) [19]
0.03 0.00 4908542/4908542 particle::runNaturalEvents(unsigned int) [24]
0.00 0.00 2414256/7333584 particle::update(int) [31]
This tells me exactly where to look first for optimization.
-
This thread seems to have turned into some kind of group discussion about implementing danmaku engines :)
Some things I've observed while writing my own engine (http://www.shrinemaiden.org/forum/index.php/topic,6623.0.html)...
The type of the collection/container used to store all objects doesn't influence performance much (the difference was barely measurable when I tested vector vs. linked list)
I haven't tested it myself, but reusing dead objects (memory pooling) doesn't appear to me as a great source of optimization. You save one allocation, replacing it with a call to some kind of reset function (which has to be implemented manually and may be slower than the allocation it replaces). And that's just one allocation, In my case I'd still need to do 4-5 more to fully initialize the object.
There are two major performance bottlenecks: collision detection/handling and rendering.
There are many approaches for doing fast collision detection, but they mostly boil down to trying to do the smallest number of collision checks possible. Divide your objects into groups by position and/or type (items for example can only collide with players).
For rendering, read this: http://realtimecollisiondetection.net/blog/?p=86 (http://realtimecollisiondetection.net/blog/?p=86)
Using a similar technique I was able to cut drawing time almost in half.
It may also be a good idea to check the performance of sin & cos for your language of choice. If they're too slow you can implement your own using a lookup table.
-
This thread seems to have turned into some kind of group discussion about implementing danmaku engines :)
Some things I've observed while writing my own engine (http://www.shrinemaiden.org/forum/index.php/topic,6623.0.html)...
The type of the collection/container used to store all objects doesn't influence performance much (the difference was barely measurable when I tested vector vs. linked list)
I haven't tested it myself, but reusing dead objects (memory pooling) doesn't appear to me as a great source of optimization. You save one allocation, replacing it with a call to some kind of reset function (which has to be implemented manually and may be slower than the allocation it replaces). And that's just one allocation, In my case I'd still need to do 4-5 more to fully initialize the object.
There are two major performance bottlenecks: collision detection/handling and rendering.
There are many approaches for doing fast collision detection, but they mostly boil down to trying to do the smallest number of collision checks possible. Divide your objects into groups by position and/or type (items for example can only collide with players).
For rendering, read this: http://realtimecollisiondetection.net/blog/?p=86 (http://realtimecollisiondetection.net/blog/?p=86)
Using a similar technique I was able to cut drawing time almost in half.
It may also be a good idea to check the performance of sin & cos for your language of choice. If they're too slow you can implement your own using a lookup table.
Quadtrees are great for collision detection. They are extremely efficient (O(log n), but don't quote me on this), and are much better than a) per-pixel and b) a lot of bounding boxes. The Wikipedia article (http://en.wikipedia.org/wiki/Quadtree) has a pretty diagram on how it would work. Since collision detection should be the main overhead of the engine, you should experience quite good performance when using a quadtree-based approach.
As for rendering, XNA's SpriteBatch supports sorting and you probably won't have to do a hell of a lot with that.
-
Even with 2000+ particles, the naive one-to-many circle vs circle collision step of my sim was only 2% of my frame time. Applying the 6000 transformation matrices and drawing those 2000 particles, on the other hand, is some 20% of the frame.
Never optimize before profiling.
-
Quadtrees are great for collision detection. They are extremely efficient (O(log n), but don't quote me on this), and are much better than a) per-pixel and b) a lot of bounding boxes. The Wikipedia article (http://en.wikipedia.org/wiki/Quadtree) has a pretty diagram on how it would work. Since collision detection should be the main overhead of the engine, you should experience quite good performance when using a quadtree-based approach.
I thought a bit about quadtrees a while ago. In the specific case of danmakus, I think a real quadtree would take too much time putting every bullet in the right box because we have a lot of objects moving quickly. Moreover most of the time we're not interested in bullet vs bullet collisions but one isolated object vs a lot of grouped objects. It'd be a waste of time to optimize the collision between all those bullet. It'd also be a waste to create and delete boxes over and over in the tree. A better solution would be a quad-tree, but with a fixed size, so that the sorting phase of the quad tree is faster, but it still improves things a lot. The actual depth of the tree I have no idea though, you'd have to experiment and see. I think something around a depth of 8 looks good to me, but I've no idea really.
Even with 2000+ particles, the naive one-to-many circle vs circle collision step of my sim was only 2% of my frame time. Applying the 6000 transformation matrices and drawing those 2000 particles, on the other hand, is some 20% of the frame.
Never optimize before profiling.
I agree, and pretty much everything I said is purely theoretical, I haven't tested anything performance-wise yet because I'm way too busy implementing features first.
However, I think that even if you should not optimize before profiling, you should prepare the job a little when it's possible. Knowing in advance where you could optimize and make it easier when you'll have to do it, because if you've got to rewrite half of your code to optimize something, that's really poor design and it could have been easily avoided with no added work.
-
Even with 2000+ particles, the naive one-to-many circle vs circle collision step of my sim was only 2% of my frame time. Applying the 6000 transformation matrices and drawing those 2000 particles, on the other hand, is some 20% of the frame.
How is that measured? For collision detection you want peak time per frame, not an average.
Space subdivision isn't critical, as long as you divide objects into collision groups. 200 player shots vs. 100 enemies (200x100) is a lot faster than (200+100)2. I wanted to allow player shot vs. enemy shot collisions (200x2000) which gets slow fast, so I further subdivide into a uniform grid.
-
gprof, which is free, as long as you can compile with a descendant of gcc. It's a sampling profiler, so yes I'm working off of average, not single frame traces for peak time. But, I'm using a test script that is designed to stress the system 100% of the time, so it's not like the long-term average time is being artificially deflated by trivial frames.
If you're using C# you might be able to use PIX, but I've never used that on Windows / C# so YMMV. Not sure if there are any other analogous free profiling tools for C# worth using.
If you are doing a lot of collisions (like bullet-bullet collision instead of just bullet-object collision) it may be worth spending time trying to squeeze performance out of it. But that's why you profile first. Profiling my sim told me to look at overhead, so as an exercise I did and in about 2 hours last night I was able to improve performance 20% by putting in some simple caching, switch from double to float on GL calls, switch from list<> to vector<>, etc. Now runs at 55 frames during the stress test.
-
I thought a bit about quadtrees a while ago. In the specific case of danmakus, I think a real quadtree would take too much time putting every bullet in the right box because we have a lot of objects moving quickly. Moreover most of the time we're not interested in bullet vs bullet collisions but one isolated object vs a lot of grouped objects. It'd be a waste of time to optimize the collision between all those bullet. It'd also be a waste to create and delete boxes over and over in the tree. A better solution would be a quad-tree, but with a fixed size, so that the sorting phase of the quad tree is faster, but it still improves things a lot. The actual depth of the tree I have no idea though, you'd have to experiment and see. I think something around a depth of 8 looks good to me, but I've no idea really.
I agree, and pretty much everything I said is purely theoretical, I haven't tested anything performance-wise yet because I'm way too busy implementing features first.
However, I think that even if you should not optimize before profiling, you should prepare the job a little when it's possible. Knowing in advance where you could optimize and make it easier when you'll have to do it, because if you've got to rewrite half of your code to optimize something, that's really poor design and it could have been easily avoided with no added work.
In theory, I'd say with the quadtree approach, you could use it as a replacement for a bounding box -- i.e. you have the root node of the quadtree which specifies origin coordinates, then that's free to move around as it wishes and if the player's root node intersects with the bullets, you perform further collision checking. I suppose you could memoize for different bullet types so you don't have to algorithmically regenerate a quadtree over and over again, or even compile bullet images to a quadtree and have the engine load that.
Also, why not have bullets collide with each other (optionally, e.g. adding BULLET to a Bullet's collision mask attribute)? Sounds like an interesting danmaku experience to me :derp:
gprof, which is free, as long as you can compile with a descendant of gcc. It's a sampling profiler, so yes I'm working off of average, not single frame traces for peak time. But, I'm using a test script that is designed to stress the system 100% of the time, so it's not like the long-term average time is being artificially deflated by trivial frames.
If you're using C# you might be able to use PIX, but I've never used that on Windows / C# so YMMV. Not sure if there are any other analogous free profiling tools for C# worth using.
If you are doing a lot of collisions (like bullet-bullet collision instead of just bullet-object collision) it may be worth spending time trying to squeeze performance out of it. But that's why you profile first. Profiling my sim told me to look at overhead, so as an exercise I did and in about 2 hours last night I was able to improve performance 20% by putting in some simple caching, switch from double to float on GL calls, switch from list<> to vector<>, etc. Now runs at 55 frames during the stress test.
Isn't PIX an Xbox profiler? IIRC VS2010 comes with a built-in profiler (http://blogs.msdn.com/b/profiler/archive/2009/06/10/write-faster-code-with-vs-2010-profiler.aspx), which I've used with my (non-danmaku) engine (though it was practically useless due to the huge amount of IronPython-C# interoperability I have). I'm not sure if the Express editions have one, though.
Also, I propose Wriggle renames the topic to A Theoretical Discussion on the Implementation of Danmaku Engines :3
-
In theory, I'd say with the quadtree approach, you could use it as a replacement for a bounding box -- i.e. you have the root node of the quadtree which specifies origin coordinates, then that's free to move around as it wishes and if the player's root node intersects with the bullets, you perform further collision checking. I suppose you could memoize for different bullet types so you don't have to algorithmically regenerate a quadtree over and over again, or even compile bullet images to a quadtree and have the engine load that.
Hmm, I read a few time but didn't understand. Could you develop a little, preferably with an example? Sorry ^^'
Also, why not have bullets collide with each other (optionally, e.g. adding BULLET to a Bullet's collision mask attribute)? Sounds like an interesting danmaku experience to me :derp:
My Danmagine can do that already :p
It's an option people are not likely to use very often, but objects can go into multiple collision layers. Actually, making player bullet and enemy bullet collide is the same thing as making enemies kill the player when touched (collision-wise). You could also do enemy bullet vs enemy bullet collisions easily by a similar mechanism (which already exists too) :)
My engine might still look ugly (because I didn't have time to do a nice demo), but it's becoming quite powerful under that (^-^)
-
Hmm, I read a few time but didn't understand. Could you develop a little, preferably with an example? Sorry ^^'
My Danmagine can do that already :p
It's an option people are not likely to use very often, but objects can go into multiple collision layers. Actually, making player bullet and enemy bullet collide is the same thing as making enemies kill the player when touched (collision-wise). You could also do enemy bullet vs enemy bullet collisions easily by a similar mechanism (which already exists too) :)
My engine might still look ugly (because I didn't have time to do a nice demo), but it's becoming quite powerful under that (^-^)
Here's a crappy diagram (image only ~60KB, and I think it's fine to include inline -- link it if you don't think so, mods):
(http://dl.dropbox.com/u/2880866/quadcollider.png)
I'm going to whip up a prototype of the algorithm in Python and check how well it performs against per-pixel and straight, full viewport quadtrees.
An alternative is to use convex hulls only and use SAT.
-
Well today I was able to make quite a bit, and I finnaly figured out how to draw many objects and danmaku patterns, I even made a playable character with focus movement and all that stuff, but one problem I have is that I cant get these different class instances to interact much, since their all defined in the main class, the game.
the player cant use the playershoot classes' ShootBullet method that makes them active for example, because when I try to use the main classes bullet array it tells me that an array or method of that name doesnt exist, and global stuff doesnt seem to work on anything in XNA, so yeah, new problem to fix XD getting global variables and arrays so that Player and Boss classes can use the Bullet and Bomb classes to shoot and use them.
-
Here's a crappy diagram (image only ~60KB, and I think it's fine to include inline -- link it if you don't think so, mods):
(http://dl.dropbox.com/u/2880866/quadcollider.png)
I'm going to whip up a prototype of the algorithm in Python and check how well it performs against per-pixel and straight, full viewport quadtrees.
An alternative is to use convex hulls only and use SAT.
Wow, I see now, what you did there is quite original!
But what about circles then? Circular-ish shapes are used very often in danmakus, and they are very cheap to test. Wouldn't it be a waste to approximate a circle by AABB? You'd have to treat the circles as a special case, and from that it'd become so complicated that I have no idea how it would perform :p
However by going this way, you'd end up in only AABBs. I've read this (http://www.shmup-dev.com/forum/index.php/topic,1635.0.html) a while ago, from what I remember it's basically a way to greatly speed up things when you've got only AABBs by putting all of that in an array, sorting it and then only testing neighbours.
With this you could potentially end up with a very fast collision detection. If you complete your algorithm and test it, please tell me the result, it's a really interesting technique :)
-
However by going this way, you'd end up in only AABBs. I've read this (http://www.shmup-dev.com/forum/index.php/topic,1635.0.html) a while ago, from what I remember it's basically a way to greatly speed up things when you've got only AABBs by putting all of that in an array, sorting it and then only testing neighbours.
Essentially, it is that technique, but in quadtree form to optimize searching. Hopefully, it won't cost O(n?) in the worst case scenario, like the AABB array technique, but rather, by my half-assed guessing, O(n log n).
But what about circles then? Circular-ish shapes are used very often in danmakus, and they are very cheap to test. Wouldn't it be a waste to approximate a circle by AABB? You'd have to treat the circles as a special case, and from that it'd become so complicated that I have no idea how it would perform :p
Screw circles, they should learn to be squares like the rest of us :3
Well today I was able to make quite a bit, and I finnaly figured out how to draw many objects and danmaku patterns, I even made a playable character with focus movement and all that stuff, but one problem I have is that I cant get these different class instances to interact much, since their all defined in the main class, the game.
the player cant use the playershoot classes' ShootBullet method that makes them active for example, because when I try to use the main classes bullet array it tells me that an array or method of that name doesnt exist, and global stuff doesnt seem to work on anything in XNA, so yeah, new problem to fix XD getting global variables and arrays so that Player and Boss classes can use the Bullet and Bomb classes to shoot and use them.
Would you mind showing me/us your code? I can review it for you and tell you what you should and shouldn't do (it's nice to have some sort of structure rather than just a hodge-podge of things all glued together with paste, and, the fact you're using globals makes me lean towards the latter).
Also, a moderator should split this thread so we stop intruding on Wriggle :V
-
Essentially, it is that technique, but in quadtree form to optimize searching. Hopefully, it won't cost O(n?) in the worst case scenario, like the AABB array technique, but rather, by my half-assed guessing, O(n log n).
Screw circles, they should learn to be squares like the rest of us :3
Would you mind showing me/us your code? I can review it for you and tell you what you should and shouldn't do (it's nice to have some sort of structure rather than just a hodge-podge of things all glued together with paste, and, the fact you're using globals makes me lean towards the latter).
Also, a moderator should split this thread so we stop intruding on Wriggle :V
Well here's what my game looks like:
I have a main class that created for my by XNA, it does all the drawing and processes, it has the usual framework much similar to Danmakufu, I start by making some classes, like: Bullet, Player, Frame, etc. I create instances of these classes in the main game class:
Player GamePlayer;
Frame GameFrame;
and with bullets:
static int MaxBullets;
Bullet[] BulletArray = new Bullet[MaxBullets]
and then in initialize I do a for statement to really create them all, so basically every bullet has a variable I can call to in other methods, as their part of a big array, and I can draw and update all of them, the bullets have a method that looks kinda like this:
public void Shoot(Texture2D texture, float speed, float angle)
{
Active = true;
Speed = speed;
etc...
}
That method makes the bullet active and gives it what it needs, but because the array used to access each instance is in the main class, classes like Player and Boss can't access it and thus can't create bullets...D=
-
Well here's what my game looks like:
I have a main class that created for my by XNA, it does all the drawing and processes, it has the usual framework much similar to Danmakufu, I start by making some classes, like: Bullet, Player, Frame, etc. I create instances of these classes in the main game class:
Player GamePlayer;
Frame GameFrame;
and with bullets:
static int MaxBullets;
Bullet[] BulletArray = new Bullet[MaxBullets]
and then in initialize I do a for statement to really create them all, so basically every bullet has a variable I can call to in other methods, as their part of a big array, and I can draw and update all of them, the bullets have a method that looks kinda like this:
public void Shoot(Texture2D texture, float speed, float angle)
{
Active = true;
Speed = speed;
etc...
}
That method makes the bullet active and gives it what it needs, but because the array used to access each instance is in the main class, classes like Player and Boss can't access it and thus can't create bullets...D=
Easily solved -- give Player and Boss a property that can access the BulletArray field, e.g. when you initialize them, add a bulletArray parameter to the constructor so you can use this._bulletArray. As it's a reference, changing it from within Player makes the BulletArray field in the game class change too.
Alternatively, you can singletonize the Game class so it can be accessed from anywhere, or give Player and Boss an _game field so they can access the core game class.
-
Easily solved -- give Player and Boss a property that can access the BulletArray field, e.g. when you initialize them, add a bulletArray parameter to the constructor so you can use this._bulletArray. As it's a reference, changing it from within Player makes the BulletArray field in the game class change too.
Alternatively, you can singletonize the Game class so it can be accessed from anywhere, or give Player and Boss an _game field so they can access the core game class.
So its possible to refference the class itself by singletonizing it? like Game.BulletArray[FindLowest]?
Speaking of which would my method FindLowest used to find the inactive bullet with the lowest ID be global too? how do I do that? this seems pretty useful.
-
So its possible to refference the class itself by singletonizing it? like Game.BulletArray[FindLowest]?
Speaking of which would my method FindLowest used to find the inactive bullet with the lowest ID be global too? how do I do that? this seems pretty useful.
You generally don't want to singletonize anything if you can avoid it, as singletons are globals in disguise and globals are bad. Also, you can implement FindLowest as a member function, so it would work like this.BulletArray[this.FindLowest()].
Never ever use globals.
-
You generally don't want to singletonize anything if you can avoid it, as singletons are globals in disguise and globals are bad. Also, you can implement FindLowest as a member function, so it would work like this.BulletArray[this.FindLowest()].
Never ever use globals.
Hmmm...I tried referencing the main game class and using "this.", but I usualy get something along the lines of "that method doesn't exist" or "That doesnt belong here" I even made a variable in the constructor for Boss that represents the main class and then when I use "Main.BulletArray[FindLowest]" it tells me I cant use the array or the method because its protected, how do you create a member function?
-
Isn't PIX an Xbox profiler? IIRC VS2010 comes with a built-in profiler, which I've used with my (non-danmaku) engine (though it was practically useless due to the huge amount of IronPython-C# interoperability I have). I'm not sure if the Express editions have one, though.
PIX is indeed an xbox360 profiling tool, but from what I hear it's been generalized to work on Windows with C# through the XNA toolkit. If you're working with C# it makes sense to look into what it can do for you.
As for C++ code, the VS2010 profiler only comes with a commercial-grade license which is at minimum $700, which is a little out of reach for hobbyist programming. gprof on the other hand is Free, but requires an instrumented binary compiled by gcc/mingw with the -pg flag. That said, writing gcc-compliant code is generally desirable. Plus, mingw(gcc 4.5) binary version spanks msvc binary by at least 10% for my project.
-
Alright, here's an implementation of my unanchored quadtree collision detection theory:
http://pastebin.com/nusmwsZf
No benchmarks yet, so I have no idea about the performance.
Keep in mind this is a narrowphase algorithm, so you'll still need a broadphase algorithm, such as spatial hashing.
-
Well today I had the clever idea of putting the PlayerBullet array in the Player's class and the Bullet arrays for each separate enemy depending on how many bullets they need, but then I realised that even though that works for drawing and shooting, it's gonna be tricky to make colissions... Such as bullets to hitbox, Bombs to bullets, etc.
So yeah I can't sneak my way out of this one, I need to learn better methods to make classes interact better.
-
Well today I decided to try something new, if it was too risky to mess around with the main class that does all the game drawing and updating, that I would make a class called Manager, and get it do all the connecting between classes, whenever a class is made their given a variable that's used to call Manager's methods like FindLowest and such, it seems to work because now Player can tell bullets to use the method Shoot, unfortunately when I passed all the draw commands from Manager onto the main class nothing was drawn.
My guess is that when I made a variable in Manager that could call the main class, and used it to load a graphic withing Manager (which didn't bring up any errors) the graphic never really loaded, Either a silly mistake on my part or I may need to rethink this trough...
So a class that's used to with interact all the other classes, hold BulletArrays and hold the Player and Boss instances, good idea?
-
Well today I decided to try something new, if it was too risky to mess around with the main class that does all the game drawing and updating, that I would make a class called Manager, and get it do all the connecting between classes, whenever a class is made their given a variable that's used to call Manager's methods like FindLowest and such, it seems to work because now Player can tell bullets to use the method Shoot, unfortunately when I passed all the draw commands from Manager onto the main class nothing was drawn.
My guess is that when I made a variable in Manager that could call the main class, and used it to load a graphic withing Manager (which didn't bring up any errors) the graphic never really loaded, Either a silly mistake on my part or I may need to rethink this trough...
So a class that's used to with interact all the other classes, hold BulletArrays and hold the Player and Boss instances, good idea?
Oh hey its because my BulletArray was set to a maximum of 0...Oops.
-
PIX is indeed an xbox360 profiling tool, but from what I hear it's been generalized to work on Windows with C# through the XNA toolkit. If you're working with C# it makes sense to look into what it can do for you.
http://mynameismjp.wordpress.com/samples-tutorials-tools/pix-with-xna-tutorial/ (http://mynameismjp.wordpress.com/samples-tutorials-tools/pix-with-xna-tutorial/)
Could have been posted sooner but...