Game Development Megathread

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

«‹›622 »

Vino: Aug 11, 2010

I don't see WebGL being used for anything more than Flash is used for right now due to Javascript. I wish that instead of WebGL they would just provide an easier way to run native code from a browser.

# ? Nov 29, 2011 08:19

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 04:41

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Vino posted:

I don't see WebGL being used for anything more than Flash is used for right now due to Javascript. I wish that instead of WebGL they would just provide an easier way to run native code from a browser.

Chrome is, they're doing that whole native client thing that seems interesting and also has the advantage of not giving you direct access to the video card basically.

# ? Nov 29, 2011 10:23

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

I'm not clear why anyone would use WebGL over Molehill. Flash has effectively universal penetration, and if you go that route, hey, you can eventually just use Unity or UDK instead of wasting time on your own engine.

(and Unity3D/UDK also solves the "my app runs on mobile... at 1fps" problem, vs writing your own native engine there)

Shalinor fucked around with this message at 17:03 on Nov 29, 2011

# ? Nov 29, 2011 17:01

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

I am creating a side-scrolling 2D platformer game. Should I use Box2D? I don't want a 'physics-y' type of game where it's obviously using a physics engine, I just want to save myself some work when implementing 'classic 2D (think: megaman, metroid, etc) physics.'

Also, this is in C#, so I'm looking at Farseer (a C# implementation of Box2D). Are there any other ports I should consider?

# ? Nov 29, 2011 23:29

DeathBySpoon: Dec 17, 2007; I got myself a paper clip!

Box2D would be overkill for that- if it could work on the Super Nintendo, it's much less work to just code the movement yourself.

# ? Nov 29, 2011 23:39

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

DeathBySpoon posted:

Box2D would be overkill for that- if it could work on the Super Nintendo, it's much less work to just code the movement yourself.

Is this something you have experience with? I feel like there's actually quite a bit of work implementing proper collision detection, even in a fairly simple SNES-type game.

# ? Nov 29, 2011 23:52

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!

Orzo posted:

Is this something you have experience with? I feel like there's actually quite a bit of work implementing proper collision detection, even in a fairly simple SNES-type game.

The work involved in integrating Box2D is probably more than the work involved in implementing your own simple collision detection, from my experience. If you want your collision detection to cause things to bounce off things that aren't square, however, then Box2D is probably easier. It's not a huge difference.

I'd recommend not using Box2D unless you plan on doing something using actual physics in future - the learning curve is obviously going to be bigger than the alternative learning curve for not needing to learn anything.

# ? Nov 30, 2011 00:06

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

Orzo posted:

I feel like there's actually quite a bit of work implementing proper collision detection, even in a fairly simple SNES-type game.

You haven't watched a TAS lately.

The way console-era collision tended to work was that there were predefined collision shapes that occupied a block of space, and responses were generally clipped to a predefined way of interacting with those. There was typically a LOT of "you got stuck in a collidable this frame, so we'll kick you out of it next frame."

# ? Nov 30, 2011 00:09

mewse: May 2, 2006

there's an article here with details on a real-world NES collision detection algo

# ? Nov 30, 2011 00:13

CaptainPoopsock: May 2, 2005; My dear cherry blossoms.. bloom in full splendor!

I'm looking into getting into game development as a hobby during the winter months. I'd like to make something 3D, perhaps RPGish in nature just to screw around with. Hardly having delusions of grandeur, I realize this is going to be just something to entertain myself with and if it ends up being something more then great!

I'm eyeing the UDK engine. I see there's a UDK thread but it's pretty empty lately. Anyone here have extensive experience with it who can recommend it over alternatives, or does anyone want to show off anything they've made in UDK to show what it's capable of?

# ? Nov 30, 2011 00:55

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

Orzo posted:

Is this something you have experience with? I feel like there's actually quite a bit of work implementing proper collision detection, even in a fairly simple SNES-type game.

It's not too terrible if you restrict the number of collision object types to, say rectangle, circle, and ray types. More collision types means more TypeA vs. TypeB collision handlers to write so keep it basic.

Here's some nice writeups that I used as a base when setting up my own system:
Physics Engines for Dummies
Speculative Contacts
Collision Detection for Dummies

