Game Development Megathread

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

«‹›622 »

GuyGizmo: Feb 26, 2003; stupid babies need the most attention

Broken Knees Club posted:

Eh what. There is latency I suppose, but if it's noticeable then you're doing something horribly wrong.

The MediaPlayer class is mainly meant for playing individual single songs. What I would need to do is have lots of smaller sections of songs, divided into individual sound files, playing in perfect time with each other, and also overlapping each other or cross-fading into each other. You can't really use MediaPlayer for that, or the SoundEffect and SoundEffectInstance classes either.

There's also no support for starting sounds at positions other than the start of the wav, changing the playback position of a sound, change a sound's volume dynamically, change the pitch of a sound dynamically, and all sorts of other things that are extremely useful if not required for what I want. I poured over the documentation and developer forums for XNA, and the resounding consensus (including from everyone of those forums) is that XNA has really inadequate low-level control over audio. A lot of people were asking for that for being able to do real-time sound synthesis or dynamic audio processing, but the functionality simply isn't there. There might, *might* be a tricky way to do what I want, but I got the feeling pretty fast it'd be a big up-hill battle. It's pretty clear that Microsoft designed that part of XNA to be very simple and functional for 90% of the game developers out there (whom would only need to play background music and incidental sound effects), but didn't take things any farther than that.

Also, the main reason I was interested in using XNA was the potential for Xbox 360 development. But more recently I've found myself extremely disappointed with the 360's indie game section of the store, as well as XNA's ability to do low level audio stuff. So if I'm not developing for the 360 or PC with XNA, that leaves developing for just the PC, and at that point I may as well choose a library that can for sure do what I need to, and if it's cross-platform too that's even better. OpenTK/Mono is starting to look more and more appealing.

Avenging Dentist posted:

Python is compiled to bytecode. Haven't you ever wondered what .pyc files are?

Yeah, I kind of figured that it was operating at the same level as C# or Java in that respect. So I'm assuming that it would get similar performance to both (assuming of course you write efficient code), unless anyone knows otherwise.

# ? Oct 25, 2009 21:11

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 20:00

GROVER CURES HOUSE: Aug 26, 2007; Go on...

GuyGizmo posted:

The MediaPlayer class is mainly meant for playing individual single songs. What I would need to do is have lots of smaller sections of songs, divided into individual sound files, playing in perfect time with each other, and also overlapping each other or cross-fading into each other. You can't really use MediaPlayer for that, or the SoundEffect and SoundEffectInstance classes either.

There's also no support for starting sounds at positions other than the start of the wav, changing the playback position of a sound, change a sound's volume dynamically, change the pitch of a sound dynamically, and all sorts of other things that are extremely useful if not required for what I want. I poured over the documentation and developer forums for XNA, and the resounding consensus (including from everyone of those forums) is that XNA has really inadequate low-level control over audio. A lot of people were asking for that for being able to do real-time sound synthesis or dynamic audio processing, but the functionality simply isn't there. There might, *might* be a tricky way to do what I want, but I got the feeling pretty fast it'd be a big up-hill battle. It's pretty clear that Microsoft designed that part of XNA to be very simple and functional for 90% of the game developers out there (whom would only need to play background music and incidental sound effects), but didn't take things any farther than that.

Also, the main reason I was interested in using XNA was the potential for Xbox 360 development. But more recently I've found myself extremely disappointed with the 360's indie game section of the store, as well as XNA's ability to do low level audio stuff. So if I'm not developing for the 360 or PC with XNA, that leaves developing for just the PC, and at that point I may as well choose a library that can for sure do what I need to, and if it's cross-platform too that's even better. OpenTK/Mono is starting to look more and more appealing.

Ah, I get you now. See if the iirKlang does the job though, I used it instead of XNA back in 2.0 when audio support was horrifically buggy on non-360 platforms. Also get used to using third-party libraries to augment or replace its crippled functionality :v:

GuyGizmo posted:

Yeah, I kind of figured that it was operating at the same level as C# or Java in that respect. So I'm assuming that it would get similar performance to both (assuming of course you write efficient code), unless anyone knows otherwise.

