Evolution of Danmakufu

[Henry]

As a Danmakufu user, I think many of us have some opinion about Danmakufu. I hope it is a good place to let people discuss how it can be improved.

I shall share some of my ideas:

1.

Code: [Select]

let x,y; doesn't work in Danmakufu, but DOES work in C.
2. I hope the for loop can be used in Danmakufu because it is really useful

[Helepolis]

I am not a programming guru but what is the difference between a 'for' loop and a 'while' loop anyway? and as far as I know the regular 'loop' function is pretty godlike in danmakufu. And don't forget that Danmakufu is based on C, not nessecary C. Besides this is a bad evolution post.

And aside the discussion about improvement, is it possible to even modify current engine of Danmakufu? Is there source code? Want real evolotion? Give us scriptable MoF/SA/UFO engine with more ShotData abilities as maximum of 255 IDs suck.

[Thaws]

What's the difference between for loops and ascent loops?

I am not a programming guru but what is the difference between a 'for' loop and a 'while' loop anyway?

I think 'for' loop is pretty much ascent loops in danmakufu. I use ascents alot, because I can have a temporary varible for bullet spamming at varying angles more conviently as I don't have to declare it beforehand, and it increases itself by 1 each time it loops automatically.
It's basically a more limited 'while' loop for things like those you know how many times it'll loop already.

[Suikama]

for loops work something like this:

Code: [Select]

for (a in b){do something;}So let's say b is something like number of pixels in a picture. The loop will then run once for every pixel in the picture, and the variable "a" will be assigned to the current pixel of each loop.

while loops work something like this:

Code: [Select]

while (a){do something;}or

Code: [Select]

while (a == True){//or FALSE
    do something;
    }Basically while loops use booleans, and will continue to loop while the overall statement is TRUE, and stop when it becomes FALSE. If you don't give the while loop something that will eventually become FALSE, it will run forever and crash.

for loops are essentailly while loops that end once it has looped for every object. So for the given examples it might look something like this:

Code: [Select]

while (a < b){
    do something;
    a++;
    }Of course this wouldn't really work if the variables a and b weren't numbers, so you would have to do it differently for other things. Thus it would be easier to just up a for loop.

Hope that helps (and that I didn't mess up somewhere...)

[Naut]

1.

Code: [Select]

let x,y; doesn't work in Danmakufu, but DOES work in C.[/code]

Code: [Select]

let x; let y; too much to type? Don't even need to type them on separate lines.

2. I hope the for loop can be used in Danmakufu because it is really useful

loop, while, ascent and decent are too much of a bother....? I'm sure you can manipulate them fairly easily to achieve what you're looking for.


Honestly, I'm more concerned with being able to manipulate the boundries of the field, freely editing what operates around the edge of the screen (points and whatnot, add your own, remove another section, etc) and being able to set the drawing layer of everything I create on the game inside a spell card script (being able to say that the player will be drawn on layer 7 instead of layer fucking 3).

[Helepolis]

and being able to set the drawing layer of everything I create on the game inside a spell card script (being able to say that the player will be drawn on layer 7 instead of layer fucking 3).

This

As my spellcard in my Afro boss has like too many flashy effects blocking the lifebar, timer and spellcard name =.=

[Nuclear Cheese]

And aside the discussion about improvement, is it possible to even modify current engine of Danmakufu? Is there source code? Want real evolotion? Give us scriptable MoF/SA/UFO engine with more ShotData abilities as maximum of 255 IDs suck.

Quick check of Danmakufu's site - I don't see any download for the source.  So editing Danmakufu's code to extend its functionality by our own desires is very unlikely.

It'd probably be easier, honestly, to just bunker down and write up our own engine.  Trouble with that, though, is that its just a bit complex to parse syntax even approaching what Danmakufu is capable of, let alone something of a complexity rivaling, say, C++.
Honestly, though, I do think I could get behind such a project.  I know I can do pretty much every piece of it ... only thing I'd need to figure out is the script parsing.  Bonus point - since I normally use C# and SDL.net, it could be incredibly easy to play it on non-windows systems by using Mono (although, lacking a decent non-windows test platform, I haven't actually tried this yet).

What's the difference between for loops and ascent loops?

An ascent loop is Danmakufu's incredibly limited version of a for loop.  It allows a loop where a counter variable, well, counts up from one number to another.

To be fair, though, I don't use ascent often/ever (personal bias, mainly), so I might not have the best of grips on any nuances it has.

and being able to set the drawing layer of everything I create on the game inside a spell card script (being able to say that the player will be drawn on layer 7 instead of layer fucking 3).

This

