Game Development Megathread

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

«‹›4 »

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

zigb posted:

code:

// Instead of defining flags like:
#define FLAG1 = 1 
#define FLAG2 = 2
#define FLAG3 = 4
#define FLAG4 = 8
... 
// They use left-shifts to do the same thing, in a much more readable (to me) manner: 
#define FLAG1 = 1<<0
#define FLAG2 = 1<<1
#define FLAG3 = 1<<2
...

Too bad they're still using #defines. :barf:

# ¿ Dec 7, 2007 17:56

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 01:43

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

Kimani posted:

A massively threaded game environment.

I have not the words.

# ¿ Sep 14, 2008 20:29

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

Kimani posted:

This is the plan. We'll have, say, 1024 core machines sometime in the future, and this system will take full advantage of them. All new PCs sold today are dual core or better as it is.

Yeah, coding for a system that doesn't exist, and probably won't for another 10 years at least, seems like a great idea.

Kimani posted:

This means except for the time taken to do the updating and parsing any messages, it's sleeping the better part of 1/30th of a second.

Hahahahahahahaha

# ¿ Sep 15, 2008 00:06

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

ehnus posted:

CRITICAL_SECTIONS are only fast in the case where there is no contention. If there is contention for the lock then it degenerates into a MUTEX which means thousands of cycles wasted as you take a trip down into kernel land and I'd imagine there's a fair bit of contention with that many threads.

Even then, lockless programming is significantly faster, and all that still ignores the issue of object-level parallelism for collision detection/response.

I'm really not even going to bother explaining anymore why your chosen method of parallelism is stupid, since it should be self-evident to anyone with even the most rudimentary knowledge of multithreading.

Avenging Dentist fucked around with this message at 02:37 on Sep 15, 2008

# ¿ Sep 15, 2008 02:35

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

ehnus posted:

True, though lockless programming is drat difficult and fraught with pain and misery even if you have experience doing it.

One good way to do lockless programming is to use a single thread. :xd:

# ¿ Sep 15, 2008 02:48

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

Kimani posted:

Explain "anymore"? You haven't really said anything besides hahaha and that you haven't the words. I'm interested in your insight.

I'm not going to get into this too much, but parallelizing at the object level is inappropriate because it requires synchronization between any pair of objects to perform comparison between them (e.g. for collision detection). Parallelizing physics is extremely hard because - to create an efficient engine - operations on pairs of nearby objects should be as fast as possible (culling is very important too, but that's a separate issue). It would be better (though still not great) to have a thread per BSP partition rather than per object. This would greatly reduce the amount of synchronization and context switching required.

As other people have mentioned in brief, even for a supercomputer with arbitrarily many cores, your method of parallelism is inappropriate simply because of synchronization overhead. In general, you should always endeavor to put objects that "talk" to each other in a single thread.

Really trivial example of good parallelizing: imagine a 2d cartesian grid simulating the propagation of a wave. The equations for wave propagation at a given point are based on the adjacent points. By dividing the grid into an appropriate number of subgrids (one per core), you can achieve significant performance improvements in part because only the points at the edges of each subgrid depend on the points belonging to another core.

# ¿ Sep 15, 2008 03:41

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

ATL lets you keep track of reference counts in the output window:

http://msdn.microsoft.com/en-us/library/6x61t5y4(VS.80).aspx

# ¿ Sep 15, 2008 23:27

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'm also using GL with GL_NEAREST, not sure why you aren't having the same problem with scaling artifacts.

It doesn't happen at all float coordinates, only some. Lower image shows the ugliness.

You're probably getting floating-point error. Having textures with power-of-two coordinates helps, as does putting the textured quad in the middle of a pixel on the screen (i.e. if 1 unit = 1 pixel, your vertices should be some_int + 0.5).

# ¿ Dec 1, 2008 12:50

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

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

# ¿ Dec 4, 2008 08:33

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

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

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

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

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

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

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

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

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

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

nihilocrat posted:

I've gotten really addicted to trying to keep everything very seperated and decoupled, so in many cases this might be overkill, and it is safe (and easy) to just have one object call all the code and be done with it.

