Cheap way to get around this problem, just use bounding circles instead. If you want to do rotated bounding box collisions google OBB.

Use a mediation network like adwhirl (now owned by google) this way you can use iAd + admob + house ads and so forth.

You can also look at revmob.

Wire transfer can be cheaper than paypal after around 1000 USD often. There can also be tax withholding issues if paying non-usa individuals rather than companies, this also is affected by tax treaties in place.

I mean that its just a pain. Bunches of the markets have their own installers you need to build, many you need to deliver builds via email to specific representatives. So you then end up needing to contact people, build new packages, etc, for outlets that aren't really generating any revenue.

An auto updater I do suppose would make this much easier. Though it seems like they have their own share of issues due to security settings on later versions of windows, let alone also on Mac and Linux. If anyone can show me a third party auto updater that is cross platform, handles all the various gotchas, and is secure I'd love to see it though.

Although there are also distribution channels which don't allow you to use any updater other than via their store.

Memset clear the arrays at the end of the frame?

I recommend against the release it on every store idea. Many have next to zero sells, while almost all of them require custom assets, and when you go to release a patch or update, it can be a nightmare to have to update every distribution channel.

Standard 30% that is pretty industry wide.
No upfront fees.
Are tied in with the IndieRoyal bundle people.

Seemingly much less market share.
Software only on Windows.
500 USD minimum payouts (not sure what Steam has)
No services like leader boards, and so forth that I know of.

Tried the demo, I can't say much about random elements in that.

In general I really disliked it though.

1. Huge player inertia.
2. I really disliked the blue balls, as I kept thinking they we're bullets more or less.
3. Maybe just my preference, but I really prefer level layouts where with skill and memorization you can kill 100% of the enemies that spawn, its possible I really sucked at this level, but I don't think thats possible given what I saw. 

As to bullet aiming and homing stuff Udderdude really summed that up, player controls that, plus the spawn points of enemies are normally fixed so they're also often destroyed quickly.

The random bit is where exactly they spawn, bullet aiming chance, exact placement of power ups etc... The levels still feel familiar and structured between plays, but the exact positions and probabilities will be random, if that makes sense!

As a long term shooter fan, this sounds very annoying. It also likely impacts scoring. Its your game though of course, good luck

You are wrong.
DX11 support every video card that supports DX9. You just don't get the latest features for that card, but DX11 API can run on older video cards.

Yeah I suppose that is true, assuming said older cards have drivers for the newer OS which is required. Though that of course goes back to the OS requirement.

Want a good reason not to target DX10/11 besides OS?

Millions of video cards which don't support it.

[My question to you guys:]

My question to you guys:
What do you think of modern bullet hell games? In my opinion they look very pretty but everything is scripted so it is much more of a memory game. With mine there is a lot of random behaviour and AI that reacts to the player. Also enemy spawns are random, so the emphasis is more skill based (I hope!)... every encounter is unique.

And I have yet to determine what the final boss will be

I think memorization is a core aspect of general shooter design. It is what allows for mastery of levels, and zen like flow to develop to a large degree.

I only use XP, but also only inside of a VM.

I don't see any requirements for threading. http://www.opentk.com/node/210

Now if your trying to do ogg decoding and feed an OpenAL buffer, than yeah threading can help there, but for wavs I'd just load them at boot up.

Obviously performance is a potential problem. As to going fullscreen you can use AIR instead and create a native window giving you much more control over things and getting around that requirement.

Another potential solution might be to take your flash game and port it to Haxe, then use Haxe to create the desktop versions. I've not tried this myself though.

As long as your not concerned about memory use, theres no significant reason to stream from disk ogg and decompress chunks over time into an audio buffer that I can think of.

Certainly try AIR, you can create it as a captive runtime which yeah costs a few megs but so does tons of other runtime library requirements that other frameworks require.

As to resolution switching, I personally don't believe in it anymore now that LCDs are the dominate monitor type. Usually they really only have one native resolution, and anything else is going to get scaled, stretched, or adjusted.

Realize that only the latest versions of Mac OS X (Lion/MT lion) support OGL 3.0

Didn't know that. Might be a good idea to go for 2.1 if it's not an advanced 3D game, then.

Yeah its annoying... get use to glew and extension whoring.

Realize that only the latest versions of Mac OS X (Lion/MT lion) support OGL 3.0