Game Development Megathread

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

«‹›623 »

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

unSavory posted:

It was unreal. But UDK's audio management is loving awful. I've gotten ten times farther in just a few days than I did over weeks of pushing through UDK. Just by switching to Unity so that I can code in a language that I know and not unrealscript.

I was wondering how you did that with UDK. Looks great, regardless!

Another way you could deal with the loop count is by throwing up relatively frequent mid bosses that trigger breaks and bridges. Though that would require you to do quite a few more track variations, for each segment of the level between each mid-boss.

# ? Sep 18, 2011 02:19

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 10:12

Paniolo: Oct 9, 2007; Heads will roll.

What program are you using to make the music tracks, by the way?

# ? Sep 18, 2011 03:16

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

My suggestion, since people are making suggestions, is that it would be a neat thing a few times to have to form a specific tune to get past a door/boss. So you'd have to be carrying the bass rhythm from monster type A, and the drum rhythm from monster type Q, etc. (With the thing you have to get past playing the tune you need to pass it, probably.)

# ? Sep 18, 2011 05:05

unSavory: Sep 26, 2004; fellow

Paniolo posted:

What program are you using to make the music tracks, by the way?

Ableton Live. Makes splitting a track into game friendly loops really easy.

Thanks for all the ideas and suggestions everyone. Definitely got me to rethinking a few things.

# ? Sep 18, 2011 06:22

Leif.: Mar 27, 2005; Son of the Defender
Formerly Diplomaticus/SWATJester

Powerup envelopes.

# ? Sep 18, 2011 07:54

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

unSavory posted:

Ableton Live. Makes splitting a track into game friendly loops really easy.

Thanks for all the ideas and suggestions everyone. Definitely got me to rethinking a few things.

Also... I assume you've seen this, but just to be sure, realize you're going to be compared to Planck pretty heavily: http://www.shadegrowngames.com/whatisplanck/

Very similar concepts at work. Taking down enemies to build a beat, etc. Not a bad thing, it just helps to be aware of the likely comparisons ahead of time.

# ? Sep 18, 2011 16:10

unSavory: Sep 26, 2004; fellow

Thanks for bringing that to my attention. Looks like a pretty cool game. I'm not to worried about the comparisons really. It seems like they're going for more of a Rez meets Guitar Hero on rails kindof feel than the free motion I'm trying to achieve.

Also if anyone has music experience, I'm going to post up a musicians lounge thread in a bit. The game has a soundpack feature allowing for guest artists to make downloadable content in the form of prepackaged sets. Details will be posted in that thread later today.

Edit: somebody else should post something their working on! I feel like I've hijacked the thread. Oops haha

unSavory fucked around with this message at 19:38 on Sep 18, 2011

# ? Sep 18, 2011 19:36

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

poemdexter posted:

HumanControl: This is something I might look into later. Right now I let XNA's keyboard stuff worry about moving and just tells the player entity to do an action for the position component. Of course my only keys at the moment are up,down,left, right so this might get changed later.
AI: Mobs have a component for the A* pathfinding. the action is "MoveTowards". It takes an argument of the target position (in case i want mobs to pick up gold and not just steam towards player). The action will actually do the pathfinding and the tell the position component to move.

I thought I would update the thread--and particularly you for expressing some interest--in what came up while I was getting HumanControl working. It gets a little hairy when it comes to activities that could get cancelled.

Say that you are doin something with real-time rendering with a 3d animated mesh, although it isn't entirely necessary. Once an attack animation is triggered, you probably don't want to let the player just let go of the attack button, and move around, aborting that animation. Similarly, you wouldn't want an enemy to always be able to abort an attack sequence. So once the attack animation starts, a lot of animation is suspended.

In my case, the state of animation is in one component, but human control is the one trying to request things happen up front. So there's some interplay there. What I have right now is that HumanControl will send a request out to anything that will tell it if the entity isn't accepting movement at the moment. If it's accepting movement, it will update the position component, which here has a relation to physics. That figures out the physical possibilities of movement. Once that component says it's okay, it sends out yet another signal that everything is in fact moving, and the mesh better get animated like it is.

