I have decided I am going to try to obtain some kind of electronic drumset.  I know nothing about this subject and I do not know how to play the drums. I have this idea I can get something that is set up like the drumset from Rock Band, but when you hit things it plays sampled or synthesized drums or something. I saw something like this for sale at Best Buy once and i'm not even sure what the vocabulary for it is. Ideally whatever I get, I would be able to plug a MIDI cable into it (or are they replacing MIDI with USB these days? I Just want to be able to input MIDI into a sequencer program) or else in a pinch plug just a sound cable into it and plug that directly into my computer to record audio. I am intending this only for recording music with the computer.

I originally wanted to get a "real" drumset because I am usually very sensitive to sampled instruments feeling more fake and repetitive than live ones, but then I realized that since this really is all for recorded music getting live drums would require me to learn a great deal about things like drum tuning and more about recording practices than I know now (most home-recorded drums seem to have very bad digital clipping and have this not-altogether-pleasant punchy sound to all the drums, and I've been told the "correct" way to record drums is to mic every drum and then carefully adjust levels, which just, holy crud, I can't do that) in order to get even the most basic sound. And the process for converting live drums to output MIDI (something I do want someday) sounded complicated.

Would anyone know-- what are my options here? What should I look out for? How much should I expect to pay? Will I get something significantly different/better depending on what price point I'm aiming at? My current plan is to stumble into some music stores and ask them what they have.

Turns out that it is an interesting Ubuntu 11.10 "feature": the -l commands HAVE to be the last thing in the gcc command; AND they have to respect a specific order that is arbitrarily selected by the spirit of Stallman permeating the GCC (WHY libgl must come before lua, WHY?). If you fail to abide, every single symbol results as undefined.

I sorted the -l's via try and error, and now I learned to stop worrying and love open source 

I *think* this is normal in GCC of all platforms and types, and probably non-gnu cc's, I seem to remember that the idea is you must list -ls in the order that libraries depend on each other. So if liblua.a references symbols in libgl.a, then you must put -lgl before -llua? This is because as you go left to right (or is it right to left...) the linker adds each new object file or library one by one, so if libdonkey needs zlib_fuckbiscuits() then you must have instructed the linker to load libz before libdonkey. My memory is fuzzy on this though.

Earthbound used sampling heavily in its music! (The sound chip in the SNES was basically a sampler, but Earthbound was almost the only game I can think of where the music treated it like one instead of trying to mimic traditional instruments). In fact there is a persistent rumor I have never tried to verify, that the reason Nintendo will not re-release Earthbound on VC in America is because it has several uncleared samples of pop songs owned by litigious entities. The specific example I was given was a claim that there are actually Beatles samples in there and, thinking about it, the strange little loop that plays in the cave you seek in the Lost Underworld does sound seriously like a chopped up version of the intro to All you need is Love...

If it's a 2D game, what are you doing that requires C++?

I'd suggest looking into Flashpunk/Flixel. Beginner-friendly, effortless to deploy, works well for 2D stuff.

A bit simple compared to some of the other things posted here, but something I decided made my life much much easier was a dedicated class for representing rectangles.

Code:

#ifndef CP_RECT_H
#define CP_RECT_H

// Include cpVect.h first

// Set to -1 for "opengl style"
#define YFLIP 1

// A rectangle class based on cpVect. Not the same thing as a cpBB.
// Any non-inlined methods are defined in util_display.cpp

inline cpVect xflip(cpVect v) { v.x = -v.x; return v; }
inline cpVect yflip(cpVect v) { v.y = -v.y; return v; }

inline cpVect u_yflip(cpVect v) { if (YFLIP > 0) v = yflip(v); return v; }
inline cpVect d_yflip(cpVect v) { if (YFLIP < 0) v = yflip(v); return v; }

struct cpRect;
cpRect cpr(cpVect,cpVect);

