Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

TSDK: Nov 24, 2003; I got a wooden uploading this one

Citizen Erased posted:

I think this has been addressed twice now in this thread but I can't wrap my head around it in the context of my application:

I have a ring of verticies that are at an arbritrary position in local 3D space which I want to rotate to face an arbritrary direction and then translate in that direction by n units.

Using row vectors:

p := sum of all positions / num verts (the origin of the ring in other words)
q := position to look at
T_-p := Translation matrix along vector -p
T_n := Translation directly 'up', n units
R := Rotation matrix to 'look at' q-p, from the origin
T_p := Translation matrix along vector p

Transform for each vertex

p' := p.T_-p.T_n.R.T_p

The only pain in the rear end is if the verts start off pre-rotated and you need to undo that rotation as well (which you can add here: ...T_-p.S^-1.T_n... ). And also keeping a consistent 'up' direction when generating your look at matrix.

# ¿ Dec 6, 2007 19:28

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 04:49

TSDK: Nov 24, 2003; I got a wooden uploading this one

f and n need to be negated before being passed in, by the looks of it. Since you're looking down negative Z, then the clip planes are actually at -0.1 and -500.0.

# ¿ Dec 12, 2007 14:38

TSDK: Nov 24, 2003; I got a wooden uploading this one

fryzoy posted:

As long as I am not totally misunderstanding you, you should be fine with adding the product of the direction vector (normalized) and thrust scalar to your momentum vector.
So let's say you have D, your direction vector, V, your momentum vector and a your accelleration force scalar, you'd then do D = D + V * a.

Nope, D is the constant here and it's V you want to update. For simple newtonian mechanics using euler integration:

D - Ship's forward vector
V - Ship's current velocity
F - Thrust
m - Mass of ship
dt - Timestep

a = F/m
V' = V + D*a/dt

# ¿ Jan 4, 2008 14:19

TSDK: Nov 24, 2003; I got a wooden uploading this one

FBz posted:

Thanks fryzoy and TSDK, that worked a treat! Now I need to figure out how to limit the speed, but I think I have an idea on how to do that.

A couple of (artificial) options here which both produce a reasonable handling experience:

1) Introduce drag, such that V' = V*drag ... where drag is between 0 and 1 and proportional to |V|

2) Modulate the thrust downwards proportional to the speed in the desired direction. This is a bit harder to do, and if you don't drop the thrust fast enough then you can end up going very fast just by wiggling from side to side whilst accelerating...

# ¿ Jan 4, 2008 15:48

TSDK: Nov 24, 2003; I got a wooden uploading this one

FBz posted:

Just to clarify, is |V| the Length of the Velocity Vector?

Yup. You could even make it proportional to the square of the length, which avoids a square root. Drag in air (which although not correct for space, is what our brains are hard-wired to accept as 'correct') in proportional to the speed cubed, so it will still 'feel' more slippery to control than a plane in the air.

EDIT: Oops, no it's not - the force is proportional to the relative velocity squared; it's the power required to maintain a constant speed against drag that goes up with the cube...

FBz posted:

What I had before is that I pre-calculated the maximum momentum vector based on my desired maximum speed and prevented the velocity vector from increasing any further when it hit this value, the ship would be travelling in a straight line when it hit this value. I think this was broken (or poorly implemented).

Clamping the maximum length of the velocity (note that it's velocity you're talking about, and not a momentum vector, which is something different) doesn't work too well because, as you've probably found, depending on exactly where you get the clamp, you either end up losing all steering at top speed, or the ship suddenly transitions into an 'on rails' mode where it turns incredibly sharply.

TSDK fucked around with this message at 18:22 on Jan 4, 2008

# ¿ Jan 4, 2008 18:20

TSDK: Nov 24, 2003; I got a wooden uploading this one

Collision detection has always been, and still is, about spatial partitioning. Use bounding boxes for quick checks to trivially reject collisions that can't possibly happen. Maybe subdivide the screen with either a kd-tree or quad-tree so that you don't check object versus object when they're completely contained in different leaves.

Once you've pruned out all of the collisions that can't happen at a high level, then you're left with those that may happen at a lower level. How you check those will depend on what sort of sprites you've got and what sort of collision you want.

It may be good enough just to subdivide the sprite down further and do overlapping box checks on a smaller scale. If you want to go pixel perfect, then you could alway render the overlap region offscreen using a logical-and mode and then scan through the vram with the cpu to check for non-zero results. Or you could store the min and max extent values for each line of pixel data in the sprite, and then for the overlap lines you're doing a 1d min-max overlap check.