It's kind of ugly. Another thing I thought I'd try is have the animation component send a signal when it wasn't moving, and then other components could unregister for certain signals until another comes along saying all is well again.

----

I picked up some of the Game Programming Gems books and saw some neat stuff. I've been doing C for... almost 20 years (holy poo poo!) and never really respected macros too much, but there was some good stuff about how to use them effectively. I haven't really interacted with expert C or C++ developers too much so it was enlightening to see why they decide to do this or that. Amongst some of the stuff was A*. I haven't worked on the AI side with pathfinding at all, so I have been worried about this. I'm kind of wondering how this has worked out for anybody else on here. In my case, I'm not working with systematic tiles so it sounds like I should probably define waypoints in my levels to guide AI.

# ? Sep 18, 2011 22:58

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Rocko Bonaparte posted:

I thought I would update the thread--and particularly you for expressing some interest--in what came up while I was getting HumanControl working. It gets a little hairy when it comes to activities that could get cancelled.

Say that you are doin something with real-time rendering with a 3d animated mesh, although it isn't entirely necessary. Once an attack animation is triggered, you probably don't want to let the player just let go of the attack button, and move around, aborting that animation. Similarly, you wouldn't want an enemy to always be able to abort an attack sequence. So once the attack animation starts, a lot of animation is suspended.

In my case, the state of animation is in one component, but human control is the one trying to request things happen up front. So there's some interplay there. What I have right now is that HumanControl will send a request out to anything that will tell it if the entity isn't accepting movement at the moment. If it's accepting movement, it will update the position component, which here has a relation to physics. That figures out the physical possibilities of movement. Once that component says it's okay, it sends out yet another signal that everything is in fact moving, and the mesh better get animated like it is.

It's kind of ugly. Another thing I thought I'd try is have the animation component send a signal when it wasn't moving, and then other components could unregister for certain signals until another comes along saying all is well again.

----

I picked up some of the Game Programming Gems books and saw some neat stuff. I've been doing C for... almost 20 years (holy poo poo!) and never really respected macros too much, but there was some good stuff about how to use them effectively. I haven't really interacted with expert C or C++ developers too much so it was enlightening to see why they decide to do this or that. Amongst some of the stuff was A*. I haven't worked on the AI side with pathfinding at all, so I have been worried about this. I'm kind of wondering how this has worked out for anybody else on here. In my case, I'm not working with systematic tiles so it sounds like I should probably define waypoints in my levels to guide AI.

It seems kind of ugly, but that's probably how I'd do the animation honestly. I'm lucky enough where I'm only dealing with sprites in a roguelike so your problem is a little out of my scope.

For A*, you'd definitely want some sort of waypoints in your game. The more waypoints you use, the more interesting the movement of your AI can be. Also remember that you have the option to add weights to your points so that the AI might go around a puddle of mud instead of walking through it if it turns out it's faster to go around.

http://www.policyalmanac.org/games/aStarTutorial.htm

I love this link. It explains everything very very clearly and even has some images so you can follow it along. There's no code examples so don't worry about trying to parse java to C++ or anything like that.

Personally, I have a "move via AI" component. You pass the target to the entity and it gives you the queue of moves you need to take to get to the target. Very handy.

# ? Sep 18, 2011 23:52

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

poemdexter posted:

Personally, I have a "move via AI" component. You pass the target to the entity and it gives you the queue of moves you need to take to get to the target. Very handy.

The one thing to watch out for in this type of system is to make sure the queue of moves doesn't go "stale" as things in the world move around and change the paths that are available. Ask me how many times I've created bugs that centered around this!