# ? Nov 30, 2011 01:54

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!

CaptainPoopsock posted:

I'm eyeing the UDK engine. I see there's a UDK thread but it's pretty empty lately. Anyone here have extensive experience with it who can recommend it over alternatives, or does anyone want to show off anything they've made in UDK to show what it's capable of?

The opposite of what you're asking for, but I've used UDK a little in a workplace, and I've just started poking at Unity3D a few days ago for my own thing, and I'm inclined to really recommend Unity, especially if you're mostly just screwing around. It's ridiculously easy to get started compared to anything I've ever used before (other than 2D "make a game out of icons" sort of things). I'd even venture to say it seems easier to me than making a Flash game.

# ? Nov 30, 2011 02:12

AntiPseudonym: Apr 1, 2007; I EAT BABIES

mewse posted:

there's an article here with details on a real-world NES collision detection algo

That's an awesome article, thanks for that!

I've just started writing a collision-detection system for my 2D game today as well, although I still can't work out how I should handle non-rectangular collisions with the environment. I want the levels to feel more organic than standard platformers (Like Donkey Kong Country instead of Mario, basically), so I'm going to have to handle slopes somehow.

I'm thinking of going for multiple collision tile types that specify different slope gradients, but I was wondering if anyone had any articles or insight on how to go about it. I could technically just do everything with vectors (Placing collision lines on the ground and the like) but I'm worried that'll make level design less consistent and more painful.

edit: Also didn't get to the end of the article before I posted that, whoops. Still, if anyone has any additional advice, it'd be appreciated.

AntiPseudonym fucked around with this message at 03:05 on Nov 30, 2011

# ? Nov 30, 2011 02:48

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

Tile types specifying slopes seems like a pretty solid idea. I've also seen systems that use two tilesets- visible tiles and corresponding collision masks that represent a simplified version of the geometry that can be used for per-pixel collision or simply as a source of heightmap data. I think the collision mask approach becomes a better option as you start dealing with more complex collision geometry in a single tile- your costs remain essentially constant given a particular tile size.

# ? Nov 30, 2011 03:05

AntiPseudonym: Apr 1, 2007; I EAT BABIES

Internet Janitor posted:

Tile types specifying slopes seems like a pretty solid idea. I've also seen systems that use two tilesets- visible tiles and corresponding collision masks that represent a simplified version of the geometry that can be used for per-pixel collision or simply as a source of heightmap data. I think the collision mask approach becomes a better option as you start dealing with more complex collision geometry in a single tile- your costs remain essentially constant given a particular tile size.

Yeah, was definitely going to go the collision mask route; apart from anything it makes it easier to have secret passages and the like. The plan was to have each tile have a default collision type so the collision gets updated when the tile changes, and the user can manually go into the collision map afterwards and alter whatever they like.

# ? Nov 30, 2011 04:53

Visible Stink: Mar 31, 2010; Got a light, handsome?

PDP-1 posted:

Here's some nice writeups that I used as a base when setting up my own system:
Physics Engines for Dummies
Speculative Contacts
Collision Detection for Dummies

These look really interesting, I'll be perusing them more closely when I get home from work. Thanks!

# ? Nov 30, 2011 05:12

Suran37: Feb 28, 2009

I have a beginner level of experience when it comes to programming. I have only taken two programming classes so far. I am really interested in game development as a hobby (as opposed to a job when I graduate.) Would Stencyl be the recommended route for messing around at this point? Sorry, I'm sure this gets asked a million times in this thread.

EDIT: I'm interested in 2D at this point in time, and maybe doing an RPG.

Suran37 fucked around with this message at 09:49 on Nov 30, 2011

# ? Nov 30, 2011 09:41

Svampson: Jul 29, 2006; Same.

Suran37 posted:

I have a beginner level of experience when it comes to programming. I have only taken two programming classes so far. I am really interested in game development as a hobby (as opposed to a job when I graduate.) Would Stencyl be the recommended route for messing around at this point? Sorry, I'm sure this gets asked a million times in this thread.

I would check out Flixel for starters, this is an excellent starting point. If you can't wrap your head around it you might have better luck with Stencyl (tough personally I found working with Stencyl very annoying and slow)

Svampson fucked around with this message at 10:03 on Nov 30, 2011

