Gaming Creating an ocean exploration simulator

There are definitively interesting things to do with acoustics, from a physics simulation point of view.

Thermal layers ? :P
 
(everything seems to be an object???)

Everything that isn't a primitive, but that's not really different from C++ (or any other language for that matter... hell, Java even wraps its primitives into objects for use in collections!).
The difference is that you can never access an object directly in C#, only by reference. Objects also only get passed by reference, so if you're coming from C++, you have to get used to explicitly copying stuff if you need duplicate data. As I said, I found it easiest to adapt if I think of anything not a primitive as a pointer. It's technically not quite correct, but it helps avoiding most common mistakes.
 
The difference is that you can never access an object directly in C#, only by reference. Objects also only get passed by reference, so if you're coming from C++, you have to get used to explicitly copying stuff if you need duplicate data.

Im not sure I follow all of that. Can you explain that a bit more, ie with a piece of code?
 
Im not sure I follow all of that. Can you explain that a bit more, ie with a piece of code?

Well, in C++, you could for example put a VECTOR3 into a vessel. when you create the vessel, memory for the VECTOR3 is automatically reserved together with the vessel.

Now, in C# or Java, objects are always references, so instead of reserving memory for the VECTOR3, you would reserve memory for a reference to an object of the class VECTOR3. You need to reserve memory for this class (or a subclass of it) manually (or let a factory class do that) and store a reference to that memory.

It is much like pointers or references in C++, but like Java, C# also has garbage collection: The references to a class can change and point to different memory locations, if needed, without the programmer having much control over it. When a class has no longer references on it, it is marked for disposal and will be removed from memory should the garbage collection clean up the next time. And contrary to C++, you can not prevent objects from being references (or pointers), they simply are by definition.

So in code:

Code:
class X {
};

class Y {
	X x;
};

class Z {
	X &x;
};

class Y has the X class object inside it and will reserve memory for it.
class Z has only a reference to an X class object.

In C# you would only be able of:

Code:
public class X {
};

public class Y {
	private X x;
};
 
Last edited:
Well, in C++, you could for example put a VECTOR3 into a vessel. when you create the vessel, memory for the VECTOR3 is automatically reserved together with the vessel.

Now, in C# or Java, objects are always references, so instead of reserving memory for the VECTOR3, you would reserve memory for a reference to an object of the class VECTOR3. You need to reserve memory for this class (or a subclass of it) manually (or let a factory class do that) and store a reference to that memory.

It is much like pointers or references in C++, but like Java, C# also has garbage collection: The references to a class can change and point to different memory locations, if needed, without the programmer having much control over it. When a class has no longer references on it, it is marked for disposal and will be removed from memory should the garbage collection clean up the next time. And contrary to C++, you can not prevent objects from being references (or pointers), they simply are by definition.

so in other words, everything not a primitive in C# is like an instance of std::unique_ptr? (save for that it only cleans itself up when the last scope to it is finished I think?)
 
so in other words, everything not a primitive in C# is like an instance of std::unique_ptr? (save for that it only cleans itself up when the last scope to it is finished I think?)

Much worse than that... much worse. Think of something also moving your classes in memory to free memory for larger objects.

Free your mind a bit of C++ there and only work with the concept.

For example, as other difference: All objects in C# and Java are derived automatically from the object Object. In C++, there is no generic superclass.
 
I suggest grabbing latest Unity 5 - it has image postprocessing like bloom effects, hdr rendering and displacements so you can easilly create for example fisheye effect.

Here is quick render after few minutes of playing:
 
Think of something also moving your classes in memory to free memory for larger objects.

Well, that's basically an STL vector... :lol:

Im not sure I follow all of that. Can you explain that a bit more, ie with a piece of code?

A simple demonstration:

Code:
MyObject object_one(myargs);
MyObject object_two;

object_two = object_one;
object_two.Clear();

This pseudocode in C++ would result in two separate objects with the same data, until you call Clear on object_two. Then object_two will still reserve its memory space, but it's data will be gone, while object_one remains unchanged.

Now figure this in C#, where everything's a reference:

Code:
MyObject object_one = new MyObject(myargs);      //note that you can't call the contructor directly without calling new. This is because this is in fact an uninitialised reference
MyObject object_two;

object_two = object_one;
object_two.Clear();

What we did now is allocate space for ONE MyObject, and created a reference object_one to it. Then we created a reference object_two, and aimed it at the same object as object_one. We did NOT allocate space for another object. When we cleared object_two, we also cleared object_one, because the two are references to the same data. So, intuitively, this feels a lot like:

Code:
MyObject *object_one = new MyObject(myargs);      
MyObject *object_two;

object_two = object_one;
object_two->Clear();

in C++. Except that in C#, that's the only way you have of doing it.
 