struct cpRect {
cpVect center;
cpVect rad;

inline cpVect size() { return cpvmult(rad,2); }
// Upper left, Upper Right, Down left etc using OpenGL coords
inline cpVect ul() { return cpvadd(center,u_yflip(xflip(rad))); }
inline cpVect ur() { return cpvadd(center,u_yflip(rad)); }
inline cpVect dl() { return cpvadd(center,d_yflip(xflip(rad))); }
inline cpVect dr() { return cpvadd(center,d_yflip(rad)); }

inline cpFloat u() { return center.y-YFLIP*rad.y; }
inline cpFloat d() { return center.y+YFLIP*rad.y; }
inline cpFloat l() { return center.x-rad.x; }
inline cpFloat r() { return center.x+rad.x; }

inline cpVect vert(int at) {
switch (at) {
case 0: return dl();
case 1: return ul();
case 2: return ur();
case 3: return dr();
}
}
inline void fill(cpVect *v) {
v[0] = dl(); v[1] = ul(); v[2] = ur(); v[3] = dr();
}

inline cpRect translate(cpVect by) {
return cpr(cpvadd(center,by), rad);
}

inline cpRect scale(cpFloat factor) { // Toward 0
return cpr(cpvmult(center,factor), cpvmult(rad,factor));
}

inline cpRect inset(cpFloat factor) {
return cpr(center, cpvmult(rad,factor));
}

inline cpRect inset_fixed(cpFloat by) {
cpVect r = cpv(max<cpFloat>(0,rad.x-by*2),
   max<cpFloat>(0,rad.y-by*2));
return cpr(center, r);
}

inline cpRect align_u(float to) {
cpRect r = *this;
r.center.y += to-(r.center.y-YFLIP*r.rad.y);
return r;
}
inline cpRect align_d(float to) {
cpRect r = *this;
r.center.y += to-(r.center.y+YFLIP*r.rad.y);
return r;
}
inline cpRect align_l(float to) {
cpRect r = *this;
r.center.x += to-(r.center.x-r.rad.x);
return r;
}
inline cpRect align_r(float to) {
cpRect r = *this;
r.center.x += to-(r.center.x+r.rad.x);
return r;
}

inline cpRect set_u(float to) {
cpRect r = *this;
cpFloat offset = (to-(r.center.y-YFLIP*r.rad.y))/2;
r.center.y += offset;
r.rad.y -= YFLIP*offset;
return r;
}
inline cpRect set_d(float to) {
cpRect r = *this;
cpFloat offset = (to-(r.center.y+YFLIP*r.rad.y))/2;
r.center.y += offset;
r.rad.y += YFLIP*offset;
return r;
}
inline cpRect set_l(float to) {
cpRect r = *this;
cpFloat offset = (to-(r.center.x-r.rad.x))/2;
r.center.x += offset;
r.rad.x -= offset;
return r;
}
inline cpRect set_r(float to) {
cpRect r = *this;
cpFloat offset = (to-(r.center.x+r.rad.x))/2;
r.center.x += offset;
r.rad.x += offset;
return r;
}

inline cpRect reflect_x() {
cpRect r = *this;
r.center.x = -r.center.x;
return r;
}

inline cpRect reflect_y() {
cpRect r = *this;
r.center.y = -r.center.y;
return r;
}

inline cpVect scale_for(cpVect size) {
return cpv(2*rad.x/size.x, 2*rad.y/size.y);
}

static inline cpRect square(cpFloat r) {
return cpr(cpvzero, cpv(r,r));
}
};

inline cpRect cpr(cpVect center,cpVect rad) {
cpRect r = {center, rad};
return r;
}

inline cpRect cpbounds(cpVect ul, cpVect dr) {
cpRect temp = {cpvzero, cpvzero};
cpFloat u,d,l,r;
if (ul.x > dr.x) {
r = ul.x; l = dr.x;
} else {
l = ul.x; r = dr.x;
}
if ((YFLIP>0) ^ (ul.y > dr.y)) {
u = ul.y; d = dr.y;
} else {
d = ul.y; u = dr.y;
}
return temp.set_u(u).set_l(l).set_d(d).set_r(r);
}