Basically, there are loads of options out there, and you'll only figure out which one is best after trying a few, profiling and weighing the cost up against memory footprint etc...

# ¿ Feb 18, 2008 19:38

TSDK: Nov 24, 2003; I got a wooden uploading this one

Nibelheim posted:

I'm a little confused on the tree solutions. Care to elaborate?

For more detail you could always check wikipedia, but the basic idea is this:

You can put your sprites into two lists - those on the left half of the screen, and those on the right. Note that the lists are not mutually exclusive, as you can have a sprite straddling both. When running through the sprite versus sprite checks for sprites evenly distributed around the screen, then you've cut your work in half. You don't have to check the sprites in the left list against those in the right list, because they're nowhere near each other.

For the quad or kd-tree, you recursively split the halves in two, then in two again etc... until you get a suitable level of granularity whereby you've cut down the number of sprite-sprite collisions, but not at too much of a cost in memory or overhead maintaining the list.

Note that there are some different flavours of quad-trees, and node storage varies between them. For instance, earlier I could have said make 3 lists: left only, right only, and straddling both. What this means is that instead of duplicating pointers by keeping the elements in multiple lists, you're trading CPU time for memory by adding a traversal step where you check the lists in all of the parent nodes as well.

# ¿ Feb 18, 2008 21:25

TSDK: Nov 24, 2003; I got a wooden uploading this one

Nibelheim posted:

Things are much clearer now. Thanks.

This though, is regarding sprite vs sprite collision. Can the same theory be applied to the game's map? The level itself is not a sprite per se, but rather a.. well, map.

You can, but it might be overkill for static map data. For an old-school platformer, I'd go with a tile based approach and define the level as an NxM array of tiles.

TSDK fucked around with this message at 13:48 on Feb 19, 2008

# ¿ Feb 19, 2008 13:45

TSDK: Nov 24, 2003; I got a wooden uploading this one

brian posted:

While we're on the subject of physics i've been trying to do a simple 2D implementation of Jakobsen's Verlet intergration system of using projection instead of penalty or impulse based collision and i've run into a snag. Basically for some reason the integration when combined with constraints is generating its' own torque and it actually looks pretty realistic if it wasn't for the fact it's not meant to be happening.

Your constraint code is wrong. I was trying to work out exactly how you managed to remove the sqrt, and so I looked up the paper:
http://teknikus.dk/tj/gdc2001.htm

This gives the constraint satisfaction code as:

code:

// Then satisfy (C2)
Vector3& x1 = m_x[0];
Vector3& x2 = m_x[1];
Vector3 delta = x2-x1;
float deltalength = sqrt(delta*delta);
float diff = (deltalength-restlength)/deltalength;
x1 += delta*0.5*diff;
x2 -= delta*0.5*diff;

Which makes a lot more sense.

# ¿ Feb 25, 2008 18:57

TSDK: Nov 24, 2003; I got a wooden uploading this one

brian posted:

Thanks for the help, however I linked said paper at the end of my post, the reason for the changed constraint code is because it's using the later faster revision in the paper used to remove using costly sqrt() calls.

That's under the cloth sim part though and you can get away with more inaccuracies with that. I don't think it'll be accurate enough for rigid bodies. The best way to speed up that loop is to use SSE intrinsics, and the __m128_mm_rsqrt_ss instruction.

brian posted:

More to the point however, even with the slower and maybe marginally more accurate way from earlier in the paper the same behaviour appears with the constraint causing some odd torque. I really want to get onto intersection tests and proper rigid bodies so this is really annoying me

The first thing I'd try is bumping up the number of iterations to make sure it's converged to a decent solution, and then double-check that you've not accidentally doubled up any constraints (i.e. A-B and B-A in the constraint array).

EDIT: The other possibility is just that the order of constraint application is introducing the torque. It's been a few years since I last looked into this method, so my memory is hazy as to what results should be expected.

TSDK fucked around with this message at 20:37 on Feb 25, 2008

# ¿ Feb 25, 2008 20:34

TSDK: Nov 24, 2003; I got a wooden uploading this one

Mr Dog posted:

This has been doing my head in for most of a day so far. Can anyone please tell me why this minimal Direct3D app is chewing nearly 100% of my CPU?

Is it actually chewing 100% of your CPU, or is it just being reported as using 100% of CPU by Task Manager.

Try doing a few other things whilst the app is running. If other apps run okay whilst yours is going, then the problem is just with the way Task Manager reports usage and not the app itself.