# ? Sep 19, 2011 02:30

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Does anyone know of a good SlimDX guide? The SlimDX website contains a whopping three examples that don't get any more sophisticated than drawing a single colored triangle, and the SDK contains about a dozen other bits of code which are mostly uncommented and annoyingly split up into a dll file + stuff that taps into that dll for added unbrowsability.

The SlimDX system looks cool as heck, but it feels like every single step that I try to take results in a half-hour of searching github or Google code for examples, or trying to translate C++ DirectX code into the mashed-up version of the API that SlimDX exposes via the poke-n-hope method.

There's just got to be an easier way to do learn this. :negative:

# ? Sep 19, 2011 03:03

AntiPseudonym: Apr 1, 2007; I EAT BABIES

Rocko Bonaparte posted:

I thought I would update the thread--and particularly you for expressing some interest--in what came up while I was getting HumanControl working. It gets a little hairy when it comes to activities that could get cancelled.

Say that you are doin something with real-time rendering with a 3d animated mesh, although it isn't entirely necessary. Once an attack animation is triggered, you probably don't want to let the player just let go of the attack button, and move around, aborting that animation. Similarly, you wouldn't want an enemy to always be able to abort an attack sequence. So once the attack animation starts, a lot of animation is suspended.

This really does seem like a prime situation for using a state machine.

The way I deal with it in my system is to have a CharacterStateManager component that is responsible for setting states as well as playing animations. States can be interrupted, but the current and the next states check whether or not they want to do the interrupt, queue it or just deny it. For example:

code:

State::InterruptResult AttackState::CanInterrupt(State *nextState)
{
    // Can cancel attack state with a jump (Jump cancelling)
    if(nextState == characterComponent->GetJumpState())
    {
        return INTERRUPT_Allow;
    }

    // Allow the player to play hit reactions after a certain point in the animation
    if(!IsAttackCoolingDown())
    {
        return INTERRUPT_Allow;
    }

    // Queue up the next attack
    if(nextState == characterComponent->GetAttackState())
    {
        return INTERRUPT_Queue;
    }

    // Nothing else is allowed to interrupt
    return INTERRUPT_Disallow;
}

void AttackState::OnStart(State *previousState)
{
    cAnimatedModel *model = GetComponent<cAnimatedModel>();

    if(model)
    {
        if(previousState == characterComponent->GetAttackState())
        {
            model->PlayAnimation("AttackCombo");
        }
        else
        {
            model->PlayAnimation("AttackFromStanding");
        }
    }
}

# ? Sep 19, 2011 05:39

Relaxodon: Oct 2, 2010

Does anyone know a good resource for animated 3D models? I need stuff to display with my engine. I don't have much expertise with modeling software, so i need something free to test with. I am using OpenGL so no .x stuff please.

# ? Sep 19, 2011 09:14

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Internet Janitor posted:

The one thing to watch out for in this type of system is to make sure the queue of moves doesn't go "stale" as things in the world move around and change the paths that are available. Ask me how many times I've created bugs that centered around this!

I do the exact opposite and refresh the queue every turn. I'm banking on the fact that roguelikes don't have that many monsters at the player at once as well as being small rooms and hallways making the A* not take long at all. So far so good.

# ? Sep 19, 2011 13:55

seiken: Feb 7, 2005; hah ha ha

unSavory posted:

Also if anyone has music experience, I'm going to post up a musicians lounge thread in a bit. The game has a soundpack feature allowing for guest artists to make downloadable content in the form of prepackaged sets. Details will be posted in that thread later today.

I'll totally be a guest artist! Did you post this yet? I couldn't see it.

# ? Sep 19, 2011 14:18

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

poemdexter posted:

I do the exact opposite and refresh the queue every turn. I'm banking on the fact that roguelikes don't have that many monsters at the player at once as well as being small rooms and hallways making the A* not take long at all. So far so good.