# ? Nov 30, 2011 09:51

DeathBySpoon: Dec 17, 2007; I got myself a paper clip!

Orzo posted:

Is this something you have experience with? I feel like there's actually quite a bit of work implementing proper collision detection, even in a fairly simple SNES-type game.

Plenty of it. Like mentioned above, proper 2D collision detection really isn't that bad. Some simple rectangle and circle checks are more than enough to get something that works for a simple Megaman / Metroid style platformer, especially with tile based environments.

AntiPseudonym posted:

I've just started writing a collision-detection system for my 2D game today as well, although I still can't work out how I should handle non-rectangular collisions with the environment. I want the levels to feel more organic than standard platformers (Like Donkey Kong Country instead of Mario, basically), so I'm going to have to handle slopes somehow.

There are lots of ways to handle this- Vector based terrain actually isn't that bad, but you can get it done with tiles more easily. Store the angle of each tile and just plop each object on the appropriate spot with a basic line formula. If you need more complex terrain shapes, you can take the Sonic the Hedgehog approach and store an angle value for each column of pixels- this lets you easily do curves, loops, etc. All you have to do is look the tile up in a table, check the angle of the pixel you're on, and adjust your movement for it.

# ? Nov 30, 2011 18:49

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

Speaking of old techniques coming back - is graphics hardware (on average / not cutting edge) finally to where you can emulate palette-based rendering and basically get away with it, perf-wise? What about in Flash? Anyone tried it recently?

I really miss all the tricks you could do with it, but there for the longest time, hardware didn't support it and emulating it was an obscenely costly notion.

... well, I miss that, and I also miss copper bars, but faking copper bars in this day and age would be entirely masturbatory

EDIT: VV Couldn't you avoid that by generating all texture data, per-frame if you're doing palette rotation tricks, from palette-based assets? I'm seeing a huge number of write/discard buffers if you did it in DirectX et al. Flash would be a lot more straightforward, but also assumedly very slow.

Shalinor fucked around with this message at 21:53 on Nov 30, 2011

# ? Nov 30, 2011 21:10

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

The problem with palette based rendering isn't performance, it's filtering it. You can sort of emulate filtering by using unfiltered LUTs and deriving the filter from the texture coordinates, but that starts breaking down when dealing with varying min/mag levels and is difficult to do anything beyond bilinear with.

If you don't care about good filtering then it's easy as gently caress, just use intensity as a lookup into a palette texture. It's plenty fast, hell most games these days use pretty much the exact same method for specular in a much more resource-intensive way.

Also, a lot of the stuff you'd want to use palette-based rendering for like "palette swaps" can be handled equally well with overlays. See: Pretty much every RTS.

OneEightHundred fucked around with this message at 22:29 on Nov 30, 2011

# ? Nov 30, 2011 21:47

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

I'm working through the OpenGL tutorials at http://arcsynthesis.org/gltut/ and translating them to WebGL as an educational exercise for personal growth. I'm finding myself loading my shaders by simply typing in this into my html:

code:

<script  id="vshader" type="x-shader/x-vertex">
	attribute vec4 position;
	attribute vec4 color;

	varying vec4 outColor;

	void main()
	{
		gl_Position = position;
		outColor = color;
	}
</script>

It works great, but it bothers me on some sort of spiritual level to not have the shaders in separate files. At first, I naively thought I could do something like:

code:

<script src="fragment.frag" id="fshader" type="..."></script>

But that won't work. You can't get the text of a script tag that loads from a src attribute.

I'm looking for a solution that is as simple as possible, as I'm trying not to stray far from the context of the original tutorials. So, while I could spin up jquery and make an ajax request for the file and store the response, that would require me to change a fair amount.

Is there some other solution that would be acceptable? Would I be shot for something like:

code:

# index.html
<script src="fragment.js" id="fshader" type="..."></script>

# fragment.js
var frag = {

    content: "
        #version 100
        void main()
        {
            gl_FragColor = vec4(1.0,1.0,1.0,1.0);
        }"
};

That, at least, seems more reusable and keeps the main html file smaller, but I can't escape the feeling that it is wrong somehow. Maybe it's the dark beer and late hours.

# ? Dec 3, 2011 09:01

