※ Danmakufu Q&A/Problem thread 3 ※

[Andi]

So I just noticed that loose lasers have to "extend" again anytime you set their position. Is there any way around this?
(I've got a sort of "tree" of loose lasers and I'd like to have them shake around a bit before breaking away. Currently I'm just changing their angle, but that makes the "tail" shake much more than the "head". Considering trying to seamlessly swap them out with straight lasers for the shaking around bit, but that wouldn't help if I wanted to actually change its position.)

[JDude :3]

Is there any place that I can learn how to make Dialogue?Or there is a "universal" template/function in here?

[Drake]

So I just noticed that loose lasers have to "extend" again anytime you set their position. Is there any way around this?
(I've got a sort of "tree" of loose lasers and I'd like to have them shake around a bit before breaking away. Currently I'm just changing their angle, but that makes the "tail" shake much more than the "head". Considering trying to seamlessly swap them out with straight lasers for the shaking around bit, but that wouldn't help if I wanted to actually change its position.)

It often makes sense for it to work this way due to the behaviour of the lasers. A bit weird this is mandatory, but I don't really think there's a proper way to get around it. Two options:
1) If you wanted to change its position once at max length, it would make sense to swap into a straight laser.
2) It is possible to set position, set speed to laser length, wait one frame then set speed back to 0, but this is pretty weird and you do need the one frame gap in between each move for the speed calc to apply.

[Kinedyme]

It often makes sense for this to happen due to the behaviour of the lasers, but I don't really think there's a nice way to do so. Two options:
1) If you wanted to change its position once at max length, it would make sense to swap into a straight laser.
2) It is possible to set position, set speed to laser length, wait one frame then set speed back to 0, but this is pretty weird and you do need the one frame gap in between each move for the speed calc to apply.

Would it work if you had multiple lasers already created in the shaking positions and then toggled visibility between them? I don't know if hitbox detection can be disabled as well for invisible objects, but if they are not generated near to the player would it create the visual effect?

[Zinochan]

Is there any place that I can learn how to make Dialogue?Or there is a "universal" template/function in here?

You can make a dialogue by showing a image and text in a specific timing, and make that the player cannot shoot and can skip it with VK_OK.
Edit to prevent double post:
How do I flip only one part of the camera, like half the screen is flipped?(I mean flip like Seija)

[[INSERT USERNAME HERE]]

How can replicate the patterns that fairies shoot in SA Stage 4?
You know, they shoot 30-40 amulets stacked on, some time passes, then they turn a certain amount of degrees, some of them even start going backwards...

Don't kill me plz I'm new to Danmakufu

Edit: Ehh never mind I guess I've found a way to do it. -_-

[Arcvasti]

That's probably impossible to do with the basic camera functions. I don't doubt that its possible to do that, but its definitely a far greater undertaking then just flipping the whole screen around.

[Zinochan]

That's probably impossible to do with the basic camera functions. I don't doubt that its possible to do that, but its definitely a far greater undertaking then just flipping the whole screen around.

I think render targets should do it, but it is so complicated to mess with it.

[Sparen]

How do I flip only one part of the camera, like half the screen is flipped?(I mean flip like Seija)

Looking for flipping the screen like with Seija? Look no farther than the Danmakufu ph3 Tutorials! For future reference, the topics highlighted in each lesson are bulletpointed on the page.

You will find details on the 2D Camera functions and their usage in Extra Lesson 4.

[Andi]

Looking for flipping the screen like with Seija?

I think they were actually asking how to do that to only part of the screen.
Pretty sure you'd need to use render targets for that. Maybe look at SampleE02 for an example, that sort of bulges part of the screen instead of flipping it but the concept is similar.


I'm trying to put together some functions to set SpeedX, AccelerationY, etc individually instead of having to spell out every parameter in an AddPatternB*. To do this, I'm using AddPatternB2 with NO_CHANGE for all but the desired property - and, of course, x/y max speed because NO_CHANGE doesn't work on max speed for some reason (why is that, by the way?). For that I use the value stored by my custom versions of built-in functions, or, failing that, 99 times the sign of the relevant speed. I'm having a lot of issues, and until just now had very little idea why. (Well, I had plenty of ideas for things that might not work about what I was doing, but not with the particular results I was getting.)

