GeneralQuery

Direct3D and OpenGL are both low level graphics APIs that, in their modern form, are for all intents and purposes intefaces to the underlying 3D hardware. As such, all this stuff of buffers, pipelines, primitives and so of is very much a reflection of the common theory and practice of 3D rasterization, things that is certainly not a Microsoft or DirectX specific way of doing things.

 

I think a big mistake beginners make is that they choose to dip their toes into 3D graphics with no real grasp of the underlying concepts, a mistake which is further compounded by choosing possibly the lowest level API that you'll ever use for 3D rendering. This of course results in a big "WTF!?" moment when you decide to take a peek at the docs or online tutorials because suddenly you're bombarded with not only API-specific stuff but also universal rendering concepts thrown in for good measure. I know i was certainly left utterly baffled when I first started out, and this was in the days of the (relatively simpler) fixed function pipeline.

 

I think you need to have a think about where your interests lie: if you want to learn the low level nuts and bolts of how things appear on the screen then be prepared to do  a lot of extra curricular research and learning about the mathematics and concepts of 3D rendering in general as learning the API specifics should really just be housekeeping. If you want to get things up and running as painlessly as possible to make games and the like then IMO a higher level API/engine would be a wiser investment in time as you can add the low level stuff to your repertoire at a later date..

OpenGL and DirectX are (essentially) just APIs for interfacing with the GPU. Leaning one or other is no great challenge in principle, it only really becomes difficult and problematic when people dive in with little or no mathematical understanding of the concepts behind the APIs (in my opinion). "Learning" the DirectX/OpenGL APIs certainly does not equip oneself to use it, when working at such a low level you need to have a good handle on the math to do anything useful without it becoming a frustrating teeth pulling exercise.

So would SDL be a waste of time? Well, it depends on what you know and what you want to learn. Using SDL and DirectX/OpenGL are not mutually exclusive, I haven't used it myself (so take what I say with a pinch of salt) but from my understanding SDL is (amongst other things) a quick and simple means of getting a window up and running for rendering on whatever platforms it supports. DirectX/OpenGL alone do not replace frameworks such as SDL as they are only concerned with interfacing with the GPU, not creating windows, playing sounds, handling networking and so on (I'm not a DirectX user myself but I believe earlier versions did come with a framework to handle a lot of the boiler plate stuff like window creation, resource loading etc. but I'm not sure if that's the case with the latest version).

In my opinion, I'd stick with SDL for the time being and focus on getting stuff done rather than fretting about hypotheticals. There's nothing to say you can't learn SDL and then move onto something else in the future, it certainly won't be "wasted" time if your using it to get valuable game-making experience.

What current experience do you have? Developer experience is certainly a plus but games are a radically different from most developing roles (gross generalization, I know). If you're looking to roll your own, make some really basic games first like Pong and Breakout, that sort of thing. Otherwise, you might be more interested in using an off the shelf engine if you're looking to get things done so you can both get stuck in.

I'm not following what your problem is. Do you have the grid already? If so, you say you move the camera, what is the problem? Translating the camera or grid will achieve the same thing albeit in opposite directions. Or is the problem with rendering the grid?

Translating the grid by the mouse delta when a mouse button is held would be the simplest solution but what specifically are you having trouble with?

"Blah" isn't descriptive enough, varVariable should do the trick

@cr88192: 100-200ms can be an eternity in terms of audio/visual syncing. I just ran a very crude test and with a latency of 100ms the discontinuity was jarring under certain conditions. A lot of it will be source dependent though, a lot of sounds really aren't critical in terms of syncing with a particular visual cue. A monster cry of pain for example wouldn't need to be synced to start exactly at the same time as the animation. The rate and indeterminacy is also a factor, under my crude test rapid "weapon fire" was much more forgiving than intermittent weapon fire.

 

Apologies to OP, my post isn't really on topic.

Short answer: you don't jump from "Hello World" to writing game engines. What is your primary focus? Is it to make games or are you more interested in the programming side of things?

so like is this loop is going to loop until nbActors-- reaches 0 before it breaks out?

 

also

 

If i wanted to specify a specific actor in that array " *actors++ " and start looping upwards from there how would that be done? for example if i wanted to start at index 5 and then ++ from there how would that be done?

See Bregma's post above for further insight to your OP. Regarding your further questions, consider this code snippet:

 

 

int array[10];
int* p = array; // p points to first element of the array, i.e. array[0]
 
p += 4; // p points to 5th element of array, i.e.  array[4]
 
cout<<*p; // dereference p to access the data at array[4] and print the result
 
cout<<*(p-1); // dereference p to access the data at array[3] and print the result

int* q = p++; // as p is still pointing to array[4], q points to array[5]

// and so on...
 

The NxActor* actor = *actors++ line is getting a pointer to the next object in the array pointed to by actors using pointer arithmetic. The while loop is looping nbActors number of times which I'm assuming in turn specifies the number of elements in the array of NxActors pointed to by actors.

