james7132 / danmaku Goto Github PK

Potentially 2 types :

• With a single float value, applying to both x and y (uniform scaling)
• With a Vector2, to change both x and y (independent scaling)

The advantage of solution 2 is that you could simulate the rotation of a bullet around an axis with a behaviour. (for instance scaling down X or Y to zero to make it look like it's rotating around the X or Y axis).

Requirements

• Progressive Stages
• Life/Bomb tracking
• Score Tracking

Almost all objects require a DanmakuField and a lot cannot function without a reference to one. This results in calls to Util.FindClosest in almost all Awake calls.

Util.FindClosest is slow due to a call to FindObjectsOfType and should have an alternative built into the DanmakuField type itself.

To improve the variety of colliders Danmaku can use several collider types should be added:

• Box
• Line
• Point

This problem can be replicated in a few ways:

1. Using the Test Scene, enable both emitters and set the frame rate of one the emitters to something like 9999 while the other can be left at 0. After some time, bullets by the other emitter will disappear before reappearing when the 9999 frame rate emitter starts shooting again.

2. Disable one of the emitters after it has been shooting for awhile. Bullets by other emitters will also disappear until the disabled emitter is re-enabled.

Technically, the other emitters are still enabled and will still continue to run their own Update() and call their own fireable.Fire(). In fact, their bullets are still in existence and collisions by these danmaku will still register with DanmakuColliders and trigger OnDanmakuCollision (even though you can't see them).

However, all bullets will no longer be rendered while any one of these emitters are disabled / "lagging".

Fast, generic way to fire bullets and define bullet patterns with scripting support.

Add Danmakufu style coroutine handling.

• Handled by the Danmaku Game Controller
• Needs to take game pausing into account
• Needs support for:
  • Wait for single frame
  • Wait for multiple frames
  • Wait for seconds
  • Wait for conditions via delegates or predicates
  • Nested tasks

Use Triggers to activate Projectile Emitters instead of having each of them run their own timer.

Should be able to do the following:

• Accumulate a score to show to the player
• Have an accessible interface for developer made scripts
• Handle high scores

There has been recent interest in reviving DanmakU as a project after it fell into disrepair.

If you are interested, please respond or react for a vote of confidence.

Right now the new implementation uses a GameObject rendering backend. This can introduce lots of lag.

The Guide is still incomplete, for example the "Handle Collision" part.

At DanmakU\DamakU Plugin\Runtime\Fireables\Shapes\Circle.cs

Method : Fire

float radius = Radius.GetValue ();
int count = Mathf.RoundToInt (Count.GetValue ());
var rotation = state.Rotation.GetValue ();
for (int i = 0; i < count; i++)
{
    var angle = rotation + i * (Mathf.PI * 2 / count);
    state.Position = state.Position + (radius * RotationUtiliity.ToUnitVector (angle));
    state.Rotation = rotation;
    Subfire (state);
}

I think the right implemention is

float radius = Radius.GetValue ();
int count = Mathf.RoundToInt (Count.GetValue ());
var rotation = state.Rotation.GetValue ();
var origin = state.Position;
for (int i = 0; i < count; i++)
{
    var angle = rotation + i * (Mathf.PI * 2 / count);
    state.Position = origin + (radius * RotationUtiliity.ToUnitVector (angle));
    state.Rotation = rotation;
    Subfire (state);
}

Since the state.Position will be change during the "for" loop.

I just found this bullet system and if you continue it will be greats!
Thank so much!

Hi, thanks for the great danmaku project you shared !
I want to ask about why the instantiated bullet doesn't appear in the hieararchy ?
I would really appreciate it if you are willing to answer this newbie question. Thank you !

http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/index_e.html

At Method in Asset/DanmakU/Runtime/Bounds2D line 115.

Method "Intersects":

public bool Intersects(Bounds2D bounds) {
    return (Math.Abs(Center.x - bounds.Center.x) < Extents.x + bounds.Size.x) &&
            (Math.Abs(Center.y - bounds.Center.y) < Extents.y + bounds.Extents.y);
}

I think the correct condition is

public bool Intersects(Bounds2D bounds) {
    return (Math.Abs(Center.x - bounds.Center.x) < Extents.x + bounds.Extents.x) &&
            (Math.Abs(Center.y - bounds.Center.y) < Extents.y + bounds.Extents.y);
}

Requirements:

• Generalizable effects
• Interchangeable with Projectiles - same underlying data structure
• Pooled like Projectiles

Hi,
So I've just created a new game object as a ground with one of the collider script you created. I tried it with collider2D attached but still not working, Then I add rigidbody2D to it but still the same.
Can you help me please why this is not working for me ?

I know that you aren't supporting this package.

However I'm really interested in it. When I download the source cod project, there are some missing references in the hierarchy test scene (GameObject and Test). Can you tell me what are the scripts that are supposed to be there?

Kind Regards,

Currently all of the danmaku object updates are entirely single threaded. A great performance boost should be attainable by multithreading each update.

Several parts are required:

• Minimize the number of Unity API calls needed to be made in each update
• Create an effective alternative threadpool, since Unity Mono doesn't have one that actually works effectively.

http://virtualdropkick.com/page/danmakujson-documentation-format

In an attempt to move away from using Unity objects to render bullets and items, a generic, automatically batched rendering object needs to be created.

This will also ease the transition into multithreading the kit, as it removes the need for Transform manipulations in danmaku/item object update calls.

Can also be generalized to be the underlying object for handling Item drops as well.

The current implementation of Danmaku Pool has an occasional bug when spawning new bullets where it encounters a IndexOutOfBoundException that effectively stops all danmaku movement.

This needs to be fixed.

This is not true; C#'s % is Danmakufu's modc.

Causing collisions to occur, even when the collider is nowhere near the bullet.

Attached is a mp4 showing the issue (Happy to upload to youtube or something if you'd prefer.) Note the bullets turning red when the collider (attached to the ship sprite) isn't close to them.

An example of a Danmaku's OldPosition and Position the moment it triggers a collision:
OldPosition (271384100000000000000.0, 236805600000000000000.0) Position (300.0, 0.0)

Which is pretty clearly uninitialized data leaking into physics calculations.

I was able to fix this behavior by initializing OldPosition on a Danmaku whenever a Danmaku was created.

I added:
OldPositions[danmaku.Id] = danmaku.position;

in three places in DanmakuPool.cs.
(I'm putting together a pull request.)

video.zip

Need 3 Types:

• Static: Shows itself several frames before doing hitbox collisons. Does not move.
• Standard: like bullets, but gradually grow in size until it is a certain length;
• Curved: Has angular velocity parameter.

Due to the way DanmakuPool and DanmakuRenderer interact, whenever a bullet is destroyed, the rendering order of the most recently fired bullet is altered.

The DanmakuPool is implemented as a class of parallel arrays and a active count. A bullet is identified by it's index along these arrays. If the index is less than the active counter, the bullet is active. Spawning a new bullet simply involves incrementing the active counter. Destroying a bullet involves and swapping the values of the latest spawned bullet with the destroyed bullet then decrementing the active counter. This is effective at creating and destroying bullets as these actions does not allocate or deallocate any memory, nor does it create objects.

The rendering system pulls batches of X (currently 4096) colors and transforms for bullets to render. For performance reasons, this is done sequentially via memcpy. This means that the order of bullets within the pool is also the render order of those bullets. Newer bullets are rendered after older bullets, or at least it should be that way: the bullets swapped by the destruction of other bullets interrupt this ordering, causing random bullets to start appearing out of order as others are destroyed.

Resolution options:

• Sort by spawn order - re-sort the pool by spawn order if and only if bullets were destroyed in a given
  update. Assuming the pool remains almost sorted frame to frame, an insertion sort pass would be an
  effective O(n) average case pass through the pool.