A replacement for Danmakufu?

[Ragnikarth]

Failing that, I have a backup plan which will require a small bit of work on the scripter's side - split the song into two files: one for the intro (before the loop) and one for the loop.  What will then happen is the intro file will be played once, and when that finishes the loop file will start playing and loop repeatedly.  Syntax would be something like this:

PlayMusic("omgbestsongevar_intro.ogg", "omgbestsongevar_loop.ogg");

THAT WORKS.

Just need to confirm something, if we use:

PlayMusic("song",A,B);

will it start from 0:00, then play to B, then go back to A?

[Nuclear Cheese]

I think you'd do well to deal with infinite-loops by having it somehow check for them in a check-for-problems stage that it does before actually executing the script.

... are you asking me to solve the Halting Problem? o_O

Pre-execution analysis of a piece of code to determine whether or not it will infinite-loop is a rediculously hard problem, even when simplified down from the (as far as I know) literally unsolvable general case.


As far as "infinite protection", right now I have a limit to the number of commands that can be executed in a single script execution (currently one million, but might be pushed higher), so any single script can't run infinitely.
But this wouldn't catch infinitely-spawning tasks like I mentioned above.  However, I really can't think of anything practical that a single object would need, say, a thousand different tasks simultaneously running to accomplish.

The idea here is to keep the program from locking up permanently (like Danmakufu does) by saying "Hey, this script is going way beyond what anything that would be reasonable.  Something is very likely wrong."

THAT WORKS.

Just need to confirm something, if we use:

PlayMusic("song",A,B);

will it start from 0:00, then play to B, then go back to A?

If I can get that approach to work, then yes, music will start at 0, run to B, then start looping from A to B.

[Naut]

While on the subject of lol fun musics:

PlayMusic(music.wav, loop point A, loop point B, time taken to fade in [if 0 then no fade in will occur]);

FadeMusic(music.wav, number of frames to take to fade out music);

As you can see, if there is someway to control the volume of music over time then I think a fade in and out option should be implimented. This is particularly useful when transitioning between songs -- instead of the song ending abruptly and the new one starting immediately, you can have one fade out and the other fade in. This would be even better if you could play more than one song at a time. I seperated the functions because you may need to fade out depending on user inputs. Is something like this possible?

[Drake]

i want a music function that will make echo effects and reverse the clip and have it normalize the decibel peaks and add change the instruments in the song

[Montblanc]

No support for MP3....

HERE'S THE KNIFE CHEESE. PLUNGE IT INTO MY HEART.

Over-Drama aside, I'm loving your updates. xD I've missed quite a bit, so it's lovely catching up on it all and seeing how quickly it continues to progress.

That EXE option is very appealing, so I'll toss my opinion in on the consideration side - if you can manage it, it'd be awesome.

I have no real preference one way or another with how you choose to implement the scripting (underscores or nor, brackets, whatever and whatnot). As long as it's functional and I can work it, I don't care what it looks like.

xD Of course, I'm not being overly picky for the primary reason that CHEESE IS DOING US A GRAND FAVOR BY BUILDING THIS PROGRAM SO WE WILL ACCEPT WHAT HE GIVES US AND WE WILL LIKE IT.

Not an attempt to kiss up, I'm serious. =/ Seems like some people are being far too picky considering you don't HAVE to do this for us at all.

[Naut]

i want a music function that will make echo effects and reverse the clip and have it normalize the decibel peaks and add change the instruments in the song

Cause adjusting volume is totally on tier with that right

[Suikama]

Cause adjusting volume is totally on tier with that right

You could just, you know, use audacity :V

[Drake]

You could just, you know, use audacity :V

That was my point

[Naut]

THANKS BROS DIDNT THINK OF THAT

The idea was so that you could fade in a second song when you make the transition from stage to boss, which will not always happen at the same time due to fps lagging and any points where you need to rely on input from the player. Adjusting volume in a song is pretty hurr, I just wanted to know if we could make the song transitions a little smoother by adjusting it in any given script.

[Gc]

How about a way to set parents ? you know ? movement relative to another bullet ? EASILY ?

But what am I saying... nothing can be easy in danmaku. except some ⑨ stuff.

[Nuclear Cheese]

While on the subject of lol fun musics:

PlayMusic(music.wav, loop point A, loop point B, time taken to fade in [if 0 then no fade in will occur]);

FadeMusic(music.wav, number of frames to take to fade out music);

As you can see, if there is someway to control the volume of music over time then I think a fade in and out option should be implimented. This is particularly useful when transitioning between songs -- instead of the song ending abruptly and the new one starting immediately, you can have one fade out and the other fade in. This would be even better if you could play more than one song at a time. I seperated the functions because you may need to fade out depending on user inputs. Is something like this possible?