This is third-hand, shaky knowledge, but Python can inline C code and has a smaller interop overhead so you can beat some obscenely fast code out of it with sufficient dedication. But on average? :iiam:

# ? Oct 25, 2009 22:06

BATH TUB: Jun 27, 2003

I'm writing a DX9 game engine in C++ as a exercise in frustration and wasting time, and before I write too much more code, I want to separate my subsystems into different threads -- right now, just a rendering thread and a game logic thread.

Now, pushing the render state updates across threads is a solved problem, but there are a few questions I still haven't been able to find an answer to:

1) What kind of overhead am I looking at from the D3DDevice as multithreaded? Is it going to lock all the time?

2) What do I have to concern myself about in terms of memory allocation? Can I just new and delete things as before, or do I need a thread-safe allocation scheme to avoid race conditions?

# ? Oct 25, 2009 22:37

Intel Penguin: Sep 14, 2007; hooray

Avenging Dentist posted:

Python is compiled to bytecode. Haven't you ever wondered what .pyc files are?

Not an executable?

# ? Oct 26, 2009 01:23

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

Intel Penguin posted:

Not an executable?

Which puts it on the same playing field as C# being compiled to MSIL? :confused:

# ? Oct 26, 2009 01:29

captain_g: Aug 24, 2007

timecircuits posted:

I'm writing a DX9 game engine in C++ as a exercise in frustration and wasting time, and before I write too much more code, I want to separate my subsystems into different threads -- right now, just a rendering thread and a game logic thread.

Now, pushing the render state updates across threads is a solved problem, but there are a few questions I still haven't been able to find an answer to:

1) What kind of overhead am I looking at from the D3DDevice as multithreaded? Is it going to lock all the time?

2) What do I have to concern myself about in terms of memory allocation? Can I just new and delete things as before, or do I need a thread-safe allocation scheme to avoid race conditions?

One rule of thumb is that you allocate and de-allocate memory from the same context. This makes things a bit complex. Things that need video memory need to be created from where your D3D rendering context lies. In terms of new and delete I am not sure how Windows serializes memory function calls, but I am sure it does some serialization. There's also the EXE / DLL problem where you might end up calling new and delete from different heaps. I am not sure if this still issue, but it used to be.

What library are you using for concurrency anyway? Boost? You are about to enter never ending world of poo poo and I personally wouldn't count the exercise worth the time invested. You aren't going to learn that much useful in terms of concurrency, you are just starting an endless struggle against inane implementation details of the platform and the libraries. Furthermore there are countless of frustrating concurrency problems that might take stupendous amount of time to get solved. Mostly, because you won't simply have all the required information.

captain_g fucked around with this message at 14:30 on Oct 26, 2009

# ? Oct 26, 2009 14:23

biznatchio: Mar 31, 2001; Buglord

Dijkstracula posted:

Which puts it on the same playing field as C# being compiled to MSIL?

Does CPython JIT?

# ? Oct 26, 2009 14:37

Kennedy: Aug 1, 2006; hard to breathe?

EDIT: Bahah, as always, hits me in the face as soon as I post

code:

 Vector3 camLookForward = new Vector3(0f, 0f, -0.5f);
            camLookForward = Vector3.Transform(camLookForward, Matrix.CreateFromQuaternion(playerRotation));
            camLookForward += playerPosition;

Here's a pretty sill Vector math question:

I'm programming a camera for my XNA game. At the moment, it's a 3rd person view of the player's vehicle, pointed at the model's center.

However, I'd like it to look along the forward vector of the player, so more of the screen is visible. What's the math I need so that the camera is always looking at a point 2f along the player's forward vector?

And here's my current code:

code:

            // slerps the camera to follow just behind the player
            cameraRotation = Quaternion.Lerp(cameraRotation, playerRotation, 0.1f);

            // moves the camera in relation to the player position
            Vector3 campos = new Vector3(0.0f, 0.15f, 0.5f);
            campos = Vector3.Transform(campos, Matrix.CreateFromQuaternion(cameraRotation));
            campos += playerPosition;
            
            // make the camera look ahead of the player
            // code goes here
   

            // positions the camera's up vector
            Vector3 camup = new Vector3(0, 1, 0);
            camup = Vector3.Transform(camup, Matrix.CreateFromQuaternion(cameraRotation));

            // creates the view matrix from the player's position for the camera, and the projection matrix for the camera
            viewMatrix = Matrix.CreateLookAt(campos, playerPosition, camup);
            projectionMatrix = Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, device.Viewport.AspectRatio, 0.2f, 500.0f);