Our old PC engine used to do exactly that - it would 'expand' to claim all unused CPU in the Task Manager display, but it would back off whenever other stuff was going on, down to the actual usage level.

# ¿ Apr 14, 2008 09:57

TSDK: Nov 24, 2003; I got a wooden uploading this one

heeen posted:

Your engine actually used 100% cpu, its just the premptive scheduler dividing the cpu up on all tasks when you start another one.

No, it wasn't. Each update loop was more or less a constant cost, and when setting other tasks running (which at one point was also anther instance of the game when we were testing certain features) then neither the other tasks, nor the game suffered any slowdown from normal operation.

If it were actually using 100% of the CPU, then you'd expect it to slow down when other tasks kick in.

EDIT: On second thoughts, I suppose it could have been the sound thread doing some sort of retarded busy-wait. Our sound guy wasn't exactly the best programmer in the world, and he did do ridiculous things like setting his thread priority so high that it stopped the keyboard drivers from working properly on the low-end spec...

TSDK fucked around with this message at 14:14 on Apr 14, 2008

# ¿ Apr 14, 2008 14:08

TSDK: Nov 24, 2003; I got a wooden uploading this one

PnP Bios posted:

Mr. Dog, it's because your program is using PeekMessage instead of WaitMessage. Instead of waiting for input, you are polling for it, which means your program is going to cycle through regardless of what's in the message, so your process running at 100% is perfectly normal.

No it's not. Using present parameters of either ONE or DEFAULT should be causing the loop to sync with the refresh rate of the monitor. If it's not, then either the window is minimised, or (another random thought) the drivers have been told to ignore vsync.

Unless you're writing a turn based non-realtime game, using WaitMessage in a game loop is mostly retarded.

# ¿ Apr 16, 2008 09:07

TSDK: Nov 24, 2003; I got a wooden uploading this one

Wang tiling is your friend:
http://en.wikipedia.org/wiki/Wang_tiles

EDIT: Actually, it's a slightly higher level than that you want, isn't it? I'd probably look at grammar rules and markov chains.

EDIT2: Have a look at this paper:
http://graphics.stanford.edu/papers/texture-synthesis-sig00/texture.pdf
What you basically want is a reference texture with some natural looking patches of grass, water edges etc... and then use texture synthesis to make larger maps based on those smaller samples.

TSDK fucked around with this message at 18:01 on Apr 22, 2008

# ¿ Apr 22, 2008 17:49

TSDK: Nov 24, 2003; I got a wooden uploading this one

DBFT posted:

If I'm not mistaken aren't the methods you gave me more to do with how the map will appear (blending one tile into another, etc.) rather than making the layout of water/land/rocks/etc look natural?

They are and they aren't. Because you're looking for a method to generate 2D maps, then the techniques you're looking for will have more in common with texture synthesis and generation than they will to the most common terrain generation techniques, which focus mainly on 3D.

It might be worth seeing if the file format for Dwarf Fortress is easy to interpret - no point writing your own generation code if you can generate one in DF and then extract the map data to your own format.

# ¿ Apr 22, 2008 19:40

TSDK: Nov 24, 2003; I got a wooden uploading this one

heeen posted:

Edit: http://heeen.de/proj/refract.avi http://www.youtube.com/watch?v=hqLobCH8PFo

Looking good so far.

This is a pretty good method for adding caustic effects, if you want to bump the bling up a notch.

EDIT: There's also a nice technique which uses the water surface mesh rendered as triangles into a texture and projected onto the underwater geometry, where the brightness of the triangles is adjusted based on the size/gradient of the triangle relative to the rest size. This gives you sharper caustics, but I can't find a paper on it at the minute. They used that technique in the PS3 Big Duck demo.

TSDK fucked around with this message at 10:41 on Apr 24, 2008

# ¿ Apr 24, 2008 10:28

TSDK: Nov 24, 2003; I got a wooden uploading this one

forelle posted:

Ooooh I invented something similar to this (but not as good) back in 2000ish.

http://www.patentstorm.us/patents/6809729.html

drat, "Don't publish but patent" companies.

What the hell? Issued 2004? Hell, I think I've almost got prior art on that sucker as well.

# ¿ Apr 25, 2008 09:33

TSDK: Nov 24, 2003; I got a wooden uploading this one

The single biggest selling point for COLLADA is that there are open source exporters for both Maya and Max. Even if you have to extend the exporters, then having a solid(ish) starting point is an absolute godsend for those starting afresh on a toolchain.

