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.