ooooooops I missed the B (joke not intended)

Garbage collection is a travesty, and an abomination.

Well, technically C and C++ are high level languages.

But honestly, I was at day 22 up to last week and had to take a break and again my problem with the code is not being low level abstraction but how messy things are.

I hope the core game code is more encapsulated and structured than the platform layer.

Is it?

It's not very messy at all, it's a work in progress, for educational purposes. And even for me who never wrote C++, it's easy to read. If not, it must be because one does not understand what the code does. But that is imo a diffrent matter.

ThadeuMelo

But honestly, I was at day 22 up to last week and had to take a break and again my problem with the code is not being low level abstraction but how messy things are.

I hope the core game code is more encapsulated and structured than the platform layer.

Is it?

Yes, currently the game code is a little more structured than the platform layer. But keep in mind that things are constantly evolving. Like Casey says, we're in exploration mode so thinking about the higher structural layout is just a waste of time right now.

nofoam
Garbage collection is a travesty, and an abomination.

I'll bite.

GC does what it's designed to do, and works just fine. It's just that languages based on GC are used in ways GC is not suitable for.

GC doesn't work for me. It deletes variables that I need and causes my game/program to crash. I experience this with multiple GC in Different languages and it's horrible. I'll just rather do it myself.

GC never deletes variables that you use. It only frees memory from variables that are not accessible from any place. You simply have a bug in your code if your program crashes. It would be like blaming free function in C because it deallocated memory while you still want to access its contents afterwards.

I used to think C++ was a very nice language. That changed when I tried to make a game.

Personally, I think you're not giving enough credit to Casey and other programmers like him. Their views are often backed by years of hard learned lessons/experience that are difficult to fully enumerate or for someone else to fully appreciate unless they've been there themselves.

In my own experience, high level language features are very alluring and enticing at first glance. But more and more, I've come to realize that the vast majority of these features simply do not assist me in my job (or if they do help, they come with massive negatives that aren't apparent until working with them over the long term).

Many people tout "high level", "abstraction", "generality" as good things. In some sense, I might agree, but the fact of the matter is that at the end of the day I need to get things done and I need to get the CPU to do things that I want it to do. Many high level programming languages seem to forget this fact and introduce incredible amounts of overhead (typing overhead, programmer thought overhead, performance overhead...) to get the CPU to do things I know I can do much more simply and effectively through other means.

It really isn't about "hating abstractions" just because. Through our experience, we've found that the abstractions being sold to us by these languages simply do not help us do our jobs. They claim X, Y, Z, but we've found not X, Y, or Z and instead found U, V, W which are worse. Of course, it depends specifically on which features you're talking about and it even matters who is looking at them since not everyone thinks the same thing about different features.

If the abstractions being used in these languages actually did what they claimed to do, I think game programmers would be less likely to have a negative attitude about them.

DaleKim
I used to think C++ was a very nice language. That changed when I tried to make a game.