The idea was so that you could fade in a second song when you make the transition from stage to boss, which will not always happen at the same time due to fps lagging and any points where you need to rely on input from the player. Adjusting volume in a song is pretty hurr, I just wanted to know if we could make the song transitions a little smoother by adjusting it in any given script.

Basic fadeout/fadein I can do, pretty much 100% certain of it.

Cross-fading from one song to another might not be as simple, unfortunately.  I think SDL's music functionality explicitly stops one music when you start another.  I might be able to just use the sound effect channels for it instead, but I think that'd be a bit of a kludge.

i want a music function that will make echo effects and reverse the clip and have it normalize the decibel peaks and add change the instruments in the song

...
...
...
... no.

No support for MP3....

HERE'S THE KNIFE CHEESE. PLUNGE IT INTO MY HEART.

Well, if you insist ...


Seriously, though, MP3 is a proprietary format, which means the SDL devs would need to fork out a licensing fee to have code in there to use it.  Lame, but that's how shit rolls.  Ogg Vorbis works just as well, and it's not hard to convert between the two, though, so not all is lost.

Over-Drama aside, I'm loving your updates. xD I've missed quite a bit, so it's lovely catching up on it all and seeing how quickly it continues to progress.

That EXE option is very appealing, so I'll toss my opinion in on the consideration side - if you can manage it, it'd be awesome.

I have no real preference one way or another with how you choose to implement the scripting (underscores or nor, brackets, whatever and whatnot). As long as it's functional and I can work it, I don't care what it looks like.

xD Of course, I'm not being overly picky for the primary reason that CHEESE IS DOING US A GRAND FAVOR BY BUILDING THIS PROGRAM SO WE WILL ACCEPT WHAT HE GIVES US AND WE WILL LIKE IT.

Not an attempt to kiss up, I'm serious. =/ Seems like some people are being far too picky considering you don't HAVE to do this for us at all.

Glad to hear you like what I've shown so far.  It still has quite a way to go, but I've been trying to keep updates steadily going*.

And, as long as it doesn't get out of hand, I don't really mind people being a little picky.  After all, one of the main things we're aiming for is to make this easier to use than Danmakufu, and I think the input of those who've used Danmakufu a bunch would go a long way towards that goal.

How about a way to set parents ? you know ? movement relative to another bullet ? EASILY ?

But what am I saying... nothing can be easy in danmaku. except some ⑨ stuff.

Ooh, good idea.  Actually, this wouldn't be that hard to do in the code - basically, we'd just need to determine how much the parent object has moved, and move the child objects as well.  It could also adjust child object angles and/or rotate child objects around the parent, based on the parent object's angle.

With the code in place, the script would be really simple.  I'd say just put in a couple easy commands to determine it:

Adopt(id) - makes the object refereneced by the given ID number a child of the current object.
Disown(id) - makes the object referenced by the given ID no longer a child of the current object.

One question here is - if two different objects try to adopt the same child object, what happens?  Either the first one wins, and we disallow reassignments until the child object is disowned or orphaned (parent object is despawned), or the second one wins, and we allow objects to steal other objects' children.

Another possible problem is circular references - If A adopts B, B adopts C, and C then adopts A, we have a problem, since we'll get in an infinite loop saying "A moved, update B!  B moved, update C!  C moved, update A! etc ...".  My recommendation here would be to, when something tries to adopt another object, check for a circular reference, and disallow it if it would cause such a problem.

Finally, if a child object is orphaned (parent object is depawned), do we just reset it to parentless, or do we set it to the original parent's parent, if any?



* Exception - Like I mentioned previously, I have a tournament tomorrow, so this weekend will probably be light on updates.

[Naut]

Basic fadeout/fadein I can do, pretty much 100% certain of it.

This is very important, glad to hear it.

Cross-fading from one song to another might not be as simple, unfortunately.  I think SDL's music functionality explicitly stops one music when you start another.  I might be able to just use the sound effect channels for it instead, but I think that'd be a bit of a kludge.

This is not so worrisome. As long as I can fade out songs whenever I feel like it (for example, if user input changes when a song is likely to end), then I'm not worried about crossfading. I can just fade out one song then immediately fade in another, which is fine too.

...
...
...
... no.

He was just making fun of my request because he didn't actually think about how it could be applied. Such faith nowadays, it's hurtful

Seriously, though, MP3 is a proprietary format, which means the SDL devs would need to fork out a licensing fee to have code in there to use it. Lame, but that's how shit rolls.

o u

One question here is - if two different objects try to adopt the same child object, what happens?  Either the first one wins, and we disallow reassignments until the child object is disowned or orphaned (parent object is despawned), or the second one wins, and we allow objects to steal other objects' children.

First one wins, so says my coin flip.

