Game Development Megathread

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

«‹›622 »

posting smiling: Jun 22, 2008

Avenging Dentist posted:

Just use the dynamic separating axis theorem: http://realtimecollisiondetection.net/files/levine_swept_sat.txt

Thanks a million; this is exactly what I was looking for but none of my searches terms were turning anything up. For anyone in the same spot as me I also found this tutorial which makes it a bit easier to digest.

# ? Dec 5, 2008 01:30

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:04

Peao: Dec 1, 2004; If you can read this, remind me of why I shouldn't post.

For anyone interested in free 2D art to use in their games, the Tyrian artist has a couple of cool packages, including all the Tyrian ships.

http://lostgarden.com/labels/free%20game%20graphics.html

CTRL+F for "Zelda" on that page. Lovely art, reminds me of Tales of Phantasia on the Super Nintendo. Of course, there's the small problem of "the rest of the game's art" but if you stick to a single village and a single forest, you should be fine

# ? Dec 6, 2008 13:36

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

That PlanetCute stuff is awesome, too.

# ? Dec 6, 2008 18:23

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

Peao posted:

For anyone interested in free 2D art to use in their games, the Tyrian artist has a couple of cool packages, including all the Tyrian ships.

http://lostgarden.com/labels/free%20game%20graphics.html

CTRL+F for "Zelda" on that page. Lovely art, reminds me of Tales of Phantasia on the Super Nintendo. Of course, there's the small problem of "the rest of the game's art" but if you stick to a single village and a single forest, you should be fine

This is a wonderful resource. I'm reading through some of his other slides right now on a presentation he gave, and they are full of good information.

# ? Dec 6, 2008 18:35

a slime: Apr 11, 2005

I found a series of really nice articles on game physics and then on networking by someone named Glenn Fiedler. They were very eye opening to me, hopefully they'll be of use to some of you as well.

# ? Dec 6, 2008 22:55

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

not a dinosaur posted:

I found a series of really nice articles on game physics and then on networking by someone named Glenn Fiedler. They were very eye opening to me, hopefully they'll be of use to some of you as well.

Haha, he actually advises fixed-timestep physics and then goes on to use some stupid-rear end accumulator system instead of just using two threads. Granted, it's a couple years old, but multi-core machines have been around for a while, so not only is he using a more complicated method, he's ignoring a really easy place to make performance improvements.

His writing is absolutely god-awful, too.

EDIT: Also, his accumulator system will get FUBAR if physics processing takes longer than expected (e.g. on a slower computer).

Avenging Dentist fucked around with this message at 23:08 on Dec 6, 2008

# ? Dec 6, 2008 23:06

a slime: Apr 11, 2005

Avenging Dentist posted:

Haha, he actually advises fixed-timestep physics and then goes on to use some stupid-rear end accumulator system instead of just using two threads. Granted, it's a couple years old, but multi-core machines have been around for a while, so not only is he using a more complicated method, he's ignoring a really easy place to make performance improvements.

His writing is absolutely god-awful, too.

EDIT: Also, his accumulator system will get FUBAR if physics processing takes longer than expected (e.g. on a slower computer).

Agreed that threads are an obvious improvement, but what do you see going wrong with the accumulator? If the rate at which you manage to step the simulation is less than what you fixed, you just end up doing multiple updates until you catch up. What's the problem here? Am I missing something?

I guess if your machine can't handle it, you could fall further and further behind and then you are hosed. Yeah, that sucks.

# ? Dec 7, 2008 00:14

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

not a dinosaur posted:

Agreed that threads are an obvious improvement, but what do you see going wrong with the accumulator? If the rate at which you manage to step the simulation is less than what you fixed, you just end up doing multiple updates until you catch up. What's the problem here? Am I missing something?

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.

# ? Dec 7, 2008 00:44

a slime: Apr 11, 2005

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.

I think he is advocating fixed timesteps for two reasons. First, the articles are clearly oriented for beginners. Correct me if I'm wrong, but I would assume that while real simulations use timesteps that are variable, they certainly aren't arbitrary. Fixing the timestep is a straightforward way to overcome problems with arbitrary timesteps.

Second, he's building up to presenting a (very simplified) way to synchronize physics over a network. Obviously in that case you want to minimize divergence in simulation between the client and server as much as possible.

I'm still convinced his articles are at least a good place to start with a couple of intermediate game design topics. If you can suggest anything better, please do.

# ? Dec 7, 2008 00:58

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

not a dinosaur posted:

