Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sadly, I must say goodbye to Leaf, my programming language

mortoray.com

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Sadly, I must say goodbye to Leaf, my programming language

#101

Post by humanrebar »

hzhou321 wrote: post #55
Bekwnn wrote: post #26

Earlier quoted context omitted.

Games are still in need of a better language. I have some skepticism and hope for Jai. I really wish D as better C worked better in that realm, but it's missing a few crucial things. Rust asserts too much control over memory. I'm all ears for anything that's somewhere between C and C++ as an alternative to write games in. Most new languages just don't get the things right that C++ did, which is why despite it having…

Here is a direction if you are all ears : instead of a new language, add a new layer. I tried creating my own languages before, some 15 years ago. While I had fun writing compilers, I missed a lot more writing actual programs. One day I suddenly realized I don't really need new language, what I needed is simply context dependent syntax and code block organization, which can easily implemented on the spot. It become M…

How is MyDef not another language?

Re: Sadly, I must say goodbye to Leaf, my programming language

#102

Post by gmueckl »

foota wrote: post #35
pixelbash wrote: post #22

Earlier quoted context omitted.

Re the second point did you manage to get around this? Played with it a bit and it felt almost like flash back in the day where you could eschew the timeline and do everything programmatically. In the end ran into a problem where I wanted to move the universe around the player and couldn’t get the particle engine to cope..

Perhaps I'm missing something here, but you should just need to move the player in the opposite direction of the world's desired movement? No game system I'm aware does it the other way around, as it requires changing all the other models transforms. But yes, I am dealing with the interface, primarily by ignoring it. I'm still trying to get down the right way to organize my code, but it's making sense.

Once your game world size crosses a specific threshold, you need to move the world instead of the player because numerical accuracy starts to become troublesome (most engine code runs with floats, which gives about 6 decimal digits of precision). The first engine that I am aware of that did that was that of Dungeon Siege. There's an excellent post mortem around about the challenges of this approach.

Re: Sadly, I must say goodbye to Leaf, my programming language

#103

Post by akuji1993 »

dajomu wrote: post #97
hzhou321 wrote: post #55

Earlier quoted context omitted.

Here is a direction if you are all ears : instead of a new language, add a new layer. I tried creating my own languages before, some 15 years ago. While I had fun writing compilers, I missed a lot more writing actual programs. One day I suddenly realized I don't really need new language, what I needed is simply context dependent syntax and code block organization, which can easily implemented on the spot. It become M…

This sounds really interesting, can you provide a link so I can read some more about it?

This seems to be the Github repository for it: https://github.com/hzhou/MyDef

Re: Sadly, I must say goodbye to Leaf, my programming language

#104

Post by atilaneves »

Bekwnn wrote: post #62
nicwilson wrote: post #52

Earlier quoted context omitted.

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the way of use.

Under "unavailable features" https://dlang.org/spec/betterc.html#consequences 3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects. 3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still m…

That page should be updated.

I was suspicious about #3 since classes in D don't necessarily need the GC. For starters D supports C++ classes, so this works:

https://gist.github.com/atilaneves/b69ed0399efac21bb7a977afd...

I used `scope` with `new` to allocate on the stack, but `emplace` should just work as well to "placement new" a class in malloc'ed memory.

#4 is annoying but one could always use the OS threading API. It's doable to write a library solution to do that akin to boost or Qt before C++11. You do it once and it's there.

#5 No dynamic arrays are also annoying. But... writing a clone of std::vector isn't hard, and there's a unique array in my automem library that _should_ be usable in betterC (but I haven't checked): https://github.com/atilaneves/automem/blob/master/source/aut...

> Another note is that a big thing I'm looking for is massively improved compile times

You get that with D.

Re: Sadly, I must say goodbye to Leaf, my programming language

#105

Post by p0nce »

Bekwnn wrote: post #62
nicwilson wrote: post #52

Earlier quoted context omitted.

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the way of use.

Under "unavailable features" https://dlang.org/spec/betterc.html#consequences 3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects. 3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still m…

I have a smallish D game on Steam and trust me, you can absolutely use the D runtime instead of -betterC. -betterC is a work in progress and not representative of D.

You will say that you don't want a GC but in reality the GC can be optimized as much as you wan't, and in the mean time you'll get precious _developement time_ to optimize further.

If you can afford the D runtime by all means take it ; for some products I'm doing without the D runtime, and the surprise was that it did't make things any faster _at all_ without the runtime (we did it for other reasons). The only real gain is memory consumption of GC vs manual and that is achievable without going through extreme coercitive measures like -betterC.

Re: Sadly, I must say goodbye to Leaf, my programming language

#106

Post by p0nce »

makomk wrote: post #89
FeepingCreature wrote: post #72

Earlier quoted context omitted.

It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.

As I understand it, garbage collection is kind of a non-starter for games programming because it leads to unpredictable pauses in what should be a low-latency, interactive application.

Infognition has found that if you keep the D GC heap under 100k the max pauses will be about 1 ms. The means to reduce GC usage have only grown more diverse in recent years:

- std.experimental.allocator

- @nogc to ensure, well, no GC usage

- various things built on placement new (`emplace`)

- GC profiling with -profile=gc, will display number of allocations and size

None of this existed when people were already making high-performance systems with D...

Re: Sadly, I must say goodbye to Leaf, my programming language

#107

Post by axilmar »

C is a perfect language for writing games into; C++ has some extra sauce that makes some things easier, faster to write and more correct.

There is no actual need for a new language for writing games; that's why so many, including the author, give up. C/C++ has the 90% of what is needed to write any application, and the rest 10% is simply elusive and might not even exist.

Re: Sadly, I must say goodbye to Leaf, my programming language

#108

Post by qznc »

makomk wrote: post #89
FeepingCreature wrote: post #72

Earlier quoted context omitted.

It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.

As I understand it, garbage collection is kind of a non-starter for games programming because it leads to unpredictable pauses in what should be a low-latency, interactive application.

You can put the low-latency stuff in a non-gc thread which will not be interrupted [0] and still use the convenient garbage collector for the rest.

[0] https://p0nce.github.io/d-idioms/#The-impossible-real-time-t...

Re: Sadly, I must say goodbye to Leaf, my programming language

#109

Post by Philipp__ »

axilmar wrote: post #107

C is a perfect language for writing games into; C++ has some extra sauce that makes some things easier, faster to write and more correct. There is no actual need for a new language for writing games; that's why so many, including the author, give up. C/C++ has the 90% of what is needed to write any application, and the rest 10% is simply elusive and might not even exist.

Problem with C/C++ is maintaining and writing code. I am sure you are well aware of Jonathan Blow's efforts in writing Jai programming language. If not take a look at his Youtube channel. Pretty eye opening. (I am no game dev btw)

Re: Sadly, I must say goodbye to Leaf, my programming language

#110

Post by xxs »

makomk wrote: post #89
FeepingCreature wrote: post #72

Earlier quoted context omitted.

It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.

As I understand it, garbage collection is kind of a non-starter for games programming because it leads to unpredictable pauses in what should be a low-latency, interactive application.

You can have low pause, fully concurrent GC even in Java. A GC can utilize read barriers and overall eliminate stop-the-world pauses.

--- A popular example is minecraft that uses mainstream G1 GC.

Post reply on HN