Oh. Well usually I do the same but I just return a single delta that will move you toward the target. If the path is regenerated every tick you don't really need to return a queue at all. If you aren't generating an entire path you can potentially speed things up a lot by first walking a low-rez graph of components in the map, possibly representing rooms. In a dungeon-like maze there will be a lot of rooms that are only accessible from a limited number of small chokepoints. Then if you know a sequence of rooms is in the optimal path you can do a normal A* to the closest chokepoint leading you along that path. I think Dwarf Fortress does something along these lines, but I think the DF implementation loses path optimality.

# ? Sep 19, 2011 14:56

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Internet Janitor posted:

Oh. Well usually I do the same but I just return a single delta that will move you toward the target. If the path is regenerated every tick you don't really need to return a queue at all. If you aren't generating an entire path you can potentially speed things up a lot by first walking a low-rez graph of components in the map, possibly representing rooms. In a dungeon-like maze there will be a lot of rooms that are only accessible from a limited number of small chokepoints. Then if you know a sequence of rooms is in the optimal path you can do a normal A* to the closest chokepoint leading you along that path. I think Dwarf Fortress does something along these lines, but I think the DF implementation loses path optimality.

Hmmm. That's actually pretty interesting! However, all mobs are docile until the player opens the door. So even then, there's maybe max 10 spaces the mob needs to traverse to get to the player. I probably will switch up the method to return a single point to move to howevever, it's one extra line of code and not a big deal at the moment.

# ? Sep 19, 2011 15:10

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

Relaxodon posted:

Does anyone know a good resource for animated 3D models? I need stuff to display with my engine. I don't have much expertise with modeling software, so i need something free to test with. I am using OpenGL so no .x stuff please.

Use the dubiously-named Assimp for loading, it supports the majority of readily-available game formats and intermediates (including .blend and .dae)

How you animate it is up to you, there are basically three ways to do skeletal animation:

- Store weights as premultiplied bone-space coordinates and the vertex index, deform by doing a large number of multiply-adds. This is the best method if you're deforming on the CPU.
- Store a reference frame, handle weights as a list of weights per vertex with a maximum count (usually 4). This is the best method if you're deforming on the GPU.
- Store unique weight combinations and assign each vertex to one, preblend them (you can linearize them similar to the first method), then deform each vertex using the weight combination. This is the best for CPU deforming if you're dealing with a model with fewer than 1 unique weight combination per 4 vertexes, otherwise the first method is better.

Storing your models as unique weight combinations and a reference frame is the best approach in general since it's easily convertible to either of the other two approaches in a single-step operation.

OneEightHundred fucked around with this message at 16:46 on Sep 19, 2011

# ? Sep 19, 2011 16:44

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

poemdexter: Totally. Always go with the most straightforward implementation of pathfinding you can and then add complexity when you realize performance is becoming an issue. Often it never is. The main advantage of just returning a single delta is that it's a weaker contract and thus gives you more flexibility for changing the underlying pathfinding algorithm later without disturbing your consumers.

# ? Sep 19, 2011 17:01

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Internet Janitor posted:

poemdexter: Totally. Always go with the most straightforward implementation of pathfinding you can and then add complexity when you realize performance is becoming an issue. Often it never is. The main advantage of just returning a single delta is that it's a weaker contract and thus gives you more flexibility for changing the underlying pathfinding algorithm later without disturbing your consumers.

Agreed on straightforward implementation. The developer for Braid had a talk at some college and the audio was on the internet and he talked a lot about just putting your mechanic in in the most simple way possible and then dealing with performance ONLY when it is an issue. I'm looking for it now but a lot of the media is blocked on company firewall so I'm not sure which it is.

# ? Sep 19, 2011 17:05

unSavory: Sep 26, 2004; fellow

seiken posted:

I'll totally be a guest artist! Did you post this yet? I couldn't see it.

Not yet. I got kindof sidetracked by real life work last night. I'll post an update here when I've got the thread put together

# ? Sep 19, 2011 19:02

Relaxodon: Oct 2, 2010

OneEightHundred posted:

Use the dubiously-named Assimp for loading, it supports the majority of readily-available game formats and intermediates (including .blend and .dae)