I think he is advocating fixed timesteps for two reasons. First, the articles are clearly oriented for beginners. Correct me if I'm wrong, but I would assume that while real simulations use timesteps that are variable, they certainly aren't arbitrary. Fixing the timestep is a straightforward way to overcome problems with arbitrary timesteps.

Game timesteps aren't arbitrary either. A game is a pseudo-realtime environment and thus puts constraints on the maximum delta-T per timestep. It's trivial to constrain the minimum delta-T, though you'd only want to do this to avoid propagation of floating-point error with incredibly small delta-T values.

not a dinosaur posted:

Second, he's building up to presenting a (very simplified) way to synchronize physics over a network. Obviously in that case you want to minimize divergence in simulation between the client and server as much as possible.

I only skimmed the network physics article, but none of it seems in any way dependent upon a fixed-timestep physics simulation. Fixed-timestep physics might provide a trivial improvement in network bandwidth by removing the need to occasionally send updates on the "master" location of objects, except that this ignores issues like network latency and packet loss (you can't guarantee that a packet will be received by all clients at frame N, if at all).

Fundamentally, synchronizing physics objects over the network is no harder than synchronizing player objects over the network. Both need occasional updates to correct their position (and in the case of players, to supply information about their current actions), but in between updates, any relatively stable integrator should be sufficient.

not a dinosaur posted:

I'm still convinced his articles are at least a good place to start with a couple of intermediate game design topics. If you can suggest anything better, please do.

The old adage "you get what you pay for" is appropriate here. Real-time Collision Detection by Christer Ericson and Game Physics by David H. Eberly are both highly rated, and I can say from personal experience that RTCD is a well-written book (with a few unfortunate errors).

# ? Dec 7, 2008 01:36

a slime: Apr 11, 2005

Avenging Dentist posted:

The old adage "you get what you pay for" is appropriate here. Real-time Collision Detection by Christer Ericson and Game Physics by David H. Eberly are both highly rated, and I can say from personal experience that RTCD is a well-written book (with a few unfortunate errors).

Great, thanks. School library has both :hellyeah:

# ? Dec 7, 2008 01:52

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Avenging Dentist posted:

Fundamentally, synchronizing physics objects over the network is no harder than synchronizing player objects over the network. Both need occasional updates to correct their position (and in the case of players, to supply information about their current actions), but in between updates, any relatively stable integrator should be sufficient.

Really? Synchronizing players is probably one of the bigger challenges in a network environment, and probably the aspect with the largest number of different approaches used. It's where the discrepancies between what the client thinks is happening and what the server thinks is happening show up in full force, and where tradeoffs need to be made between responsiveness and security. Getting jerked around by server corrections is far less tolerable than another object in the world winding up slightly off-course, and speed corrections in particular are very touchy: Correct too much and players get jerked as soon as network performance becomes less-than-perfect, correct too little and it's open for abuse.

There are a bunch of different models: Asynchronous (Quake 3, Unreal), delayed synchronous (Halo, Battlefield, any RTS), full authority (Red Faction, WoW), and several more recently incorporated concepts like historic lag compensation (Halo, HL2).

As for fixed-timestep, the problem with variable timestep is when systems that allow penetration gently caress up when something isn't kicked out of the object by the constraints. Of course, I've only scratched the surface of it, but at least early-on, variable timestep stuff was a great way to wind up with a very unstable physics environment.

OneEightHundred fucked around with this message at 06:05 on Dec 7, 2008

# ? Dec 7, 2008 06:01

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

OneEightHundred posted:

Really? Synchronizing players is probably one of the bigger challenges in a network environment, and probably the aspect with the largest number of different approaches used.

... which is why I said that synchronizing physics is no harder?? Once you have player synchronization working, physics synchronization pretty much just falls out (though you may want to put in some optimizations for physics objects).

OneEightHundred posted:

As for fixed-timestep, the problem with variable timestep is when systems that allow penetration gently caress up when something isn't kicked out of the object by the constraints. Of course, I've only scratched the surface of it, but at least early-on, variable timestep stuff was a great way to wind up with a very unstable physics environment.

I'm not sure how fixed timesteps would resolve this issue?

# ? Dec 7, 2008 07:57

krysmopompas: Jan 17, 2004; hi

Avenging Dentist posted:

... which is why I said that synchronizing physics is no harder?? Once you have player synchronization working, physics synchronization pretty much just falls out (though you may want to put in some optimizations for physics objects).

Yeah, but when you have to consider that someone will be hosting a game over dsl or cable, a lot of physics synchronization just isn't going to happen.

Fixed timesteps are more about being able to do things without synchronization than with it. If there is anything any game physics code is really, really, bad at (this includes PhysX, Havok and anything custom I've ever seen) it is achieving the exact same result in two slightly complex but identical situations when the timestep is different.

It doesn't matter too much when you're talking about ragdolls, which never match up on any game, or any other simple, non-gameplay relevant effects. But it's really limiting in terms of gameplay to have to limit yourself to extremely simple scenarios involving physics because of the glitchyness of correcting on the clients, or simply due to bandwidth concerns.

# ? Dec 7, 2008 08:48

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

krysmopompas posted:

It doesn't matter too much when you're talking about ragdolls, which never match up on any game, or any other simple, non-gameplay relevant effects. But it's really limiting in terms of gameplay to have to limit yourself to extremely simple scenarios involving physics because of the glitchyness of correcting on the clients, or simply due to bandwidth concerns.

How often is that actually an issue, though? I can't think of any games except Garry's Mod where there are a large number of gameplay-affecting physics objects at once. Usually it's either a handful of crates and/or barrels, which are stationary except for short bursts of activity (and even the most generic FPS only has so many crates), or it's what amounts to particle effects that can bounce off walls but don't really affect anything anyway.

EDIT: How does a system like that deal with packet loss? When using a system that occasionally sends update packets to resync objects, you can just wait until the next packet comes in and update accordingly. If only one packet is ever sent out for a given object, losing that packet would mean it would never behave on the client the way the server expects it to.

Avenging Dentist fucked around with this message at 09:09 on Dec 7, 2008

# ? Dec 7, 2008 08:53

cronio: Feb 15, 2002; Drifter

Avenging Dentist posted:

How often is that actually an issue, though? I can't think of any games except Garry's Mod where there are a large number of gameplay-affecting physics objects at once. Usually it's either a handful of crates and/or barrels, which are stationary except for short bursts of activity (and even the most generic FPS only has so many crates), or it's what amounts to particle effects that can bounce off walls but don't really affect anything anyway.

EDIT: How does a system like that deal with packet loss? When using a system that occasionally sends update packets to resync objects, you can just wait until the next packet comes in and update accordingly. If only one packet is ever sent out for a given object, losing that packet would mean it would never behave on the client the way the server expects it to.

The bandwidth requirements/difficulty is why you don't see many multiplayer games with gameplay-changing physics objects.

Games will usually have a reliable networking layer built on top of UDP, such that you can specify that a message is unguaranteed, guaranteed, or possibly guaranteed-ordered.

# ? Dec 7, 2008 09:19

krysmopompas: Jan 17, 2004; hi

Avenging Dentist posted:

How often is that actually an issue, though? I can't think of any games except Garry's Mod where there are a large number of gameplay-affecting physics objects at once. Usually it's either a handful of crates and/or barrels, which are stationary except for short bursts of activity (and even the most generic FPS only has so many crates), or it's what amounts to particle effects that can bounce off walls but don't really affect anything anyway.

It's more that you get tossing crates and barrels around because it's pretty much all we can realistically do, with the given tools. Weird multiplayer physics ideas come up all the time in brainstorming sessions but tend to get shot down pretty quickly for that reason.

# ? Dec 7, 2008 09:28

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

cronio posted:

The bandwidth requirements/difficulty is why you don't see many multiplayer games with gameplay-changing physics objects.

Games will usually have a reliable networking layer built on top of UDP, such that you can specify that a message is unguaranteed, guaranteed, or possibly guaranteed-ordered.

Even with reliable networking, you would have issues, I think. Supposing you have N physics objects that get exploded, but the packets for the last K objects arrive a few frames later than expected. Do you

1) store previous physics states for the games, roll back, and recalculate physics for everything (incurring both a memory and CPU hit)
2) run the physics code for the last K objects until they're up-to-date and hope things work out
3) demand updated information from the server and hope you get lucky with packets?

