Some Personal Modifications

Jun 28, 2012 at 3:01 AM
Edited Jun 28, 2012 at 9:11 PM

In light of Philippe's new job keeping him busy and the open source nature of IGF, rather than making requests lately, I've been tinkering the Framework when I need something fixed/altered. In the interests of supporting the project, I decided to post what I've done in case anyone's interested. So here goes:

- Updated to BEPUPhysics 1.2.0: Pretty sure this is working clean, but my testing hasn't been extensive. the BEPU changes don't seem to have been super-breaking (most of it is internal, though the Drawer code needed a small tweak IGF-side). Did this the other night because I noticed some enhancements and performance gains for things I'm specifically using in my game, so it made sense to see if I could make the update relatively easily.

- Change to the GameState default constructor: Ran into a nasty bug when using my own screen resolutions in deferred rendering. The AA had artifacts and I'd get a texture format exception on the XBox. After a bunch of investigation, found out that High detail settings and mismatched framebuffers can cause these issues. Issues continued due to LoadingGameState always using the default GameState constructor. So I changed GameState() to use the Backbuffer width/height and Medium Detail settings by default to resolve the issue. (You can still explicitly set other values with the full constructor.)

- Expanded Interpolators: I really liked the Interpolator implementation, so much so that I abandoned my own easing helper class in favor of it. But it wasn't quite as flexible as I'd have liked, so I expanded it with additional easing functions (quintic, circular, one that overshoots the target slightly before settling on it). More importantly, I added a direction option for easing In, Out or In and Out (because I really needed that functionality).

- Previous Input State: I'm currently adding code to store the previous input state in the PlayerInput class. This is to get slightly cleaner click detection in my game logic-- ultimately I'd have to store this data somewhere to properly handle button presses (right now, it's easy to accidentally start the game on XBox if you tap the A button instead of Start. This is because right now it activates on IsDown, instead of checking to see if it was up before the press). To my mind, it seems best to add it into the input class rather than keep however many copies of it I need myself. Turns out that the gamepad code, at least, has facilities for this already. Button.IsPressed only returns true for the single frame the button changes from unpressed to pressed, and IsReleased does the same. Need to investigate to see if mouseclicks and keyboard are detected similarly. Update: The mouse and keyboard code don't do this, BUT keyboard-> gamepad mappings do. Since this seems to be the way IGF is really intended to work and my keyboard/mouse needs are kind of game-specific, I'm leaving it alone and implementing my specific needed logic in my game instead of adding it in IGF.

- Fix for SessionManager player identification when Followed by a Menu: The problem I was seeing above is actually that SessionManager watches for IsPressed and menu buttons watch for IsReleased, so one press of the A button will trigger both a new session during a Press Start screen and also select the Play item out of the following menu when it's released. This could be solved by leaving the menu inactive for a period of time after the session starts, but it would be better to solve the actual issue than work around it so that it behaves as expected. I've therefore altered my copy of SessionManager to use IsReleased instead.

 

I've done my best to not fundamentally change the way IGF's been architected. That said, my time doesn't really permit me to get to know it inside and out, so I can't entirely guarantee everything works awesome. Still, if there'd be interest in some or all of these changes, i could submit a patch for people to use.

Coordinator
Jun 30, 2012 at 2:14 PM

Hi Zizi,

Thanks for sharing this information on your own usage of IGF ;)

Would you consider contributing back your changes as I believe this makes sense for all other IGF users. If you could submit a patch, I'd then apply it to the source code.

Otherwise, we could even consider adding you as an official contributor and give you access to the repository for commiting the changes directly ;)

Cheers

Jul 4, 2012 at 7:32 PM

You're quite welcome.

I'd be happy to submit a patch-- I'll probably try to pull that together and upload it today sometime, once I get a bit of time to spare for it. Though, I should really, come to think of it, make sure my fix to GameState is fully doing what I intended first. In any case, I should have a patch uploaded today sometime. :D

Jul 5, 2012 at 5:07 AM

Patch uploaded for anyone that wants it. I should note, the Physics update does NOT include Indie version project file changes, as I only have a Sunburn Pro license, so I wouldn't be able to build an Indie copy to verify functionality. (Also, as I don't use Indie, I can't really spend time messing with it.)

Jul 7, 2012 at 10:23 PM

Hey Zizi, can you upload the binaries for this updated version somewhere? I tried to merge it with the source code and am getting a lot of errors when trying to build the source code. Also any suggestion on how I can get started working with IGF quickly as the documentation is outdated and don't believe it works with the current version and also wanting to focus on using this for Windows Phone.

Jul 11, 2012 at 8:46 AM
Edited Jul 11, 2012 at 8:50 AM

Two questions: One, which version of Sunburn? Two, what kind of errors?

