A replacement for Danmakufu?

[ChaoStar]

  I did not see that. Now I feel stupid...

[Montblanc]

>.< Blargh. Yet more proof that I shouldn't be allowed to post at 4 AM. Lemme try this again:

I think player scripts should be allowed to define a slew of tags that stage and menu scripts can tweak on. For example, a player script might have a section that looks something like this:

Code: [Select]

AddTag("Reimu")
AddTag("Homing")
AddTag("Human")
AddTag("Solo")
AddTag("Superpower")And then menu scripts can filter the player lists based on tags that are/aren't included, stages can have different things happen depending on what properties the player has, and generally there's a lot more room for creativity.

This person is thinking.  I like it.

So do I. I can see oodles of possibilities with that system in place. =D PROPS

[G_gglypuff]

What about system requirements? Do you think this will use more or less power when compared to Danmakufu?

Btw, I like how this project is so serious. We really need a better engine to work with...

PS: I don't know how to code anything, but I'm never looking forward to use danmakufu if I have anything else to spend time on.

[Be Pok U (1998 burst style)]

What about system requirements? Do you think this will use more or less power when compared to Danmakufu?

Btw, I like how this project is so serious. We really need a better engine to work with...

PS: I don't know how to code anything, but I'm never looking forward to use danmakufu if I have anything else to spend time on.

This is being built from the ground up to replace danmakufu isn't it? I'd assume its suppose to be faster...

So is this going to have multicore support ?  :V

I noticed the plan is to use a single "numbers" data type for all numbers; I can see the simplicity in that, but feels kinda memory expensive if you were to like use doubles for all numbers.

[Naut]

So is this going to have multicore support ?  :V

Danmakufu runs on multiple cores, so I hope to God on high that this will as well.

[Nuclear Cheese]

What about system requirements? Do you think this will use more or less power when compared to Danmakufu?

Hard to give any real numbers at the moment.  My desktop, where I do my development, is (if I remember correctly):
AMD Sempron 3000 or so
1GB ram
WinXP
a good five(-ish) years old

The program, as-is, runs perfectly smooth with 363 objects (minimal collision scripts at the moment, though).  And that's with my habit of leaving ten or so multi-tab Firefox windows open at a time.

At the end of the day, though, how much power is needed will all come down to the scripts being run.  A script that says "lol fier bullat" is probably going to need less processor than "go here and draw the crazy effect while firing an ellipsis of bullets that slowly home in on each other while moving towards the ... etc" :V

This is being built from the ground up to replace danmakufu isn't it? I'd assume its suppose to be faster...

Being more efficient than Danmakufu is certainly a goal, although it might not be quite there at first.  Implement, then optimize - that's how I tend to do things.  Although, if I see optimizations I can do right off the bat, of course I'll throw them in.

So is this going to have multicore support ?  :V

Danmakufu runs on multiple cores, so I hope to God on high that this will as well.

Danmakufu does what now? o_O

... shit, now I need to look up how to do this.  And perhaps note to get a multicore processor when I finally decide to update my semi-piece of shit desktop. :V

Good thing you brought this up, though.  A lot of the things done in this engine are stupid easy to work into parallel processing, so it should be able to take advantage of multiple cores quite easily.
Only real issue you'd come across is that, if you're parallelizing things like running the tick scripts of each object, you could run into situations where the different scripts may not always run in the exact same order; if this becomes an issue there are ways to work around this, though.

I noticed the plan is to use a single "numbers" data type for all numbers; I can see the simplicity in that, but feels kinda memory expensive if you were to like use doubles for all numbers.

Are you seriously going to be storing so much data that this will even be a concern?

double = 8 bytes, if I remember correctly.

Even NTSD, which goes hell-crazy with arrays of arrays of arrays of numbers (no joke!) probably only stores at most maybe a hundred or so numbers for its own use, so that's only going to be maybe 1K or so of RAM used there.

