Wanting an engine to work with~

[WriggleNightbug]

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.

[Gc]

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 or XNA Game Studio (C#  only)
Then there are premade engines like Unreal Engine 3 and Unity Engine, 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)

[Grumskiz]

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

[WriggleNightbug]

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 or XNA Game Studio (C#  only)
Then there are premade engines like Unreal Engine 3 and Unity Engine, 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?

[Gc]

By "similar syntax" I mean it uses the

Code: [Select]

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.

[rfw]

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.

[WriggleNightbug]

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. ^^

[bennelsey]

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

[Gc]

(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* by simply loading Texture2D objects with the default ContentManager and drawing them with the default SpriteBatch 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

[Mjonir]

Since I was mentioned above I thought I'd add a word: My engine called Damagine 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

[WriggleNightbug]

I think you're mistaking XNA for straight-up DirectX there...
It's possible to achieve pretty good results* by simply loading Texture2D objects with the default ContentManager and drawing them with the default SpriteBatch 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

[WriggleNightbug]

Since I was mentioned above I thought I'd add a word: My engine called Damagine 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. ^^

[rfw]

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* by simply loading Texture2D objects with the default ContentManager and drawing them with the default SpriteBatch 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.

[WriggleNightbug]

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

[rfw]

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.

Code: [Select]

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

[Mjonir]

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.

[WriggleNightbug]

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

[Mjonir]

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.

[rfw]

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).

[Mjonir]

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.

[Gc]

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.

[rfw]

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

[Mjonir]

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

[WriggleNightbug]

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...

[Mjonir]

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:

Code: [Select]

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:

Code: [Select]

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());
            }
        }
    }


[rfw]

I'll be lazy and just copy some code:

Code: [Select]

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:

Code: [Select]

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.

[Mjonir]

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).

[tldr]

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:

Code: [Select]

[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.

[anonl]

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...

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
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.

[rfw]

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...

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
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 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.