next »

[_Tommo_]

Got Bullet working in a multithreaded setup with one physics thread per world, with up to 2500 cubes up and running per thread  
Each thread runs the physics with a 120hz fixed timestep, timesharing it with a lambda-based (lockless) command queue used by the game to interact with physics.
Why do I need more than one world running at the same time? MISTERY

BTW C++11 lambdas are really a game-changer on the amount of code you need to write to make, anything with threads. Everything just takes less effort!
Say, an asynchronous raycast done like this

Code:

static RaycastResult future;
world.asyncOp([&]()
{
    world.raycast( start, end, future );
})
.onFinish( [&]() 
{
    if( future.hasHit() )
        future.hitObject->color = Color::RED;
});

would have been a real nightmare to make without lambdas... functor classes 

[Trent]

This doohickey 

[darkhog]

Some kind of level editor?

Anyway, dunno how it fits under "programming", but I'm making HTML5 game with Game Develop right now. Great tool.

[RalenHlaalo]

I got moving platforms to work nicely with Box2D without using joints. My solution was actually very simple; I just detect collisions against the platform and add colliding entities as children, then remove them when they stop touching the platform. In my engine, children are translated/rotated along with their parent.

EDIT: Damn, I just discovered my solution doesn't work because when the dynamic body is moved, it appears to lose any momentum it had, meaning it gets completely stuck on the platform.

[RandyGaul]

I got moving platforms to work nicely with Box2D without using joints. My solution was actually very simple; I just detect collisions against the platform and add colliding entities as children, then remove them when they stop touching the platform. In my engine, children are translated/rotated along with their parent.

EDIT: Damn, I just discovered my solution doesn't work because when the dynamic body is moved, it appears to lose any momentum it had, meaning it gets completely stuck on the platform.

Ha, this sort of thing is how you *should* do it. You should write logic to determine if you're attached to a platform or not. Ideally your character controller will have a "grounded" state. This way if you're attached to a platform you move relative to it, and are unattached when you exit the "grounded" state.

You shouldn't have to lose all your momentum. I also am unsure if momentum is the right word, did you mean velocity?

[RalenHlaalo]

I got moving platforms to work nicely with Box2D without using joints. My solution was actually very simple; I just detect collisions against the platform and add colliding entities as children, then remove them when they stop touching the platform. In my engine, children are translated/rotated along with their parent.

EDIT: Damn, I just discovered my solution doesn't work because when the dynamic body is moved, it appears to lose any momentum it had, meaning it gets completely stuck on the platform.

Ha, this sort of thing is how you *should* do it. You should write logic to determine if you're attached to a platform or not. Ideally your character controller will have a "grounded" state. This way if you're attached to a platform you move relative to it, and are unattached when you exit the "grounded" state.

You shouldn't have to lose all your momentum. I also am unsure if momentum is the right word, did you mean velocity?

Velocity, yes - or whatever the state of the object is that determines how it should move on the next timestep; it seems that some aspect of the object's state is reset on translation (velocity being the only relevant thing I can think of). I tried preserving the velocity by setting it to whatever it was before the transformation, but that didn't work. I'll have to investigate further as to whether this method is fundamentally unworkable in Box2D or if the problem lies in the way my engine is handling things.

EDIT: Fixed it! The problem was with my engine, not Box2D.

[darkhog]

Trying to get my friggin' collision to work. The guy's not supposed to be on top of the platform, he pushed through the sphere-to-stage detection and now he's up there.

I hope you'd keep this artstyle. IMO game which uses checkerboard patterns for everything would look very cool.

[Vanin]

Gameplay redesign to be more tactical and keep the fight focused on the letter board. And it's a lot better. I feel validated today as a designer again.

[DC]

I hope you'd keep this artstyle. IMO game which uses checkerboard patterns for everything would look very cool.

Thanks! The checkerboard is just a placeholder texture for the stage (unless I decide to add a circus level or something, I doubt it though), but the robots are probably final. It's programmer art for sure, but I don't have the money to hire a real artist to do it for me.