As my spellcard in my Afro boss has like too many flashy effects blocking the lifebar, timer and spellcard name =.=

Not sure if it'll help, but have you looked at effect objects?  If you're just looking to have eye candy, those let you determine what layer they're placed on.

Other than that, I agree it is a bit limiting with the draw order.  I believe the order is based on what would normally be considered the "most important things to see" in the game.  For instance, seeing things like enemy bullets is much more important than seeing the enemy lifebar.  By my observation, this is the reasoning behind Danmakufu's normal draw order - things that require the player's attention the most get drawn above everything else, so that the player (hopefully) has their attention where it's needed.

for loops work something like this:

Code: [Select]

for (a in b){do something;}So let's say b is something like number of pixels in a picture. The loop will then run once for every pixel in the picture, and the variable "a" will be assigned to the current pixel of each loop.

*obsessive code freak mode ACTIVATE*

Technically, what you described is a foreach loop - that is, it does the contents of the loop for each element in some construct.

A true for loop, by how it is defined in C and many other languages, is basically a shortcut for a while loop, mainly intended for counting purposes (but which can be repurposed quite generally).  Using C syntax, the for loop

Code: [Select]

for ([declaration]; [condition]; [iteration])
{
  [stuff];
}
is equivalent to the following while loop

Code: [Select]

[declaration];
while (![condition])
{
   [stuff];
   [iteration];
}
While it is true that they are generally used for counting, they do have a wider variety of uses.

Of course this wouldn't really work if the variables a and b weren't numbers, ...

Actually, it'd work just fine, regardless of the data type.  All you need is the right operators defined for it.  Of course, this is getting into pretty "hardcore" programming techniques (can programming even be eligible for the status of "hardcore"?).




... er, sorry.  End rant.

[Suikama]

can programming even be eligible for the status of "hardcore"?

Uh...

P=NP? :V

[Henry]

Em...
Ascent/Descent is a very limited version of for loop with the iteration step 1.
The advantage of using for loop is you can track the starting and finishing points easily.
The advantage of using a while loop is when you are not certain when the iteration will end.

In fact, as NC said before, for loop and while loop can be interconverted.
But in my opinion, I like for loop more

[Naut]

and being able to set the drawing layer of everything I create on the game inside a spell card script (being able to say that the player will be drawn on layer 7 instead of layer fucking 3).

This

As my spellcard in my Afro boss has like too many flashy effects blocking the lifebar, timer and spellcard name =.=

Not sure if it'll help, but have you looked at effect objects?  If you're just looking to have eye candy, those let you determine what layer they're placed on.

Other than that, I agree it is a bit limiting with the draw order.  I believe the order is based on what would normally be considered the "most important things to see" in the game.  For instance, seeing things like enemy bullets is much more important than seeing the enemy lifebar.  By my observation, this is the reasoning behind Danmakufu's normal draw order - things that require the player's attention the most get drawn above everything else, so that the player (hopefully) has their attention where it's needed.

Alright, then my main issue is Danmakufu assuming things that I'd like to have the option of changing at some point. It assumes that I won't want the hitbox to be seen above everything (seriously), and I'd like it to... un... assume that. Now, this is a very poor example since I know I can use effect objects and laugh it to death with SetLayer, but I'd like to be able to change things from inside a spell card script, not the actual player scripts themselves. A better example would be: "I want the default characters to have real hitboxes that don't require me to script and run a task alongside my @MainLoop processing an effect object drawn over the player's X and Y coordinates.... Every single spell card." I should be able to say something like

DEFAULT_OVERRIDE{
    SetPlayerLayer(7);
    SetFrameLayer(5);
    SetBulletLayer(6); //Oh baby
}

Or whatever. For anything. Any property that is automatically set by Danmakufu should be editable. Point item value multipliers, SetScore multiplication rates, layers of random shit, the outter frame's graphic (instead of having to put it in some folder and name it some special thing).... Etc. All of it should be editable in some way from directly inside of a spellcard.

While I'm ranting, you should also be able to get more information than a player's focused and unforcused speed, as well as numerous information from enemies. It should be no problem detecting collision with an enemy or getting it's current angle.... But it is. Just ask Drake. Getting information from any other script is a pain in the ass, if it's even possible. There should be easier ways to do this.

These are the things I want to see changed for Danmakufu 1.0, if it ever comes/is made by somebody else and called something different.... _{Like OpenDMF.}

[Drake]

I've been at it for weeks and still haven't gotten it exactly yet, lol.

But yeah. Considering the limitations in Danmakufu to begin with, I don't think it'd be wise to even attempt editing Danmakufu rather than just making a new program altogether.