My recommendation here would be to, when something tries to adopt another object, check for a circular reference, and disallow it if it would cause such a problem.

Yes.

Finally, if a child object is orphaned (parent object is depawned), do we just reset it to parentless, or do we set it to the original parent's parent, if any?

Parentless.

* Exception - Like I mentioned previously, I have a tournament tomorrow, so this weekend will probably be light on updates.

Take all the time you need.

[Cabble]

Two questions

1. How far are you into creating this, if you are creating it?

2.

PoFV AND PoDD TYPE STAGES

(At least easier to make.)

[Lishy1]

How would PODD stages even work?
How would one be able to code all the random fairies and the enemy AI?

[Stuffman]

One question here is - if two different objects try to adopt the same child object, what happens?  Either the first one wins, and we disallow reassignments until the child object is disowned or orphaned (parent object is despawned), or the second one wins, and we allow objects to steal other objects' children.

First one wins, so says my coin flip.

No, I'd much prefer the latter as it would allow more freedom in how objects are controlled. If we want to make sure we're not grabbing children that have parents, there can be a function that checks that.

[Cabble]

How would PODD stages even work?
How would one be able to code all the random fairies and the enemy AI?

Possibly the AI is prewritten, however you can change it also?

[Stuffman]

PoDDanmakufu should be a seperate project.

[Naut]

No, I'd much prefer the latter as it would allow more freedom in how objects are controlled. If we want to make sure we're not grabbing children that have parents, there can be a function that checks that.

Sir Stuff hath spoken, and thus it shall be.

[Suikama]

If we want to make sure we're not grabbing children that have parents, there can be a function that checks that.

STRANGER DANGER!
STRANGER DANGER!

[Lishy1]

PoDDanmakufu should be a seperate project.

I agree with this post. Having it in the same program could complicate things.

That said, a PoDDMugen-type of game could be very fun if the community can keep it balanced.
Then again, I would kill to play as the Gay Tuna Primeus and shoot Peter Griffon danmaku

[Nuclear Cheese]

He was just making fun of my request because he didn't actually think about how it could be applied. Such faith nowadays, it's hurtful

I knew he wasn't serious; that's exactly why I gave such a short, blunt reply.

o u

Wow.  I didn't even think of that when I made the post.

Two questions

1. How far are you into creating this, if you are creating it?

Well, here's a quick summary off the top of my head.  Should be pretty accurate, but I might make a mistake:

• Basic structures mainly in place.
  This includes code structures for objects and object types, as well as other basic things in the code.
• Rendering Engine - Mainly functional.
  Currently only renders one image per object, at the object's coordinates.  Support for other rendering will be added later.
• Execution Engine - Mainly functional.
  This handles execution of scripts.  The main thing left here is to add in new functionality for scripts to use.
• Script Processing - Basic script format working.
  Currently, there is a working parser for the main script language, mdScript, which reads in the script files and translates them internally to the format for the Execution Engine, which can then run said scripts.

2.

PoFV AND PoDD TYPE STAGES

(At least easier to make.)

We discussed this earlier in the thread, and the conclusion we came to was that this would be better off as its own, separate program.  It could end up being made as an offshoot of the Musuu no Danmaku code, though.




EDIT: Just a quick bit of progress so I don't feel like a completely lazy jackass:

• Command line arguments.
  Now checks for command line args.  -dt enables debugging info in the title bar.  Any filenames in the command line will be loaded as script files (if none are specified, it currently reverts back to its default of script2.txt).
• Added logging to a file.
  This will log certain events (currently just startup and errors) to a timestamped file.  By default, this is disabled; use the -l command line argument to enable it.
• The code now picks a Boss and Player object and automatically spawns them, assuming you define a Boss/Player in any of the loaded scripts.  This removes the need for the Starter object I had in the previous script examples.
• Added the ability to include other script files from within a script file.
  Note that it automatically checks for circular includes and ignores them; each script file will be loaded only once.

The base testing script is now three files:

Code: (script2.txt) [Select]

Musuu
Script[mdScript]

include("ThePlayer.txt");
include("TheEnemy.txt");



Code: (ThePlayer.txt) [Select]

Musuu
Script[mdScript]

// ThePlayer
// Player object
Player "ThePlayer"
{
   initialize
   {
      Set_Image("test1.png", false, 20);
      Set_Player_Movement(5.4, 3.2);
      Set_Size (3.2, 16);
   }
}



Code: (TheEnemy.txt) [Select]

Musuu
Script[mdScript]