I think you might be getting bogged down with the application of theory. It's not so much that there is a conscious thought process as to how the music will progress or that it's a problem solved through analytical breakdown, rather the theory is a framework that you (mostly) unconsciously tap into. Music really is one of those disciplines where the key is the learn and practice until it becomes instinctual rather than a discipline that is honed through intellectual rigour. It seems like you're looking at the pieces of the puzzle but it's not really clicked yet. This isn't a shortcoming on your part, it's a necessary part of the process. The only thing I can suggest is to periodically review your theory material to see if you're ready to click any more but also to grab as many tracks as you can and (either with your ear or finding tabs/videos online) rip them apart musically. Build up your instincts and the theory will slot into place in due time.

What features should every software package offer?  Are there any features so important that it's not worth considering a package that doesn't offer them?  What are the killer features you personally look for, or which lead you to choose the software you currently use?

 

 

First, let's dispel a popular myth: "all DAWs sound different". Short answer, they don't. So, really it's down to feature set. A checklist of requirements:

 

1) BUDGET!

2) MIDI sequencing capabilities

3) Audio recording/editing capabilities

4) Number of audio tracks required

5) Number of virtual instruments required

6) Video syncing requirments

7) Quality and quantity if bundled instruments, effects and ROMplers

6) (probably the most important) Personal preference.

 

There's little details such as automation editing functionality, routing options, insert slots and stuff like that but that's not a concern for you at this stage (dip your toes in first!).

 

DAWs such as Cuckos's Reaper and FL Studio have cheap entry level versions (and I believe you can try Reaper for free for as long as you want). Other DAWs such as Cubse have a variety of pricing structures but there's no demos to try before you buy (although student licences are dirt cheap).

 

Are there any features that would be considered important to the majority of composers but which a beginner might not think to look for?

In my opinion: when you start out, every DAW is hard to use (with varying degrees, of course). Don't plump for a more limited DAW with an easier learning curve as making the work flow transition to a more featured DAW at a later date is a cost of your time.

 

Is there any particular process you follow when trying out demo versions of software to make sure you've tested thoroughly, or do you just play around with them?

 

Really, it's all down to personal preference. Every modern DAW is more than adequate for producing high quality, professional music (it's the entity between the chair and keyboard that counts) but if you're going to be doing, say, a lot of audio recording and editing then something like FL Studio probably isn't your best option. This is a bit of a chicken and egg scenario so your best bet would be to download demos of each DAW (where appropriate) and have a whirl.

 

Lastly, what software do you personally use, and why did you choose it?  Are there any areas you feel are lacking in your current set up, or is there anything you're really wanting to add to it?  Would you recommend the same software to others?

 

We're in flame war territory but I personally use Cubase because it's the most feature rich for the work I do. It's certainly not flawless and in an ideal world I'd have a DAW encompassing the best of all worlds but reality dictates trade offs have to be made. Some options might not be available, such as Logic (Mac only) and FL Studio (PC only). In all likelihood you'll stick to what you started out it so it's all ultimately meaningless (within reason).

 

What do I like about Cubase? Well, I like the clear separation of arrangement and mixing, the MIDI editing is second to none, the audio recording editing is very strong, the bundled effects are mostly decent and the general suite is comprehensive and competent. Things I dislike are the limited number of insert slots and the rigid routing and signal flow (Cubase is much more of an 80/80 rule piece of software which can be restricting at times).

 

On top of this a decent audio editor is essential. In order of personal preference: Adobe Audition, Wavelab, SoundForge, possible Audacity (never used it myself but it is free).

 

To clarify your aims a bit more, what sort of music do you intend to be writing?

Interesting thread. Sorry for not including poster names in my quotes, hopefully it's not too confusing to read.

Uh.. no, sorry, but this is bad advice. A multiband compressor is a very powerful tool for very specific tasks. When you have access to the mix you should never even want to use a multiband compressor. Why squash and distort the mix you have so carefully created? As for a limiter, you use one to limit peaks and prevent clipping, not to "maximize your audio."

Headroom management is about RMS which is determined by making the most of the bandwidth available. Broadband tools alone cannot maximise headroom if one is looking to make a mix as perceptibly loud as possible. You also conflate loudness with harshness. As I said in my first post, loud = easy (drawback: harsh), clean = easy (drawback: too soft), loud + clean = loud and clear = where the challenge lies. IF this is your goal then multiband tools are essential. Does that mean squashing everything into oblivion is fine? Of course not, if you're doing such a thing then you should reassess exactly what it is you are trying to achieve.

My advice is that you should create a minimum -2db headroom. At that point you must scrutinize your mixdown (in terms of leveling, potential frequency clashing, dynamics, depth and panning). When you decide that everything sounds good, wait at least 2 days and check it again.

Peak headroom is meaningless from a mastering perspective. If one wishes to farm out the master to a specialist mastering engineer then leaving enough RMS headroom is where the truth of this advice lies, but even then a broadband track with -2dB RMS would essentially sounds like a distorted square mess. Loud, modern EDM final masters would not be pushing much more than -8dB RMS. Leaving RMS headroom is really just a rule of thumb, in my opinion propegated by mastering engineers to stop people sending them FUBAR'd pre-masters where the client decided in their infinite wisdom to ruin the mix with some unnecessary/incorrectly applied dynamics processing over the stereo bus

Edit: as a side note, I should clarify that peak monitoring is important but it does not tell you anything about the dynamics. I personally use a waveform visualizer for this as well as RMS meters and I keep an eye out for headroom-gobbling superfluous peak information and fix accordingly. Phase relationships between different frequency bands as well as different mix elements is also extremely important.
 

After that, you may add a master compressor to glue things a bit (if you really think you must), a frequency exciter (be very careful with those; apply with MODERATION) and finally a limiter.

I personally only use a limiter as the mix is there in front of you to do everything else. MAYBE a compressor, but you might as well just mix into the compressor from the get go but as always, context is king (my requirements may differ from yours etc.).


 

No, a multiband compressor is not a "standard" tool. The only "standard" there is in mastering is EQ, a Limiter, and maybe a normal compressor. But don't take my word on it, have a look at what some professional mastering engineers are saying on the topic of multiband compression:
http://www.gearslutz...ompressors.html
http://www.gearslutz...ompression.html
http://www.gearslutz...ion-voodoo.html
http://www.gearslutz...ompression.html
http://www.gearslutz...compressor.html

I would take most things written on Gearslutz with a pinch of salt ;)


 

As for "comparably loud", how loud is comparable? And comparable to what? When you're clipping the limiter, you're creating distortion, diminishing the quality of your music. When you present your material you would want it to be at the best quality, so squashing your mix to get some imaginary "loudness" (it's not) seems counter intuitive to me. Just turning the volume knob would have provided better results. Now if you're working on a project where you're mixing with sfx 'n such in mind i can see why you would want your music comparably loud

Loudness is relative but is generally interpreted as a high(er) RMS. High RMS does not necessarily equate to squashed dynamics, as with many things in audio engineering there is a gap between the naive approaches (which deliver less than stellar results) and more intricate approaches that are largely birthed from the power and flexibility of modern DAWs.

 

I don't want to start a "loudness war" discussion here - but it's a fact that loud & clipping music has become a sound aesthetic on its own, at least in electronic/rock/popular music in general.

I largely agree with this although I think clipping is probably pushing it ;) The modern aesthetic of loudness (not the silly loudness war nonsense) in electronic music is COMPLETELY different from traditional/acoustic music (the latter does not take well to heavy dynamics processing without being abrasive and fatiguing). The key is context, context, context.

I think this touches on a important point: "traditional" mixing styles and "rules of thumbs" very rarely translate to modern electronic music, thus a lot of the "dos and don'ts" make little sense (and are often counter productive) hence why it's important to grasp the underlying concepts instead of assuming advice is correct (and of course this applies to my post as much as anybody else's ). This is why it's also important to understand the context of the advice: who is giving it and what is their background? An oldschool analogue legend giving advice about do's and don'ts rarely applies to me as my techniques, tools and requirements are completely different. I produce my records with the aim of being louder and clearer than my competitors (amongst other things, of course) but then my music is designed to be played back on large sound systems. Many of the mix micromanagement techniques and processes I use are overkill for people with different requirements. Context = king.

Edit: another side note. My distinction between "modern" and "traditional" music is somewhat lacking. Let me expand on this: if your sounds are sourced from acoustic/traditional sources (as I'm sure a lot of you making, say, orchestral video game music are) then I put that in the "traditional" camp. Your mileage will be more restricted in terms of processing traditional instruments for a couple of reasons: a) there is a strong cultural expectation as to how these instruments should sound (distorted to death is not such an expectation ) and many instruments simply don't take to such processing (for example, because of their timbre and/or the inevitable intermodulation artefacts of heavy processing). Granted, my distinction is broad and simplistic but should suffice for the context of my thoughts on the matter.

Making things loud is easy. Making things clean is easy. Making things loud and clean is where the skill lies. It all about headroom management, judicious (where appropriate) use of dynamics processing, eq, saturation and distortion (I'm simplifying but you get the gist). Experiment with these effects, techniques such as parallel saturation work wonders for increasing loudness in a fairly transparent (or at least desirable) manner. Sticking a limiter on your master bus can only do so much. It's really a last step that has to be done on the master as it's not really possible/practical to do it in the mix.

If your interest is 3D, learn 3D graphics first. Don't even consider designing and building a 3D engine if you do not have a good grasp of 3D concepts and implementation. Check out the APIs (DirectX/OpenGL), brush up on your linear algebra and work your way through tutorials of the API of your choice. Build some tech demos to flex your skills as you progress, then you'll be in a position to start pondering games, engines and other such creatures.

Another way is more top-down. Try out and experiment with existing engines to get a feel for how things are put together as a whole and what sort of functionality you should be exposing to the user in your future designs. Of course, an understanding of 3D concepts is still needed (esp. the linear algebra part) but not at as fine a level. Work your way down from ther.