itch.io

I will look into it.

This one may take a little longer.

Confirmed.

I will look into that as well.

Confirmed.

Some native libraries required for some actual device operation were missing.

(It was hard to notice since it was working in the simulator on the PC)

We will update the data later, but we remember the circumstances that prevented us from downloading the data immediately.

We have placed the adjusted version directly at the following address, if you would like to use it.

Thank you.
I'll take a look.

Hello.
We believe that this is some kind of glitch.
It would be helpful if you could give us a project that can confirm the glitch in order to determine the cause.
(Of course, minimal data would be fine)

This is probably due to the DirectX11 drawing system.

The line drawing process is not a process within the GPU, so the drawing is flushed at that timing and

I think the drawing data up to that point was processed in the correct order.

At any rate, thanks for the report!

Debug_DrawSurfaceArea is an instruction to produce a line.
Function for checking the position of an object's existence.
Usage is for debugging.

If (0) is specified, the line disappears.
If (1) is set, the line is drawn.

The default is 0, so there must be an instruction somewhere that sets it to (1).

A revised version has been uploaded.

It is possible to erase lines with Debug_DrawSurfaceArea(0).
(This is a function to check the area where the object exists)

Of course, if you do so, the display order will be out of order, which is the problem in this case.
It is also unexpected that the display order has been normalised by Debug_DrawSurfaceArea(1).

We'll hurry up and fix it.

Thank you for your report.

We are aware of the issue. We would like to fix it.
This seems to be happening in DirectX11.

In addition, we have confirmed that it does not happen in DX9, so you can try using it until the problem is fixed.

Basically, it should work if you use the same track number and call a different motion only once.

The intermediate animation until the motion is changed is then also reproduced.

https://ugken.com/ext/Spine/change_motion.zip

The reason for the animation being slow (or the behaviour being different to that intended)

If multiple motions are ordered, this may be due to a large number of intermediate motions being generated.

I have a Discord account, so please message me here if you like.

azarl#1872

Some of the causal areas have been corrected, please check.
"AndroidSpine_0628_test.zip".

Thank you.
We have received.

I will continue to check it out.

In the meantime, I have extended the uploader to 80 MB, is that enough?

Adjusted to work in the latest Android environment.
"AndroidSpine_0627_test.zip".

If the problem still persists after this.
It would be helpful if you could give us a file that confirms the relevant defects.
(The minimum amount of data that would allow us to check the status is fine)

Video confirmed.
We only checked the operation of the attached sample at runtime.
There may be an effect due to the state of scrolling, etc.

We would like to track down the cause and fix it.

Is this what you mean?
See sample for details
http://ugken.com/ext/Spine/MultiResource.zip

You can get the value when the event occurs.
I hope this will be of some help.
http://ugken.com/ext/Spine/EventCheck.zip

That is indeed the case.

However, it is difficult to make special changes to the composite animation behavior for channel IDs because it is part of the SpineSDK specification.
(If the animations manipulate the same material, the latter ID's animation is stronger and overrides the former.)

I think it is appropriate to deal with this in the way events are organized.

A new instruction has been added to clear the animation.

Here is a sample example of how it is applied.
http://ugken.com/ext/Spine/Test_spine.zip

It can be represented by a combination of "ClearAnimation" and "SetUpdate".

It is certainly conceivable that there may be times when you want to switch animations without animation completion.

Prepare an instruction that allows the animation to be changed without completion.

This was a point that I would not have noticed without actually working on the piece in depth.

Thanks for the report.

I did a little research to see what was going on.

Basically, when multiple SetAnimation calls are made

The animation does not switch immediately.

The intermediate animation is complemented, and then the motion set later on is applied.

In this case, when SetAnimation("17_aim") is called for the second time

SetAnimationSpeed(0) interferes with the transition from the first motion to the second motion, causing the animation to freeze.

However, when I try to reproduce this under the same conditions using SpineBoy, it works fine.

Therefore, it seems to me that the structure of the file (existence of keyframes?) is not the only thing that needs to be taken into account.

It is highly possible that this is a bug in the SpineRuntimeSDK, including the structure of the file

In the meantime, it is possible to protect the animation by preventing it from playing back when the same animation is attempted to be played back.

I think it can be handled by using an instruction on the CF2.5 side to let the same animation not be performed.

(Or perhaps adding some kind of keyframe to the file?)

-----

+ getAnimationName$( "hal_platform", 1 ) <> "17_aim"

hal_platform : SetAnimation( 1 , "17_aim" , loop=0)

-----

I tried to play multiple animations and SpineBoy did not freeze.

It seems to be a combination of factors, such as keyframes not being registered.

I found this to be the case on line 68.

It seems that the animation that has already been set is frozen when it tries to be set again.

The linkage problem we have identified here is
AIM animation set on line 68 was always running.

It appears that the animation value changes were not changing correctly.

I am glad to hear that it worked.

I understand the intent.

The two animations are not working together.
I will look into it.

Yeah, okay.
Is this what you want to do?
(Test_spine.zip)

Details.
Line 113.
"getAnimationEndTime( "hal_platform", 0 )" is
"getAnimationEndTime( "hal_platform", 2 )"

is the corresponding track ID, I think.
Although it is conceivable that it is the keyframes that are the cause, just in case

It seems that the json output is missing the time key.

For example, if you look at spineboy-pro.json
The time following the "run" item has keys up to 0.8 ("time": 0.8), and its status is recorded.

And this is the EndTime.

In the file you gave me,
The key recorded in "04_walk_spec" that you are trying to play is
"time":0.6667

and it looks like there are not enough keyframes.

SetAnimationSpeed allows you to change the animation value added to each frame.

Setting the value to 0 will stop the animation.

(uploader url)

The reference time inside Spine is 0.0166.
This is the value of (1.0sec / 60frame).

http://ugken.com/ext/Spine/AnimationTime.zip
*Updated.

In addition, it is possible to obtain events at specific times.
3 of the included sample file (Motion event), there is a sample of a function that can catch specific events when they occur during an animation.

I am not sure about specific animation freezes.
If you have reproducible data, I would appreciate it.

Is this what you mean?
I think it is possible to set the animation time so that it can be expressed

http://ugken.com/ext/Spine/AnimationTime.zip

Registration in the binary space is a necessary thing.

And although the binary data was to be extracted without an extraction instruction (the extraction instruction is executed inside the Extension)

The extraction function was not working well depending on the environment.
(I believe this has been fixed in the 20231116 version)

Thanks for the report.

This function requires that you first select the target of the change with Select_Slot.
http://ugken.com/ext/Spine/rgb_slot.zip

This is a problem with loading embedded data, but I think I was able to fix it.
Please check it out.

Appreciate the report.

RGB coefficient can be set via the editor properties
or from standard commands

Here is a sample
http://ugken.com/ext/Spine/rgb_sample.zip

I can see a few areas where there are loading errors.
I will look into it to see if it can be corrected.

(It seems to be due to Unicode, character encoding, or other environment-dependent characters.)

The binary is not extracted, maybe the mfa file of the project is corrupted.
The sample you gave me failed to read the binaries when I built it over here.

In the project where I copied the frames from the sample into a new project, the binaries also worked.
(There is no visible difference, so it is a very strange behavior.)
http://ugken.com/ext/Spine/sample2_mfa.zip