krysmopompas posted:

It's more that you get tossing crates and barrels around because it's pretty much all we can realistically do, with the given tools. Weird multiplayer physics ideas come up all the time in brainstorming sessions but tend to get shot down pretty quickly for that reason.

Well, that's part of my point. I can't think of any way to guarantee relatively accurate mirroring of physics events without providing periodic updates to correct any errors. Networking is a bitch. We should just pull a Carmen Sandiego and steal South Korea's internet.

# ? Dec 7, 2008 09:36

cronio: Feb 15, 2002; Drifter

Avenging Dentist posted:

Even with reliable networking, you would have issues, I think. Supposing you have N physics objects that get exploded, but the packets for the last K objects arrive a few frames later than expected. Do you

1) store previous physics states for the games, roll back, and recalculate physics for everything (incurring both a memory and CPU hit)
2) run the physics code for the last K objects until they're up-to-date and hope things work out
3) demand updated information from the server and hope you get lucky with packets?

Well, that's part of my point. I can't think of any way to guarantee relatively accurate mirroring of physics events without providing periodic updates to correct any errors. Networking is a bitch. We should just pull a Carmen Sandiego and steal South Korea's internet.

No one here is disagreeing with you. You don't see any multiplayer games with complex physics setups because it's too difficult to do right now. The last FPS I worked on (which just came out a month or so ago) does entirely peer-to-peer communication, with no authoritative server involved, so nothing physics-related is synced at all. It's simply assumed that physics is for eye-candy and nothing else.