And how it looks currently (please ignore the Ferrari in Tron):

Kennedy fucked around with this message at 15:18 on Oct 26, 2009

# ? Oct 26, 2009 15:09

BATH TUB: Jun 27, 2003

captain_g posted:

One rule of thumb is that you allocate and de-allocate memory from the same context. This makes things a bit complex. Things that need video memory need to be created from where your D3D rendering context lies. In terms of new and delete I am not sure how Windows serializes memory function calls, but I am sure it does some serialization. There's also the EXE / DLL problem where you might end up calling new and delete from different heaps. I am not sure if this still issue, but it used to be.

What library are you using for concurrency anyway? Boost? You are about to enter never ending world of poo poo and I personally wouldn't count the exercise worth the time invested. You aren't going to learn that much useful in terms of concurrency, you are just starting an endless struggle against inane implementation details of the platform and the libraries. Furthermore there are countless of frustrating concurrency problems that might take stupendous amount of time to get solved. Mostly, because you won't simply have all the required information.

I'm not using a library for concurrency because I don't really feel that I learn anything by using Boost and calling it a day. Seeing as how the rest of my programming career is probably going to be writing multithreading-aware code, I should get on this ahead of time.

Does anybody have a better answer?

# ? Oct 26, 2009 16:17

haveblue: Aug 15, 2005; Toilet Rascal

Kennedy posted:

EDIT: Bahah, as always, hits me in the face as soon as I post
code:
 Vector3 camLookForward = new Vector3(0f, 0f, -0.5f);
            camLookForward = Vector3.Transform(camLookForward, Matrix.CreateFromQuaternion(playerRotation));
            camLookForward += playerPosition;
Here's a pretty sill Vector math question:

I'm programming a camera for my XNA game. At the moment, it's a 3rd person view of the player's vehicle, pointed at the model's center.

However, I'd like it to look along the forward vector of the player, so more of the screen is visible. What's the math I need so that the camera is always looking at a point 2f along the player's forward vector?

And here's my current code:
code:
            // slerps the camera to follow just behind the player
            cameraRotation = Quaternion.Lerp(cameraRotation, playerRotation, 0.1f);

            // moves the camera in relation to the player position
            Vector3 campos = new Vector3(0.0f, 0.15f, 0.5f);
            campos = Vector3.Transform(campos, Matrix.CreateFromQuaternion(cameraRotation));
            campos += playerPosition;
            
            // make the camera look ahead of the player
            // code goes here
   

            // positions the camera's up vector
            Vector3 camup = new Vector3(0, 1, 0);
            camup = Vector3.Transform(camup, Matrix.CreateFromQuaternion(cameraRotation));

            // creates the view matrix from the player's position for the camera, and the projection matrix for the camera
            viewMatrix = Matrix.CreateLookAt(campos, playerPosition, camup);
            projectionMatrix = Matrix.CreatePerspectiveFieldOfView(MathHelper.PiOver4, device.Viewport.AspectRatio, 0.2f, 500.0f);
And how it looks currently (please ignore the Ferrari in Tron):

Well, you're using a lookat call, so you have all the info you need right here. Just drop campos to the ground, find the vector extending from it to playerPosition, scale that vector up by however much, and use its new endpoint instead of playerPosition.

# ? Oct 26, 2009 16:20

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

timecircuits posted:

I'm not using a library for concurrency because I don't really feel that I learn anything by using Boost and calling it a day. Seeing as how the rest of my programming career is probably going to be writing multithreading-aware code, I should get on this ahead of time.

What? Dude, it's not like Boost does the concurrency for you. And I really doubt you're "not using a library" because that would imply that you're hand-writing system calls in assembly or something.

