Ability checks
-3 | -2 | -1 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SS | 0.74 | 2.96 | 7.41 | 12.59 | 17.04 | 18.52 | 17.04 | 12.59 | 7.41 | 2.96 | 0.74 | ||||||||
DW | 0.40 | 1.19 | 2.38 | 3.97 | 5.95 | 8.33 | 10.32 | 11.51 | 11.90 | 11.51 | 10.32 | 8.33 | 5.95 | 3.97 | 2.38 | 1.19 | 0.40 |
-3 | -2 | -1 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SS | 0.74 | 2.96 | 7.41 | 12.59 | 17.04 | 18.52 | 17.04 | 12.59 | 7.41 | 2.96 | 0.74 | ||||||||
DW | 0.40 | 1.19 | 2.38 | 3.97 | 5.95 | 8.33 | 10.32 | 11.51 | 11.90 | 11.51 | 10.32 | 8.33 | 5.95 | 3.97 | 2.38 | 1.19 | 0.40 |
Ok, so I've modified the sandbox so it's a regular memory bitmap & thus needs to be blitted to the screen. Not much of a performance hit (if at all) on my Mac. Now to see how it fares in Windows. Everything is still line drawing, so replacing it w/bitmaps should help a bit.
The tough part is going to be determining which quadrant each vector is in. & I really should run tests on this. But I need to know what the right answer is, 1st.
Before I even get to any of that, I need to figure out this performance problem. Look at some examples / tutorials... See if I can spot what I'm doing differently (wrong).
I wonder if there's some sort of objects-on-screen stress-test example? A blitting example, or something.
[trig. diagrams] vx1f = vx1 - m21 ⢠dvxz vx1f = vx1 - m2 / m1 ⢠-2(vx21 + a + vy21) / ((1 + a2)(1 + m21)) [I don't really know what this's about]
what?! d = √(dy2 + dx2)
So yeah, my math for that was completely wrong.
The flocking needs work. The little bit I did before work today, to implement an FOV for the bots, doesn't seem to work.
How wd I go about "overloading" the math operators for vectors in plain C?
Okay, the ships(!) flock now but it needs tweaking. They're pretty psychotic. I need to put a cap on their velocity... or something. And a better rule for when there's no other flockers in view. Then flocking for bullets.
Enemies need to have a rule for when & under what conditions to leave the screen. So do powerups.
Enemies that shoot at the player.
Handle player death / game over
Bullet paths. Enemies following paths, too. Probably clean up my code. Take more advantage of subclassing.
I know it's premature, but I'm thinking a bit about optimization, too.
I know unrolling loops is supposed to help, but I don't have any loops I can unroll.
Lasers. A secondary ship.
multiple kinds of powerups.
Ship animations?
accelleration / decelleration? (very slight)
Missles. That's what bullets w/variable paths should be used for. They'll need a timer. They seek until that timer runs out ("fuel"?) at which point they just continue offscreen.
Want to do something w/fluid dynamics. Not sure exactly... Probably some sort of background animation.
Not now, but I will want to niceify the OS X version (& probably the Windows, too) – make them behave more like native apps. Menus, being able to close the window from the title bar, etc.
Missles. Missles need trails. Now, I see 2 possibilities for this. Have each "segment" be a distinct element - say a square - that gets drawn w/o reference to the other elements. OR: draw the trail as polygons connecting 2 elements.
Treat missles as multiple seeking particles that all start moving in different directions, but converge on the same target.
Theme: steampunk. cyberspace. demonic?
Some forms of missles encircle the enemy & create a containing sigil... or something.
Story? I like the idea of a secondary story like in the 1st Katamari Damacy where it's about characters who are affected indirectly by the events in the game.
MARVELS
Ok; but that's not important now. Missles, there should be a cap (upgradeable) on how many are onscreen @ once. if (# < cap>) fire_missle();
while (ship) {
if â(dx + dy) < d {
target = ship
d = â(dx + dy)
}
ship = [ship next]
}
ok, missles are go. And they're quite powerful. Don't really like how they behave, though.
What next? New kinds of enemies? Further enhancements to weapons? Tweaks/improvements?
m1v1 + m2v2 = m1v1f + m2v2f
m1v1f = m1v1 + m2v2 - m2v2f
m1v1f = m1v1 + m2(v2 - v2f) * v1f = (m1v1 + m2(v2 - v2f)) / m1 Then solve for v2f in the other equation & substitute? where exactly does the cosθ come from? I'd have to figure that out, anyways, and I'm not 100% sure how. (Hell, I don't have a clue.) m1v12 + m2v22 / 2 = ... wait ... why the x/2? Both sides of the equation are divided by 2. Couldn't I just get rid of it? The answer to that, of course, is yes. but basically I'm solving for 4 unknowns. 2 vectors = 2 sets of 2 values each. Either force + angle or dx + dy. And I can convert between those. m1v12 + m2v22 / 2 = m1v1f2 / 2 + m2v2f2 m1(v12 - v1f2) = m2(v22 - v2f2) m1(v12 - v1f2) / m2 = v22 - v2f2 v2f2 = v22 - m1(v12 - v1f2) / m2
So I should treat all collisions (that don't destroy both objects) as collisions between spherical objects, at least as far as determining the post-collision movement vectors. Then I need to determine the line connecting their centers, and calculate the objects' movement vectors (x,y components) relative to that line. The y component will remain unchanged. [some notes pertaining to a graph that won't make sense w/o the image] v1f =
this doesn't help me! a2 + b2 = c2 ? (Do I know either a or b? I don't think I do.) This can't be that hard. Hell, if it helps I can even tweak the equation so one body is at "rest". I need a good geometry / physics book. But I can't. I'm already behind on my bills. There's the internet, granted, but that's not the same. [many more trig. notes that would be useless w/o the diagrams accompanying]