How you animate it is up to you, there are basically three ways to do skeletal animation:

- Store weights as premultiplied bone-space coordinates and the vertex index, deform by doing a large number of multiply-adds. This is the best method if you're deforming on the CPU.
- Store a reference frame, handle weights as a list of weights per vertex with a maximum count (usually 4). This is the best method if you're deforming on the GPU.
- Store unique weight combinations and assign each vertex to one, preblend them (you can linearize them similar to the first method), then deform each vertex using the weight combination. This is the best for CPU deforming if you're dealing with a model with fewer than 1 unique weight combination per 4 vertexes, otherwise the first method is better.

Storing your models as unique weight combinations and a reference frame is the best approach in general since it's easily convertible to either of the other two approaches in a single-step operation.

Thanks for the overview, I will read up about all that in more detail once i have this Entity/Component thing setup. Assimp looks nice, too bad i am programming C#. But maybe i can call it via Interop.

# ? Sep 19, 2011 19:16

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

Convert to your internal format. A bunch of those formats (i.e. blend, DAE, SMD) are pretty capable but are terrible for direct use.

# ? Sep 19, 2011 19:55

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

OneEightHundred posted:

Convert to your internal format. A bunch of those formats (i.e. blend, DAE, SMD) are pretty capable but are terrible for direct use.

This. Try and think in terms of two asset sets - the during development set, and the baked-for-release set.

If you use an interchange format like DAE for internal work, you open your toolbase up to be augmented by all kinds of things that take in and spit out DAEs. Not so, if you use baked-for-release assets only.

# ? Sep 19, 2011 20:08

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

What is the best way to implement a stable framerate timer/limiter system?

I'm trying to move from XNA to SlimDX and I'd like to emulate XNA's default behavior of locking the framerate to a maximum of 60FPS for Update/Draw calls, plus falling back to only calling Update if the system can't keep up. Most SlimDX examples just run the loops as fast as they can go but I want to preserve any extra CPU cycles beyond what's needed for 60FPS to do other stuff with and physics simulations can get squirreley if when the framerate gets too fast or bounces around a lot.

The dead simple thing to do is use .NET's System.Timers.Timer class to trigger something every 16ms (close enough), or I could tap into Win32.dll and use a QueuedTimer to callback into my code, but I don't know how stable these things will be given that Windows has a 4ms thread quanta which is a pretty huge percentage variation on top of a targeted 16.67ms per frame time.

How do the AAA games handle this stuff?

# ? Sep 20, 2011 02:11

Internet Janitor: May 17, 2008; "That isn't the appropriate trash receptacle."

Echoing PDP-1's question. I've tried a number of approaches for framerate control and building my game engines around variable-speed ticks, but most of the time I just end up sleeping for a couple milliseconds and calling it good- so long as the sleep time dominates the time spent working by a large factor the results are consistent enough. I'd love to know what the best practices are for this sort of thing.

# ? Sep 20, 2011 02:33

unSavory: Sep 26, 2004; fellow

seiken posted:

I'll totally be a guest artist! Did you post this yet? I couldn't see it.

Here's the ML thread:
http://forums.somethingawful.com/showthread.php?threadid=3438355

# ? Sep 20, 2011 04:09

AntiPseudonym: Apr 1, 2007; I EAT BABIES

PDP-1 posted:

What is the best way to implement a stable framerate timer/limiter system?

I'm trying to move from XNA to SlimDX and I'd like to emulate XNA's default behavior of locking the framerate to a maximum of 60FPS for Update/Draw calls, plus falling back to only calling Update if the system can't keep up. Most SlimDX examples just run the loops as fast as they can go but I want to preserve any extra CPU cycles beyond what's needed for 60FPS to do other stuff with and physics simulations can get squirreley if when the framerate gets too fast or bounces around a lot.

The dead simple thing to do is use .NET's System.Timers.Timer class to trigger something every 16ms (close enough), or I could tap into Win32.dll and use a QueuedTimer to callback into my code, but I don't know how stable these things will be given that Windows has a 4ms thread quanta which is a pretty huge percentage variation on top of a targeted 16.67ms per frame time.

How do the AAA games handle this stuff?

You should be okay with just throwing a sleep in there if your main thread finishes earlier than expected.

Although if your physics are getting weird when the frametime changes then that's another thing you should probably look at fixing, as you should be using a fixed timestep.

# ? Sep 20, 2011 04:12

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Interesting article. Question: is the temporal aliasing that's mentioned near the end (the solution without taking care of the small 'remainder' frames) really that noticeable at 60+ fps?

# ? Sep 20, 2011 04:19

AntiPseudonym: Apr 1, 2007; I EAT BABIES

Orzo posted:

Interesting article. Question: is the temporal aliasing that's mentioned near the end (the solution without taking care of the small 'remainder' frames) really that noticeable at 60+ fps?

It can be, because as your eye follows the object it won't line up with where you expect it to be for a single frame and it can feel quite jarring.

# ? Sep 20, 2011 05:05

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

code:

currentTime = getTime()
timeSinceLastUpdateStarted = currentTime - timeLastUpdateStarted
framesToUpdate = floor(timeSinceLastUpdateStarted * worldUpdateRate)
if(framesToUpdate > updateLimit)
{
    runningSlow = true
    framesToUpdate = updateLimit
}
else
{
    runningSlow = false
    timeLastUpdateStarted += framesToUpdate / worldUpdateRate    // Ensures that fractions of a frame are handled correctly
}


for(i=0;i<framesToUpdate;i++)
    stepWorld()

if(runningSlow)
    timeLastUpdateStarted = getTime()
draw()

End result of this:
- If the world is updating faster than the renderer, then you can draw intermediate states with your spare time
- If the renderer is going too slow, then it tries pushing more updates, potentially causing a loss of framerate but not game speed
- If everything is too slow, it slows the entire process down

The pro answer: Put your draw calls in a separate thread so you can use swap intervals without blocking your game thread.

OneEightHundred fucked around with this message at 16:43 on Sep 20, 2011

# ? Sep 20, 2011 06:30

Rupert Buttermilk: Apr 15, 2007; 🚣RowboatMan: ❄️Freezing time🕰️ is an old P.I. 🥧trick...

unSavory posted:

Here's an update on the music-based FPS I'm working on. Getting all the audio sorted out, along with a few other nifty things.

http://www.youtube.com/watch?v=bCLRUS-vOn4

Hey, I know I'm a bit late (or am I?) but I'd love to be a part of this.

Also, UDK now supports the mac!

:toot:

# ? Sep 20, 2011 16:08

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Thanks for the comments on timing - good stuff. What I am getting out of it is (1) run the Update loop as many times as needed with a fixed timestep, (2) call Draw when needed using an interpolated time, and (3) just sleep the game loop thread for a bit if there is time left over.

Just to elaborate a bit on why I'm sperging out over threading:

This game will have modifiable/destructible geometry. When the player is just cruising around the game loop is pretty lightweight but when they take an action that could modify the world in some way a computationally intensive bit of world remeshing needs to happen that could take 0-100ms to complete. Other operations like pathfinding or general world simulation updates also get complex when the geometry can change at any time and may be best handled by passing chunks of work off to other threads. The upshot of all this is that I'm looking at a threadpool/task model for the long operations and I want to keep the main game loop thread as 'sleepy' as possible instead of spinning it so hard that it takes up 100% of one CPU core.

I also have to somehow ensure that if the threadpool has a lot going on it doesn't choke out the main game thread and cause stuttering (this happened in my early attempts that just used .NET's TPL libraries directly - all CPU cores lit up to 100% which was great except that the game loop became totally unpredictable). No idea how that's gonna work yet. :v:

# ? Sep 20, 2011 16:14

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Another question about the update/draw timing thing:

There are some designs/architectures where drawing between two interpolated states can be difficult. What would the best solution be in this case? Separate threads?

# ? Sep 20, 2011 16:51

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

PDP-1 posted:

Thanks for the comments on timing - good stuff. What I am getting out of it is (1) run the Update loop as many times as needed with a fixed timestep, (2) call Draw when needed using an interpolated time, and (3) just sleep the game loop thread for a bit if there is time left over.

Just to elaborate a bit on why I'm sperging out over threading:

This game will have modifiable/destructible geometry. When the player is just cruising around the game loop is pretty lightweight but when they take an action that could modify the world in some way a computationally intensive bit of world remeshing needs to happen that could take 0-100ms to complete. Other operations like pathfinding or general world simulation updates also get complex when the geometry can change at any time and may be best handled by passing chunks of work off to other threads. The upshot of all this is that I'm looking at a threadpool/task model for the long operations and I want to keep the main game loop thread as 'sleepy' as possible instead of spinning it so hard that it takes up 100% of one CPU core.

I also have to somehow ensure that if the threadpool has a lot going on it doesn't choke out the main game thread and cause stuttering (this happened in my early attempts that just used .NET's TPL libraries directly - all CPU cores lit up to 100% which was great except that the game loop became totally unpredictable). No idea how that's gonna work yet.

Rendering APIs really want you to issue everything from one thread, so you don't want to pool draw calls.

If you have game operations thread pooled, then you can afford to keep rendering synchronous (in the sense that you don't do game updates and high-level rendering at the same time). That is, basically what I showed before: Run as many world state updates as it takes to get the world where it should be (which may be zero!) with a hard cap on number of frames updated to prevent it from backlogging excessively, and once that's done, draw based on the interpolated world state.

Orzo posted:

There are some designs/architectures where drawing between two interpolated states can be difficult. What would the best solution be in this case? Separate threads?

Just draw the most recent state, usually.

Realistically, you should plan on using a design with interpolated states for the simple reason that it is massively cheaper to compute an interpolated state (since you can ignore physics and interactions) than a new world state.

OneEightHundred fucked around with this message at 17:07 on Sep 20, 2011

# ? Sep 20, 2011 16:53

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

OneEightHundred posted:

Rendering APIs really want you to issue everything from one thread, so you don't want to pool draw calls.

Yep, all draw calls are issued by the main game thread which also handles all the other DirectX stuff. If some expensive operation needs to happen it gets pawned off to a pool thread that rebuilds any meshes and constructs new index/vertex buffers, then passes references to those new objects back to the main thread when the work is done. The main thread makes the new buffers active and releases any old resources between draw calls.

# ? Sep 20, 2011 17:34

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

OneEightHundred posted:

Realistically, you should plan on using a design with interpolated states for the simple reason that it is massively cheaper to compute an interpolated state (since you can ignore physics and interactions) than a new world state.

Except it introduces all sorts of new complexity that wasn't there before. What if you have mutable state? What do you do with objects that exist in one frame and are destroyed in the next? Individually these things might not be that hard to deal with, but it does involve introducing a whole new set of rules about how to draw in-between frames that may not even be necessary.

# ? Sep 20, 2011 18:30

unSavory: Sep 26, 2004; fellow

Rupert Buttermilk posted:

Hey, I know I'm a bit late (or am I?) but I'd love to be a part of this.

Also, UDK now supports the mac!

Were still wayyyyyy way off from even an alpha version of this, so you're not late at all. If you're serious send me an email at contactdramaticat @ gmail.com.

I don't know what you have in mind, but I'm sure there's some way you can help.

# ? Sep 20, 2011 19:08

The Cheshire Cat: Jun 10, 2008; Fun Shoe

Okay, I have a technical question regarding C compiling that's been driving me nuts.

Essentially, what I'm trying to do is compile the NetHack source (It's actually SLASH'EM, with the Lethe patch) with the GTK+ windowing interface for Windows. Now, the thing is that I've actually compiled this before, with no trouble.

What's been driving me nuts is that I've changed literally NOTHING, and now it refuses to compile for me. It craps out at the stage when it tries to link the stuff related to the GTK interface - I thought maybe the issue was that there was a change in my version of GTK that made it incompatible with SLASH'EM (since SLASH'EM is kind of old), but I tried downloading other versions and compiling with those, and kept running into the same problem. Here is the step that craps out:

(note that this isn't the entire compile from the start - it's able to compile several other source files before this point just fine)

code:

C:\Users\The Cheshire Cat\Projects\Slethe\src>mingw32-make install
copy /y          ..\win\gtk\cc-gtk.c .
        1 file(s) copied.
gcc -occ-gtk.exe cc-gtk.c
cc-gtk.c: In function 'pkg_config':
cc-gtk.c:220: warning: passing argument 3 of 'spawnvpe' from incompatible pointe
r type
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:130: note: e
xpected 'const char * const*' but argument is of type 'char **'
cc-gtk.c:220: warning: passing argument 4 of 'spawnvpe' from incompatible pointe
r type
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:130: note: e
xpected 'const char * const*' but argument is of type 'char **'
cc-gtk.c: In function 'main':
cc-gtk.c:343: warning: passing argument 3 of 'spawnvp' from incompatible pointer
 type
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/process.h:129: note: e
xpected 'const char * const*' but argument is of type 'char **'
cc-gtk -l gcc  -mwindows  -oslashem.exe slashem.lnk

code:
gcc -mwindows -oslashem.exe slashem.lnk -LC:/win-gtk/lib -lgtk-win32-2.0 -lgdk-w in32-2.0 -latk-1.0 -lgio-2.0 -lpangowin32-1.0 -lgdi32 -lpangocairo-1.0 -lgdk_pix buf-2.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl -lpng14

code:

gtk.o:gtk.c:(.text+0x5bf): undefined reference to `gtk_timeout_add'
gtk.o:gtk.c:(.text+0x5cd): undefined reference to `gtk_main_iteration'
gtk.o:gtk.c:(.text+0x1145): undefined reference to `gtk_main_quit'
gtk.o:gtk.c:(.text+0x1161): undefined reference to `gtk_main_quit'
gtk.o:gtk.c:(.text+0x1173): undefined reference to `gtk_main_quit'
gtk.o:gtk.c:(.text+0x1196): undefined reference to `gtk_item_factory_get_widget'

gtk.o:gtk.c:(.text+0x11a9): undefined reference to `gtk_widget_set_sensitive'
gtk.o:gtk.c:(.text+0x1225): undefined reference to `gtk_item_factory_create_item
s'

*clipped - imagine the above errors times about a million for all the references to gtk functions in the source*

(I realize that this all kind of looks like the matrix so I separated out and bolded the line where it actually hits all those errors).

For reference, I'm trying to compile on Win7 64-bit, using mingw and GTK 2.22 64bit. As I said, I've compiled it on this machine before, so I can't figure out why it's just decided to stop working when I haven't changed anything.

# ? Sep 20, 2011 19:59

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 10:12

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

The Cheshire Cat posted:

Okay, I have a technical question regarding C compiling that's been driving me nuts.

The first block is just warnings (that don't appear to be related), so can probably be ignored.

The other part is a link error; my guess is you should be linking against the 32-bit GTK since you don't have a 64-bit SLASH.

(Specifically, I'd guess that those functions being reported as 'undefined' are defined as taking 64-bit parameters, and SLASH is trying to pass 32-bit parameters, so the full function definitions are not matching.)

Edit: it's maybe even in your bolded bit: -lgtk-win32-2.0 - but I don't know if 64-bit gtk still uses filenames with 32 in them.

roomforthetuna fucked around with this message at 20:20 on Sep 20, 2011

# ? Sep 20, 2011 20:18

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

«‹›623 »