Looking for code feedback?

#21 Ron, nullable types cause boxing if used with value types, which can cause a lot of memory churn if happens in the wrong place (megs a second from a single box if it's in just the wrong code).

In the non-nullable case your version would be more compact, but I bet it compiles the same. Pretty much never gave the ?? operator any thought because we were so quickly turned off by nullable types (an early implementation had nullable ints being returned by a proto input manager and it sucked big time).

If I get a chance I'll look for those cases in our code where it can be replaced (after checking the il to make sure it isn't worse -- sometimes the compiler does weird things...you probably don't notice with server apps, but you do with games if that weird thing happens at just the wrong spot).

#22

Quote:
We can agree to disagree. I don't like your method because it assumes that if I'm on a PC I am not using a gamepad, but what if I am? This is why, in TankBuster at least, I am binding for both the keyboard and gamepad. It gives me the option of playing the game anyway I like.

Aha, but you can test for a gamepad on a PC too young skywalker! It's not that big of a deal at all. Was just a 'why not' type thing. The binding methods don't take up hardly any memory so unless you're binding 10000 things for each platform, it shouldn't be an issue on performance.

#23 Something I like about having the binds in there from the start (in addition to the already mentioned good reasons) is I don't always have my gamepad plugged in when I start the game. I can plug in the Xbox controller after the game is already started and just start using it. I would think it annoying if I had to have all my peripherals plugged in and ready to go before clicking the executable. I realize this is the way most apps work, and it has frustrated me for years ;) If it were standard practice to test for the gamepad before binding then this would never work to plug it in after you're already playing.

#24 @Ben - It's USB, your .net programs can detect new USB devices just like windows can. You can have the binds called when the controller is detected, not just when program is loading.

#25 Interesting comments.

Aside -> It always amazes me how talking about code conventions always seems to evolve into a cat fight. ;)

The CLR Shared Source is a great example of Microsoft code (or at least the contractors they paid to port it.)

All I care about is consistency & the great use of regions, although I would like to throw a plug in for more code comments. That's my biggest complaint about the TGE & TSE source too. I usually have to put break points in and debug it before I understand what the heck it's doing. Every 10 lines or so, it would be nice to have a comment that talks about what it's generally doing. This especially applies to changes in existing source. It's nice to know 'why' something changed. A simple changelog would also go a long way here.

#26 Tim, I think you mis-read if you thought there was a cat fight going on. For one thing, we're all burly men here. I think Robert was a little touchy on the controller issue, maybe that's what you were thinking about. BTW, should we bind without a controller connected? Give me a break. I watch the profile closely. That doesn't show up.

#27 Cat fights are for women! Either way, no heat at all (at least from what I've been reading). I'm just a picky bastard and when you open up and say "send comments on code format, etc" then I gotta stick my big nose where it doesn't belong and be critical.

It's all in good intentions. I think the best programmers in the world aren't really the ones who can program the best, but are the ones who can put their pride aside and listen to criticism of their code and coding style. Communication is key!

#28 Reading back I do not see any cat fighting etc. We are just having an open healthly discussion regarding the current state of the code and how it could possibly be modifed to be more flexable and or use friendly. Yes, most of what we (Jonathon and I) have brought up are nit picky, but could provide ease of use for true indie developers and those who are new to C#. Just like everything else in life; their will be things you agree with and things your dont, TorqueX is not different.

All in all, think GG is moving in the right direction.

-Ron

#29

Quote:All in all, think GG is moving in the right direction.

I'd agree. I do think that the way it's set up will be harder for true C# developers more than newcomers however. Most C# developers have the standards that Ron and I have been pointing out. So long as consistancy exists (and they quit using S as a variable *pfffft*) things will be fairly easy to work through.