Last edited:
Well, that's basically an STL vector... :lol:

No, that is what a STL vector "may" do internally - but if you put a pointer into it, you can expect it to remain constant.
 
I know of course... otherwise its use would be rather limited.

Yeah - but thats different inside C# or Java. In Java, you have thus no pointer math at all, in C# there is just another compromise to combine both worlds and drive you crazy.
 
Yeah - but thats different inside C# or Java. In Java, you have thus no pointer math at all, in C# there is just another compromise to combine both worlds and drive you crazy.

Just looking at all this C# code with new everywhere makes my C++ brain do backflips. "No, wait, what are you doing, stop calling new, for the love of god STOP PLEASE" :lol:

But C# lessons aside, how are we going to store say a vessels global position (ie latitude & longitude) in our Unity app? I sense that we need to make the whole unity assemblage of physics objects & visual pieces like meshes a child of some class that we define, but Im not sure how to do that in Unity.
 
We're already sort of doing it:
Code:
public class BouyancyScript : MonoBehaviour {
You'd just change it to something like:
Code:
public class BouyancyScript : MonoBehaviour, DiverPhysObject {
(actually, Bouyancy would be part of the phys, so wouldn't be inheriting DiverPhysObject, but you get the point...)
It would probably take a fancy bit of thinking to get everything set up, but once its good it will work elegantly.

Now if you don't mind I think I'm going to go read the KSP dev blogs again. I have a feeling I'll be seeing a lot of the same problems in this project...
 
Code:
public class BouyancyScript : MonoBehaviour, DiverPhysObject {
(actually, Bouyancy would be part of the phys, so wouldn't be inheriting DiverPhysObject, but you get the point...)

Be aware that C# does not allow multiple class inheritence, in contrast to C++. You can't derive your BouyancyScript from both the MonoBehaviour and the DiverPhysObject class (if they ARE classes, that is).

What you can do, though, is defining multiple interfaces your class can implement. Something like this would work (of course depending on what Unity really offers):

Code:
public class BouyancyScript :  MonoBehaviour, IDiverPhysObject {
or
Code:
public class BouyancyScript : DiverPhysObject, IBehaviour{
 
Be aware that C# does not allow multiple class inheritence, in contrast to C++. You can't derive your BouyancyScript from both the MonoBehaviour and the DiverPhysObject class (if they ARE classes, that is).

What you can do, though, is defining multiple interfaces your class can implement. Something like this would work (of course depending on what Unity really offers):

Code:
public class BouyancyScript :  MonoBehaviour, IDiverPhysObject {
or
Code:
public class BouyancyScript : DiverPhysObject, IBehaviour{

And I take it that an interface is a distinct concept from a class?
 
And I take it that an interface is a distinct concept from a class?

Yes and no. In C++, interfaces would be just classes, because C++ does not know interfaces.

But practically, it is a different concept and in many other languages also a special language element.

Interfaces only describe the signatures of functions and properties, that a class must provide to implement this interface. An interface does not implement any of these functions or properties - it leaves it to the class that implements it.

But you can treat an interface like a class for calling such functions. You can not create an instance of an interface (with "new"), because every instance is considered abstract but you can assign any object to a reference of that interface, that implements the interface.
 
Last edited:
:nono: Guys, we don't have to program another simulator, why don't we just replace the Dg's model with a sub, change the textures of Titan and its atmosphere and use titan with orelux.:lol:
 
:nono: Guys, we don't have to program another simulator, why don't we just replace the Dg's model with a sub, change the textures of Titan and its atmosphere and use titan with orelux.:lol:

:lol:

tumblr_inline_ndx17ihAHY1qbtb7a.gif


Yes and no. In C++, interfaces would be just classes, because C++ does not know interfaces.

But practically, it is a different concept and in many other languages also a special language element.

Interfaces only describe the signatures of functions and properties, that a class must provide to implement this interface. An interface does not implement any of these functions or properties - it leaves it to the class that implements it.

But you can treat an interface like a class for calling such functions. You can not create an instance of an interface (with "new"), because every instance is considered abstract but you can assign any object to a reference of that interface, that implements the interface.

so an interface is kinda like a virtual class?

(ps, I am sorry for all of the C++ analogies. Its wired directly into my brain you know)
 
so an interface is kinda like a virtual class?

Not really. AFAIK, virtual classes are there to deal with the diamond problem introduced by multiple inheritance in C++.
If anything, it would be more like an all-abstract class. The class itself is abstract, and all its functions need to be abstract, too. It would also contain no fields, just methods.

But it is better to learn those C# concepts without constantly comparing it to C++.
 
Any objections to updating to Unity 5? Especially the fact that by using it, we also can use all engine features now, makes it really attractive to me.
 
Back
Top