I've just realized that the point of failure here is probably my OM_Get[X/Y]Speed function, since it only gets stored in the dictionary when I first set it and not when it changes due to acceleration. Now trying to calculate it from time since setting it, but one-half-a-t-squared isn't gonna do the job and I've had no luck incorporating max speed into the formula.

Do you have a formula for how acceleration and maxspeed are applied each frame? Preferably separate ones for SA-style and XY-style movement?
Ones with t (closed-form or otherwise) would be nice as well, but I can probably derive those myself given the per-frame ones if necessary.

[JDude :3]

I'm trying to create a Reimu player, but I can't make the player's sprite change when going to left or right.
Here's the player script, the shot data and a collection of functions

[Andi]

I'm trying to create a Reimu player, but I can't make the player's sprite change when going to left or right.
Here's the player script, the shot data and a collection of functions

ObjMove_GetAngle isn't going to work for the player. Consider how the controls work: X and Y speed are controlled separately, so it won't work any more than it would for a shot that's been AddPatternB1'd (and there's no function to get X/Y speed, either, which is what I'm currently struggling with). And that's assuming it even uses speeds instead of just setting position.
Instead, use GetVirtualKeyState(VK_LEFT/RIGHT). Something like:

Code: [Select]

let L = GetVirtualKeyState(VK_LEFT )==KEY_HOLD || GetVirtualKeyState(VK_LEFT )==KEY_PUSH);
let R = GetVirtualKeyState(VK_RIGHT)==KEY_HOLD || GetVirtualKeyState(VK_RIGHT)==KEY_PUSH);
if(     L && !R){ AnimLeft;  }
else if(R && !L){ AnimRight; }
else{             AnimStill; }
Other notes:
-Why do you need to mess with YAngle? Is that just a quick patch until you get around to changing which rects are used for which direction?
-You still have her description as "Ordinary Magician".

[Drake]

There is at least one tutorial for player scripts: https://www.youtube.com/watch?v=Dtn5EtPsJjc

And you can look at other player scripts for more direction on what to do.

As a minor detail, your animation is timed slightly off because you use non-integers in the comparisons but increment by integers. Each animation frame will alternate between 7 and 8 frames.

[Zinochan]

Do render targets keep updating? (Like you don't need to create a gazillion render targets to keep it new and fresh)

[Drake]

Once you render to the target it stays as that texture until you draw more on top or clear it. If you want it to change every frame you'll need to clear the target every frame to redraw.

[Enderswift117]

I've tried to make the design I have made spin yet I have not figured out how to make it spin, here is the code
https://pastebin.com/rQBPiaHw

[JDude :3]

Instead, use GetVirtualKeyState(VK_LEFT/RIGHT). Something like:

Code: [Select]

let L = GetVirtualKeyState(VK_LEFT )==KEY_HOLD || GetVirtualKeyState(VK_LEFT )==KEY_PUSH);
let R = GetVirtualKeyState(VK_RIGHT)==KEY_HOLD || GetVirtualKeyState(VK_RIGHT)==KEY_PUSH);
if(     L && !R){ AnimLeft;  }
else if(R && !L){ AnimRight; }
else{             AnimStill; }


It works but the sprite keeps bugging(blinking or out scaling) each time it changes the direction
The player, I didn't change anything else...

[Andi]

It works but the sprite keeps bugging(blinking or out scaling) each time it changes the direction

Some of your rects are messed up. The second one for left, (35, 50, 59, 141), and the second for right, (35, 98, 59, 93), seem to have their bottom borders swapped.

Another potential issue I noticed: Using the same variable for each direction and only resetting it when going in neither direction, plus not doing anything if it's above 56, means that the player's sprite will stay facing the wrong direction if you release one direction and press the other one frame apart.