On the bright side, I finally managed to get collision working right. Had to copy someone's algorithm and convert it to Python make my own, since Panda3D doesn't let you do sweeping collision to prevent phasing through stuff at low framerates. It also forced me to lower the poly count of my test stage significantly, which is okay because the colliding part of the stage will be invisible anyway. The detailed/textured stage itself won't be collidable.

Now I just have to figure out ellipsoid-ellipsoid collision so that I can have the two robots collide with each other (and later add projectile collision), and gravity so that I can have the robots distinguish between moving down a sloped surface and falling off an edge.

[0x0961h]

Re-inventing the wheel: implementing platformer physics for next project. Collisions, gravity and stuff.

[J-Snake]

This stuff can be very specific in fine details. I would certainly do it myself too, to go sure it works exactly the way I want.

[RalenHlaalo]

I got moving platforms to work nicely with Box2D without using joints. My solution was actually very simple; I just detect collisions against the platform and add colliding entities as children, then remove them when they stop touching the platform. In my engine, children are translated/rotated along with their parent.

EDIT: Damn, I just discovered my solution doesn't work because when the dynamic body is moved, it appears to lose any momentum it had, meaning it gets completely stuck on the platform.

Ha, this sort of thing is how you *should* do it. You should write logic to determine if you're attached to a platform or not. Ideally your character controller will have a "grounded" state. This way if you're attached to a platform you move relative to it, and are unattached when you exit the "grounded" state.

You shouldn't have to lose all your momentum. I also am unsure if momentum is the right word, did you mean velocity?

Velocity, yes - or whatever the state of the object is that determines how it should move on the next timestep; it seems that some aspect of the object's state is reset on translation (velocity being the only relevant thing I can think of). I tried preserving the velocity by setting it to whatever it was before the transformation, but that didn't work. I'll have to investigate further as to whether this method is fundamentally unworkable in Box2D or if the problem lies in the way my engine is handling things.

EDIT: Fixed it! The problem was with my engine, not Box2D.

Check it out

[0x0961h]

This stuff can be very specific in fine details. I would certainly do it myself too, to go sure it works exactly the way I want.

Yup. I chose this path 'cause I concluded that using Box2D would be an overkill for me in this case. A lot of features that I don't actually need (for now at least) will somehow lead to very complex and unstable code. And I've used it for #happysad once also, and it was awful (magic numbers for friction and other parameters, yay!).

[ThemsAllTook]

This made me equal parts happy and grumpy, so I guess it belongs here... My PC's main hard drive died a little while ago, taking with it my carefully set up Linux dev environment (but fortunately not much else of value). I redid it all from scratch over the last couple of days, this time keeping extensive documentation of the setup process so I could do it a third time if I have to. Unfortunately, it's anything but straightforward. Here's the full log of what I tried as I figured it out:

Code:

All commands executed and packages installed from fresh Ubuntu 12.04.3 install to complete setup:

$ sudo apt-get install aptitude
$ sudo apt-get install subversion
$ sudo apt-get install clang

// Check out all stem libs and managed third-party libs and try to build them
// Attempt to build 3dmath complains that <bits/predefs.h> can't be found
$ sudo apt-get install libc6-dev // Didn't solve issue; may not be needed at this stage
$ sudo apt-get install gcc-multilib // Solved

// Attempt to build glew complains that <GL/gl.h> can't be found
$ sudo apt-get install freeglut3-dev // Closer
$ sudo apt-get install freeglut3-dev:i386 // Closer, still need -lXmu and -lXi for -m32
$ sudo apt-get install libxmu-dev:i386 // Closer, still need -lXi
$ sudo apt-get install libxi-dev:i386

// glew i386 compiles, but x86_64 still needs libxmu-dev and libxi-dev, which won't install
// when libxmu-dev:i386 and libxi-dev:i386 are present...let's try removing them
$ sudo apt-get remove libxmu-dev:i386
$ sudo apt-get autoremove
$ sudo apt-get remove libxi-dev:i386
$ sudo apt-get autoremove

// Nope, still can't install libxmu-dev...maybe we need to get rid of i386 freeglut3 too
$ sudo apt-get remove freeglut3-dev:i386
$ sudo apt-get autoremove
$ sudo apt-get install libxmu-dev // That's more like it!
$ sudo apt-get install libxi-dev