Similarly, I used to think that C++ was a bloated mess, and that changed when I wrote my first serious application (which wasn't a game).

DaleKim
In my own experience, high level language features are very alluring and enticing at first glance.

I don't think you can talk about "high level language features" as if all high level language features are a monolithic entity. The question, to my mind, is one of impedance match. The high-level features of C++ are far from perfect (which is one of the reasons why the standards committee keeps tinkering with them and adding stuff to ameliorate the problems caused by the last round of standardisation), but they are actually pretty good at what they do.

Unfortunately, what they don't do is what game devs want them to do. The features you want (e.g. reflection and reification) aren't there, and the features you have (e.g. inheritance) just aren't that useful.

I've worked in a lot of fields, but the two I want to highlight are visual effects and bioinformatics. I worked in visual effects some time ago. The one feature of C++ which helped enormously was namespaces (and by extension, classes-as-modules). Keeping namespaces clean is a "must have" on any medium-to-large-sized code base. Abstract base classes helped a bit, but we honestly could have done without them.

When I was working in bioinformatics, however, many of the high-level C++ features saved my bacon more than once. Yes, that includes templates; template metaprogramming was an excellent fit for the complex data modelling and advanced data structure work that we needed to do there. And when you aren't entirely sure what high-level problem you're solving (which is all too often the case when it comes to biology), being able to piece together reusable high-level components in different ways helps a lot.

The high-level features of C++ were developed for reasons. Like any system which evolved, there's a lot of cruft. However, all that stuff was added to solve real problems, just not necessarily the problems that you are trying to solve.

mmozeiko
GC never deletes variables that you use. It only frees memory from variables that are not accessible from any place. You simply have a bug in your code if your program crashes. It would be like blaming free function in C because it deallocated memory while you still want to access its contents afterwards.

my code was not complicated at all it was class like
public class seesharap
{
public int myint;
};

then I create the class and call it.


SeeSharap a = new SeeSharap();

then I would try to access it some where in the code

a.myint = 4;

crashed.

I also tried in Objective C and Coco2dx

class Gameobject {
CCSprite* cc;
}

cc = CCSprite::create("test");

some where in the code I try to access it some where in the class....crash

maybe because it doesn't do an memory alloc and it's on the stack?

in objective c you can define your variable's property to retain but if you try to something like NSString* var = NSStringWith...in a function you can't access it unless you do it in the same function.


I have done games in both C and C++ and find no annoyance with it, I don't have to worry about my game lagging because the garbage collector is working and like Casey said games should always maintain a steady frame rate but it won't if you have stuff going around in the background.

I'm not very familiar with memory management in ObjectiveC, but in C# there is no way such code will crash. Unless of course you assign "null" to variable a before accessing myint member (but that's equivalent to freeing memory). 100% there was some other bug in your code that you mistook for bad GC behavior.

DaleKim

Personally, I think you're not giving enough credit to Casey and other programmers like him. Their views are often backed by years of hard learned lessons/experience that are difficult to fully enumerate or for someone else to fully appreciate unless they've been there themselves.

This couldn't be more true. You point out one of the biggest problems. That it takes a shitload of effort to even get to the point where you can discover or understand many of the nonobvious problems, that are presented in the stream. So it's often very hard to communicate efficiently across those barriers.

Casey seems to have the skills, the experience, the attitude and the disiplin, and also the communication skills for doing it.

But maybe he is moving too fast for beginners? Idk, I just remember 30 years back, printing out code to analyze it. Today I dont need that. And I don't need to spend much time with the things Casey shows in the stream either. But when I was a beginner, maybe it would have been different? Guess someone that is a beginner will have to comment on that.

C0D3


I also tried in Objective C and Coco2dx

class Gameobject {
CCSprite* cc;
}

cc = CCSprite::create("test");

some where in the code I try to access it some where in the class....crash

maybe because it doesn't do an memory alloc and it's on the stack?

in objective c you can define your variable's property to retain but if you try to something like NSString* var = NSStringWith...in a function you can't access it unless you do it in the same function.

If you're specifying retain on your Objective-C objects, then you're not using ARC, and thus no memory management. ARC won't allow you to send retain/release messages, which means you have it turned off.

Basically, ARC works by inserting retain and release for you so you don't have to keep track of the reference counts (most of the time at least).

The other important thing about ARC in Obj-C is to be aware of strong and weak references. By default, any pointer to an object is strong unless it's declared weak, and as long as there is at least one strong reference to an object, it won't be deallocated by ARC.

OH WAIT A MIN, I made a mistake, I assumed that Unity C# and MS C# work the same way? I fixed that stupid problem by just declaring it static.

Thanks for the explanation. Isn't ARC on by default? I noticed I couldn't do NSString* mystr = [[NSString alloc] init... unless I change a compiler flag.

I'm not sure if Cocos2D has Garbage Collection on by default. Cocos2d version of Objective C's ARC is worst from what I heard about cocos2D garbage Collection.