Oh god acceleration

[Hat]

My bullet acceleration is going CRAZY. I'm trying to make a code where a bunch of these white bullets drift downwards with varying accelerations in one direction or another, just slightly (think Chen's spellcard in PCB). However, crazy CRAZINESS has been happening. First, when I set the x-velocity maximum to 99, in a crude attempt to get rid of maxima (because I was trying to fix an earlier problem which I will detail shortly), the bullets all leapt to the edge of the screen like they were trying to outrun the swine flu, I swear to god. They might as well have VANISHED. The best part was that I defined the x-acceleration to be 0.00001, and yet they still fled like it was a freaking pandemic.
But the story does not end there, my friend. I tried using rand(-0.05, 0.05) to make the drift randomized, but instead, they all just drifted to one side... aah, see for yourself. The effects are really strange (moreover, I don't get why half the bullets dive to one side, and the other half drift the way they're supposed to).

No comments about how this spell would be impossible even if it COULD work. It's a work in progress atm, and that's why the code is haphazard and flying all over the place.

Code: [Select]

#TouhouDanmakufu
#Title[Cloud Sign "The Moryo are Silently Watching"]
#Text[Spell card 02]
#Player[FREE]
#ScriptVersion[2]

script_enemy_main {
    let ImgBoss = "script\img\ExRumia.png";

    let frame = 0;
    let frame2 = 150;
    #include_function "lib\SHOT_REPLACE\shot_replace.dnh"

    @Initialize {
        SetLife(2000);
        SetTimer(120);
        SetScore(1000000);

        SetMovePosition02(GetCenterX, GetClipMinY + 120, 120);
        CutIn(YOUMU, "GOD DAMN ASS SHIT BOB SAGET", "", 0, 0, 0, 0);

        LoadGraphic(ImgBoss);
        SetTexture(ImgBoss);
        SetGraphicRect(0, 0, 64, 64);
        TMain;
        shotinit;
    }

    @MainLoop {
        SetCollisionA(GetX, GetY, 32);
        SetCollisionB(GetX, GetY, 16);
        yield;
        if(frame%20 == 0 && frame >= 0){
          Moryo(frame2);
          frame2 -= 20;
        }
        if(frame == 80){
          frame2 = 150;
          frame = -120;
        }
        frame++;
    }

    @DrawLoop {
        DrawGraphic(GetX, GetY);
    }

    @Finalize {
        DeleteGraphic(ImgBoss);
    }
task TMain{
    yield;
    TMove;
}
task TMove{
    let stepsize = (GetClipMaxX - GetClipMinX - 60)/4;
    let move_y = GetCenterY + rand(30, 120);
    let move_x = GetClipMinX + 30;
    let disc = 1;
    SetMovePosition03(move_x, move_y, 3, 10);

    loop{

      loop(4){
        move_y = GetCenterY - rand(30, 120);
        if(disc == 1){
          move_x += stepsize;
        }else{move_x -= stepsize;}
          SetMovePosition03(move_x, move_y, 3, 10);
          loop(20){yield;}
        }
        disc = -1*disc;
        loop(120){yield;}
      }
    }
function Moryo(frame_b){
    let angle_m = rand(0,360);
   
    loop(8){
      CreateShotA(0, GetX, GetY, 1);
      SetShotDataA(0, 0, 10, angle_m, 0, -1, 0, WHITE03);
      SetShotDataA(0, 7, 0, 0, 0, 0, 0, WHITE03);
      SetShotDataA_XY(0, frame_b, 0, 0.1, rand(-0.01, 0.01), 0.1, 3, 5, WHITE03); //GOD DAMN THIS LINE OF CODE. GOD DAMN IT TO HELL
      angle_m += 45;
      FireShot(0);
    }
    loop(16){
      CreateShotA(1, GetX, GetY, 1);
      SetShotDataA(1, 0, rand(7, 11), rand(0, 360), 0, -1, 0, WHITE04);
      SetShotDataA(1, 7, 0, 0, 0, 0, 0, WHITE04);
      SetShotDataA_XY(1, frame_b - 10, 0, 0.2, 0, 0.1, 99, 3, WHITE04);
      FireShot(1);
    }}
}
Enjoy this madness. Oh, and set the x-max to 99 to watch the BULLET JIG OF THE CENTURY. Oh ya, and I used the bullet replace script, but every cool kid in danmakufu should have that by now (I used pretty standard bullets anyway, but I dunno what will happen if it can't find the script)

[Naut]

Record your screen, it's working perfectly on my computer. The bullet's do pretty standard things, as in, drift to the bottom of the screen. It's not very random though, but I can see what you're trying to accomplish.

To answer why it might be going bat-shit Bob Saget on your ass, I have a theory. One that I'm actually going to record, if I get around to it. The theory is simple:

Danmakufu fucking sucks.

Allow me to elaborate. Sometimes Danmakufu will just not do what you want it to do. There is nothing you can do about it. And it will infuriate you to no end, but you can't do shit. My theory was that this shit happens if you overload the allocated memory for danmakufu (for example, trying to represent a fucking massive floating point number, for those of you who know what that means). Or when your computer can't properly calculate things fast enough, and if affects things other than your FPS. I do have evidence towards my favor, unfortunately.

Two events in question.

DeleteEnemyShotImmediatelyInCircle(); stops working in the middle of the script, even though it is called every frame and does not change in anyway. I think this is because I was incrementing a value by an incrementing value that was being incremented by another value increasing by one every frame (don't fucking ask). After a certain amount of time would pass, the DeleteEnemyShotImmediatelyInCircle() stopped deleting shots (the radius of the circle was too large for bullets to skip over) and the script would erupt into a massive cavalcade of fury. As cool as it was to see this function fail for no aparent reason whatsoever, this infuriated me, and eventually I stopped the incrementing loop and everything worked perfectly. I didn't save the effed version of the script, but I might try to reproduce it for documentry purposes.

The second event had to do with object scripts. Admittedly, at the time, I didn't really know what I was doing in regards to object scripts, but in retrospect, there was nothing for me to screw up. It was simply changing a frame value from 79 to 78, that made the script move from spawning 2 bullets to spawning 25986896134 and making the screen go white, and chaos ablaze. Interestingly enough, setting the frame value to ANY OTHER NUMBER (above or below) set the bullet loop to spawn only one bullet. I have yet to discover the reason for this, but because of this, I never use the number 78 for anything, regardless. I want to capture this on film as well, it was most humourous.


Anyway, the point of all this is: Your script works perfectly on my screen (or, does exactly what you've typed, and sounds very close to what you described was the goal), yet you claim that it goes nuts on your screen. Danmakufu is fucked. All is lost.


On a serious note to actually solve your problem, you might want to just retype out your script in a different way and see if that works. Sometimes shit just doesn't work properly, so you have to dick around another way to get it to.

[Hat]

Pfahahahah! Well, that's a very mixed bag, there. Good AND bad news. The good is that I'm not a failure, the bad news is that I've been slaving away at a program that doesn't do what it's supposed to. Lovely.

[Naut]

Usually only happens when you've called something exceptionally large or excessive, that you could've probably done some other way for the same effect (which I can only speculate). All that said, it's still the best shooting game maker available that's relatively easy to understand and pick-up.

...Isn't it sad, Danmakufu?

Anyways, can you at least take a screenshot (or two) of what's going on with your script? It sounds funny.

[Iryan]

I'm not really shure if that is how acceleration works, but...

If you say the acceleration is a random number between (0.1 and -0.1), it can be either positive or negative. Now, you have only a positive number as a (min/max) speed value and 0 as the starting speed value.

This could cause the following things if your acceleration is negative.

a) because the direction of acceleration is the opposite of the direction your maximum velocity is going for (from 0 to 5 is increasing, a negative accel is decreasing), the number 5 is then seen as the minimum velocity to which the bullet slows down, thus all bullets for which the accel is negative will be fired at a precise speed of 5, which is much! The bullet will usually leave the screen in less than a second.

b) as the cap is higher then the starting value even though the acceleration is negative, the cap is ignored. With an accel of 0.1, this means that, after one second, the bullet will have a speed of 6 and will have moved by a distance of 0.5*(60^2)*0.1,  which is 180, or almost half the width of the playing field. In other words:
The bullet will leave the playing field in little more than 1 second.


Either way, about half the bullets have the potential to kick off like there is no tomorrow. To get rid of this possible cause of error, you could define a variable, lets call it "pol", then, each time during your loop, you will set this variable randomly to either 1 or -1, for example with

Code: [Select]

pol=(1-2*rand_int(0, 1));, then give the bullet a max speed of 5*pol and an accel of rand(0, 0.1)*pol.

Note, however, that 0.1 is already a very high acceleration. Look at scenario b) up there, and you will notice that the bullet will leave the screen in less one and a half second if the acceleration is 0.5 even if the maximum is 5. you might want to decrease the maximum acceleration to something like 0.05 or even 0.02. I never use acceleration higher than the latter. 0.02 means that your bullet reaches a speed of 1.2 after the first second and 2.4 after the second second, and so on.