dizzywhip: Dec 23, 2005

That's an interesting problem! I don't believe you can grab the contents of a linked script though, unfortunately. I think the two options you listed are the only ways to do it really -- I would personally just ajax the scripts.

If you decide to embed the script as a string in JavaScript, you can make it a little bit nicer by not wrapping the string in an object. So instead of doing var frag = { content: "..." } you can just do var frag = "...". You'll have to be careful to escape any double quotes inside your script though, which could be annoying, and you'll probably lose any syntax highlighting if you write your code this way.

I could be wrong and there might be some other way to do it. I'd actually check out some WebGL tutorials to see how they include their shaders.

# ? Dec 3, 2011 10:23

DeathBySpoon: Dec 17, 2007; I got myself a paper clip!

Is there a Unity3D thread or is that encompassed here? I'm finally making the move to 3D after almost ten years of 2D programming and I wouldn't mind having a place to discuss it all. I learned most of my 2D programming by recreating the playstyles of other games- Sonic, Metroid, etc. I figure I'll do the same for this, so I'm starting with Zelda style movement. I'm not going to use Unity's CharacterController because I want to learn how to write one myself. How does everyone go about their level creation for stuff like this? I'm learning Blender and it seems to work well enough. My only problem so far is that I don't know how to keep a consistent scale between game objects- in 2D you just compare the size pixel by pixel. How does one go about doing something similar in 3D?

# ? Dec 3, 2011 19:00

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!

DeathBySpoon posted:

Is there a Unity3D thread or is that encompassed here? I'm finally making the move to 3D after almost ten years of 2D programming and I wouldn't mind having a place to discuss it all. I learned most of my 2D programming by recreating the playstyles of other games- Sonic, Metroid, etc. I figure I'll do the same for this, so I'm starting with Zelda style movement. I'm not going to use Unity's CharacterController because I want to learn how to write one myself. How does everyone go about their level creation for stuff like this? I'm learning Blender and it seems to work well enough. My only problem so far is that I don't know how to keep a consistent scale between game objects- in 2D you just compare the size pixel by pixel. How does one go about doing something similar in 3D?

If you're using Unity3D then I'd think your level creation is made from components made in Blender, joined together using Unity's scene editor. Though I guess you could make the whole static level design as a single huge mesh in Blender, if your level is that unrepetitive.

As for scale - I gather the usual way is to simply use 'real' units. If you make your objects' sizes in meters, then you can compare sizes "meter by meter" much as you would "pixel by pixel" for 2D. So long as your things have real-world analogues this is actually even more convenient than measuring in pixels, in that "how high is a two-storey house in pixels?" is an unhelpfully meaningless question. You can only do your pixel scale if you have some baseline object to compare against, but when you're working in meters, sizes are mostly somewhat self-evident.