# ¿ May 22, 2008 17:24

TSDK: Nov 24, 2003; I got a wooden uploading this one

OneEightHundred posted:

Not really, FBX occupies the same niche and is closed-source.

Being closed source is a major disadvantage when putting toolchains together. I've yet to see one 'standard' file format that didn't need either extending or bug-fixing in one way or another to meet all of the requirements for a project.

# ¿ May 23, 2008 09:34

TSDK: Nov 24, 2003; I got a wooden uploading this one

OneEightHundred posted:

FBX and COLLADA both contain a shitload of information, I'm really not sure what more you'd want out of them.

Lots of things. Compression options for textures, scripted node tagging, manual layering for non-sorted alpha objects etc... It just depends if you're using them purely for the modelling stage, or if they're an integral part of the toolchain.

The whole Maya/Max interchange thing has come up very recently on another project as well, and neither FBX nor COLLADA manage to preserve the materials properly between packages.

# ¿ May 27, 2008 10:13

TSDK: Nov 24, 2003; I got a wooden uploading this one

If you just want a quick and dirty method to stop people messing with the file, then hard-code a salt value into the exe and append the MD5 of the save file contents + salt to the end of the save file.

It's not going to stop anyone with enough nouse to go through your exe to find the salt value and write a tiny tool to 'sign' modified save files, but then you were never going to stop someone with the skills to do that anyway.

# ¿ Jun 24, 2008 11:10

TSDK: Nov 24, 2003; I got a wooden uploading this one

Gary the Llama posted:

Should the Sprite class handle the rendering or the Player class?

Neither. You should have a Renderer class that renders (or adds to a deferred render list) Sprite objects passed in. The Player class then has a pointer to a Sprite object. Roughly speaking:

code:

struct Sprite
{
    LP3DXSPRITE m_d3dSprite;
    LPDIRECT3DTEXTURE9 m_pTexture;
};

class Renderer
{
public:
    void RenderSprite( Sprite *pSprite, D3DXVECTOR2 pos, RECT size );
private:
    ...
};
extern Renderer *g_p_renderer;

class Player
{
public:
    void Update()
    {
        // Update velocity and position
    }
    void Render()
    {
        g_p_renderer->RenderSprite( m_pSprite, m_pos, m_size );
    }
private:
    Sprite *m_pSprite;
    D3DXVECTOR2 m_pos;
    RECT m_size;
};

The reason for doing the split like this is so that you've got a centralised location for when it comes to optimisation time and you want to do some renderable list sorting to minimise state and texture changes.

# ¿ Jul 1, 2008 08:35

TSDK: Nov 24, 2003; I got a wooden uploading this one

StickGuy posted:

I'm not sure how scalable this approach is when you have, for example, many different types of objects that require special rendering techniques. It would get a bit messy to have all of that in one place.

Pretty scalable.

In principle, you can just think of the GPU and video memory as a set global variables that the code is setting. No matter how you separate out the code that sets the states and calls the rendering functions, all of the rendering calls have an effect on each other. You can't add in a HeatHaze object into a generic scene graph without considering the effect of the Bloom object that's already in there, or considering at what point your depth pre-pass is going to kick in and set up the depth buffer.

By splitting rendering effects up between classes, you're trying to pretend that each entity can be rendered in its own right without consideration to other objects, and so then you'll spend the last third of the project having to remember rules like 'the sky box must be the first object in the scene graph' and 'the water nodes must be after the player nodes'.

Both approaches are relatively common in game development, but I tend to prefer the centralised approach in general because it's a bit more 'honest' about what's actually going on, and usually offers better performance and scope for optimisation.

# ¿ Jul 1, 2008 14:30

TSDK: Nov 24, 2003; I got a wooden uploading this one

Namgsemterces posted:

Basically, I'm talking about a mask.

Sounds like you should be using the stencil buffer, but it's hard to tell without some diagrams of what you're trying to accomplish.

# ¿ Jul 16, 2008 17:16

TSDK: Nov 24, 2003; I got a wooden uploading this one

OneEightHundred posted:

11's features are basically:
- Multithreaded rendering. Who gives a poo poo, sending things to D3D is not expensive any more, you don't need to parallelize your D3D calls.

Submitting batches is actually pretty drat expensive CPU wise (i.e. framerate limiting). Being able to thread off calls is going to be handy, especially as more engines start threading more stuff off in order to take advantage of multicore systems.