# ? Dec 7, 2008 10:03

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

cronio posted:

No one here is disagreeing with you. You don't see any multiplayer games with complex physics setups because it's too difficult to do right now. The last FPS I worked on (which just came out a month or so ago) does entirely peer-to-peer communication, with no authoritative server involved, so nothing physics-related is synced at all. It's simply assumed that physics is for eye-candy and nothing else.

Well, I'm not really arguing, I just want to make sure I'm on the same page as everyone. I'm not a professional game developer (and god willing, I'll never be), so I obviously have somewhat limited information about what real game studios do.

# ? Dec 7, 2008 10:06

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Avenging Dentist posted:

... which is why I said that synchronizing physics is no harder??

Oops, read it backwards.

Avenging Dentist posted:

I'm not sure how fixed timesteps would resolve this issue?

I've barely scratched the surface of physics stuff so I may not have my information right, but the jist is that if something impacts a solid surface then normally a sort of counter-impulse is expected to kick it out, except if the timestep that pushed it in was longer than the one kicking it back out, it'll still be in the object and weird poo poo happens. I doubt that's perfectly accurate, but it's something to that effect.

As far as physics synchronization goes, it is critical to do in properly in some games, especially those with VEHICLES, and there are ways to do it. BF2 does it by using delayed synchronous player movement, Unreal does it by running two simulations and using some hacky stuff to kick players out of vehicles when they get run over.

# ? Dec 7, 2008 14:31

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

I wonder how Little Big Planet does synchronization. Almost every game object is a "gameplay-affecting physics object." Sometimes the online experience is awfully laggy, however.

# ? Dec 7, 2008 17:04

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

Mustach posted:

I wonder how Little Big Planet does synchronization. Almost every game object is a "gameplay-affecting physics object." Sometimes the online experience is awfully laggy, however.

LBP is essentially a 2d game, right? I mean, the models are 3d for sure, but you don't really interact with the depth of the game. Seems like 2D physics are a whole mess more straightforward than 3D physics.

# ? Dec 7, 2008 19:45

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

Pfhreak posted:

LBP is essentially a 2d game, right? I mean, the models are 3d for sure, but you don't really interact with the depth of the game. Seems like 2D physics are a whole mess more straightforward than 3D physics.

All of the objects can interact in all three dimensions. The gameplay is "2D" with three "lanes" or "layers", but objects can have variable depth and interact on any combination of the three layers.

# ? Dec 7, 2008 23:00

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

Mustach posted:

I wonder how Little Big Planet does synchronization. Almost every game object is a "gameplay-affecting physics object." Sometimes the online experience is awfully laggy, however.

There's little going on other than the physics interactions, and all the real action is mostly confined the small area around the players, which reduces the number of active objects. How many players can you play with? 2? 4?

# ? Dec 8, 2008 00:19

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

tbradshaw posted:

All of the objects can interact in all three dimensions. The gameplay is "2D" with three "lanes" or "layers", but objects can have variable depth and interact on any combination of the three layers.

2^32 * 2^32 * 3 is a hell of a lot less than 2^32 * 2*32 * 2^32.

# ? Dec 8, 2008 01:30

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

Avenging Dentist posted:

2^32 * 2^32 * 3 is a hell of a lot less than 2^32 * 2*32 * 2^32.

No. The gameplay is limited to the "lanes", the physics engine is not. Ala, if a log 3 "lanes" deep is rolling, and hits something only on "lane 1", it can spin off the front of the "map". Things can move forward and backwards, etc, with full physical interaction.

MasterSlowPoke posted:

There's little going on other than the physics interactions, and all the real action is mostly confined the small area around the players, which reduces the number of active objects. How many players can you play with? 2? 4?

Yeah, 4. And you can't get too far apart or it kills the distant player. Probably the screen size * 5 or so in running world. Although, the off screen things might not be really "running", I haven't noticed either way. I know an off-screen lift still works, but perhaps only essentials are "running".

tbradshaw fucked around with this message at 02:34 on Dec 8, 2008

# ? Dec 8, 2008 02:31

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

tbradshaw posted:

No. The gameplay is limited to the "lanes", the physics engine is not. Ala, if a log 3 "lanes" deep is rolling, and hits something only on "lane 1", it can spin off the front of the "map". Things can move forward and backwards, etc, with full physical interaction.

Yes, but at that point, it's just for show anyway, so you don't actually need a whole lot of accuracy. I'd be willing to bet money that most of the physics is optimized for a discrete Z component and that it just makes things look like they're more complex.

# ? Dec 8, 2008 02:35

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

Avenging Dentist posted:

Yes, but at that point, it's just for show anyway, so you don't actually need a whole lot of accuracy. I'd be willing to bet money that most of the physics is optimized for a discrete Z component and that it just makes things look like they're more complex.

I guess it just depends on what you consider "physics" and what you consider "rendering". It seems like a pretty flexible boundary lots of the time. I would also wager that most interactions are optimized for limited Z.

The depth (ala, thoroughness rather than coordinates) of simulation is still quite involved. Enough that it provides an interesting academic exercise to consider a game that requires much physics synchronization. Especially in light of recent traffic in the thread.

edit: Here's a YouTube video that shows Little Big Planet displaying exactly 2D behavior, http://www.youtube.com/watch?v=3e84YLG8NRU.

# ? Dec 8, 2008 02:47

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

tbradshaw posted:

edit: Here's a YouTube video that shows Little Big Planet displaying exactly 2D behavior, http://www.youtube.com/watch?v=3e84YLG8NRU.

If everything is exactly on the same Z coordinate, and symmetrical along the XY plane (which spheres are), then it's going to wind up looking 2D because there is nothing pushing anything along the Z axis.

# ? Dec 8, 2008 07:08

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

OneEightHundred posted:

If everything is exactly on the same Z coordinate, and symmetrical along the XY plane (which spheres are), then it's going to wind up looking 2D because there is nothing pushing anything along the Z axis.

Fair, an alternative: http://www.youtube.com/watch?v=Z8HkbqEGSic&feature=related

# ? Dec 8, 2008 08:27

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

tbradshaw posted:

Fair, an alternative: http://www.youtube.com/watch?v=Z8HkbqEGSic&feature=related

To be honest, this behaves as if there was no 3rd dimension.

# ? Dec 8, 2008 17:17

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

Pfhreak posted:

To be honest, this behaves as if there was no 3rd dimension.

Yes, agreed. As Avenging Dentist supposed, other than a few discrete z-axis values, the 3rd dimension appears to only be used for rendering.

# ? Dec 8, 2008 17:48

Contero: Mar 28, 2004

tbradshaw posted:

Yes, agreed. As Avenging Dentist supposed, other than a few discrete z-axis values, the 3rd dimension appears to only be used for rendering.

Avenging Dentist! :argh:

Why must you be right about everything?

I have a stupid openGL question: How the hell do you do texture mapping?

I know this seems like something that should be a no-brainer, just go google for it right? But every tutorial or explanation seems to do it entirely differently. I have a book that uses glBitmap, an example that uses some strange bind call and also looks at least 10 years old and my professor does it some terrible way where he creates the bitmap every frame.

So I'm betting that there is a generally accepted, clean and fast way do load textures and render them onto quads in openGL.

code:


void init ()
{
    BYTE rbg_bitmap[256][256][3]; //lets assume I already filled this with info from a file with RGB values.
    
    // Do some magic to load this as a texture
}

void draw ()
{
    
    // Some openGL calls to set up the texture and scene
    
    glBegin(GL_QUADS);
    
    // setup texture coords for vertex
    glVertex3f(0,0,0);
    // setup texture coords for vertex
    glVertex3f(0,1,0);
    // setup texture coords for vertex
    glVertex3f(1,1,0);
    // setup texture coords for vertex
    glVertex3f(1,0,0);
    
    glEnd();
    glutSwapBuffers();
}