Edit to avoid double-posting:
(^Text glow to help this not get lost, since that's happened a few times lately when I ask questions in edits.)
(Speaking of which, I still need those formulae for how acceleration/max speed are applied.)

Today I was working on my package script, minding my own business, when all of a sudden everything between the background and the overlay (not everything in the stage frame - just certain priorities, I think) starts rendering somewhere around GetScreenWidth/2 to the left of where it's supposed to be when I start the game (any mode) through the package.
I'm pretty sure the only things I had been messing with when it started happening were the package (and the two libraries accompanying it), the player script, and (maybe) the pause script. Of those, the only thing I can think of that was really related to render priorities was changing the priorities of some of the effects in the player script in an attempt to fix a bug where the parts that are supposed to be transparent (ADD_RGB) aren't. While doing so I changed them from SetRenderPriority to SetRenderPriorityI, if that matters.

Honestly, though, I basically just have absolutely no idea why this has started happening. Here's all of the code.

E: Whatever is causing it definitely involves GetScreenWidth. I changed the screen size in th_dnh.def as a test and all affected objects went off the screen entirely.
EE: It seems to return to normal at the end of a stage? Not when the stage scene is closed, but during the dialogue single at the end of the fight, after the boss explodes and is deleted. Happens with both dialogue singles I have to test.

[Enderswift117]

Every time I try to run my script as a plural script Danmakufu crashes. I can't figure out why it does.

[Sparen]

Every time I try to run my script as a plural script Danmakufu crashes. I can't figure out why it does.

We have no context. What script are you trying to run, and what do you mean by 'try to run my script as a plural script'? Without this information, it will be hard to help you.

[Enderswift117]

We have no context. What script are you trying to run, and what do you mean by 'try to run my script as a plural script'? Without this information, it will be hard to help you.

These are the pastebin uploads for all the files, what i meant was transferring the single scripts to a plural script and then running it, but every time I run it Danmakufu crashes.
Attack.txt - https://pastebin.com/VgLW4V66
Eternallight.txt - https://pastebin.com/LGsNvRP3
Testtt.txt - https://pastebin.com/sR8kf6qE
BoWaP.txt - https://pastebin.com/FPrNwnBv
Plural script - https://pastebin.com/XRkhiapL

[Kinedyme]

Hello, may I ask this again because it got buried on the last page before it was approved?

I have a question regarding Danmakufu's tasks - Is there a performance/processing cost connected to calling tasks recursively, as opposed to repeating said tasks with loops?

Thanks in advance

[Sparen]

These are the pastebin uploads for all the files, what i meant was transferring the single scripts to a plural script and then running it, but every time I run it Danmakufu crashes.
Attack.txt - https://pastebin.com/VgLW4V66
Eternallight.txt - https://pastebin.com/LGsNvRP3
Testtt.txt - https://pastebin.com/sR8kf6qE
BoWaP.txt - https://pastebin.com/FPrNwnBv
Plural script - https://pastebin.com/XRkhiapL

You need to put the contents of #Text and #Title in quotations ""

[Andi]

I think I figured out my weird issue with things being drawn GetScreenWidth/2 to the left. I tested exactly which priorities were affected (with a big line of text objects labeled by priority) and found that everything from 20-69 was affected - the same range as the 2D camera. Lo and behold, Set2DCameraFocusX(GetStgFrameWidth/2); fixed the problem. I'm guessing it's getting set to 0 at some point before there is a stage frame? This works as a patch job, but I'd prefer to figure out why it started happening and fix that so input is still appreciated.

[Drake]

Hello, may I ask this again because it got buried on the last page before it was approved?

I have a question regarding Danmakufu's tasks - Is there a performance/processing cost connected to calling tasks recursively, as opposed to repeating said tasks with loops?

Thanks in advance

Could you explain why you want to do it recursively in the first place? It shouldn't matter any more than regular recursion, as the tasks spawned recursively don't depend on the calling task once they're in the task scheduler. One main "advantage" to calling tasks in a loop is that you can have the arguments to the task depend on the loop context in some way, and this doesn't invade the task code itself. If you think there's a solid programming benefit to calling them recursively then it's probably fine. I haven't seen any particularly shallow recursion limit in DNH. That being said, recursion in general can be wasteful because you keep building up the call stack until the very end and you have to keep track of all deferred operations (i.e. there is no tail-call optimization).

E: Whatever is causing it definitely involves GetScreenWidth. I changed the screen size in th_dnh.def as a test and all affected objects went off the screen entirely.

My measurements:
640x480: -130, -18
800x600: -210, -78
960x720: -290, -138

It's adding a displacement of (-80, -60) for change in screen width of 160x120, so that's changing by that offset plus width/2. Why (130, 18) though. The STG frame is offset by (32, 16).

EDIT: nvm, it is a displacement of (-ScreenWidth/2 + StgFrameWidth/2, -ScreenHeight/2 + StgFrameHeight2)
You can also reset the camera focal point with Reset2DCamera.

[Kinedyme]

Could you explain why you want to do it recursively in the first place? It shouldn't matter any more than regular recursion, as the tasks spawned recursively don't depend on the calling task once they're in the task scheduler. One main "advantage" to calling tasks in a loop is that you can have the arguments to the task depend on the loop context in some way, and this doesn't invade the task code itself. If you think there's a solid programming benefit to calling them recursively then it's probably fine. I haven't seen any particularly shallow recursion limit in DNH. That being said, recursion in general can be wasteful because you keep building up the call stack until the very end and you have to keep track of all deferred operations (i.e. there is no tail-call optimization).

Thank you for this insight.

I envisioned that recursion would be useful for a pattern where bullets split or multiply as long as they are still on the screen. Something like this:

task CreateShot(angle, position) {
// Create shot from position with angle
// Wait for 180 frames
// If current bullet is still on screen{
// Get bullet position as 'shotposition'
// Get bullet angle as 'shotangle'
// Call task recursively:
CreateShot(shotangle + 20, shotposition)
CreateShot(shotangle - 20, shotposition)
}
// Delete current shot
}