So long.

[Suikama]

Something slightly related yet unrealted: If I make a bullet fired at a speed of 30 every single frame, instead of firing the shots, they become fixed onto the screen. I found this out when creating my silly danmaku paranoia card. When I set the middle aimed stream to be fired too rapidly and to quick, then they stopped moving altogether.

[Naut]

Haha, that's because of how speed works in Danmakufu. What velocity to Danmakufu is how many pixels you want to shift the bullet's position to for the next frame, towards the angle you specified. So since you're shifting the bullet 30 pixels every frame, it skips thirty pixels. The reason why they look stationary is because you spawn bullets everty frame, so every frame it draws the bullets on those same spots.

Here's a test to prove my point. Create a bullet every frame with 99 speed and GetAngleToPlayer. Move around. The bullets will follow you. Get close to the bullet. You'll get insane amount of graze.

[Hat]

So as it turns out (figured it out the next day, it came to me when I woke up, lol), what I was doing wrong was I was trying to feed a many-decimal number into a frame count. I used rand instead of rant_int when I was making the little wee modifier for the clouds falling down, so I guess that made the game's brain go blooie.

I've kind of given up on this card, though. It was a neat thought in concept, but I cannot be troubled to think of a way to make it possible (I reduced the number of jumps to three, and cut out the small white bullets entirely, but there are still times when you are thoroughly trapped).

