~Hakurei Shrine~ > Rika and Nitori's Garage Experiments
Evolution of Danmakufu
<< < (2/3) > >>
Helepolis:

--- Quote from: Naut on July 21, 2009, 08:51:22 PM ---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).

--- End quote ---
This

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

--- Quote from: Helepolis on July 21, 2009, 04:07:43 PM ---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.
--- End quote ---

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).




--- Quote from: Thaws on July 21, 2009, 04:12:21 PM ---What's the difference between for loops and ascent loops?
--- End quote ---

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.




--- Quote from: Helepolis on July 21, 2009, 09:18:09 PM ---
--- Quote from: Naut on July 21, 2009, 08:51:22 PM ---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).

--- End quote ---
This

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

--- End quote ---

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.




--- Quote from: Suikama on July 21, 2009, 04:47:24 PM ---for loops work something like this:

--- Code: ---for (a in b){do something;}
--- End code ---
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.
--- End quote ---

*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: ---for ([declaration]; [condition]; [iteration])
{
  [stuff];
}
--- End code ---

is equivalent to the following while loop

--- Code: ---[declaration];
while (![condition])
{
   [stuff];
   [iteration];
}
--- End code ---

While it is true that they are generally used for counting, they do have a wider variety of uses.



--- Quote from: Suikama on July 21, 2009, 04:47:24 PM ---Of course this wouldn't really work if the variables a and b weren't numbers, ...
--- End quote ---

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:

--- Quote from: Nuclear Cheese on July 21, 2009, 11:48:37 PM ---can programming even be eligible for the status of "hardcore"?

--- End quote ---
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:

--- Quote from: Nuclear Cheese on July 21, 2009, 11:48:37 PM ---
--- Quote from: Helepolis on July 21, 2009, 09:18:09 PM ---
--- Quote from: Naut on July 21, 2009, 08:51:22 PM ---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).

--- End quote ---
This

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

--- End quote ---

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.

--- End quote ---

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.
Navigation
Message Index
Next page
Previous page

Go to full version