// TheEnemy
// Enemy boss that makes some fucking danmaku.
Boss "TheEnemy"
{
   define count;

   initialize
   {
      Set_Image("reimu1.png", false, 30);
      Set_Size(24, 30);
      count = 60;
   }

   tick
   {
      count = count - 1;

      // When count reaches zero, we fire a spread of bullets, and spawn a point item.
      if (count <= 0)
      {
         // Adjust the "20" here to change the frequency of firing spreads.
         count = count + 20;

         // Adjust the "20" here to change the density of spreads.
         increment = 1.5707963267948966192313216916398 / 20;
         angle = 3.9269908169872415480783042290994;
         while (angle > 2.3)
         {
            Fire_Shot_01(213, 100, angle, 2.5, "shot1.png");
            angle = angle - increment;
         };
         Create_Object("Point_Item", 213, 100);
      };
   }
}
You could run the program without any args, and (by the way it's hard-coded for now) it will default to reading script2.txt, which in turn will signal the program to read the two other files.

You could also just have the program read the two files directly with a command line like this:
"Musuu no Danmaku.exe" ThePlayer.txt TheEnemy.txt


Of course, this command line stuff won't be necessary in the long run, as you'll have a menu to pick script files.



Another question to ponder on - how much "completeness" do you people want in here before I start releasing test builds?  I mean, do you guys want to start playing around with it while it's still in the "Well, it works, I think" phase, or do you want to wait until it gets more into the "Shiny, complete program" phase?
Advantage of the former would be that we could hopefully get bugs and such ironed out faster, but keep in mind it would require you guys to put up with a really incomplete program (and the possibility of script incompatibility with the real release version).
Choice is yours; I could probably have a functional download of it next weekend if you guys want (no promises, though.  Who the hell knows what could come up).
Similar question with the code, although I'd prefer to have the code to myself as far as actually programming things is concerned until the program reaches more of the "Shiny, complete program" phase.  Maybe that's just me being a jerk, though.

At this point, the program is still pretty limited in functionality, but it should be pretty stable.  Things on my to-do list* at the moment:

• Figure out how to get parser errors - right now it catches them internally and doesn't let the program know.  An odd model, if you ask me.
• Ability to setup different bullet graphics to use different collision sizes.
  Right now the built-in script uses a default size, and to use another you'd have to assign it after spawning the bullet in whatever script spawned it.
  
  • Perhaps even use a default based on the image size (overridable by other things, of course) ...
• Boss life, and player shots to eat away at it
• Player lives and bombs.  Right now, the player can't shoot or bomb, and when they get hit the player object is just despawned.
• More functions, including
  
  • Exponents
  • Get the state of the player input
  • Get and set the position of an object (angle and speed are already there)
  • Trig functions
  • Get the state of the player (probably through the player's object ID) as well as other, player-specific things (like lives)
  • ... bunch of other stuff I'm not thinking of right now :V
  • Font graphics/text rendering
    I already have a plan for this, but I need to sit down and work out the details.  Hopefully it won't be too performance-killing.

* this isn't everything that needs to be done - this is just the "near future" of things.  Let me know if you think other things are important and should be there.

[Dizzy H. "Muffin" Muffin]

I think releasing it sooner would be better. That way you can catch any "OH GOD WHAT"s in the current stuff while there isn't much else, for one thing.

[MCXD]

I'd say release it sooner, but once you add some more of that 'basic functionality' that you mentioned in your most recent to-do list. Soon enough that we can catch bugs, but not so soon that we can only make about 3 things with the program to test bugs with!

[Ragnikarth]

Release it to a small team of testers who are willing to do really weird things to check for bugs.

I may or may not be the first to make a full game out of this. (right now it's "Should I use danmakufu or wait for this")

Also, are you going to release a tutorial, or at least a help file defining functions?

[Nuclear Cheese]

Looks like sooner for a testing version it is.  Hopefully I can get something together this coming weekend, so we can start seeing how much needs to be unbroken. :V

Also, are you going to release a tutorial, or at least a help file defining functions?

Documentation will, of course, be necessary at some point.  I should, at least, post up a basic list of what you can do (functions available, syntax, etc) with the testing release.

The Danmakufu wiki might end up being a good place for actual documentation ... perhaps we could start thinking about using that?


Also, I forgot in my last list - trig functions, and functions to get info on the player.  I'll edit it into the list there for consolidation.

[Naut]

The Danmakufu wiki might end up being a good place for actual documentation ... perhaps we could start thinking about using that?

Yes.

Also, I forgot in my last list - trig functions

Very, very, very, important. Don't worry about ancillary trig functions, just sin and cos is needed for now (it's really all you ever need, so yeah).

[Nuclear Cheese]

Don't worry about ancillary trig functions, just sin and cos is needed for now (it's really all you ever need, so yeah).

But what about arctangent?

[Chronojet ⚙ Dragon]

But what about arctangent? :-

Seems there's atan in Danmakufu...

[Zengar Zombolt]

But what about arctangent? :-

Cos / Sin

[Drake]

Every trig function comes from sin and cos somehow so yeah