Aah, I'm starting to get bored of Danmakufu... I need ideas.

[Naut]

I've taken a while to sit and think about this, but I can't seem to figure it out. Why would it work fine on my computer? What a pissoff that is.

Also, we all go through times where coding just isn't as rewarding as it once was, and you need a bit of a break. If you do enjoy it however, you'll come back to it in no time, so no worries. Coming up with spellcard ideas is always the hardest part about coding in Danmakufu.

Aside from, of course, coding in Danmakufu.

[Single manly tear]

[Hat]

Well, my computer is an award-winning retard, for one, so that might have something to do with it (which is why I have trouble thinking of new cards, because I always VASTLY underestimate the maximum number of bullets I should have on the screen at once).

I have a couple ideas for weather-themed danmaku, but only a couple (obviously the one here was a test-drive of one of the ideas, which didn't quite work out the way I planned, in that it was impossible XD) Also, I keep getting stalled with the Yuka PC project, because I always strive to accomplish things that cannot possibly manifest in Danmakufu.

[Naut]

Hmm. What are the effects you're looking for? Usually there isn't enough syntax in Danmakufu to directly accomplish what you're looking for, but with all of us thinking, we can usually find a workaround (however makeshift it may be).

[Hat]

Hmm. Let's wait until I have the basics of Yuka down, then I can get to the over-elaborate bomb mechanisms. XD

I'd use the drawloop to animate Yuka's different sprites, though, yes? One for stationary, left and right, etc? (There's probably a thread about this... ah well)

[Naut]

Yes sir. In Stuffman's player script tutorial, he tells you how to animate the left, right and stationary graphics properly. In the first post, even!

[Hat]

... heheh. =D Whoops.
Actually, he only said how to make the graphic CHANGE, something that is fairly simple (which I knew already, from inspection of other player scripts). It's the animating bit that's a little wierd, as that needs to be housed separately in the drawloop. I think.

[Naut]

No sir, not that hard at all. What you'll wanna do is create a variable that you'll increment every drawloop.

Code: [Select]

@DrawLoop{
drawcounter++;
}
Then you'll probably want to use the modulus function (%) to correctly animate per frame. You'll want to get how many frames you want to skip per each animation frame (like, you wont want the animation changing every frame because it would look garbage, so you'll want to diddle with the modulus function a bit to corespond with how many frames you want to skip inbetween changing the animition frame. So, using the modulus function of a counte, you can put the following (for left movement):

Code: [Select]

if(GetKeyState(VK_SHOT)==KEY_PUSH || GetKeyState(VK_SHOT)==KEY_HOLD){
 if(drawcounter%6==0){
  SetGraphicRect(0,0, 64, 64);
 }else if{drawcounter%6==1){
  SetGraphicRect(64, 0, 128, 64);
 }else if{drawcounter%6==2){
... Etc.

I go on a shpeel about how to use the modulus function in another thread, if you're unfamiliar with it.

[Hat]

I know how to waltz the modulus waltz. D=< Who do you take me for?

Ah, yeah, that's what I thought I'd have to do. It's just so TEDIOUS...

[Garlyle]

Yeah, but such is what you have to do.

Also, don't have the image change every frame.  Remember, there's 60 frames in a second when running at full speed - changing every frame would literally be so fast that the images would all blur together.

Changing only every 3-10 frames should result in smooth animation depending on how many different frames there are and how fast you want it to look.

[Naut]

You'll want to get how many frames you want to skip per each animation frame (like, you wont want the animation changing every frame because it would look garbage...

Also, don't have the image change every frame.  Remember, there's 60 frames in a second when running at full speed...

...if you're unfamiliar with it.

I know how to waltz the modulus waltz. D=< Who do you take me for?

_{Does anybody actually read what I say...?}

[Hat]

I was making a joke... =o I didn't mean it!

And yeah, I know I'm gonna have to space out the frames somewhat. I'm using the PoFV Yuka sprites anyway, making it moving at sixty fps would look HILARIOUS, but awful.

[Naut]

If you don't want to dick around with a massive if() statement (like if(drawcounter%42>=5 && drawcounter%42< 9 || drawcounter%42>=16 &&...etc){}, you could just animate every single frame, which would be tedious but you're almost guarenteed not to screw up.

Also, 60fps animation is definately hilarious, I've tried it before. Oh my...