In theory, this pseudocode should create a scenario where every three seconds a shot splits into two shots that branch off at 40-degree angles from each other until they leave the screen. It is much simpler and more flexible when designed recursively than using ascent loops to calculate spawn points and timings.
But I'm not confident with how well such a program would scale, especially if you wanted the shots to split into more than two, or if you started with more than one shot.

I understand that tail-call optimization isn't possible since tasks can't return a value, but does calling the return on a task remove it from the call stack? Can it do so even if the child tasks are still running?

[Drake]

That level of recursion is absolutely fine, you can definitely do that. I'm talking more on a very deep scale. In your example the bullets scale exponentially, but you still shouldn't have any trouble until the number of bullets gets to the point where it's ridiculous on screen anyways.

Using return in a task is just the same as letting the task end. With recursive functions, the call stack can become large with deep recursion because each function has to keep track of the context it was called from and you have to wait for the function to complete to fold back. However like I wrote above, with tasks they only need to know that until they're put in the task scheduler. That is, control returns to the parent context once the task either finishes or yields. After this a task becomes detached from its parent context -- which is also the reason tasks can't return values.

Basically what that means is that for the most part if you're using recursive tasks you don't need to worry much about building up waste unless you're doing the recursion before any yields, which is usually not the case.

[Kinedyme]

That level of recursion is absolutely fine, you can definitely do that. I'm talking more on a very deep scale. In your example the bullets scale exponentially, but you still shouldn't have any trouble until the number of bullets gets to the point where it's ridiculous on screen anyways.

Using return in a task is just the same as letting the task end. With recursive functions, the call stack can become large with deep recursion because each function has to keep track of the context it was called from and you have to wait for the function to complete to fold back. However like I wrote above, with tasks they only need to know that until they're put in the task scheduler. That is, control returns to the parent context once the task either finishes or yields. After this a task becomes detached from its parent context -- which is also the reason tasks can't return values.

Basically what that means is that for the most part if you're using recursive tasks you don't need to worry much about building up waste unless you're doing the recursion before any yields, which is usually not the case.

Thank you lots and lots: This is a very clear and informative explanation. You've helped a lot!

[Andi]

You can also reset the camera focal point with Reset2DCamera.

You know, I tried that before setting it directly and nothing happened. I think I ran into a similar issue at some point in the past as well.

E: Now I've got another issue: The game crashes instantly upon trying to load my package. And by "instantly", I mean I put WriteLogs everywhere I could think of (including @Loading and global) and none of them got executed. The last thing written to the log is the message that it's trying to load a package script (パッケージスクリプト[path]) and then nothing. Not really sure what's going on, since it neither errors nor actually does anything. Same github

[Sparen]

E: Now I've got another issue: The game crashes instantly upon trying to load my package. And by "instantly", I mean I put WriteLogs everywhere I could think of (including @Loading and global) and none of them got executed. The last thing written to the log is the message that it's trying to load a package script (パッケージスクリプト[path]) and then nothing. Not really sure what's going on, since it neither errors nor actually does anything. Same github

If it's crashing immediately after selecting it, it is, from my experience, a parsing error in the script - some kind of thing you are doing that Danmakufu cannot comprehend and crashed trying to do so.