Given that you now need to define "force shield" code in 4 places, I would say this is the opposite of decoupled. :pwn:

# ¿ Dec 24, 2008 00:36

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

Staggy posted:

I'm not being arrogant, but how would you do it differently? I'm genuinely interested as to what sort of structure would work here.

Basically what ultra-inquisitor said.

Also, there's the whole "data-driven game engines" that game developers hype every couple years. (In other industries, this would just be considered "not being totally stupid".)

# ¿ Dec 25, 2008 04:31

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

OneEightHundred posted:

I've seen this with stuff like SOF2 and COD4. It works great until you need to make something that doesn't conform well to the preconceived ways that things of that type should work, then it becomes a complete pain in the rear end.

It's about a hundred times harder using a non-data-driven system.

# ¿ Dec 27, 2008 01:05

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

I think you're conflating hard-coding and data-driven models. A good data-driven model will let you extend things however you like (within reason). The real issue is when the data-driven model doesn't let you extend the various data types that represent objects in the game world. That's an issue with hard-coding.

# ¿ Dec 27, 2008 08:26

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

ehnus posted:

I think what you're looking for is called a scripting language.

Call me cynical but whenever I hear someone propose a data driven solution for a problem in video games I get the feeling that it will end up being fragile, bloated, slow, poorly designed, not willingly supported by developers, and not willingly used by artists/designers.

A good scripting language (and API/framework) is a good example of a data-driven model. Data-driven programming isn't just "using INI/XML/etc files", it's considerably more involved.

This page has a pretty good summary: http://www.catb.org/esr/writings/taoup/html/ch09s01.html

# ¿ Dec 28, 2008 03:05

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

Pixels are a terrible unit for pretty much anything gameplay related.

# ¿ Jan 11, 2009 23:26

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

Make some meaningful in-game measurement unit and either define your world coordinates in terms of them, or convert to screen coordinates.

# ¿ Jan 11, 2009 23:37

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

I'm not going to pore over the PyGame docs, but in general 3D rendering libraries (and PyGame uses OpenGL via SDL, so it's included) go through a "transformation pipeline". Basically, given a model (either 3D, or a sprite a.k.a. textured quad), you start with a set of coordinates. These are in "model space", that is, the origin is in the middle of the model (or something). To place this model somewhere, you have to supply a matrix transform, called the world transform, to put it somewhere in worldspace. From there, you need to transform the coordinates again into something based on the viewer/camera, called the view transform. From there, you continue on into the projection transform, which sets near and far clipping planes and does perspective. Then you transform it again into viewport coordinates, and draw it. There's more info about this here, but that's the idea.

I am going to assume that PyGame supports some kind of transformation pipeline like this because otherwise, it's completely loving retarded and couples the position of the camera with the position of objects in-game. If Python doesn't support anything but screen coordinates, you can make a transformation pipeline yourself, which really is just doing some matrix multiplication on every relevant coordinate.

# ¿ Jan 12, 2009 10:03

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

Why not just make an installer and have it install the dependencies?

# ¿ Jan 14, 2009 00:48

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

Null Pointer posted:

QueryPerformanceCounter has issues with Windows XP and some AMD processors or BIOSes when the scheduler assigns your thread to a different core than the previous call.

There's a hotfix for that (I think this is the one): http://support.microsoft.com/kb/895980

# ¿ Jan 14, 2009 22:32

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

Alvie posted:

code:
man::

Stop this.

# ¿ Jan 17, 2009 04:52

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

Of course it would, it's local to the class.

Also, don't use 1 and 0 for Boolean variables, you should be using true/false for readability.

Also also, you should probably just set some breakpoints or print some debug messages. There's nothing obviously wrong with your code (aside from some unusual choices regarding collision detection, gravity, and coordinate systems).

# ¿ Jan 17, 2009 05:00

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

very posted:

Find a good library. We use bullet.

Collision detection and physics are completely different.

# ¿ Jan 17, 2009 08:38

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

ehnus posted:

But also closely related in practice. If you had looked you would have seen that Bullet has a collision detection component.

I did look. But that doesn't change the fact that, if you're not going to use physics, Bullet is overkill.

# ¿ Jan 17, 2009 11:07

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