Can anyone help me fill in the blanks?

# ? Dec 9, 2008 05:37

a slime: Apr 11, 2005

Contero posted:

code:


GLuint texture;

void init ()
{
    BYTE rbg_bitmap[256][256][3]; //lets assume I already filled this with info from a file with RGB values.
    
    glGenTextures(1, &texture);
    glBindTexture(GL_TEXTURE_2D, texture);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 256, 256, 0, GL_RGB, GL_BYTE, rbg_bitmap); // rgb_bitmap?
}

void draw ()
{
    
    // Some openGL calls to set up the scene

    glEnable(GL_TEXTURE_2D);
    glBindTexture(GL_TEXTURE_2D, texture);
    
    glBegin(GL_QUADS);
    
    glTexCoord2f(0,0);
    glVertex3f(0,0,0);
    glTexCoord2f(0,1);
    glVertex3f(0,1,0);
    glTexCoord2f(1,1);
    glVertex3f(1,1,0);
    glTexCoord2f(1,0);
    glVertex3f(1,0,0);
    
    glEnd();

    glDisable(GL_TEXTURE_2D);
    glutSwapBuffers();
}

Can anyone help me fill in the blanks?

Is it an RGB bitmap or an RBG bitmap?

You need to generate a texture using glGenTextures and load the image data to it with glTexImage2D. If you're only rendering the one object, you could move the glEnable and glBindTexture calls out of the loop. glTexCoord lays out texture coordinates on the quad.

edit: You're also going to want a corresponding glDeleteTextures somewhere.

a slime fucked around with this message at 06:05 on Dec 9, 2008

# ? Dec 9, 2008 05:56

Contero: Mar 28, 2004

not a dinosaur posted:

Is it an RGB bitmap or an RBG bitmap?

You need to generate a texture using glGenTextures and load the image data to it with glTexImage2D. If you're only rendering the one object, you could move the glEnable and glBindTexture calls out of the loop. glTexCoord lays out texture coordinates on the quad.

edit: You're also going to want a corresponding glDeleteTextures somewhere.

Yes I meant RGB.

This is awesome. See, your code doesn't look insane and I can actually see what calls are relevant to the texture mapping. I'll give this a try. Thanks.

# ? Dec 9, 2008 10:57

a slime: Apr 11, 2005

Contero posted:

Yes I meant RGB.

This is awesome. See, your code doesn't look insane and I can actually see what calls are relevant to the texture mapping. I'll give this a try. Thanks.

I left something out- before doing glTexImage2D, you need to call glPixelStorei

code:

glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

Which tells OpenGL that your pixel data is byte-aligned (as opposed to word-aligned which I believe is the default). Otherwise, you'll probably have a segfault or something because glTexImage2D will try to read four times the data you actually have.

I think it's a few pages back now, but we do have an OpenGL thread here in CoC. People there will be much better at answering your questions.

# ? Dec 9, 2008 11:22

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

PnP Bios: Oct 24, 2005; optional; no images are allowed, only text

not a dinosaur posted:

I left something out- before doing glTexImage2D, you need to call glPixelStorei
code:
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
Which tells OpenGL that your pixel data is byte-aligned (as opposed to word-aligned which I believe is the default). Otherwise, you'll probably have a segfault or something because glTexImage2D will try to read four times the data you actually have.

I think it's a few pages back now, but we do have an OpenGL thread here in CoC. People there will be much better at answering your questions.

You don't need glPixelStorei. And technically, shouldn't he be using PBO's :P

# ? Dec 10, 2008 06:07

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:04

Morpheus: Apr 18, 2008; My favourite little monsters

I've got a program that has a structure similar to this (in C#):

code:

GameObject
     |
MovableObject
     | 
   Entity
   |     |
Player   Enemy

There's a function called collide() in GameObject that is overridden in each of the objects. I also have a List that holds a bunch of GameObjects in it, but they're really Players, Enemies, and other MovableObjects, just stored as GameObjects. Now, if I get an GameObject out of the List, is there anyway to call collide() on it so that Player.collide() or Enemy.collide() or whatever is called, instead of GameObject.collide()? The only way I can figure is to type cast every object I pull out of the List like:

code:

foreach (GameObject gO in ListOfObjects){
  if (gO is Player) { (Player)gO.collide(); }
  if (gO is Enemy) { (Enemy)gO.collide(); }
  etc.
}

Which pretty much defeats the purpose of putting collision code in each object.

# ? Dec 18, 2008 00:07

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

«‹›622 »