# ¿ Aug 13, 2008 11:47

TSDK: Nov 24, 2003; I got a wooden uploading this one

Morpheus posted:

Hello folks I would like to ask a question about code design for a somewhat simple 2D platformer. I'm pretty sure how I'm going to go about doing all the design, but the biggest thing I'm not sure about is the most important: collision detection. This ties into the very core of the code, so it's kind of important to decide before I start, as this is my first 2D platformer.

I would imagine something to do with a tile-based world, where one tile could be 'terrain' and I'd check against the tiles around my character to see if he's colliding with any of them. I feel like this really limits level design to a NES-era platformer, with bricks and blocks and no curves. Is there a better, more expandable approach available?

Check out the replies given to a similar question earlier in the thread.

# ¿ Sep 18, 2008 10:19

TSDK: Nov 24, 2003; I got a wooden uploading this one

Good grief, you're all making it more complex than it needs to be. The original question is essentially how do you move a 2D character along, given sloped and non-sloped tiles.

The easiest method to get the same sort of behaviour as old-school platformers is to move the character along horizontally, perform your collision check downwards from a central point:

code:

'

      X ----> X'
      |       |  M
    N |       V
      V     /---------
-----------/

Call the rest height for the character N, and the new height above the terrain M. Provided N - M is less than some given amount, then you allow the character to move to that point, and adjust their position to be N, the rest position above the terrain.

code:

'

              X''
      X ----> |
      |       |  N
    N |       V
      V     /---------
-----------/

If M is smaller than N by a predefined amount, then it counts as a collision, and the character is stopped from moving to the new point.

This also works when M is greater than N by less than a predefined amount, and the character will stick to the slope when walking downhill. Note that the predefined amounts by which you're comparing the difference essentially determine how steep the steepest slope can be for your character to walk up.

Doing it this way gives you a relatively nice behaviour, without having to special case slopes with state machines etc...

# ¿ Oct 21, 2008 19:06

TSDK: Nov 24, 2003; I got a wooden uploading this one

Avenging Dentist posted:

Well, for one thing, I absolutely don't buy into his claim that variable-step integration methods are inherently inferior to fixed-step ones. While fixed-step integration is more predictable, integration methods like RK4 are perfectly suitable for variable-step integration, assuming the step doesn't vary too much.

Actual simulations (as opposed to games) have used variable-step simulations, especially when you need varying degrees of accuracy (e.g. for a two-body collision simulation, you'd want less accuracy when the objects are far apart, and more when they are close). Games, clearly, have significantly lower requirements for accuracy than simulations proper, since in a game, "if it looks right, it is right". With games, you obviously can't predict exactly when you'll gain/lose accuracy in your timestep, but let's be honest here, we're not exactly trying to prove the existence of the Higgs boson.

What the author is attempting to do is to remove the potential for variance in simulation outcomes by fixing the timestep. While this (obviously) makes for a predictable system if you have the same input each time, games generally do not behave exactly the same way each time, and so errors (such as the well-known issue of ragdolls shaking uncontrollably) will propagate from other sources. Fixing the timestep won't do much except obscure the problem in your test cases.

The primary reasons for using a fixed timestep for games are not necessarily about accuracy or network issues. The primary reason is consistency. With variable timesteps, it's very easy to author (for example) a jump for a car which works at one framerate, and doesn't at another. Once you've spent days of your life tracking down bugs that happen at one framerate, and not at another (remembering of course that Debug and Release builds run at completely different framerates even on the same machine) then the benefits of having a consistent baseline are immediately obvious.

A good secondary benefit to fixing a timestep is that all of your physics code gets faster, because you've eliminated a shed load of multiplies.

# ¿ Dec 9, 2008 19:10

TSDK: Nov 24, 2003; I got a wooden uploading this one

Vinlaen posted:

I'm trying to create a "simple" networked/multiplayer 2D game and so I've been trying to a read a lot about networking principles, player synchronization, etc. However, it seems like most articles (eg. gaffer.org) tell you to send keyboard/mouse inputs to the server, have the server process them, and send the results back to the client.

Why?

Is this only done for cheat protection?

What is the disadvantage to sending actual player position to the server and doing a sanity check?

One of the main advantages of sending only the user inputs, is that the inputs often amount to a lot less data than sending position data.

For example, in your hypothetical 2D sprite based game, you can probably compress all of the relevant inputs (up/down/left/right/jump/fire) into a byte or two. Depending on the size of the play area, you may need anywhere from four to eight bytes just to send a single player's 2d position.

# ¿ Jan 15, 2009 14:54

TSDK: Nov 24, 2003; I got a wooden uploading this one

Unless you're going to go for a complete fluid dynamics simulation, then anything you write is going to be an approximation. As such, you're better off figuring out what sort of motion or effect you're after, and then working towards an equation that describes that.

You could take a very simplistic approach to wind and just say that it's a constant force along X. In which case, it becomes exactly like your equation with gravity. Something like:

code:

x = vx*time + 0.5*a*time^2

Where a=f/m in the usual manner.

You can also add in very simple drag (again, constraining it to the horizontal if you so wish) by having the force vary with some function of vx. Pick a drag function to play with, plug in vx to get out f, divide by m, and plug that in as the acceleration.

Try something simple like:

code:

float speed_difference = vx - wind_speed;
float wind_force = drag_coefficient * powf( speed_difference, 3.0f );
float acceleration = wind_force / projectile_mass;

And play around with different powers and drag coefficients.

# ¿ Feb 11, 2009 00:29

TSDK: Nov 24, 2003; I got a wooden uploading this one

not a dinosaur posted:

And so far I haven't really found a solution.

It looks very much like you need to check out the rasterisation rules and texel lookup rules, because that's exactly the sort of effect I'd expect if you haven't got the pixel->UV->texel alignment, or pixel coverage right.

# ¿ Apr 3, 2009 12:03

TSDK: Nov 24, 2003; I got a wooden uploading this one

ZorbaTHut posted:

Can anyone give me a page talking about standard techniques for making platformers? I've had trouble coming up with an elegant way to handle collisions and slopes and the like - I've got a few ideas, but they all seem more complicated than necessary. Can anyone sum up a standard technique in, like, ten lines?

Here you go.

# ¿ May 19, 2009 13:35

TSDK: Nov 24, 2003; I got a wooden uploading this one

SkankerX posted:

I've got an interview for a game programming position coming up. I worked as a game programmer about a year ago, so the math isn't new to me. BUT, I really need to brush up on linear algebra stuff again, just to be able to answer any questions. Are there any solid overview sites available? I'm not really looking for proofs as much as just various cookbook-esqe pointers. Relationship between dot-product and angles / magnitude, etc.

I've googled around, but so far all I've found is wikibooks. If this is already in this thread, then I'm sorry. I looked around but couldn't find a solid link. Apologies in advance.

I generally find this site to be quite readable as a quick refresher for things like lines intersecting planes etc...:
http://softsurfer.com/algorithm_archive.htm

# ¿ Jul 1, 2009 12:11

TSDK: Nov 24, 2003; I got a wooden uploading this one

Yes, there is another way without going through the decomposition route. For composite transformations like the ones you've got, rotations (and I'm fairly certain scales as well) can just be concatenated, ignoring the influence of the other transforms.

So the rotation for the child in model space is just the product of all of the rotations from the bone down through the hierarchy to the root. Likewise with the scales (if I remember rightly).

For translations, you have to form a complete matrix from all of the rotation, scale, translation parts of all of the bones down to the root. You then run the vector [0,0,0] through the matrix, and that's the bone's location in model space (or just pull the appropriate row/column out of the matrix, which amounts to the same thing).

# ¿ Aug 4, 2009 20:32

TSDK: Nov 24, 2003; I got a wooden uploading this one

Double post!

OneEightHundred posted:

That doesn't matter. Row and column major matrices are interchangable for processing, as long as you keep them consistent and know how matrix math works so you don't gently caress the order up.

The in-memory layout is identical for both, so in that respect it doesn't matter, but when you're composing matrices like this it matters a great deal because it reverses the order in which you do the multiplcations - and that's pretty fundamental.

# ¿ Aug 5, 2009 13:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

Citizen Erased posted:

fryzoy posted:

FBz posted:

FBz posted:

FBz posted:

Nibelheim posted:

Nibelheim posted:

brian posted:

code:

brian posted:

brian posted:

Mr Dog posted:

heeen posted:

PnP Bios posted:

DBFT posted:

heeen posted:

forelle posted:

OneEightHundred posted:

OneEightHundred posted:

Gary the Llama posted:

code:

StickGuy posted:

Namgsemterces posted:

OneEightHundred posted:

Morpheus posted:

code:

code:

Avenging Dentist posted:

Vinlaen posted:

code:

code:

not a dinosaur posted:

ZorbaTHut posted:

SkankerX posted:

more falafel please posted:

OneEightHundred posted: