Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


kunos

Member Since 06 Aug 2008
Offline Last Active Mar 05 2015 10:14 PM

#5207986 Some programmers actually hate OOP languages? WHAT?!

Posted by kunos on 31 January 2015 - 08:11 PM

Thanks for the tutorial mate, I hope you don't mind me simply ignoring it?. Luckily for me I've got better things to do on a sunday morning than waste my time arguing with a sore idiot on the interwebz with some kind of mental disorder. But I'm glad to have contributed to make you feel smarter today, it was my pleasure to help you reach a new peak in your life, way to go sporty!

 

EDIT: Seriously, the fact that people like you are moderators here really makes me reevaluate the point of participating in here.




#5207963 Some programmers actually hate OOP languages? WHAT?!

Posted by kunos on 31 January 2015 - 05:39 PM

Nice language and conversation handling there from a "senior mod". Congrats.
does vs 2015 looks like that when you install it? My VS 2013 does not, and I dont see any 'deafult' in tools..export setting, just options to import, export and reset setting but hey.. Im stupid so what do I know? I'll leave it to you smart and gentle guys and I promise I will check the world's VS entire install base before making stupid claims.


#5207842 Some programmers actually hate OOP languages? WHAT?!

Posted by kunos on 31 January 2015 - 06:17 AM

 

There's a lot of your history that is wrong and/or misleading. Most of the principles of Object Orientation were modeled in Smalltalk. OOP existed prior to then, however formalization of many of the common principle of object orientation happened in Smalltalk.

 

true.. I shouldn't have used "born" but rather "came to rule" or something like that.

 

But I really think that calling gamedevs "early adopters" is going a bit too far smile.png

 

Regarding Microsoft and C#.. we went from a position where C# was the (only) solution to every problem... maybe you forgot the Windows Phones that just supported C#.. or you forgot the versions of Visual Studio where you had.. new project.. C# or "other languages".. it was all about XNA, Silverlight and co. , to the current situation where .NET became the official scapegoat for the Vista debacle, there are no more "other languages" in VS tongue.png , and C++ is the suggested solution for everything performance oriented.

 

Finally, I find it funny you felt compelled to quote my sentence and post an "answer" to it saying EXACTLY the same thing that I said right after that sentence.. but you got points for that so you must be doing something good obviously. biggrin.png




#5207791 Some programmers actually hate OOP languages? WHAT?!

Posted by kunos on 30 January 2015 - 08:40 PM

OOP was born in a era when computers were getting faster and faster with no sign of a slow down. In those years, it was all about abstractions and optimize programmers' cost and time. Languages such as Java and C# started in that world and hit their target perfectly. Java bureaucracy of interfaces, factories, adapters and all that cruft managed to make a huge impact in the software business, allowing less experienced programmers to jump aboard because most hard and unsafe elements of the process were hidden away.

 

One big advantage of OOP languages that often gets ignored is how they allow for code discoverability and IDE integration. Hit "." after an object and the IDE will tell you what you can do with that thing. Think about the same in C.. you can't, you'll have to rely on naming standards (ie.. in ODE.. I have a dBody , I know I can manypulate it with functions starting with dBodySomething ) or start to dig into documentation. In Java/C#, it's all there in the IDE, the API is autodocumenting itself.

I really got into programming with C++/Java and this is the thing I find most disturbing when trying to use languages without a clear connection between data, and code that can be run on that data.. it's not a surprise that the new era languages such as Go and Rust both went for a solution where the data is clear POD, but you can bind code to the data.. getting the best of both worlds: clear data definition, and code discoverability. 

 

The gamedev world has always been resisting to changes, they were ages late to the "C party" (most games were done in assembler up to fairly recent days), ages late to the C++ party, and never really got in the C#/Java party because the party was over before they showed up (talking about AAA here, if you are writing a Mario clone in 2015 it doesn't really matter what tech you are using).

 

The Java/C# way of approaching abstractions is now "not cool" because we live in very different times.. computers are not getting faster, they're getting actually smaller and slower.. they have more cores and multithread requirements hit us like a rock.. devs had to start worrying about things like battery life.. at that point, the cost of a virtual machine started to loose it's appeal. We're now back in a situation where devs need to fight for every cpu cycle, care about memory to CPU transfer times, caches and so on.. abstraction over these things is not an option anymore.

 