The list of objects will be a bit more, with each object having at the least X, Y, angle, and speed as numbers, so (for now) 32 bytes in numbers per object.  Times, say, a few hundred objects on screen at once, you get around 10K of RAM used in numbers.  Still not that much, considering the average computer these days easily has at least a half gig or more of RAM.

For reference, Windows has a virtual memory page size of 4K (I just google'd it) - this means that Windows swaps memory in and out of RAM in 4K chunks.  So we're talking about maybe a few pages of RAM here ... I don't think this should become a big issue that easily.

Of course, feel free to disagree if you have some reasoning against what I said.

[Montblanc]

I've got another possibly nooby question.

As far as I know, Danmakufu couldn't make games with a Phantasmagoria (versus type) set-up.

Seeing as how this seems to be based on the standard setup of a standard Touhou game, I doubt it will be the case here either, but just ofr the sake of asking, will it be possible to set-up a game to follow a Versus shooter set-up?


Also, going back to the Suguri thing that was mentioned previously - implementing the "Power up for Super Move" thing would be as simple as setting the script so that the Player gains a Bomb after collecting a certain number of items (of your choosing).

The Power Graphic can be represented with a little bar on the screen, and your actual player-shot will never change power. Since Suguri gains Power by destroying enemies, you can just set all enemies to drop a specific item, which you can then set to auto-collect upon appearance, which will then boost your "Power", which will then modify the graphic you set on the screen.

...did that make sense?

[Drake]

The only thing Danmakufu is missing for TSS style is the giant screen.

And if I'm interpreting it correctly you can change the size of the game window, so that shouldn't be a problem.

[Nuclear Cheese]

I've got another possibly nooby question.

As far as I know, Danmakufu couldn't make games with a Phantasmagoria (versus type) set-up.

Seeing as how this seems to be based on the standard setup of a standard Touhou game, I doubt it will be the case here either, but just ofr the sake of asking, will it be possible to set-up a game to follow a Versus shooter set-up?

Adding support for TSS/PoDD/PoFV-style versus mode is certainly possible.
Given how different that type of game is though, it might be wiser to make a separate executable based of the same engine that would do this type of game.

Also, going back to the Suguri thing that was mentioned previously - implementing the "Power up for Super Move" thing would be as simple as setting the script so that the Player gains a Bomb after collecting a certain number of items (of your choosing).

The Power Graphic can be represented with a little bar on the screen, and your actual player-shot will never change power. Since Suguri gains Power by destroying enemies, you can just set all enemies to drop a specific item, which you can then set to auto-collect upon appearance, which will then boost your "Power", which will then modify the graphic you set on the screen.

...did that make sense?

Sounds like a perfectly viable way to do it.





Looked at a bit of stuff on using multiple cores late last night, and it comes down to multithreading the program, plain and simple.  That's good, because I already know what the hell I'm doing with that shit.

From a quick brainstorming session, here's a few places where I see possibility of spliting the program up into multiple threads:

Warning
The big post is approaching at full bandwidth.
According to the data, it is identified as Technical Details.
NO REFUGE

• Separate the Rendering Engine into its own thread
  
  • Idea: split the rendering code off into its own thread.
  • Implementation:
    
    • When something is commanded to be drawn in the engine, put it in a list (this is already done in the current build, so that things can be drawn in the correct ordering based on layers)
    • Each frame, pass off the list from the main thread to the rendering thread.  The rendering thread renders the current frame while the Execution Engine processes the next frame.
    • Use Semaphores/Mutexes to keep the two threads in sync, of course.
    • Should yield a significant performance improvement on 2⁺ core systems, since rendering and script execution can run in parallel.  Might even give a (smaller) boost to performance on a single-core system, depending on how long a thread has to wait for OpenGL calls to go through.
  • Risks:
    
    • Possibly up to one frame of lag on the visuals, mostly when experiencing heavy load on the renderer thread.  I don't really see this as much of an issue, but I wonder if anyone else here really cares about 0.016666 seconds ... :V
• Split collision detection and collision script execution into separate threads
  
  • Idea: split the collision detection code into its own thread.
  • Implementation:
    
    • When checking for collisions, have two threads: one that builds a list of colliding objects, and another that reads through that list and runs collision scripts on each colliding pair.
    • In the typical case, I expect that there will be a lot of possible collisions (based on what types in play have collision scripts defined), but not many actual collisions (for instance, 200 bullets want to collide with the player ... almost all of them probably aren't), so splitting the work like this will probably be a pretty fair divide.
  • Risks:
    
    • Possible desync of data ...
      
      • If a collision script moves or resizes an object, that may take place before or after that object is collision-checked in the other thread, causing the possibility of an unpredictable outcome.
      • This risk can easily be eliminated by caching what changes are commanded by the scripts, and not applying them until all collision checking has been completed.
• Multiple threads for running scripts
  
  • Idea: split the work of running scripts between multiple threads.
  • Implementation:
    
    • For each set of scripts to be run (tick scripts, for instance), divide the list of objects between multiple threads and have them concurrently run the scripts.
    • This could yield substantial speedup, since (ideally) we could have as many threads as there are cores on the system, and they could all be processing scripts simultaneously.
  • Risks:
    
    • Possible desync of data ... worse than with the collision thread idea ...
      
      • If two scripts modify the same global variable, or the same parameter of an object, there could be a race condition on what order they get executed, resulting in multiple possible outcomes depending on how the threads are executed.
      • Not as easy to resolve as with the collision thread idea, because of the fact that the actual order of what scripts get executed when becomes indeterminate.
      • Using the "delay actual assignment until after we're done" approach wouldn't work as well here, since in this case the problem also applies to global variables, which we would expect to change immediately.

... whew, that's quite a bunch of detail.  Anyone have any thoughts?
I think that the separate rendering thread wouldn't be hard to do at all.  Of the other two, the separate collision detection thread is the easier of the two, but both could get tricky.

[DarkslimeZ]

Rendering generally shouldn't be an issue, but if splitting the collision detection into a different thread is feasible for you, go for that. I think it might be actually slower(check me on this), especially if you're using non-rectangular shapes for collision masks.

A possibility is just to have a separate thread running that will check if anything on the screen is colliding(important things - player with enemy bullet, enemy with player bullet) and updating some kind of data structure with that information, so all the main thread has to do is go through and deal with them appropriately(using a mutex, waiting for the lock). I don't think you should put that in another thread because of desyncing problems and I only have two cores.

But then again, I'm not too experienced with threads. ><; Just thought I'd throw that out there.

[Lishy1]

I can't imagine POFV vs type gameplay in danmakufu replacement (Does it have an official name yet?)
I just don't think it would work out with netplay and all that.

My suggestion is to best save it to as a different project altogether.

[Montblanc]

I see what y

Adding support for TSS/PoDD/PoFV-style versus mode is certainly possible.
Given how different that type of game is though, it might be wiser to make a separate executable based of the same engine that would do this type of game.

I thought as much. Ah well, I suppose in a few years when I actually get to MAKING such a thing (it's on the far reaches of the to-do list), THEN I'll worry about what program to use for it. xD


As for your wall of text of Thread-Splitting, I'm nowhere near advanced enough in scripting programs to give any meaningful opinion on it. But I can at least say that I kinda like the idea, and as for that first risk on minor FPS loss, I could honestly care less about a split second xD

[Be Pok U (1998 burst style)]

Rendering on its own thread should be fine for the most part; rendering of bullets (maybe player/hitbox) I might be concerned about though, given that's what facilitates the dodging but that shouldn't be a problem as long as drawing delays is minimal. Rendering for backgrounds and effects otherwise should have the least of problems right ?

Collision I'm worried about it being messed up if a bullet happens to be flying stupidly high speeds,it might worsen the desync problem. Timing is everything. Are there speed limits for bullets?  :V

Mutlithreading scripts looks a bit nasty to me though; Depending on the person writing the script, bloated scripts might just out right crash the engine for instance, unless, you can really make the scripting idiot proof somehow...  :V

[DarkslimeZ]

That kind of collision problem is going to be a problem in its own right, regardless of whether threads are used. Fortunately, at 60 FPS, it shouldn't be too bad as long as you don't have bullets going at absolutely ridiculous speeds. XD

[8lue Wizard]

Collision I'm worried about it being messed up if a bullet happens to be flying stupidly high speeds,it might worsen the desync problem. Timing is everything. Are there speed limits for bullets?  :V

I don't think you're quite understanding the concern here; suppose you have a collision script that moves bullet A 10 frames in some direction. And suppose that causes a collision between that bullet and another (bullet B), resulting in another collision script being run. If, when this scene is replayed, the collision between bullet A and bullet B is checked before the first collision script moves bullet A, then it will fail, and the second collision script will not be run: hence, a desync. However, this all happens within a single frame, while the speed of a bullet only matters between frames.

But yeah, discretion is advised when weilding high-speed bullets.

The rendering thing would, at most, introduce a 1-frame lag, which would really only matter in cases where you have massive slowdown anyway (and possibly disrupt some TASers. Sounds win-win to me. =P)

As for threading scripts... well, it sounds like a phenomenally bad idea to me. I'll just leave it at that.

[Drake]

Generally you shouldn't be firing bullets more than 8px/f anyways.

Although honestly, a 1 frame lag is more of an issue for playing at 60fps. A TAS with this might be tougher to get used to initially, but after a short awkwardness it would be easier at frame-frame than deathbombing a frame too late at normal speed.

I say split rendering. Higher level scripts usually take tons of data just in rendering and effects, it's likely that splitting it between cores would improve performance more than script splicing and splitting the collision functions.

[Nuclear Cheese]

Rendering generally shouldn't be an issue, but if splitting the collision detection into a different thread is feasible for you, go for that. I think it might be actually slower(check me on this), especially if you're using non-rectangular shapes for collision masks.

At the moment, all collision is done with circles.

Only time something different will need to be done is when lasers are added in.

A possibility is just to have a separate thread running that will check if anything on the screen is colliding(important things - player with enemy bullet, enemy with player bullet) and updating some kind of data structure with that information, so all the main thread has to do is go through and deal with them appropriately(using a mutex, waiting for the lock). I don't think you should put that in another thread because of desyncing problems and I only have two cores.

But then again, I'm not too experienced with threads. ><; Just thought I'd throw that out there.

The way you're suggesting collision be separated to its own thread is basically what I was saying above.

I see what y

"... ou did there?"


 :V

Collision I'm worried about it being messed up if a bullet happens to be flying stupidly high speeds,it might worsen the desync problem. Timing is everything. Are there speed limits for bullets?  :V

Fast-moving bullets won't cause collision to break in-and-of-themselves.  Worst that happens is a bullet "hax" through the player because of how fast it is going.  This can happen in Danmakufu and even official Touhou in some places.

Mutlithreading scripts looks a bit nasty to me though; Depending on the person writing the script, bloated scripts might just out right crash the engine for instance, unless, you can really make the scripting idiot proof somehow...  :V

What I was referring to was not multithreading at the script level, but rather multithreading in the program itself to take advantage of multiple-core CPUs.  Of course, this would be made in such a way as to avoid any risk of problems.

I say split rendering. Higher level scripts usually take tons of data just in rendering and effects, it's likely that splitting it between cores would improve performance more than script splicing and splitting the collision functions.

That was my basic thought on the matter, at least.  I may go ahead and try splitting off collision detection into its own thread too, although that does get a bit more involved.

But that's something for further down the road, anyways.  Get it working, then get it working better.





A couple small updates to the code tonight.  First off, I found and fixed a stupid error in the collision code which made it end up only collision-checking against other objects of the same type.  Yeah, that was a stupid one.

Other than that, I added a few new commands to the Execution Engine, including obj_create.  May not sound like much, but it's now enough for me to do this:


(if you can't see the image - click here)

Yes, folks.  You are now looking at the very first danmaku in the program, coded from scratch using mdBase.  Here's the script, for anyone who's interested:

Code: [Select]

Musuu
Script[mdBase]


/ Effect object - Starter
/ Should be spawned once when the game starts
/ Creates all necessary objects, then deletes itself
Object_Type Effect Starter

Script initialize

obj_create !id, "ThePlayer", 213, 400
obj_create !id, "TheEnemy", 213, 100
obj_get_id !id
obj_destroy !id



/ Player ThePlayer
/ object for the player
Object_Type Player ThePlayer

Script initialize
obj_get_id !tmp
obj_set_angle !tmp, 0
obj_set_speed !tmp, 0
obj_set_image !tmp, "test1.png"
obj_img_rotate !tmp, false
obj_set_pmove !tmp, 5.4, 3.2
obj_set_size !tmp, 2.2, 5
obj_set_layer !tmp, 20

/ Right now, we need to have the collision scripts here,
/ since we can't get the object ID of the other object
/ collided with yet.  This will, of course, change later.
Script collide Boss
obj_get_id !tmp
obj_destroy !tmp

Script collide Enemy_Shot
obj_get_id !tmp
obj_destroy !tmp



/ Boss TheEnemy
/ boss object
Object_Type Boss TheEnemy

Script initialize
obj_get_id !tmp
obj_img_rotate !tmp, false
obj_set_size !tmp, 16, 20
obj_set_image !tmp, "reimu1.png"
obj_set_layer !tmp, 30
add @count, 60, 0

Script tick
sub @count, @count, 1
less !tmp, 0, @count
jmp !tmp, 12

add @count, @count, 20
div !inc, 1.5707963267948966192313216916398, 20
add !ang, 3.9269908169872415480783042290994, 0

/ loop to create a spread of shots
obj_create !id, "AShot", 213, 100
obj_set_angle !id, !ang
obj_set_speed !id, 2.5
sub !ang, !ang, !inc
less !res, 2.3, !ang
jmp !res, 6




/ Enemy_Shot AShot
/ basic shot type.  Won't be needed in the long run, since
/ a default type will be supplied by the program.
Object_Type Enemy_Shot AShot

Script initialize
obj_get_id !tmp
obj_set_image !tmp, "shot1.png"
obj_set_size !tmp, 5.5, 7.5
obj_set_layer !tmp, 40

Remember: the final scripting language will not look like this!

The script defines four object types:

• Starter (Effect) - this is hard-coded in the program to spawn when the program starts.  It simply spawns the player and enemy boss, and then dissapears.
  Once things get a bit prettier, we won't need this anymore, as the program should be able to decide what to initially spawn.
• ThePlayer (Player) - the player's object (silly triangle thing).
  Note that currently, since I haven't yet implemented the ability to get the object collided with's ID in the collision scripts, I need to put the "omg I dead" collision scripts in the player object.  These will be much better organized, and generally pre-defined once things get more finalized.
• TheEnemy (Boss) - Pyro-Reimu strikes again!  This object just handles the timing and firing of the bullets.
• AShot (Enemy_Shot) - A simple object type for a basic enemy shot.  This will be built into the program, as a default predefined type, later on.

The way it is set up right now, the game simply lets you move around the player object while the boss shoots out danmaku.  If you collide with a shot or the boss, your player object dissapears.  Simple, but it's certainly progress!



The numbers in the title bar, by the way, are as follows:

• First number is the frame rate (60 is the ideal).
  The game ran (as far as my perception can tell) perfectly smooth with these conditions.
• Second number is the number of objects currently existing.

Still quite a ways to go, but I think it's shaping up nicely so far.
What do you guys think?

[Stuffman]

Looks awwwwwright

Oh, how does it determine drawing priority for bullets? The shot overlap looks really odd.

[Rinnosuke Morichika]

This looks brilliant. The script syntax you made is strangely similar that of an MMOG programming language I code in frequently, so I feel like I already know how to script it.

Looking forward to its completion, I'll definitely be using it once its released. 

[Nuclear Cheese]

Looks awwwwwright

Oh, how does it determine drawing priority for bullets? The shot overlap looks really odd.

Right now, the drawing order on the bullets isn't explicitly defined, since they all have the same drawing layer.  Later on, I should probably tweak the code so that it looks a bit better.

This looks brilliant. The script syntax you made is strangely similar that of an MMOG programming language I code in frequently, so I feel like I already know how to script it.

Looking forward to its completion, I'll definitely be using it once its released. 

To be honest, while you can use mdBase to write scripts, like I did above, it's a real bitch to do so.  There's going to be a higher-level scripting language, with syntax somewhat similar to C or a variant thereof - that will probably be a much better choice for anything complex.






EDIT:

Wow, a whole day without a new post?  That's new ...

Bit of code work today:

• Cleaned up some pieces of code, which had old, commented-out crap lying all over the place.
• Fixed the same bug I fixed yesterday, but for collide_2 scripts.  I'm a freaking idiot. :V
• Added commands to the Execution Engine: add_graze, add_score, set
• Updated the code so that, for collide and collide_2 scripts, they are automatically given a local variable, colliding_with_id, which gives the ID of the object that is being collided with
• Added some default scripts ...
  
  • Player colliding with Enemy/Enemy Shot/Boss kills the player.  Right now, the player object is just de-spawned.
  • Player collide_2-ing with Enemy Shot increases graze (once per shot)

I also started to look at implementing the separate thread for rendering.  I don't think I'm gonna go ahead and implement it soon, but I do think it'll be a good thing to throw in there eventually.

[Hat]

Oh wow, I hope the final scripting language doesn't look like that... it hurts my brain to see. I'm sure it's more intuitive than I'm giving it credit for, but still... ouch. What will I do without my precious brackets?!

[Naut]

It's directly below the script block and you still don't read it? C'mon. Seriously.

[Hat]

I meant to say 'nothing like that'. I read the part below the script box, Naut. I just phrased it badly. \=| Perhaps now you'll understand?

I can't wait to see the finished product... I think the most important part of this project won't be that Danmakufu will be reimagined, but that we'll also have the source code available, should we wish to make improvements to the program itself.

[Drake]

Have you ever programmed in C? Have you ever programmed in Danmakufu? It'll look like that. The end.

The colliding_with_id variable actually looks pretty useful.

[Hat]

I know, I know, I saw the examples.

Frankly, while an easier collision detection mechanism would be better, I'd much prefer a freer graphical system, especially regarding the sidebar. Danmakufu requires too many workarounds to get at that.

[Dizzy H. "Muffin" Muffin]

Anything new to report, NC?

[Ragnikarth]

I know, I know, I saw the examples.

Frankly, while an easier collision detection mechanism would be better, I'd much prefer a freer graphical system, especially regarding the sidebar. Danmakufu requires too many workarounds to get at that.

A custom GUI system would be awesome, with changeable fonts and all because the font Danmakufu uses isn't SUPERFLASHY.

[G_gglypuff]

Nice to know this is more affordable. Danmakufu lags even without any script being run here.

[Naut]

You are aware that you're not actually supposed to plug a monitor in to the back of a microwave, aren't you?

[Suikama]

You are aware that you're not actually supposed to plug a monitor in to the back of a microwave, aren't you?

But it's cool

:cool: