Second'd FlashDevelop.

As for "installing" either of those.  Flixel has no installation per se, you just drop the org folder of into your development folder and boom, done.

For Box2d there are two different libraries out there, one is an swc (a precompiled library) and the other is a pure AS3 port of Box2d.  I would recommend using neither.  Both are pretty slow.  
For physics in AS3 I would recommend nape.  It is much faster (e.g. I was unable to get more than 180 dynamic objects in Box2d without slowdown, but I'm able to get 2500 in nape), easy to use, and was designed for AS3 from the beginning (as opposed to just being a port).  
EDIT:
I also forgot.  Personally, I'm moving away from Flixel and am using nd2d as my renderer of choice.  This makes particular sense for you if you want to use a different physics engine than the one supplied by Flixel.  If you need help getting this pairing set up, I can help.

I'd recommend reading about the separating axis theorem.  While you can reduce this case to simple checks as Jasmine says, it wouldn't be a bad idea to understand it in more general terms.

http://en.wikipedia.org/wiki/Separating_axis_theorem
and
http://www.codeproject.com/KB/GDI-plus/PolygonCollision.aspx

Are good resources.

The standard rules of thumb for hitboxes:
1) Bad (enemies, projectiles, etc.) hitboxes are smaller than what is shown
2) Good (powerups etc.) hitboxes are larger than what is shown
3) The player hit box is just about (perhaps a touch smaller) than what is shown

If you don't mind me asking, why no external libraries?

Just started playing last night, so I don't have too much to say.
What I can say is that I'm loving the included music CD.  That shit is phenomenal.

The places where a PCG system make sense:
1) Where content can be samey but shouldn't be the same.  e.g. trees
2) Where having the same content repeated makes the game uninteresting (or less interesting or just goes against the design principles of the game). e.g. Roguelikes (turning from strategy game to puzzle game)