And so you see the shifts.. Microsoft shying away from C# to embrace C++ and similar trends all around the software industry.. the very fact that C++ got such a deep revamp and went into overdrive mode wrt updates is also a sign.

 

All this gave to the "Mike Actons" of the industry the big chance to get out of their labs and proudly claim "see! I told you so!"... my very personal opinion is that they're just naturally inclined to resist changes, but, this time around, they got lucky and history worked in their favor.

 

At the end of the day, OOP is now seen as "uncool" because it doesn't solve the big problems of today's high performance software: parallelism and data locality. But that doesn't mean we should stop use it where it makes perfect sense (ie.. gameplay code). A smart programmer should be able to understand where it's right to use one paradigm or another.. rewriting your basic "GameObject" system because you think your few thousands pointers are slowing your game down and that, by rewriting it DOD will give you 20fps because some dude on the internet said so, is not really a smart thing to do.




#5204983 [Car Physics] Turbochargers and friends

Posted by kunos on 17 January 2015 - 06:23 PM

 


You are right about the clutch pack differential, it doesn't turn into an "open" diff.. the clutches are still engaged creating friction... it's just that the difference of torque in the system is bigger than the clutches friction and the diff starts to slip.. but it doesn't turn into an open diff.

 

Ok, but it makes me confused, if I take the salisbury diff (everybody wants a Lotus49 smile.png )

I more or less understand the concept of the ramp angles and how to derive torque bias ratios, but there are still clutches that provide the locking, and when it comes to exact figures I feel lost.

 

Example:

The wheels have 100Nm and 300Nm road torques, that is 3:1 ratio, if we have a diff with 2:1 bias ratio, in this case it would "open".

And then with the same diff if the wheels have 20Nm and 60Nm, that is still 3:1 ratio, and would "open" again.

But, in the first case the clutches could resist 100Nm torque difference and in the second the same clutches slip at 40Nm difference.

Somehow I have problem with this smile.png

 

 

mah I don't really think about bias. I have an open diff, to make a salisbury I just calculate the slip between the diff cage and the arms and apply friction from the clutches based on that, it all works out by itself.

In your example, the reason why you'll have "only" 40Nm from the clutches is explained by the fact that, in order to have 20Nm+60Nm coming as reaction torque, it is likely your engine torque is also around that value.. thus the force trying to push the clutches against the housing is less than the force in your previous example with 100,300Nm... so it all balances out at the end.

 

BTW, great stuff both of you. Are you using some game engine for your things or custom code? Are you looking for a job perhaps? :P




#5204496 [Car Physics] Turbochargers and friends

Posted by kunos on 15 January 2015 - 09:44 AM

In netKar PRO I did it the "hard core" way.. had a turbo with its own RPM, inertia and so on.. exhaust spins the turbo, that produces pressure that goes into the engine. The relationship between torque and pressure is basically linear.. 2 bar = twice the torque, nothing complex there.

For Assetto Corsa things are much easier because the data to feed into the "complex" system I had in netKar is basically impossible to find.. so, at the of the day what you have is the max boost for a car and the amount of lag in the system.. which is how AC is modelling it.. much easier to get to the target result quickly and more effectively.

The blow off valve protects the engine intake.. when you close the gas you close the intake, but the turbo is still spinning and pushing air through the intake that now is closed or half closed.. this generates huge pressure that needs to be eliminated to avoid damage.. that is where the valve opens to relieve the pressure.

An easy way to model it is to have an amount of pressure that can be handled by the intake as function of gas pedal position.. if the pressure is higher than that.. the valve opens.

 

You are right about the clutch pack differential, it doesn't turn into an "open" diff.. the clutches are still engaged creating friction... it's just that the difference of torque in the system is bigger than the clutches friction and the diff starts to slip.. but it doesn't turn into an open diff.




#5167097 Is c++ good

Posted by kunos on 16 July 2014 - 01:43 AM

One thing I find "difficult" dealing with C++ is that it is a big big monster with different heads. You say "C++" but which one? Every C++ codebase I have come across uses a different subset of the language, completely different coding styles and guidelines.. and the more they add to the language the more this become evident.

More modern languages seem to have a better appreciation about coding standards and the importance to promote a clear style that identifies a language. Java comes with a style both "visually" (where the braces go, how you name things, which case you use) and logically.. with the standard library promoting that style. C# is even more on the same line.. Go is forcing the idea of "the one true way to Go". I have been writing C++ for almost 20 years.. I look at Unreal Engine 4 and my eyes hurt... it;s not nice and it wouldn't happen in a more modern language.




#5166707 Game doesn't crash if currently printing

Posted by kunos on 14 July 2014 - 05:22 AM

I agree with LennyLen.. you HAVE a bug, and you are lucky enough to have found a way to reproduce it reliably. Moving things around will just hide the bug..it'll be back, on some of your users' PC and you will have no way to fix it. Fix it NOW that you can see it.




#5164212 In need on some guidance.

Posted by kunos on 01 July 2014 - 09:06 PM

they are all irrelevant.

Just choose whatever you want and get going.. these are not "issues", they are just excuses to faff around.




#5164209 Problems passing an XMFLOAT4 to a shader

Posted by kunos on 01 July 2014 - 08:54 PM

Oh maybe you have missed my edit.

You need to bind the CB to the PS with PSSetConstantBuffers because that is where you are using image_alpha.




#5164202 Problems passing an XMFLOAT4 to a shader

Posted by kunos on 01 July 2014 - 08:41 PM

This is one of the few areas in DX11 where the same operation can be performed in 2 ways:

 

UpdateSubresource

You need these flags:

cbDesc.Usage = D3D11_USAGE_DEFAULT;
cbDesc.CPUAccessFlags = 0;
 
Map/Unmap
cbDesc.Usage = D3D11_USAGE_DYNAMIC;
cbDesc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
 
I have benchmarked these 2 and got no substantial difference.. so in my code I am using Map/Unmap simply because it looks more clear to me, especially the buffer creation flags.
The code is something like:
D3D11_MAPPED_SUBRESOURCE MappedResource;
context->Map(buffer, 0, D3D11_MAP_WRITE_DISCARD, 0, &MappedResource);
 
memcpy(MappedResource.pData, bdata, bsize);
 
context->Unmap(buffer, 0);
 
Instead of a single call to UpdateSubresource.
 
I think your problem might be that you are binding the CB for the VS, if you are using it in your PS, you need PSSetConstantBuffers.
 



#5163539 I've got problems with interviews

Posted by kunos on 28 June 2014 - 06:41 PM

if you really detect a pattern in your interviews you should treat it just as you treat any other programming problem you have solved: work on it.

Sadly you cannot make the rules, even if you think the rules are stupid, you either play by the rules or stay in KFC.

I can assure you that once you get hired the first time everything becomes easier.

It should be quite easy to find these kind of interview-like tests on the internet.. force yourself to work on these 1 hour a day and eventually you will get better and land your software dev job... I am sure it'll also widen your horizons and give you different perspectives on things in the process.




#5163417 An good game engines for 3rd person shooter

Posted by kunos on 28 June 2014 - 04:54 AM

The answer is: all of them.

The real bottleneck is you.




#5163221 Vector Efficiency question

Posted by kunos on 27 June 2014 - 06:25 AM

The reason to put object in a list is to allow fast iterations of common operations.

If you need operation on a "player".. then you should have a Object* player; Object* ground; and so on.. having to go through a list to find a object EVERY TIME makes no sense, and having a list without performing common operations on that list doesn't make sense.

 

Unless it's a VERY rare occurrence, it should never be necessary to retrieve an element from a list, by name, in the game loop.

 

In other words.. if you are retrieving an object by name "hundreds" of time in a frame, you are doing it wrong, map or no map.




#5163144 Help Engine

Posted by kunos on 26 June 2014 - 09:26 PM

In general people seem to agree that Unity is the easiest engine to work with... I agree with that too.






PARTNERS