A replacement for Danmakufu?

[Nuclear Cheese]

Hey again.

I've been working on MnD's inner workings a bit, and I've got some new stuff to report:


First, error reporting has been vastly improved, since now it'll report the line number an error occurred on.  This includes both syntax errors (detected when the script file is loaded) and runtime errors.


Secondly, I just got done coding up some major optimizations for collision detection.  This has bumped up the game's performance considerably.

I have two collision performance test scripts, which each just create 100 objects that can all collide with each other.  One script uses circular objects, the other uses laser objects.  To give you an idea of the improvement, here's the FPS numbers for the old and new collision algorithms:

	Old Algorithm	New Algorithm
Circles	35-41	56-62
Lasers	26-29	52-57

... before you start thinking that it's bad, since it's choking on "only 100 objects", keep in mind that each of those objects is being collision-checked with every other one; this results in nearly 10,000 collision checks per frame.  This is something that wouldn't come up in a normal script - a lot of object pairs have no reason to be collision-checked, since there's no scripts to run for such a collision.



Here's the latest look at the running "to do" list:

Checklist update:

• Bullet definition files
• Additional functions for:
• Random numbers
• Some more mathematical functions like the power function.
• The drawing functions.
• Improved audio control (loop points, pausing/resuming, possibly fadein/fadeout)
• Improved bullet shooting functions like CreateShotA to avoid having to script overtly simple patterns with objects
• Default support for:
• Lives/respawning
• Points/Graze
• Bombs
• Power system
• Plural files, stage files, possibly game files?
• Lasers
• User-defined functions/subroutines/tasks.
• Message functions for objects.
• Various bugfixing
• Code optimization to make the program run faster (major progress)
• Better error handling (mostly done)
• *Low priority* Dialogue events.
• *Low priority* Effect objects with vertices, 3D drawing.
• *Low priority* Replays.

One more thing - I had another niffy idea, and I figured I'd throw it out here:

To help scripters figure out issues in their scripts, I was thinking of implementing a runtime script debugger.  I'd have it be a separate program that connects to MnD via a socket (meaning you could, if you wanted, run it on a different computer than MnD itself is running on), and allow you to set breakpoints, inspect variables, and other fun things. :3

It'll be a bit to implement, but I think it'll go a long way to help people figure out issues in their scripts.  Also, based on how I plan to implement it, it'll force me to refactor some of the script engine, which also will help with other things (like implementing tasks).

I have a basic idea of how the communication protocol for the debugging interface will work - it'll be all-text, so it won't be a pain to implement another program to interface it (or, if you're a bit crazy, access it through telnet :V )

[XephyrEnigma]

Oh, so you're actually going through with this? If you get a perfectly stable version out I will love you forever.

[Stuffman]

This is starting to look really good. How long until we have function documentation? That's the only thing really stopping me from playing around with it at this point.

[Nuclear Cheese]

Oh, so you're actually going through with this? If you get a perfectly stable version out I will love you forever.

Technically, the current "Test Release" is "perfectly stable", albeit feature-incomplete. :3

This is starting to look really good. How long until we have function documentation? That's the only thing really stopping me from playing around with it at this point.

It might be a bit out of date (I think I last updated it a bit before the last test release), but there is this page on the MnD project site.  Between that and the sample scripts that come with the Test Release, you should hopefully be able to get something rolling.

[XephyrEnigma]

Uh.. If I were to make some folders to organize everything (so that all the resources arent in one folder, would that still work?

[Nuclear Cheese]

Uh.. If I were to make some folders to organize everything (so that all the resources arent in one folder, would that still work?

Sorting the files into subfolders is file, so long as you add the folder names to the files when you reference them in code.

For instance, if you have an "images" subfolder to store your visual resources, you could do something like this:

SetImage("images/cool.png", false, 30);



You'll notice I used a forward slash ('/') instead of a backwards one ('\').  While either will work fine on a Windows system, the backwards slash won't work on non-Windows systems (which should (hopefully) be supported via Mono), so using a forward slash makes the script (theoretically, at least) more portable.



(btw, for reference - the "false" indicates that the image will not rotate as the object rotates, while the "30" indicates what layer the image is drawn on - higher layers get drawn over lower layers.

[XephyrEnigma]

One last little thing here, if I wanted to use an animated picture for a sprite, I can do so? Or do they absolutely have to be static?
(I'm guessing I can, but looking for confirmation)

[Nuclear Cheese]

One last little thing here, if I wanted to use an animated picture for a sprite, I can do so? Or do they absolutely have to be static?
(I'm guessing I can, but looking for confirmation)

Right now, the only way to animate a sprite is to keep reassigning its image each frame (not much different than what you'd do in Danmakufu).  Basically, you need a static image of each frame of the animation, and set the appropriate one each frame in your script to have it animate in the game.

I have thought about adding the ability to script simple animations, but that wouldn't come until later.

[Stuffman]

Maybe a nice, easy way to do it would be some sort of, like, image equivalent of CreateShotA?

CreateAnimation(image x, image y, true/false looping);
SetAnimationStep(same parameters as SetImage, number of frames);
SetAnimationStep...
SetAnimationStep...
StartAnimation();

It would need to read the variables in image x and image y each frame so it could be moved dynamically, and you'd need to make it more complicated if you wanted to have the ability to kill the animation before it's finished, so I guess it's not really that simple. Still, even something as lacking in functionality as the above would be pretty useful.

[Azure Lazuline]

As long as there's some equivalent of #include_function, there's no reason NC would have to make an animation library. Just leave it to the users, like how Blargel made one for Danmakufu.

[Stuffman]

Well there's no reason he has to do anything besides the most basic graphics and object functions since we could program everything else ourselves, but it's nicer to have that stuff built in :V

That said, I don't expect him to do anything beyond DMF's graphic functions, it's just a suggestion worth thinking about.