improving code quality to enable -Wall with minor discounts

[kortemik]

improving code quality to enable -Wall with minor discounts

[DanielGibson]

Im drowned in boring warnings, including switch() statements that don't handle all cases (so what?), I think we should suppress more warnings and fix others (like unused variables)

[kortemik]

travis-ci build does not show these warnings, so I assume they are compiler distribution package specific, however, we should include those supressions of course. -Wno-switch should help in this case, are there others that are not interesting and spam? Perhaps also disabling -Wcast-align for clang at least.

[BielBdeLuna]

what does Travis-ci do? I see it has compiled the code with several compilers. is this the utility of it? to compile in different environments and see different errors?

[kortemik]

yes, also it can deploy the built binaries to sourceforge for example, however i have been bit lazy to set it up as we don't have that many followers as of yet.

If we had test cases which could be run on ubuntu, it could also execute those and then report the status of a branch. If one is eager enough one could even write tests that go so far that the engine does dmap and then loads the map and even sees with opengl debugger that the display looks like it should. Throw in some 140hours of hacking and it might even do that :)

We could build the windows binaries and package the libraries too so it would be deploy-able kit

[BielBdeLuna]

kool aid!

[DanielGibson]

Am 10.11.2014 um 21:01 schrieb Biel Bestué de Luna:

kool aid!

?

[BielBdeLuna]

cool

[DanielGibson]

this is merged (github doesn't understand that because of rebases)

[BielBdeLuna]

Daniel have you seen the commits form wintermute on SDL2 joystick improvements which are not yet merged with Robertbackeban's? they do work wonders for the non-XBOX gamepads, like PS3's... https://github.com/Wintermute0110/RBDOOM-3-BFG/commits/master

[BielBdeLuna]

I've had some request to Wintermute but it seems he has been busy, take a look to the comments in his last commit: https://github.com/Wintermute0110/RBDOOM-3-BFG/commit/bb3067c6d5cf6873ec6c49ace94b110bd03ca3de

I asked him if he could add new actions already binded with the keys of the gamepad, the user shouldn't be able to unbind those actions from those keys becuase thos actions hsould be the same as the actual keys. so you woudl end up with two actions per key:

• 1 - the key would be binded to an action from the users choosing (that's the actual implementation)
• 2 - the key would also be binded to an action with the same name of the key

so key "d_up" would fire action "D_UP" as well as "+flashlight" (or whatever one has binded to "d_up")

why?

imagine you want some context-specific key pressing in some part of the gameplay, code-wise you are constantly using the actions (that the user can bind), but imagine you want to actually force the player to use an specified key, the actions bound to that key could be whatever the player wants, and having to guess what actions you have to code in with the context specific checks could be a nightmarish endeavour. since the "actions" seem to be a simple boolean it doesn't seem to be that demanding to the computer to have the key trigger two actions, again, the one binded by the user and a new one which has the same name as the key which would be the one used in the contextual checks.

[DanielGibson]

no I haven't, I just merged rbd3bfg master.

I haven't thought about that actions idea very much, but on first glance I don't like it. the player should be able to rebind all keys (except maybe for Escape). if he has a gamepad/joystick with a different layout than you assume making him press D_UP (or whatever) would be bad.
it's probably better to just use existing actions and make them do different things depending on context.

[BielBdeLuna]

but then how do you figure out what key does what when you're actually targeting the keys and not the bounded actions?

[DanielGibson]

What I'm saying is: Don't target the keys. Ever. Because you can't know what the players input device looks like.

[BielBdeLuna]

but you could force the player to bind their exotic device beforehand, with another setup application, to the standardized key setup of the xbox/playstation devices which should be the most common available, we could let the door open for more exotic devices like wii's but still have a strong base for those common devices, we could assume all devices should at least have a d_up, d_down, d_left, d_right, a, b, x, y two pads wich are also buttons, two trigger with double buttons, a start, a select, and a system button. so people can do games for those devices within the opentech engine