#endif // CP_RECT_H

Doing this let me interface with the rectangle using natural expressions like "the bottom of the rectangle" or "the size of the rectangle" instead of littering math everywhere.

Note: This requires cpVect.h/cpVect.cpp from the Chipmunk physics engine.

EDIT: Looks like there actually isn't a way to suppress this warning anyway?!

Possibly not explicitly, but there's some flag stuff that can get around most of that nonsense.

Yeah, was looking at that-- problem is, none of those flags appear to allow you to suppress the warning. Those are just the flags that allow you to fix the warning. But (hard to tell for sure) what I eventually worked out was happening was:

- I have a project.
- It links against libraries A, B, C, D, and E.
- Libraries A, B and C were built with visibility setting F.
- Libraries D and E were built with visibility setting G.
- Therefore, if I build my project with visibility setting F, I will get warnings when I link against D and E.
- But if I build my project with visibility setting G, I will get warnings when I link against A, B, and C.

So the problem doesn't look fixable in my case. So it looks like I have to weigh which one of the following options is the lesser imposition:

1. Recompile libraries A-E myself, carefully auditing each one to ensure that it is doing exactly the right thing wrt this "visibility" feature which looks throughly useless and which I have no incentive to learn anything about except to suppress some warnings. It should be noted these are all open source libraries not specifically targeting mac, and atm they are all being built via a cmake meta-script which I did not write. I don't know cmake.
2. Tolerate two junk warnings forever.

I don't like either option but I feel likely to go with (2) :|

[I DON'T CARE]

ld: warning: TiXmlDocument::~TiXmlDocument()has different visibility (default) in /Users/mcc/work/p/beth/Polycode/Framework/Core/lib/libPolyCore.a(tinyxmlparser.o) and (hidden) in /Users/mcc/work/p/beth/build/PolycodeTemplate.build/Debug/PolycodeTemplate.build/Objects-normal/x86_64/svgloader.o

I DON'T CARE

Is there any possible reason that suppressing the "different visibility" linker warning could come back to bite me

EDIT: Looks like there actually isn't a way to suppress this warning anyway?!

Incidentally, before I go writing a parser and affine transform class, would there happen to be a good library or sample code C++ SVG parser out there in the world somewhere?

7.6 The ‘transform’ attribute

The value of the ‘transform’ attribute is a <transform-list>, which is defined as a list of transform definitions, which are applied in the order provided. The individual transform definitions are separated by whitespace and/or a comma. The available types of transform definitions include:

matrix(<a> <b> <c> <d> <e> <f>), which specifies a transformation in the form of a transformation matrix of six values. matrix(a,b,c,d,e,f) is equivalent to applying the transformation matrix [a b c d e f].
 
translate(<tx> [<ty>]), which specifies a translation by tx and ty. If <ty> is not provided, it is assumed to be zero.
 
scale(<sx> [<sy>]), which specifies a scale operation by sx and sy. If <sy> is not provided, it is assumed to be equal to <sx>.
 
rotate(<rotate-angle> [<cx> <cy>]), which specifies a rotation by <rotate-angle> degrees about a given point.
If optional parameters <cx> and <cy> are not supplied, the rotate is about the origin of the current user coordinate system. The operation corresponds to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0].
If optional parameters <cx> and <cy> are supplied, the rotate is about the point (cx, cy). The operation represents the equivalent of the following specification: translate(<cx>, <cy>) rotate(<rotate-angle>) translate(-<cx>, -<cy>).
 
skewX(<skew-angle>), which specifies a skew transformation along the x-axis.
 
skewY(<skew-angle>), which specifies a skew transformation along the y-axis.
 
...

The following is the Backus-Naur Form (BNF) for values for the ‘transform’ attribute. [A full page of text follows]