To make a good PCG level design system you must:
1) Be able to differentiate between a good level and a bad level.
2) Be able to design a good level
3) Be able to create a system of rules that can do either 1 or 2, and hopefully both (the easiest is typically creating a system of rules that can do 1 well and 2 decently, so that you can just reroll if you determine it isn't good)

Personally, I don't think a danmaku is a horrible choice for PCG.  The Geometry Wars games sort of get to that type of play (i.e. find the negative space [or create it yourself]) and are PCG.
That being said, you should understand what makes a danmaku good and/or bad, beyond the level of "know it when I see it". And if you can do that, then you should probably be able to make a good level by hand.

The architecture I put up doesn't look to have serious bottlenecks (also after some runs in the profiler, where the killer is maths).
There's a variable number of threads that casts a ray for each single pixel in it's assigned rect in the backbuffer.
The world is made of an std::map containing Regions; each Region containing 16x8x16 Chunks; each Chunk contains 8x8x8 Tiles.

Both Regions and Chunks have an "empty" pass-through flag that makes the rays skip them without recursing. Ray casting is done via some bresenham 3D variant (not really correct right now, but still).

I know there are other ways, but I wanted to try some raycasting 

And... doing it with polygons looks like quite impossible. It would be like minecraft, but with 512x cubes (8x8x8 where now there's one block).

Have you tried marching cubes?

I love it when someone who doesn't understand the code goes to edit it and breaks it, then doesn't say anything about it to me so I spend an hour trying to figure out why it's suddenly broken.

My favorite example of that comes from one of my coworkers.

When she was in college, she had a group coding assignment.  Her partner noticed that one function always returned true, so he replaced the function with true.  Obviously, the function didn't always return true, and he horribly fucked up the code.

Well, st33d, the next time you are in the market for an AS3 physics engine, try out nape.  I don't know what it can do with computers in the "bored housewife" range, but I'd imagine you could get a lot out of it.

To resolve the inside/outside problem you need think in terms of a clockwise boundary (turning in the + direction) and an anticlockwise boundary (turning in the - direction), rather than a min/max.

if(the angle is within the valid range modulo 2*PI)
 {do nothing}
else
 {snap to the nearest boundary}

Yup.

Although, I have to say I'm slightly confused by the original question.  Just to clarify, you have a desired angle that the turret should be aiming, the turret has constraints on its range of motion, and you want to set the actual angle of the turret such that it is as close as possible to the desired angle. I'm thinking something like in Peggle, where you can aim the mouse wherever but there is a limited range within you can release it.  Is this correct?

Ok, so I found the best solution of all: a pre-existing that does all I want, more, and is super fast. 

As a note for anybody looking for a good Flash physics library, check out nape (actually it's in haXe, so I'd recommend it to haXe people as well).  It's not as fully featured as box2d (no CCD is the biggest thing that stands out to me, but there's other stuff as wel), but it's a hell of a lot faster in Flash. 

In my box2d demo, I was topping out at about 300 dynamic bodies at 60fps, whereas I am doing 2500 comfortably with nape (and figured that the stress test could reasonably stop there).

@Boris:  Hmm...I'll give it a shot, but I need more than just sensors. Maybe you can tell me if box2d would be worth it for what I need (since I see that you are heavily involved with one of the box2d as3 ports).

Here is what I need:
Dynamic/Dynamic collisions.  Some can be just sensors, but others would need for restitution to be applied. e.g. bullets are just sensors, but enemies are physical objects and could push each other around.

Dynamic/Static collisions.  Player and enemies will be able to collide with the terrain.

Beyond that, I don't really need anything. 

I was using box2d, but it was quite slow.  Admittedly, there were large amounts of bodies.  I tried putting ones that weren't affecting gameplay (something like 1.5 screens away to be safe) to sleep manually, but it didn't really help.

So, the questions:
What can/should I turn off? 

I don't have the code available, but what would be the proper way to put bodies to sleep that won't affect the gameplay?  Should I instead just have some sort of coarse check that runs periodically to see if an object might affect the game and have it add it's body to the simulation and then remove that body when it can no longer affect the game?

None of the Box2D AS3 tests have the number of objects on the screen that I envision. Would bullet hell style numbers of objects be possible with the correct things turned off (obviously the bullets would just be sensors, but I don't know if there are other optimizations to be made)?

I'm curious as to what people's favorite shmup ship designs are (if you have any).  I'm in the process of making a shmup and wanted to see if there were any particularly good designs out there that I am unaware of (and to see what people think makes an attractive shmup ship).

Personally, I'm partial to

Ikaurga


and

Vic Viper

Eh, I have something that does everything that I need (rotation, convex polygons, circles) and is fast (enough for me at least), so there's no point in using a full physics engine and turning off what I don't need.  I'm making a shmup, so actual physics (physical rotations, stacking, etc) aren't necessary, but I wanted to be able to rotate convex polygons and have accurate collision detection, so here we are.

I got my collision detection/restitution code working after a small amount of fuss.

Is there a reason why all of the ready made 2d collision detection/physics systems out there fall into one of two camps: Full physics simulations (e.g. box2d) or simple AABB systems (I'm thinking flixel, flashpunk, but it's so simple it doesn't really matter if you use a preexisting one or roll your own). There are no preexisting ones that allow for slightly more complex shapes/concepts (OBB's, convex polygons, circles) that don't do way more physics simulations than I care about. 

Am I just missing something or are there these types of codes out there and I wasted a day reinventing (or rather reimplementing) the wheel?

Unless it's simply a concern over maintenance and whether or not it simply gets neglected, but even then, I think it'll be ok. Personally I could build games against the Flex 4.5.1 SDK (with AIR 3.1 overlaid) for quite awhile into the future and be just fine.. I think.

I think this is a good point.  Just because maintenance might slacken (or drop off entirely), doesn't mean that it completely invalidates the technology.   Rich over at photonstorm was thinking about making a new game framework for Flash, but has since started to question it because of all of this hullabaloo.  I can sort of understand this, but only marginally.  If you think the platform is good enough to warrant making a new framework as it is right now, then who cares if it isn't maintained?

You are on the money there re: "::".

Although, it could also be a static member of the class (doesn't really make sense in this case, but it could be).

Maybe you aren't understanding.  Gameplay CAN NOT be protected by copyright.  So long as you don't use the name Archon (which would be a trademark issue) or use protected assets (graphics, sounds, music), you can make whatever game you want to make.

So, your next step is to make your game.

It's relatively easy to create an access violation error - much harder to track it back to the source.

And even easier to create a memory leak.
As others said, use some sort of smart pointer.  It will make your life a hell of a lot easier (especially since you are coming from a memory managed background and this stuff hasn't been beaten into you yet).

The point is, I think you and Jhonathan Blow are talking about an imaginary group of "Expert coders" who are not good at finishing programs. And somehow think all people who write articles in the academia belong to those "Expert coders" who can't finish software. And that is the reason why they don't give complete code with their articles.
Well, most people who write CS articles in the academia are actually very inexperienced programmers, because they don't code that much.

Just because people at your university suck at programming, it doesn't mean it holds true for the whole world. Most of the time, people who teach programming are good programmers (it's logical). Just because you were unlucky to be taught about computer by people who doesn't know what they are talking about it doesn't mean all of us were.

You don't understand some fundamental problems that are being discussed here, really.

Actually, I have to disagree with you.  A technical school can teach programming, but programming != computer science.  Certainly, programming is a part of computer science, but true computer science (from my experience) doesn't care as much about programming as it does about algorithm design, proofs, etc.  

And being a good programmer != clever programmer.  Computer science as a field tends to care about clever programmers.  Those who are able to find new theoretical limits and improve on algorithms.  But those algorithms are often unwieldy, unintuitive, and are only practical in limited (i.e. not real-world) circumstances. A good programmer is one who creates good, understandable, reusable code, which is not necessarily something that is going to set academia on fire.