# ? Oct 26, 2009 16:35

BATH TUB: Jun 27, 2003

Avenging Dentist posted:

What? Dude, it's not like Boost does the concurrency for you. And I really doubt you're "not using a library" because that would imply that you're hand-writing system calls in assembly or something.

http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx (hardly portable, but it's just an exercise so I don't plan on porting it)

It's pretty much a wrapper for an atomic compare-and-swap.

# ? Oct 26, 2009 16:52

haveblue: Aug 15, 2005; Toilet Rascal

timecircuits posted:

I'm not using a library for concurrency because I don't really feel that I learn anything by using Boost and calling it a day. Seeing as how the rest of my programming career is probably going to be writing multithreading-aware code, I should get on this ahead of time.

Does anybody have a better answer?

The rest of your concurrency programming career is not going to be done with raw pthread calls or atomic intrinsics. You use those to learn the fundamentals and then move on to something more streamlined and practical, which may as well be Boost.

# ? Oct 26, 2009 17:06

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

timecircuits posted:

http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx (hardly portable, but it's just an exercise so I don't plan on porting it)

It's pretty much a wrapper for an atomic compare-and-swap.

Just use TR1 atomics. They're about the same level, abstraction-wise, and have the benefit of 1) being portable, 2) teaching you the (new) standard way of doing this. Also, I rather doubt you're going to be able to get away with entirely lock-free programming, but you're welcome to try.

Er, nevermind. Those are C++0x only, it seems. Not that I voluntarily do any interesting programming in C++03 anymore.

Nevertheless, I sincerely hope you aren't planning on using atomics to reimplement semaphores or something because that is just silly.

Avenging Dentist fucked around with this message at 17:12 on Oct 26, 2009

# ? Oct 26, 2009 17:08

BATH TUB: Jun 27, 2003

haveblue posted:

The rest of your concurrency programming career is not going to be done with raw pthread calls or atomic intrinsics. You use those to learn the fundamentals and then move on to something more streamlined and practical, which may as well be Boost.

You're right, maybe I should start just one or two projects in which I explore raw thread calls and low-level synchronization procedures.

Maybe that's why I'm doing that!

And it would REALLY help me along if I could find an answer to the following two questions:

timecircuits posted:

1) What kind of overhead am I looking at from the D3DDevice as multithreaded? Is it going to lock all the time?

2) What do I have to concern myself about in terms of memory allocation? Can I just new and delete things as before, or do I need a thread-safe allocation scheme to avoid race conditions?

# ? Oct 26, 2009 17:14

BATH TUB: Jun 27, 2003

Avenging Dentist posted:

Just use TR1 atomics. They're about the same level, abstraction-wise, and have the benefit of 1) being portable, 2) teaching you the (new) standard way of doing this. Also, I rather doubt you're going to be able to get away with entirely lock-free programming, but you're welcome to try.

Er, nevermind. Those are C++0x only, it seems. Not that I voluntarily do any interesting programming in C++03 anymore.

Nevertheless, I sincerely hope you aren't planning on using atomics to reimplement semaphores or something because that is just silly.

It's not silly if you're writing something performance critical, like a game engine, wherein the 1000 instructions you save from writing a lock-free message queue can go a long way.

# ? Oct 26, 2009 17:25

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

timecircuits posted:

It's not silly if you're writing something performance critical, like a game engine, wherein the 1000 instructions you save from writing a lock-free message queue can go a long way.

What. So you think that a good way to write performance-critical software is to use lockless programming to write your own locks?

# ? Oct 26, 2009 17:30

BATH TUB: Jun 27, 2003

Avenging Dentist posted:

What. So you think that a good way to write performance-critical software is to use lockless programming to write your own locks?

Yes, I do think that -- I've asked senior developers on AAA titles about this and they've told me as much. I don't expect my code to be blistering fast. I'm writing a game engine as an exercise to expose me to all of the performance concerns that need to be accounted for, so that I have a starting point for further research and experimentation.