http://www.jenkinssoftware.com/

# ¿ Jan 19, 2009 01:22

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

Null Pointer posted:

The associated performance consequences should be obvious to anybody with even a passing knowledge of operating systems and schedulers.

Why not post numbers instead of handwaving? :colbert:

# ¿ Jan 19, 2009 07:45

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

What's wrong with the official Windows binaries?

# ¿ Jan 21, 2009 02:17

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

jonus posted:

I don't want to rewrite the game twice because I picked the wrong engine the first time.

If you actually had to rewrite a game because you changed graphics engines, it would speak way more to your talent (or lack thereof) as a programmer than to your choice in graphics engine.

# ¿ Feb 3, 2009 23:02

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

krysmopompas posted:

Right, because you can simply compile on XNA or Irrlicht at the flick of a switch if your programmer dick is big enough.

The things he listed are a lot more than just "graphics" engines. They impose a lot of constraints from the asset pipeline all the way to how entities are defined, processed and how they communicate; and there is little, if any, common ground between any of them.

I'm more speaking of "what kind of programmer would 99% finish a game and then say hey wait I just spent six months writing code for an engine that I knew was crap and unsuitable to my needs". If you're using a hypothetical awful engine and you get more than 10% of the way through a project before realizing that the engine is crap, then you've got problems. You could probably save a fair amount of the game logic at that point anyway, even if you have to restructure message-passing a little.

Besides that, the question seemed to be "can I make something pretty in engine X?" and really all you need to do is look at a few screenshots to answer that.

Nevertheless, my programmer dick is big enough that all my code compiles under all languages and all APIs at the same time. :2bong:

# ¿ Feb 4, 2009 00:04

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

krysmopompas posted:

Is there a Godwin-like law for invoking 3drealms yet?

I'm not sure DNF can even be counted as a single game anymore. More like several canceled games.

krysmopompas posted:

I'm not sure how someone new to development is going to be able to tell the difference between an engine being unsuitable, and not knowing what needs to be done or how best to achieve it. Hell, you have tech directors of major companies unable to tell the difference as well.

Well, someone new to development in general is probably going to have a hell of a time making a game (except for Pac-Man or something, I guess). But I think it depends a lot on the type of project. If you're trying to make a game with bleeding-edge graphics, you're under a lot harsher restrictions, since you need to be aware of performance at all times. If you're not trying to make the next Crysis, you're afforded a little bit more leniency and can hack things in that an engine might not be well-suited for.

Extreme example: with a simple sidescroller on modern machines, you'd hardly have to worry about performance at all. That's what makes stuff like PyGame possible. Who cares about optimizations when you're already getting 1000 FPS?

krysmopompas posted:

Anyhow, I think the key thing from his post isn't "pretty graphics" but the combination of the rts and fps view modes. Moving a camera around is an extremely simple task, but most engines do their damnedest to only assume that one way of moving it will work with 99% of the code already written.

I'd hope that you could resolve stuff like that in the prototyping stage, which is an especially important step if you aren't 100% sure what engine you want. Besides, I was responding primarily to this:

quote:

I'll be happy to start with crude 3d graphics and focus on the game mechanics, but at the very end of the development cycle I'd like to significantly improve the graphics without having to redo everything from the start.

krysmopompas posted:

p.s. I am glad for your penis.

So am I. Compile times are pretty long though since it's an NP-hard problem. :quagmire:

tl;dr: if your game doesn't have especially high performance requirements, it probably doesn't matter too much what engine you use if you get past prototyping, since that's probably where you'll find the big problems.

# ¿ Feb 4, 2009 01:25

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

Generally bounding volumes are used as an early-exit to avoid more expensive collision-detection.

# ¿ Feb 14, 2009 11:41

Adbot: ADBOT LOVES YOU

# ¿ May 3, 2024 01:43

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

MasterSlowPoke posted:

Yeah, I got that, but how am I supposed to use the bounding volume and keep the guy on the floor.

code:

if( intersects(guy.capsule(),ground) )
{
    if( intersects(guy.hull(),ground) )
    {
        guy.walking();
    }
}

# ¿ Feb 14, 2009 12:23

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

«‹›4 »