AxysPhenomenon, few replies in this thread because of ... nothing to say
Orange Brat's contribution really good, pro and 'must have' for solid looking game project. I have to say: many thanks again, nice to hear about new release.

No "praise" necessary.

UPDATE: Getting much closer. I have a couple of bugs to deal with on one of the gamepad modes(#2) and some kind of other gamepad bug pertaining to both modes 2 and 4, however that one can be easily dealt with. The former may just need to be left as is and someone can figure out on their own.

Another possible problem is adding a "strafing" mode to the animation.wdl. I've created the appropriate VARs and DEFINEs and placed them where they need to go in the script file, however I haven't added the large chunk of code that will allow the player's strafing animations to cycle and/or blend when the conditions are met(and it's only relevent to mode 0..Max Payne style camera). Again, I might leave it as is for someone else to deal with.

My game uses fixed point and/or cinematic sweeping cameras ala Ankh, Bone, Broken Sword III, Eternal Darkness, Clock Tower 3, and Resident Evil: Code Veronica, so these issue aren't really too much of a bother for me. However all or most of the bugs/omissions I mentioned a couple posts back are squashed or added, so that's some good news. I've also improved/optimised and/or streamlined a few other preexisting components, as well. I'll tinker with this sorry, bloody bastard a bit more over the next day or so and post it when I feel it's ready.

...TTYL...

No praise necessary because of it's beyond praise ?
Thank You anyway.

Thanks for sharing!

Please let us know when the updated version of this demo is finished because the files at geocities are gone already, which is okey, but I would be interested to see how you've coded those different camera types and like to see them in action.

Again, thanks!

Cheers

I took them down because I didn't want users d/ling the old version. I'll try to get something uploaded later on whether I iron out that one stupid bug or not. I do want to try and stomp one of them that I think I can handle, but the other one is just going to have to wait. It won't matter for The Disenfranchised since my cameras aren't free form look anywhere types, but for general purpose usage, it may be a nuisance for users who like to use a character relative based movement wtih their gamepad.

EDIT: Bah, the hell with it. I'm out of the house most of the night, and I'll deal with it all later, so I've uploaded it. It's defaulted to mode 3 which is camera relative movement with keyboard and mouse. Mouse moves the camera, WASD moves the player relative to the camera angle. I believe the arrow keys can also manipulate the camera. I have imposed no limits so using both the mouse and the keyboard controls at the same time will in essence double the force(s).

http://www.geocities.com/hainesrs/blending.zip
http://www.geocities.com/hainesrs/blending.rar

If you want to change movement modes and default controls then you have to do it in the last function in the "main.wdl"

Code:

---

function loadControlsDefault()
{
		mouseSensitivity = 15;
		joySensitivity = 15;
		keyCameraSensitivity = 15;
		keyPlayerSensitivity = 15;
		movementType = 3;
     	        str_cpy(fw_key, "W");
	 	str_cpy(bw_key, "S");
	 	str_cpy(tl_key, "A");
	 	str_cpy(tr_key, "D");
	 	str_cpy(tcl_key, "cul");
	 	str_cpy(tcr_key, "cur");
	 	str_cpy(tcu_key, "cuu");
	 	str_cpy(tcd_key, "cud");
	 	str_cpy(run_key, "shiftl");
	 	str_cpy(action1_key, "mouse_left");
	 	str_cpy(action2_key, "mouse_right"); 			
	 	setKeys();
}

---

Of course, I have a more complicated INI DLL I/O system in place, so I can change these per end user inputs from an options screen. I use this one for that:

http://www.geocities.com/hainesrs/ini.zip

it's great movement, and blending.
I wonder, what might be happen if this movement code combined with anti-clipping camera (axys style camera code),
it will be absolutely FLAWLESS!

I'll just sit and wait..

My next step is going to be integrating that Zelda code wall avoidance into my cam.wdl for this system. Wish me luck because the Zelda code is a mess to the naked eye. After that, I'll try and deal with those pesky Gamepad mode quirks and whatever else I feel is necessary. I might look into implementing a limits system to address the issue raised last post.

Another new version uploaded that fixes the easy to fix gamepad camera bug. Fixing this also added in a limits system just by the very nature of how the code is constructed, so that's a nice bonus.

The animation left turn/right turn frames bug for mode 2 is still present, however that is a more complicated matter. I might just ignore it given both mode 2 and mode 1(the keyboard only equivalent to the gamepad only mode 2) are worthless control schemes IMHO. This "bug" isn't really that big of a deal...just a matter of a bit of a lack of polish. I actually fixed it in mode 1 but working with gamepads is a weird little world.

http://www.geocities.com/hainesrs/blending.zip
http://www.geocities.com/hainesrs/blending.rar

I also added a new var called "joyDeadZone." This is the value used to determine your gamepad's dead zone so you don't get undesirable results when not moving your joysticks. It's defaulted to a joy_raw value fo 55 out of 255. All other defaults are the same as mentioned a couple posts back. Oh yes, and I think I neglected to mention that the analog joysticks are touch sensitive. If you barely press them the player walks, if you press them all the way it runs.

Looking good. Always nice to see how other people do things, and learn from that. I have already seen a few things in this code I will copy in my future projects. I will try it out when I come home.