Originally posted by ima
The game seems to start up fine, albeit the movement across the ground seems very rough, not sure if this is by design or not, haven't dived into the gameplay code just yet.

The player physics is currently tuned to feel somewhat like bumper cars, which was intentional. If you want fine control like you'd get in an FPS, you probably don't want to have physics driving movement. Feel free to experiment.

When I fall off the edge of the map, the teapot just disappears and the camera freezes, the only thing I can do is quit the game.

Correct, you hit the death zone. There's a zone under the arena that destroys any game object that it hits. I never hooked up the player respawning, mostly due to time constraints. Much like a real game, we had to ship with a few hacks. You can still see my hack comment on 353 of TeapotWars.cpp.

In a real game, this would just be another actor that destroyed anything it hit. If that thing was the player, it would respawn the player at a spawn point (which would be another actor).

If I quit the game, it does so unhappily, with an error message telling me the D3D device had a non-zero reference.
This also happens if I try to do anything related to changing the window, such as resizing it or going into fullscreen mode.

This is a bug. There's an unreleased object somewhere which we haven't tracked down, though it shouldn't cause any issues.

If I try to run a release build it simply fails on the linking phase, because of a missing luaplus51-1201.lib

This is probably an issue with the copy script not copying everything over. Mike wrote this script to make it easier to manage the 3rd party libs, so I'll let him weigh in on what might be wrong.

I really enjoy the book though, it just doesn't seem right that the code is so unstable.

The GCC engine is an implementation of core techniques we teach in the book and Teapot Wars is a demo using that engine. There are definitely bugs, which is very unfortunate. All projects have bugs and we did what every software engineer does, which attempted to triage them as best we could. We prioritized bugs that kept the reader from experimenting with the game. We also focused on making those core systems as solid as possible so they could serve as a demonstration of our game architecture philosophies. Things like a missed DirectX object not being released or a broken Release build weren't high on our test list. In a real game, they absolutely would be, but our purpose was different. A real game might sacrifice code readability, for example, while that was one area we absolutely couldn't sacrifice. When crunch time hits, you have to choose your battles.

Our hope is that any issues you experience don't detract from the overall lessons the book is trying to teach. The code examples of those lessons are still very solid; the place it tends breaks down is in the glue between the engine and 3rd party libs.

That being said, if there are any blocking issues with keeping you from experimenting or playing some aspect of the game, let me know and I'll see about correcting those specific issues sooner rather than later.

-Rez

Hello!

I just took a quick look at the 3rd Party libs and it seems that the Lua library is missing from the x64Release directory. Try compiling the 32 bit release version and see if that works...

Also - I assume you are using VS2010? The 3rdParty build scripts support VS2008 and VS2010 - if you are using a later version you might need to dig in to Source/GCC4/3rdParty/build_vs2010.bat and copyalllibs_vs2010.bat and port them for a later compiler.

I believe the physics collider representation of the Teapot is a flattened cube - so sometimes when the teapot hits an edge of the floor plane it will react as if it hit a bump. Solving this would involve extending the physics system a bit to calculate a legal physics collider from the vertices of the teapot. Then, at the contact points the shape would have a more gentle ramp - I believe that will fix the problem.

It was one of those things that was on my TODO list, but just ran out of time before Rez and I had to submit the final chapters...

Hello!

New guy to the forum and first post here. I'm very grateful for all the material Mr Mike and Rez have presented. As a newbie to coding game engines, it all has proven invaluable to my education.

I've been bothered by this same issue for the past couple days:

ima wrote:

If I quit the game, it does so unhappily, with an error message telling me the D3D device had a non-zero reference.

Debugging reference counts is probably over my head, but I made a discovery that might help somebody who is more knowledgeable. Using PIX I determined a D3D9 State Block is left behind when the MainMenuView is changed to the main game. Should the MainMenuView be removed when the main game takes over? I would like to try this inside the RequestStartGameDelegate() function to see if this resolves the reference count problem. Can somebody weigh in on this thought?

void TeapotWarsLogic::RequestStartGameDelegate(IEventDataPtr pEventData)
{
// VRemoveView(menuView);
VChangeState(BGS_WaitingForPlayers);
}

I just couldn't let it stay broken. The MainMenuView is removed inside of BaseGameLogic.

void TeapotWarsLogic::RequestStartGameDelegate(IEventDataPtr pEventData)
{
//This already handled in BaseGameLogic
// m_gameViews.empty();

VChangeState(BGS_WaitingForPlayers);
}

The following code in TeapotWarsView will fix the reference that is not deleted:

MainMenuUI::~MainMenuUI()
{
D3DRenderer::g_DialogResourceManager.UnregisterDialog(&m_SampleUI);
D3DRenderer::g_DialogResourceManager.OnD3D9LostDevice();
}

OnD3DLostDevice is the only location in DXUTgui that has SAFE_RELEASE( m_pStateBlock ); D3D9 State Block that is left behind.

I hope this saves somebody some time trying to track it down.

Awesome, thanks for the fix!!

My computer is in shambles right now since I'm in the middle of upgrading it and reinstalling everything. Once I finish that, I'll test out your change.

-Rez