// We lost freeglut3-dev somehow, so restore it
$ sudo apt-get install freeglut3-dev

// That got 64-bit glew building, so for now let's proceed with 64-bit builds and get all
// those working before we worry about 32-bit
$ sudo apt-get install zlib1g-dev // Needed for libpng

// Stem libs that won't build with what we have so far: glgraphics, glutshell, glslshader, pngimageio, gamepad, vorbisaudioio, gltexture, inputcontroller, glbitmapfont

// pngimageio just needs 64-bit libpng; reasonably isolated, so let's do that one first
$ sudo apt-get install libz-dev:i386 // This one looks dangerous; it removes gcc and gcc-multilib...let's see what happens
$ sudo apt-get install gcc-multilib // libz-dev:i386 did remove it, but reinstalling multilib doesn't remove libz-dev:i386...weird, but libpng builds now, as does pngimageio!

// vorbisaudioio is another relatively isolated one; let's get it up before tackling GL
// Turns out libogg and libvorbis didn't need anything additional to build! portaudio works too.
// OK, glew time. We need 32-bit libXmu, libXi, libGLU, libGL, libXext, and libX11.
// freeglut3-dev:i386 is a stubborn bastard and won't install without removing freeglut3-dev.
// Maybe we can manually download and install it?
$ sudo apt-get download freeglut3-dev:i386
$ sudo dpkg -i freeglut3-dev_2.6.0-1ubuntu3_i386.deb
// That looks like it might be more cooperative as far as not removing packages goes...
// but it won't install without freeglut3:i386, libxt-dev:i386, and libxext-dev:i386. Hmm...
// apt-get is complaining about the package with unmet dependencies, so let's remove it for now
$ sudo dpkg -r freeglut3-dev:i386

// Packages we need that apt-get won't give us: freeglut3-dev:i386 {libgl1-mesa-dev:i386 {libgl1-mesa-glx:i386 {libglapi-mesa:i386 *}, libxext-dev:i386 {}}, libglu1-mesa-dev:i386 {}, libxt-dev:i386 {}, libxext-dev:i386 {}}
$ sudo apt-get install libglapi-mesa-lts-raring:i386
$ sudo apt-get install libgl1-mesa-dri-lts-raring:i386
// Those installed OK, let's try the freeglut dpkg again and see what it thinks
$ sudo dpkg -i freeglut3-dev_2.6.0-1ubuntu3_i386.deb

$ sudo apt-get install libgl1-mesa-glx-lts-raring:i386

// That last one didn't work...let's try something else
$ mkdir packages
$ cd packages
$ sudo apt-get download freeglut3:i386 freeglut3-dev:i386 libdrm-dev:i386 libgl1-mesa-dev:i386 libgl1-mesa-glx-lts-raring:i386 libglu1-mesa:i386 libglu1-mesa-dev:i386 libice-dev:i386 libice6:i386 libkms1:i386 libpthread-stubs0:i386 libpthread-stubs0-dev:i386 libsm-dev:i386 libsm6:i386 libx11-6:i386 libx11-dev:i386 libx11-xcb1:i386 libxau-dev:i386 libxau6:i386 libxcb-dri2-0:i386 libxcb-glx0:i386 libxcb1:i386 libxcb1-dev:i386 libxdamage1:i386 libxdmcp-dev:i386 libxdmcp6:i386 libxext-dev:i386 libxext6:i386 libxfixes3:i386 libxt-dev:i386 libxt6:i386 libxxf86vm1:i386 mesa-common-dev:i386
$ sudo dpkg -i *

// That's gotten us somewhere! Most of those installed fine, but these were unhappy about coinstalling with their 64-bit counterparts: libdrm-dev:i386 libgl1-mesa-dev:i386 libglu1-mesa-dev:i386 libice-dev:i386 libsm-dev:i386 libxext-dev:i386 libxt-dev:i386 mesa-common-dev:i386 freeglut3-dev:i386
$ mkdir ../conflicting_packages
$ mv /*names of those files*/ ../conflicting_packages

