Wily's weapon, if I'm thinking of the right one, is just a set of two or three energy balls that moves in an orbit around the shot point in a steadily increasing radius.
So the fundamental part of the code is just:
this->X = counter * Sin(wobble);
this->Y = counter * Cos(wobble);
counter++;
wobble++;
There's a few things wrong with your code:
1. Adjusting Vx and Vy with Sin and Cos is tricky. You won't necessarily get a circle if you do that; you'll get an osillating shape of some sort. Remember, sin and cos are periodic functions that go back and forth between -1 and 1 as the variable (wobble, here) increases. So if you want a circle, adjust X and Y directly.
2. I don't follow your logic in multiplying Vx by the previous Vx each time. Doesn't that lead to an exponentially increasing speed if Vx is greater than 1, and a exponentially decaying speed if Vx is less than 1?
Well it needs to move along it's original velocity from the point it is shot at while moving in a circular pattern. It's not like I didn't try X before Vx with these. And yeah, this is the one that got a super fast giant circle that would wrap around the screen. heh.
So if I am reading that right, your suggesting an initial "counter" of this->X, and this->Y, before moving on to the sin and cos bit..? ..hmmm..I think that's what you mean, otherwise wouldn't it start from the top left corner?
Something like this?
...Heh, now I gotta go test it.
ffc script ffc_wobble2{ void run(){
int wobble = 0;
bool init = false;
while(true){
if(this->Y > 152||this->Y < 8||this->X > 232||this->X < 8){
this->X = 0; this->Y = 0; this->Vx = 0; this->Vy = 0;
this->Data = 1; init = false;
}
if(this->Vx != 0 || this->Vy != 0){
if(init == false){
int tx = this->X; int ty = this->Y; init = true;
}
else{
this->X = tx *Sin(wobble);
this->Y = ty *Cos(wobble);
wobble++; tx++; ty++;}
}
Waitframe();
}
}
}
Oh, I finished a ffc script that simulates Quick man's boomerang attack, which is oddly named ...auto_fork. 😮dd:
It lets the projectile go about it's business, stops it for a second, then look out from above.
for example: auto_fork combined with spread_shot would rain down 3x the normal projectiles at steady intervals.
I think you're right about making things more modular. You can use the same scripts to customize them in a shitload of ways.
Gleeok wrote:Well it needs to move along it's original velocity from the point it is shot at while moving in a circular pattern.
I still don't follow. The projectile comes out of the enemy at, say, x1, y1. It starts moving away from the enemy and clockwise or counterclockwise. In other words, all it is doing is moving in a circle of steadily increasing radius. Perhaps my use of the term "counter" was misleading. The code I provided wasn't just set up code. It should handle the entire movement. Radius keeps increasing with each tic, thats all. If you have multiple projectiles, they each start with their own "wobble" variable at regular intervals around 360 degrees.
Gleeok wrote:I think you're right about making things more modular. You can use the same scripts to customize them in a shitload of ways.
Yea. We need to set it up so that the player doesn't have to do anything but assingn scripts to FFC slots, and the scripts are by and large able to interact intelligently. So the designer doesn't have to script if they dont want.
Okay. hrm, I'm still stumped. I think we're thinking of 2 different things. I'll try to explain better.
------------->
^^projectile being shot at Vx = 1.
Now from here you can add utility scripts with no extra setup to the ffc slot used by the projectile (btw I finished ffc_bounce...[bounces the projectile off walls]) 😊 -So what im thinking of would be a circular rotation of a set radius that follows the original path of the projectile (in this case Vx = 1) where it moves across the screen in a circle. Kinda like scorpio sting item...that's doable, right?
Oh, I see what you want. A "rolling" shot like the fire weapon in Contra 1.
Your problem is the equation of a circle.
x = a1 + b1*Cos(c1*t);
y = a2 + b2*Sin(c2*t);
(a1, a2) = the center of the circle
(b1, b2) = the radius of the circle (will be elipse or other shape if b1 does not equal b2)
(c1, c2) = the speed of the object's movement around the circle as t changes (will not trace the same orbit each time around if c1 does not equal c2)
In the code you posted, you're only changing the radius of the circle, not where it is centered. Yours is centered at (0,0) which is probably what is giving you a headache.
So how can you point to exact center of the circle if it is moving at an unknown rate from an unknown point of origin?
Well...i'm stuck on the logic that "a" wound be this->location and would not be good to use that because its always adding + ellipse. which would fuck it up.
Did I mention I hate trig and geometry. 😛
Gleeok wrote:So how can you point to exact center of the circle if it is moving at an unknown rate from an unknown point of origin?Well...i'm stuck on the logic that "a" wound be this->location and would not be good to use that because its always adding + ellipse. which would fuck it up.
Did I mention I hate trig and geometry. 😛
The concept is easy to grasp with two FFCs.
FFC #1 moves according to Vx and Vy in a straight line.
FFC #2 moves in a circle centered around FFC#1. (That is, a1 and a2 are equal to FFC#1->X and FFC#2->Y, respectively).
With me so far?
You can get rid of FFC#1 by making variables that will act just like FFC#1->Vx, Vy, X, and Y. Name them orbit_hub_Vx, orbit_hub_Vy, or whatever.
So each iteration through your weapon's loop (each frame), orbit_hub_X increases (or decreases) with the value in orbit_hub_Vx. Then the orbiting FFC (called FFC#2 above) is set to move in a circle centered on the new orbit_hub_X and Y.
Get it?
Oh, I see now. It's still not perfect due to the fact that there are a billion different combinations of Vx, an Vy. and orbit_hub increasing or decreasing its X, or Y position every 2-5(?) frames would be hard pressed to match Vx and Vy of an actual ffc without some crazy ass complicated math formula.
...Well, I should ask anyway. Is there a simple(haha) routine to crunch numbers?
...ugh, i've got a headache already just thinking about it. ;P
Gleeok wrote:Oh, I see now. It's still not perfect due to the fact that there are a billion different combinations of Vx, an Vy. and orbit_hub increasing or decreasing its X, or Y position every 2-5(?) frames would be hard pressed to match Vx and Vy of an actual ffc without some crazy ass complicated math formula.
...Well, I should ask anyway. Is there a simple(haha) routine to crunch numbers?...ugh, i've got a headache already just thinking about it. ;P
What? Why? Vx and Vy do nothing but change X and Y each frame. Very simple to simulate. What's the problem?
Wait, so ffc X and Y can return decimal places!? ...If that's true then should be easy to do. I hope it does anyway. ...lets see
....
ffc script ffc_wobble2{ void run(int radiusX, int radiusY, int speed){
if(radiusX == 0){radiusX = 16;}
if(radiusY == 0){radiusY = 16;}
if(speed == 0){speed = 4;}
int wobble = 0;
bool init = false;
int tx; int ty;
int tvx; int tvy;
while(true){
if(this->Y > 168||this->Y < 0||this->X > 248||this->X < 0){
this->X = 0; this->Y = 0; this->Vx = 0; this->Vy = 0;
this->Data = 1; init = false;
}
if(this->Vx != 0 || this->Vy != 0){
if(init == false){
tx = this->X; ty = this->Y;
tvx = this->Vx; tvy = this->Vy;
init = true;
}
else{
this->X = tx + radiusX*Cos(speed*wobble);
this->Y = ty + radiusY*Sin(speed*wobble);
wobble++; tx += tvx; ty += tvy;
}
}
Waitframe();
}
}
}
I am hereby putting you in charge of the orbiting weapons division at Wily corp.
-also finished setting up more tile animation and combo cycling, and more large ffc's.
-updated the item sprites(there should now be plenty for any kind of weapon)
-added more enemies
-and random coloring and tile fixes.
-other random stuff
To the best of my knowledge, yes, FFC->X and FFC->Y can return decimal values. How else could an FFC move at rates like Vx = 0.5 each tic?
I'll change the Taurus Flame weapon to move at an upward angle but also in tight little circles. You'll see the code there.
So I've recruted someone to help with the set. Joe123 has the file right now, and the next thing i'll probably do later on is finally add the ffc->Data and some scripts. Also I figured, hey, why not make a megaman game as the stuff gets added to it. Seems reasonable to me.
MegaMan_Tileset_ver5.4.zip -Right click, save as. Don't worry, no more Mediafire, It's become really shitty lately so I stopped using it.
Now for the question on palettes:
Joe thinks the level palettes suck balls. I only half agree here, because all the colors fit in to cset 2,3,4 making it really quick and easy to make screens. If these were to be completely redone how should the end result look? If I do in fact redo all the tiles they will most likely be in a 8-bit level palette so as to be of the same structure as SNES MM tiles. (snes tiles not added yet)
What does anyone think needs to be fixed with csets 2,3,4?