(You may not know how tall Link is, but it's convenient to assume your main character is person-sized, then everything else can be appropriate sizes for a person to interact with. Also, physics engines generally perform best around that scale, ie. if you made your units kilometers such that your characters were around 0.002 units tall then the physics is likely to lose precision.)

# ? Dec 3, 2011 19:24

Themage: Jul 21, 2010; by Nyc_Tattoo

Are there any good tutorials on how to make a tile based world in C#?

# ? Dec 4, 2011 01:53

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

You could check out the XNA Platformer tutorial. It's in C# and has a tile-based world structure.

# ? Dec 4, 2011 05:14

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

Themage posted:

Are there any good tutorials on how to make a tile based world in C#?

Also, check out this article on Herringbone Wang Tiles. (Not joking.) I've been wanting to do this but other projects take priority...

herringbone wang

# ? Dec 4, 2011 05:19

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

A question for any Unity devs out there; I'm a huge fan of FMOD, and I'm just starting to get into working with Unity. FMOD's website says that it's "the default audio solution for Unity", but from doing research, I've only found that Unity seems to be using some FMOD functionality. Is there anyone out there using both and having success? I found a plugin made by SquareTangle, but apparently that only really works with Unity 2.5, because they've since 'beefed up their FMOD support' within Unity itself.

This may just be a case of me not knowing enough about Unity yet (I'm getting closer and closer every day), but it seems like, as with most things, audio is like some sort of afterthought. I'm a sound designer/composer so I take audio very seriously, and want to do some kick-rear end things within Unity, once I get something going.

# ? Dec 5, 2011 15:58

brian: Sep 11, 2001; I obtained this title through beard tax.

I wouldn't say audio is an afterthought, it's all done through the same system of Components but that's how everything works in Unity. Mess around with all the Audio components, there's basic audio sources that you can make 3D or not, reverb zones that will apply effects to certain sounds like a spherical collider and so on. Just use it and when you find something you don't understand ask on the Unity forums or (probably the best option) in the IRC room.

I mean I don't know what it is you think it's missing so I can't comment on whether it has it or not, it's not always been the best on being remotely to up to date with the APIs it uses so it's entirely possible, but asking specific questions in #unity3d on freenode is easily going to be your best option to find out.

# ? Dec 5, 2011 17:48

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

Fair enough, I'll check there. What I meant was, from what I can tell so far (which, admittedly, isn't very), the tons and tons of things you can do in FMOD (music block sequencing and scripting, occlusion, granular loops of randomized files, etc, etc) don't seem to be there in Unity, despite FMOD being the 'default solution'.

My understanding of FMOD leads me to believe that, in general, you build your sound design within it, and, because FMOD Ex has been implemented into your project by the devs, they're able to take the events you've created and place them in-game, as well as call up different parameters you (as a sound designer) have set up on your end, after you provide them with a build (.fev) file.

It seems as if using audio in Unity is more akin to "Hey, you know how FMOD generally works? Well, here are a few of the same principles" rather than "Come on and import that .fev build you've spent so much time on, it'll work in the game world you've made in Unity!".

Maybe the latter is planned for down the road, I don't know.

# ? Dec 5, 2011 18:15

DeathBySpoon: Dec 17, 2007; I got myself a paper clip!

I do know that audio buffer access is planned for the next version or so. Maybe that'll be part of it?

# ? Dec 5, 2011 20:46

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

Just an update (though most of you might already know this): If you've got the most recent version of Unity, and FMOD Designer 2010, there's no point in making an FMOD audio build as Unity cannot, in fact, import it, yet. There used to be a plugin that fixed this, and apparently in an upcoming version of Unity they've discussed the ability to import .fev files along with the asset bank.

Until then, I guess they're incompatible, despite the fact that FMOD powers the Unity audio engine.

# ? Dec 7, 2011 19:44

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

I have to ask some general questions about how you generally multithread up a game engine without generating all kinds of horrors because I think I've finally opened that Pandora's Box. I was dealing with the same scenario causing crashing in all variety of parts of my (crappy) game engine tonight. To me that smells of a race condition. Finally, I saw in a progression of test messages in at least one of the signatures that I was in the middle of the Irrlicht scene manager draw call when I freed one of my entities, which had some drawing information attached to it.

I am trying to follow the subsystem model, and I have most of the subsystems in their own threads. I have already done some thread safety within each subsystem so that calls to affect that subsystem don't cause it to blow itself up. However, the interplay of things is where things start to get a little crazy.

Generally I'm seeing the problem with an attack bounding box getting deleted. Previously, an entity with a component describing animation state has told the engine to create another entity to represent the bounding box. The bounding box is an entity with a contact trigger that applies damage to entities that are not the originator or the same faction. At the first frame that makes sense to do the attack damage, the animation state requests a new entity from the engine and has it made into the bounding box entity. The animation subsystem makes sure Irrlicht knows the mesh wants to play frames x-y. At the end of frame Y, that is the frame where it no longer makes sense for the object to be able to apply damage, so the animation state has the bounding box entity removed.

The problem goes something like this:

1. Irrlicht draws a frame.
2. The animation subsystem callback from Irrlicht is told that the part of the attack animation for some entity has finished; the part that involves keeping the bounding box active. Recall the animation subsystem is in its own thread and it triggered the callback to the animation state. This thread is separate from the main engine thread.
3. The animation component--which has the reference to the bounding box--tells the engine to start cleaning up the bounding box entity.
4. Meanwhile, the main engine thread that takes care of Irrlicht and friends has moved back to the top of the loop and is starting to tell the scene manager to draw.
5. The bounding box entity is getting cleaned up. All of its components are getting freed, including the Bullet physics stuff for the ghost object. I am using a wrapper that's Irrlicht-friendly, and that wrapper is currently displaying debug stuff through Irrlicht. That's important.
6. I believe meanwhile that in the scene manager, it's trying to draw the bounding box debug stuff for the ghost object that was getting freed, and it shits itself.

The best I can think of doing is having all the subsystem threads turn on a bool when they finished their loop, and have the main engine thread wait for this. I can't remember what it's called in Boost but I recall it has a really efficient way of doing this. I think that would take care of this particular problem. However, I expect other new and exciting problems to happen if I start trying to muck with the entities and components externally in the Python wrappers I've exposed. I think I actually first saw the problem there, even if I'm building without involving it right now. In that case, I got blown away at the same part of the engine loop when I was constructing entities and filling it with components related to drawing stuff.

Looking at the bigger picture, I can perhaps see more sinister problems afoot that make me think trying to be a big boy with multiple threads was completely stupid. I kind of did this more to better appreciate the real problems one can run into--not so much to actually make a game. But boy do I appreciate the problem now. However, even if I had made the whole mess single-threaded, I expect I'd still get into poo poo with an external scripting interpreter trying to manipulate things. So how do I generally protect this? I can't imagine that in real engines they're putting tons of locks around everything.

Edit: I suppose I just need to hear myself think through this a bit. I gave it about 10 minutes of pondering and pretty much realized I need to have a good separation of game logic from the critical section of the engine. I am thinking I may also need to have locks on the entities themselves. I expect a deadlock on that someday.

Still, I think even if I had something really simple, I could knock it on its rear end if I tried to attach some kind of scripting language to it. So I wonder if there are any good articles on trying to prevent scripting from trampling on the engine. Imagine giving a command in a script and it happens to come in at the engine's critical section. I got myself some reading on multithreaded game engines in general, but I'll take anything on that specifically since I think I may have started with something very naive.

Rocko Bonaparte fucked around with this message at 10:53 on Dec 11, 2011

# ? Dec 11, 2011 10:17

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

You should probably have a mutex on the active object list to prevent threads from modifying it (i.e. deleting the bbox) and using it (i.e. trying to draw it) at the same time.

For the most part though, the best thing you can do to keep your sanity is focus on decomposing tasks with low resource contention. Having stuff like multiple render threads that are all focused on explicit tasks like scene setup or drawing and go idle when there isn't any work to do isn't really ideal: They're operations that depend on another and get run in sequence, so threading them just adds complexity. Meanwhile, stuff like mesh transformations and animation setup are extremely easy to isolate, you can set up result space and then just run them all in parallel, getting near-100% utilization with a lot less work.

Basically, think how it would work if you tried doing everything with one thread, and see if individual parts of it could either be run as parallel operations (i.e. a task with a large number of objects with almost no interdependency), or sent to a work thread because other things you also need to do don't interfere with it, i.e. you can spin sound work off to a threadable job if you can do rendering work at the same time. poo poo with high resource contention usually doesn't thread well anyway.

OneEightHundred fucked around with this message at 12:20 on Dec 11, 2011

# ? Dec 11, 2011 12:15

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

OneEightHundred posted:

Basically, think how it would work if you tried doing everything with one thread, and see if individual parts of it could either be run as parallel operations (i.e. a task with a large number of objects with almost no interdependency), or sent to a work thread because other things you also need to do don't interfere with it, i.e. you can spin sound work off to a threadable job if you can do rendering work at the same time. poo poo with high resource contention usually doesn't thread well anyway.

After a night's sleep I've had a chance to settle down here. It looks like a big part of the engine--Irrlicht for rendering and Bullet for physics--can't run in parallel right now. I'm using a wrapper that exposes the Irrlicht object types to Bullet. I guess if there was some isolation then this could be done, but right now Bullet could move an Irrlicht object midway through drawing it and gently caress everything up royally. I don't think I want to go there (yet).

I'm mostly preoccupied with how to get a scripting console to be able to do rapid operations--ie not sit on a lock for a resource that would keep me from doing more than one script command per frame. Reading some stuff, do people approach this kind of like a GUI framework, where events are piled up into a queue?

# ? Dec 11, 2011 18:27

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

Rocko Bonaparte posted:

After a night's sleep I've had a chance to settle down here. It looks like a big part of the engine--Irrlicht for rendering and Bullet for physics--can't run in parallel right now. I'm using a wrapper that exposes the Irrlicht object types to Bullet. I guess if there was some isolation then this could be done, but right now Bullet could move an Irrlicht object midway through drawing it and gently caress everything up royally. I don't think I want to go there (yet).

One good way to deal with this (though it might not be possible depending on what Bullet/Irrlicht expose) is to double-buffer the data and basically pipeline it -- Bullet runs on the N+1th frame, while Irrlicht renders the Nth frame. You're adding latency, but improving frame throughput.

# ? Dec 11, 2011 22:39

Wideshanks: May 17, 2007; B.M.O.F.
Big Man On Forums

Is there a pre-existing framework (like codeigniter, or something built on codeigniter) for:

players logging in (with a username / password)
starting a session or game with another player

and having some sort of shared variables together that makes it possible to make them have a game together?

I have a very simple game I'd like to test but I sure as hell wouldn't want to make all the scaffolding to allow one player to do something with another player

# ? Dec 12, 2011 00:32

DancingMachine: Aug 12, 2004; He's a dancing machine!

Rocko Bonaparte posted:

Multithreading issues

Is this your first time doing asynchronous programming? You're kind of jumping in to the deep end of the pool it sounds like. Retrofitting pre-existing single-threaded code to take advantage of multiple threads is the hardest kind of async programming. It is very fraught with peril and to do it successfully you need to really deeply understand the pre-existing code inside and out, plus be fairly confident in general async concepts.

Hubis and OneEightHundred give good advice. But at a higher level, if this is your first time dabbling in threads, I would try writing something from the ground up that is parallelized. That's much easier to do, but still difficult enough that you will learn a lot.

# ? Dec 12, 2011 02:52

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 04:41

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

DancingMachine posted:

Is this your first time doing asynchronous programming? You're kind of jumping in to the deep end of the pool it sounds like. Retrofitting pre-existing single-threaded code to take advantage of multiple threads is the hardest kind of async programming. It is very fraught with peril and to do it successfully you need to really deeply understand the pre-existing code inside and out, plus be fairly confident in general async concepts.

Hubis and OneEightHundred give good advice. But at a higher level, if this is your first time dabbling in threads, I would try writing something from the ground up that is parallelized. That's much easier to do, but still difficult enough that you will learn a lot.

I'd say this is the first time I've messed around with real concurrency. Previously I just had to deal with situations where some small fries stuff had to run simultaneously, without much information sharing. I'm confident I can generally write thread-safe code. I will admit though at an architectural level, I am not experienced enough to be aware where I should be drawing the lines if I were trying to do it right.

I'm more keen on keeping that Irrlicht/Bullet critical path together than to try to get them running in parallel right now. To be honest, it's just because I'm currently not that interested in trying to do it. I want to see instead that I can start interacting with the engine with some scripting so I can try to get something vaguely resembling a game to run along. Later on, if it all really pisses me off, I can start to split up that critical path. I see a good bit of literature on that, which is reassuring that I'll be able to find good advice. The replies here have also been interesting.

What I'm really hitting right now is that a component can trample on the critical path quite easily. The entity addition/removal stuff is kind of secondary to that because it's the components the entities contain that causes the problems. After sitting on it today, it occurred to me this is the kind of reason why GUI draw threads are single-threaded. So what I guess I need is basically an event queue. The queue can be processed at any time outside of the critical section. I've seen some mutterings of action/event/command queues in some writeups, so I assume this is a pretty standard approach.

I wouldn't want to instead have a lock on the critical path because this could mean my ability to run scripted commands could be limited to my frame rate. Say, a scripted command comes in that causes some component to try to do something, but it finds its waiting on the critical path to finish, so it waits on it. In the worst case, the command completes and the next one starts just in time to hit the critical path again.

Perhaps the most illuminating thing so far I've had in doing all this is has to be the amount of architecture and engineering I do see in game engine design. Walking in, I got the impression a lot of stuff was slopped together, or that at best there were a ton of ugly compromises. But I do see a lot of structure now.

# ? Dec 12, 2011 06:19

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

«‹›622 »