Extract all with context menu (don't know how to on command-line! dpkg doesn't seem able...)

$ sudo dpkg -r freeglut3-dev:i386
$ sudo cp -r freeglut3-dev_2.6.0-1ubuntu3_i386/usr/* /usr
// Repeat similar for all expanded packages in this directory

// Looking better! Now we just need libXmu and libXi...
$ sudo apt-get download libxmu-dev:i386
$ sudo apt-get download libxi-dev:i386

Extract both with context menu
$ sudo cp -r libxmu-dev_1.1.0-3_i386/usr/* /usr
$ sudo cp -r libxi-dev_1.6.0-0ubuntu2.1_i386/usr/* /usr
// ...and with that, everything builds successfully! We probably could have done with a lot fewer
// manual-expand-and-copy-to-usr packages...all we need is the libraries, not all their dependencies



Possible minimum setup:
$ sudo apt-get install aptitude
$ sudo apt-get install subversion
$ sudo apt-get install clang
$ sudo apt-get install libz-dev:i386
$ sudo apt-get install gcc-multilib
$ sudo apt-get install freeglut3-dev
$ sudo apt-get install libxmu-dev
$ sudo apt-get install libxi-dev
$ sudo apt-get install zlib1g-dev
$ sudo apt-get download freeglut3-dev:i386 libgl1-mesa-dev:i386 libgl1-mesa-glx-lts-raring:i386 libglu1-mesa-dev:i386 libxmu-dev:i386 libxi-dev:i386
Extract downloaded
$ sudo cp -r */usr/* /usr

The main sticking point is that in order to build both 32-bit and 64-bit binaries on the same computer, you need to have both i386 and x86_86 versions of some packages installed at the same time...but the packages conflict with each other, so no matter how hard I tried, I couldn't get apt-get or dpkg to cooperate and just install both. The only way I know to make it work is to first install the x86_64 versions, then download the i386 packages to the current directory, extract them, and manually copy their contents to /usr. Everything worked once I did this with the appropriate packages, but man, what a mess!

[jjd]

This made me equal parts happy and grumpy, so I guess it belongs here... My PC's main hard drive died a little while ago, taking with it my carefully set up Linux dev environment (but fortunately not much else of value). I redid it all from scratch over the last couple of days, this time keeping extensive documentation of the setup process so I could do it a third time if I have to. Unfortunately, it's anything but straightforward.

...snip...

The main sticking point is that in order to build both 32-bit and 64-bit binaries on the same computer, you need to have both i386 and x86_86 versions of some packages installed at the same time...but the packages conflict with each other, so no matter how hard I tried, I couldn't get apt-get or dpkg to cooperate and just install both. The only way I know to make it work is to first install the x86_64 versions, then download the i386 packages to the current directory, extract them, and manually copy their contents to /usr. Everything worked once I did this with the appropriate packages, but man, what a mess!

I came across a related post, which you may have encountered http://ubuntuforums.org/showthread.php?t=1998047, but this is one of the downsides to ubuntu. It makes a lot of things nice and easy to work with out of the box, but sane dependency management is not one of them. This is the main reason why I use gentoo.

-Josh

[Trent]

Some kind of weird robotic sonic contra thing.

[Blockers]

Working on finishing Lua 5.2 integration in my new C++ engine; so I can start working on a few game designs I've been brewing on paper.

[ThemsAllTook]

I'm currently replacing the last of the GLUT wrapper code in my game framework with native stuff. Feels good to be fully native on all platforms! Haven't started on Android yet, but I have Mac OS X, Windows, Linux, and iOS all done, save for a minor feature still in progress on Linux.

[Liosan]

My PC's main hard drive died a little while ago, taking with it my carefully set up Linux dev environment (but fortunately not much else of value). I redid it all from scratch over the last couple of days

I notice no mingw. Do you not cross-compile? Or does clang do that out of the box?

Liosan

[ThemsAllTook]

I notice no mingw. Do you not cross-compile?

Nah, I boot into Windows to build Windows code. Cross-compilation could be a nice thing to have set up, but there aren't a lot of situations where I need to build for a platform without actually running the output right away.