What the shit, SVG standard

You are an XML format

The entire reason I want to use your XML format is so I don't have to write a complicated parser

Why are you specifying this in a way I potentially have to write a complicated parser

Couldn't you just use XML

I'm already using ncurses, which is quite helpful, although I've run into some trouble with stuff actually happening as I allow the game loop to run; I suspect (probably erroneously) that ncurses has some built in behaviors that prevent it from printing anything to the screen when everything is happening in such small time intervals (I'm working in intervals using gettimeofday() on linux).

Then I *think* you want to be calling timeout(0) at the start of the program so that ncurses' special getch() will return immediately rather than waiting for input.

(If you're doing the priority queue thing I suggested you could, just before calling getch(), figure out how long until the next scheduled event and set the timeout() to that exact period, which would give you potentially more efficient CPU utilization, but there's very little reason to bother with this.)

I don't understand why using a queue would be better than having update functions local to each object. For one thing, I don't understand how queue works,

So-- maybe I misunderstand what you mean. If the idea is, your loop consists of, check if there's user input, if so act on it, otherwise iterate over all the objects/monsters on screen and call update() on each--  for a roguelike, I agree that this idea is as at least as good as the queue thing I mentioned, probably better. Iterating over each object in this way would be easier to code even if you did understand what I was suggesting with the queue.

nor do I understand why it's better than what I've proposed.

Again, maybe I misunderstand. The only thing you originally proposed was multithreading. Multithreading here would be an ant's nest that would make your life very unhappy very quickly while giving disproportionately small benefit, especially since the way you described it you seemed to desire a separate thread per monster.

What engine are you using?

Uh... none? The code I'm using is all made by me.

How are you receiving "events"? I.E. how do you know when the player has pressed a key? Are you using SDL? Win32 events? getch()?

I'm currently using getch() just to play around.

The simplest answer is don't wait for input, just react to whatever the input is.

I'm not sure I understand this.

You want to not be using getch() because it's blocking.

You want to find an alternate method like _kbit() on Windows or this bullshit on Linux, a method which will return the key pressed if there is keyboard input or return 0 immediately if there is none.

Even better, switch to a library like SDL or pixeltoaster or whatever where you have a more sophisticated way of receiving keyboard, mouse, etc input than just using old broken stuff like getch(). You may be particularly interested in finding a "curses" library. "Curses" are a family of libraries that allow you to do command-line programs which have intelligent ways of listening for keyboard input (better versions of getch() basically) as well as making ascii layout easier. This will allow you to stay in text mode and will not make you learn complicated stuff like SDL or drawing.

Eventually you want to have a loop where over and over you

- Check to see if the user pressed a key
- Check a queue you made, of events which should fire at particular times, to see if you have something you need to do now

Then instead of having your monster-behavior code work like, instead of "do this, wait 4 seconds, then do this other thing", you "do this, place an item in the queue saying 'do [blah] at time now + 4 seconds', 4 seconds later the item is pulled out of the queue by your main loop and calls a function that does the other thing"

What engine are you using?

Uh... none? The code I'm using is all made by me.

How are you receiving "events"? I.E. how do you know when the player has pressed a key? Are you using SDL? Win32 events? getch()?

I can't think of a video game I considered to have succeeded at being sexy or erotic.

Though Fire Emblem got very close omg

Random comments:

I remember the free Objective C book on Apple's website being really good and a quick read. I think this is what I'm thinking of:

http://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf

Don't underestimate developer.apple.com for getting started guides, there's a lot of good material there it's just unfortunately not as well organized as it should be. The example code section is particularly of note. I think at some point I wrote a script to just download all the iOS examples and was happy I did so...

Start with the Cocoa stuff on Mac OS.  It will much easier to work with, and most of your knowledge will transfer with very little modification.

I would actually disagree with this. Cocoa Touch is much simpler, and cleaner-- Cocoa Normal has a lot of cruft left over from sometimes as far back as the 80s and shows scars of all the things that have changed in Cocoa programming in the last ten years. Conversely, Cocoa Normal has some really nice features you might start to depend on (kvc/bindings, which if you're programming for desktop you want to do absolutely everything with) and then will have to learn to do without in Touch.

I'm not sure I have a good idea of where to start. A couple things I would say: Make sure you start off coding with properties. I think a good hello-world-ish program that would introduce you well to a lot of the things you need to understand would be a toy program that displays data in a UITableView or NSTableView.

Here are some things that, if the goal is to become adept with Cocoa, you should aim to deeply understand the answers to these questions at some point:

How do you maintain and use a UINavigationController stack?
What's an NSAutoreleasePool, and why would you want to create one?
What's a proxy object, and how would you implement one?

(That last thing will almost never come up in practice, but if you understand it then you understand a bunch of things you do need to know about using Objective C.)

At least 50% of GAY PORN actors are heterosexual men who never thought they'd do this until they needed the money.

How am I supposed to enjoy my gay porn knowing the actors are being exploited

I might suggest using an NSOpenGLView and using actual OpenGL (or SFML or something) calls to draw your tiles.

That way, you can reuse your code for your tile draw-er from the level editor, in an actual game later. This not only saves you time, it means you will not have to be scratching your head once you write the game and going "why doesn't this look exactly the same".

This is bad advice if you're not already familiar with OpenGL etc because OpenGL could be time consuming enough to learn it could derail the project.

This also isn't useful advice if you intend to dump the tiles into Flash or something later.

What is the process for packaging a game with PyPy? I.E. what is the equivalent of cx_Freeze or py2exe/py2app?

Why did King Koopa turn into a grey henchman whenever I shoot fireballs at him?

That's not really bowser, each of the bowsers before the last one are common henchmen that bowser transformed to pose as him. When you kill them with fireballs they turn back into whatever they really are. If you kill Bowser with a fireball in world 8 he dies normal.

http://www.mariowiki.com/False_Bowser#Super_Mario_Bros..2FSuper_Mario_Bros.:_The_Lost_Levels

I'm on a mac.

Their own controller detection completely fucks up all the controller drivers I have installed.

It would have been better if they'd offered no controller solution. But no. It bangs on at you at the start of the game to use a controller and the controller support is horribly broken.

It overrides the controller drivers I have installed. I can't hack around it. Their solution is broken and breaks everything else.

I fairly pissed off because I pre-ordered this a year ago and now I find out it's unplayable. I've already complained on their forums.

I guess I could probably play it on keys though... Oh wait, I can't.

It's not good enough.

Yes. This describes my experience with Super Meat Boy on PC. I took like two weeks after buying it to get to the point I could play it and actually had to just try multiple different gamepads and install bootleg PS3 drivers until I hit on something that worked. I'm a little terrified what setting it up on mac will be like. It's a little startling that such an otherwise gorgeously polished game has such trouble with "how do I press the keys and make things happen?". It may make sense to just factor a 360 gamepad into the cost of the game D:

I think it's likely a tech problem.

I understand the polish argument, but it's just one piece of tech that once you've made it can slot into all of your games and increase access to your games.

I'm guilty of cutting corners myself, but when you have games that are as big as Super Meat Boy, it's a drop in an ocean of development time.

With Super Meat Boy, and this is especially obvious if you played it in the first week before the first couple of patches came down, the problem pretty clearly seems to me that the game was designed for 360 and then PC was hastily thrown in at the last moment... at first it worked with basically nothing except the 360 gamepad and the keyboard controls were set up such that they would almost certainly trigger windows Sticky Keys. (Actually, given Super Meat Boy is designed for a controller and is very upfront about "THIS GAME IS DESIGNED FOR A CONTROLLER", I think even if you could get your left-handed keyboard controls you wouldn't be very happy with them. Look at it this way, if you use a gamepad + joy2key/usboverdrive you can map controls however you want?)