Standard Win32 critical section locking costs 1000-2000 operations per lock. I can mitigate that by locking once per frame (or by pushing the locking down to the hardware level, via CAS operations, which I'm considering) but then I have to allocate memory in one thread and deallocate it in another, which raises my concern about ensuring that I can manage memory in a thread-safe fashion.

My other concern is that the D3D device has a single-threaded mode and a multi-threaded mode, and I'm not sure what the implications are. If the renderer will lock every time it touches video memory, that would be bad, so I'm trying to find out what its behavior is and write code to handle it accordingly.

# ? Oct 26, 2009 17:43

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

timecircuits posted:

Yes, I do think that -- I've asked senior developers on AAA titles about this and they've told me as much.

If using interlocked instructions to implement a lock were faster than using OS-provided locking primitives, don't you think that the OS writers would have done it that way? Unless you have an incredibly specific need, you use lockless programming to avoid locking, not to write a special-purpose lock.

timecircuits posted:

Standard Win32 critical section locking costs 1000-2000 operations per lock. I can mitigate that by locking once per frame (or by pushing the locking down to the hardware level, via CAS operations, which I'm considering)

You are micro-optimizing an engine that doesn't even exist yet, and apparently haven't bothered looking at any actual numbers:

MSDN posted:

MemoryBarrier was measured as taking 20-90 cycles.

InterlockedIncrement was measured as taking 36-90 cycles.

Acquiring or releasing a critical section was measured as taking 40-100 cycles.

Acquiring or releasing a mutex was measured as taking about 750-2500 cycles.

You'll also note that the interlocked intrinsics in Win32 already take advantage of hardware support where necessary.

timecircuits posted:

but then I have to allocate memory in one thread and deallocate it in another, which raises my concern about ensuring that I can manage memory in a thread-safe fashion.

Allocation and deallocation always lock. I don't think anyone has successfully written a (fully) lock-free malloc yet.

timecircuits posted:

My other concern is that the D3D device has a single-threaded mode and a multi-threaded mode, and I'm not sure what the implications are.

Why do you need to use multi-threaded mode if you're doing all rendering in one thread? What would the logic thread even be doing with the device?

# ? Oct 26, 2009 18:45

ehnus: Apr 16, 2003; Now you're thinking with portals!

timecircuits posted:

Standard Win32 critical section locking costs 1000-2000 operations per lock.

A critical section is only ever that expensive if the lock is contested, an uncontested acquisition of a critical section is little more than an atomic compare and swap paired with a conditional branch. If your locks are frequently contested then you should spend your time improving your architecture rather than improving lock speed.

# ? Oct 26, 2009 19:43

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

haveblue posted:

The rest of your concurrency programming career is not going to be done with raw pthread calls or atomic intrinsics.

Unless you plan on doing DirectCompute/CUDA programming :laugh:

# ? Oct 26, 2009 20:15

GuyGizmo: Feb 26, 2003; stupid babies need the most attention

Quick question: What's the programming language and libraries used for non-XNA Xbox 360 development? In particular, the SDK for Xbox Live Arcade? I assume the Xbox 360 SDK uses some kind of variant of DirectX, and I think you can program with it in both C# and C++, but I'm not sure.

(edit: clarity)

GuyGizmo fucked around with this message at 05:08 on Oct 27, 2009

# ? Oct 27, 2009 04:48

captain_g: Aug 24, 2007

timecircuits posted:

Yes, I do think that -- I've asked senior developers on AAA titles about this and they've told me as much. I don't expect my code to be blistering fast. I'm writing a game engine as an exercise to expose me to all of the performance concerns that need to be accounted for, so that I have a starting point for further research and experimentation.

The rest of your programming career is going to suck and I don't think concurrency is going to play any major role in that.

# ? Oct 27, 2009 07:56

digibawb: Dec 15, 2004; got moo?

GuyGizmo posted:

Quick question: What's the programming language and libraries used for non-XNA Xbox 360 development? In particular, the SDK for Xbox Live Arcade? I assume the Xbox 360 SDK uses some kind of variant of DirectX, and I think you can program with it in both C# and C++, but I'm not sure.

(edit: clarity)

The XDK is C++, I think I heard of one Arcade title using XNA instead, but I could be mistaken.

# ? Oct 27, 2009 14:14

haveblue: Aug 15, 2005; Toilet Rascal

GuyGizmo posted:

Quick question: What's the programming language and libraries used for non-XNA Xbox 360 development? In particular, the SDK for Xbox Live Arcade? I assume the Xbox 360 SDK uses some kind of variant of DirectX, and I think you can program with it in both C# and C++, but I'm not sure.

(edit: clarity)

This is essentially correct. The 360 C++ API is a variant of Win32 and the graphics system is a variant of DirectX 9 with some 10 stuff thrown in like geometry shaders.

haveblue fucked around with this message at 14:57 on Oct 27, 2009

# ? Oct 27, 2009 14:55

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

captain_g posted:

The rest of your programming career is going to suck and I don't think concurrency is going to play any major role in that.

But, but, senior AAA developers!

To the guy who asked this question: if you want to experiment with different types of locking, cool, write a 80 line test program and benchmark that. Writing an enormous piece of software to try something out is silly. (Also, this is where I tell you to never ever ever optimize until you've written the whole thing and your profiler tells you where the bottleneck is.)

Dijkstracula fucked around with this message at 15:46 on Oct 27, 2009

# ? Oct 27, 2009 15:42

GuyGizmo: Feb 26, 2003; stupid babies need the most attention

digibawb posted:

The XDK is C++, I think I heard of one Arcade title using XNA instead, but I could be mistaken.

haveblue posted:

This is essentially correct. The 360 C++ API is a variant of Win32 and the graphics system is a variant of DirectX 9 with some 10 stuff thrown in like geometry shaders.

Ah, okay. But you can't use C# for 360 development unless you use XNA?

# ? Oct 27, 2009 16:26

digibawb: Dec 15, 2004; got moo?

Yup, XNA is the only way to use C# on the 360.

# ? Oct 27, 2009 17:36

Sex Bumbo: Aug 14, 2004

haveblue posted:

This is essentially correct. The 360 C++ API is a variant of Win32 and the graphics system is a variant of DirectX 9 with some 10 stuff thrown in like geometry shaders.

There are no geometry shaders on the 360 or anywhere in the XDK.

GuyGizmo posted:

What's the programming language and libraries used for non-XNA Xbox 360 development? In particular, the SDK for Xbox Live Arcade? I assume the Xbox 360 SDK uses some kind of variant of DirectX, and I think you can program with it in both C# and C++, but I'm not sure.

The first XBLA game to use XNAGS was Schizoid. I'm pretty sure that there have either been more, or that others are in development, and the feedback from said developers is overwhelmingly positive. The XDK supports XACT but no one seems to like that. Not being an audio guy I can't comment. It also supports XAudio2, which I know next to nothing about.
Graphics can be handled at a much lower level. You can do almost anything you could imagine with a system with well known hardware and shared memory.

Hubis posted:

Unless you plan on doing DirectCompute/CUDA programming

GPU programming begin as assembly only, and now allows you to make higher level things like classes and interfaces. it seems naive to think that we'll be stuck with nothing better than atomic intrinsics forever.

timecircuits posted:

2) What do I have to concern myself about in terms of memory allocation? Can I just new and delete things as before, or do I need a thread-safe allocation scheme to avoid race conditions?

DX9 was not made with multicore applications in mind, and is mostly meant to be single threaded. Many of the functions you call on the device need to be called from the same thread that the device was created on.

DX11 was made with multicore applications in mind, and you can also target DX9 level hardware with it. It doesn't make a lot of sense to use DX9 as a learning process.

Sex Bumbo fucked around with this message at 22:09 on Oct 27, 2009

# ? Oct 27, 2009 22:02

Spite: Jul 27, 2001; Small chance of that...

timecircuits posted:

Yes, I do think that -- I've asked senior developers on AAA titles about this and they've told me as much. I don't expect my code to be blistering fast. I'm writing a game engine as an exercise to expose me to all of the performance concerns that need to be accounted for, so that I have a starting point for further research and experimentation.

Standard Win32 critical section locking costs 1000-2000 operations per lock. I can mitigate that by locking once per frame (or by pushing the locking down to the hardware level, via CAS operations, which I'm considering) but then I have to allocate memory in one thread and deallocate it in another, which raises my concern about ensuring that I can manage memory in a thread-safe fashion.

My other concern is that the D3D device has a single-threaded mode and a multi-threaded mode, and I'm not sure what the implications are. If the renderer will lock every time it touches video memory, that would be bad, so I'm trying to find out what its behavior is and write code to handle it accordingly.

D3D multithreaded mode sucks, don't use it. Dump your rendering to another thread. Make a queue of rendering commands and have the rendering thread consume it. The main thread should be completely renderer agnostic and the renderer thread owns all the d3d resources - textures, vertex buffers, etc.

If you are wondering what the best approach is, the reality is that you are going to have to experiment yourself. A single lock, while slow, is not nearly as slow as you are making it out to be. As long as you don't lock and unlock the same lock multiple times per thread per frame, you'll be fine. I guarantee your drivers are taking and releasing a bunch of locks when you are making d3d calls.

Also, d3d doesn't have to lock when it touches VRAM as long as it's not reading and writing the same region. You can render with half a vertex buffer and update the other half without locking.

Also, premature optimization can only end in tears. Experiment and be ready to toss your code. Since this sounds like your first engine, you're going to end up tossing a lot of it anyway.

# ? Oct 27, 2009 22:38

hakeem: Aug 13, 2005

Not sure where this question belongs, but I figure it's game related.

I'm looking to write an app that captures video in games (similar to fraps, though hopefully faster) but with the addition of being able to capture microphone input at the same time, resulting in a single voice-overed game clip. I've looked around, but I haven't found much in terms of a good api or SDK to accomplish writing this app. The one that I've tried (screen2video pro SDK) results in horribly choppy video, and I've tried capturing in many different video formats and codecs, all resulting in the same thing. Wondering if anybody has done something similar or knows of some tools to help write something like this.

# ? Oct 28, 2009 00:26

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

It's close to being finished, but I've been working on a graphics library for .net. It sits on top of OpenTK and does 2D drawing using OpenGL. I started this project 5 years ago in C. The goal was to allow for a more natural handling of sprites and images and overcome some of the limits of drawing with SDL.

I'm sure that it's no where as fast as XNA's sprite batching, but it suits my purposes. I'm working on commenting the code, writing documentation, and coming up with some examples.

http://code.google.com/p/angrymoose/ I don't have any downloads yet, but you can check the project out of subversion. There's a simple example, it demonstrates how to set things up and how to do some basic drawing.

One of my favorite features is that it uses a factory pattern to determine what kind of surface to make depending on what version of OpenGL you are running. For older versions of OpenGL, it will use a sort of tiling system to get around cards that don't support n-P2 or larger textures.

Any kind of feedback would be appreciated.

# ? Oct 28, 2009 08:34

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

Stanlo posted:

GPU programming begin as assembly only, and now allows you to make higher level things like classes and interfaces. it seems naive to think that we'll be stuck with nothing better than atomic intrinsics forever.

While you are correct, and I was mostly just making a tongue-in-cheek jest (being knee deep in some GPU computation code at the moment) I will say just for pedagogy sake that atomics are going to be a much larger part of data-parallel/throughput-oriented computing (which is a suitable model for GPUs) than generic task-parallel/latency-oriented computing, which is what you see on most multi-core oriented systems. This is mainly due to the fact that things like critical sections or semaphore locks are unacceptably bad, since it's likely that a *large* number of threads will all be requesting the same lock at the exact same time, and so end up serializing. Thus lockless design will be a lot more important in general.

(Of course, you could argue that 'atomics' are just short-term critical sections implemented within the hardware, but then we're just getting semantic)

# ? Oct 28, 2009 19:06

almostkorean: Jul 9, 2001; eeeeeeeee

I just started as an intern working for a car company, and they want me to makes a car simulation. I need to pick out a USB wheel/pedals to use for the project, but I don't really have any experience programming for hardware. So is there is a certain brand/type of wheel that is better to program with?

Edit: I guess I should make my question more clear: is there a usb wheel that has good/any documentation?

almostkorean fucked around with this message at 20:45 on Oct 30, 2009

# ? Oct 30, 2009 20:23

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

almostkorean posted:

I just started as an intern working for a car company, and they want me to makes a car simulation. I need to pick out a USB wheel/pedals to use for the project, but I don't really have any experience programming for hardware. So is there is a certain brand/type of wheel that is better to program with?

Edit: I guess I should make my question more clear: is there a usb wheel that has good/any documentation?

I'd think any of the Logitech ones for PC using DirectX to handle the input should work well enough.

# ? Oct 30, 2009 21:17

Bocom: Apr 3, 2009; No alibi
No justice
No dream
No hope

A quick question regarding Box2D. Is there any way to get a body's size? I've looked over the manual a few times (I might have possibly overlooked it), but I have found nothing.

I want to know the position because I need it for the debug drawing (using SFML) that I wrote. If there is a better way to draw bodies without needing the size, I'd gladly look over it.

# ? Nov 3, 2009 01:48

Vinterstum: Jul 30, 2003

Bocom posted:

A quick question regarding Box2D. Is there any way to get a body's size? I've looked over the manual a few times (I might have possibly overlooked it), but I have found nothing.

I want to know the position because I need it for the debug drawing (using SFML) that I wrote. If there is a better way to draw bodies without needing the size, I'd gladly look over it.

If it's for debug drawing, it's probably best to just subclass b2DebugDraw and implement the drawing methods there.

If you can't: You probably would have to fetch all the shapes attached to a body and draw them. From what I remember (I was just using Box2D briefly for a personal project), bodies don't actually have a concept of size (just mass and center-of-mass).

# ? Nov 3, 2009 08:27

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

almostkorean posted:

I just started as an intern working for a car company, and they want me to makes a car simulation. I need to pick out a USB wheel/pedals to use for the project, but I don't really have any experience programming for hardware. So is there is a certain brand/type of wheel that is better to program with?

Edit: I guess I should make my question more clear: is there a usb wheel that has good/any documentation?

Device and manufacturer-specific handling of input devices have gone the way of the dodo, every wheel you get these days is going to be handled just like a joystick by DirectInput and/or XInput provided you've installed the manufacturer drivers.

In other words, you can get pretty much any one and they'll probably work the same, though if you want force feedback or pedals then you should specifically look for ones that include those.

Logitech, Saitek, and Thrustmaster all make entry-level USB wheels, including multiple varieties with pedals and some with force feedback.

quote:

GPU programming begin as assembly only, and now allows you to make higher level things like classes and interfaces. it seems naive to think that we'll be stuck with nothing better than atomic intrinsics forever.

I'm not too sure about that because everything GPUs have been utilized for has been to do performance-sensitive stuff. If more usability is on the horizon, it will probably be in the form of better interoperability with CPU-based software.

OneEightHundred fucked around with this message at 15:27 on Nov 4, 2009

# ? Nov 4, 2009 15:24

Dijkstracula: Mar 18, 2003; You can't spell 'vector field' without me, Professor!

OneEightHundred posted:

I'm not too sure about that because everything GPUs have been utilized for has been to do performance-sensitive stuff. If more usability is on the horizon, it will probably be in the form of better interoperability with CPU-based software.

Actually, there were a few papers at SOSP this year about offloading part of your operating system to various peripherals, with the GPU being the ultimate goal, so it's at least being considered. (Ironically, the paper that pushed the network stack onto the machine's nic saw a 200% performance decrease so it's not necessarily going to be a good idea)

# ? Nov 4, 2009 17:40

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 20:00

wlievens: Nov 26, 2006

Dijkstracula posted:

Actually, there were a few papers at SOSP this year about offloading part of your operating system to various peripherals, with the GPU being the ultimate goal, so it's at least being considered. (Ironically, the paper that pushed the network stack onto the machine's nic saw a 200% performance decrease so it's not necessarily going to be a good idea)

OpenCL is the new hottie in the GPGPU world, if I recall correctly.

Edit: also, how the frak do you get a 200% decrease in a positive number??

# ? Nov 4, 2009 18:20

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

«‹›622 »