Depending on the answers to those questions, a binary might or might not actually be useful to you.

As to the rest, that's a somewhat complicated question. I think most of us have picked up Philippe's Ace on Steroids offering over on IndieCity. It's a couple of bucks to support IGF, and you get the AoS source code that uses the current IGF version. AoS does a pretty good job of illustrating most of the basic IGF usage for PC, and honestly so far XBox and WP7 haven't been much different (notably, WP7 doesn't support deferred rendering, of course).

Jul 12, 2012 at 12:31 AM

There is one modification/fix I completely forgot about when i did this patch and post. It's a small one-- ChaseCamera3D didn't work like I expected it to (it seemed to be behaving like I'd expect a 2D chase cam to behave.

Anyway, it ended up being super-minor, and I changed it ages ago. All you need to do is change the first three lines of UpdateWorldPositions() in ChaseCamera3D.cs to read:

                // Calculate desired camera properties in world space
                Vector3 chaseDesiredPosition = Vector3.Transform(DesiredPositionOffset, TargetEntity.World);
                Vector3 chaseTargetPosition = Vector3.Transform(TargetPositionOffset, TargetEntity.World);

In the IGF version, it doesn't transform the offsets by the target entity, so it doesn't really chase, exactly. I don't really know what the original author of the camera intended for its behaviour, but this change yields the kind of chase camera I think most people are expecting.

Jul 12, 2012 at 11:59 PM

Hi Zizi, I have the Pro version and when I build it I'm getting 41 errors and 134 warnings. Here is the list of all the errors I'm getting which half of them are this error:

Error 56 Could not write lines to file "obj\Debug\ProjectMercury.Plugins.DefaultControllers (SunBurn Indie).csproj.FileListAbsolute.txt". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. ProjectMercury.Plugins.DefaultControllers (SunBurn Indie)

Some of the other errors are:

Error 105 The type or namespace name 'ICELandaLib' could not be found (are you missing a using directive or an assembly reference?) C:\Users\dwc2987@msn.com\Desktop\igf-13737\1 - Source\Main\Indiefreaks Game Framework Solution\Indiefreaks.Game.IndieCity\IndieCity\UserScoresLoadDelegate.cs 1 7 Indiefreaks.Game.IndieCity Windows (SunBurn Pro)

Error 106 The type or namespace name 'ICEBridgeLib' could not be found (are you missing a using directive or an assembly reference?) C:\Users\dwc2987@msn.com\Desktop\igf-13737\1 - Source\Main\Indiefreaks Game Framework Solution\Indiefreaks.Game.IndieCity\IndieCity\IndieCityManager.cs 4 7 Indiefreaks.Game.IndieCity Windows (SunBurn Pro)

Error 107 The type or namespace name 'ICECoreLib' could not be found (are you missing a using directive or an assembly reference?) C:\Users\dwc2987@msn.com\Desktop\igf-13737\1 - Source\Main\Indiefreaks Game Framework Solution\Indiefreaks.Game.IndieCity\IndieCity\IndieCityManager.cs 5 7 Indiefreaks.Game.IndieCity Windows (SunBurn Pro)

Error 108 The type or namespace name 'CoLeaderboardUserRows' could not be found (are you missing a using directive or an assembly reference?) C:\Users\dwc2987@msn.com\Desktop\igf-13737\1 - Source\Main\Indiefreaks Game Framework Solution\Indiefreaks.Game.IndieCity\IndieCity\UserScoresLoadDelegate.cs 5 49 Indiefreaks.Game.IndieCity Windows (SunBurn Pro)

Coordinator
Jul 16, 2012 at 7:30 PM

Hi Strikerx87,

The first errot is due to a Windows limitation on file + path length. This can easily be solved by putting your solution in a directory nearer to the hard drive root such as "C:\IGF".

For the other issues, they are thrown because IGF includes a wrapper to the IndieCity API (IndieCity is a Windows distribution digital platform similar to Steam) and the ICELandaLib, ICEBridgleLib and ICECoreLib are dlls required for this implementation.
You can either A. get to Indiecity.com and download their latest sdk and it should then compile fine or B. simply unload the Indiefreaks.Game.IndieCity project under the Windows solution folder.

Oct 20, 2012 at 6:30 PM

I've been using Zizi's fix for the ChaseCamera3D since the beginning of my project, but I always had some oddness when the velocity of my model became 0. I also noticed that when I swapped out models, my camera settings were out of wack. The fix was to remove the Scale factors included in the TargetEntity.World values in the code below in case anyone else runs into this....

 // Calculate desired camera properties in world space
Vector3 chaseDesiredPosition = Vector3.Transform(DesiredPositionOffset, TargetEntity.World);
Vector3 chaseTargetPosition = Vector3.Transform(TargetPositionOffset, TargetEntity.World);