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

Show HN: Crown – A flexible game engine written from scratch in C++

github.com

Post reply on HN
Print view View original

141–150 of 179 posts

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#141

Post by mhh__ »

typon wrote: post #112
Matthias247 wrote: post #95

Earlier quoted context omitted.

Some things that are not so nice about templates: - dozens to hundreds of compiler error lines for a single error, where it's hard to find out what the real problem is (IDEs often point to the wrong line) - Code is hard to follow. E.g. try to figure out from boost asio source code which code is actually used if if you do a async_read(socket). I personally gave up after the second level of template substitutions, and…

D has templates, yet their error messages seem fine for debugging what's going on.

That's because D's standard library doesn't use templates in the same way as the STL (No iterators, less policies). Also, D has is actually vaguely modern and has proper static reflection, static asserts and static if: Writing template constraints is easy, unlike C++ (even with Concepts/-lite)

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#142

Post by lj3 »

ryandrake wrote: post #94
badsectoracula wrote: post #10

Earlier quoted context omitted.

Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers, often with custom allocation schemes. The engine at the last game company i worked at, for example, had its own containers and memory allocator and allowed you to define the allocation category and pool per allocator and per object class (so, e.g., dynamic strings would be isolated to their own pool to…

> Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers This seems a little like cargo cultism. I wonder if any of these shops regularly measure the performance of their custom containers and compare with the standard library on a modern optimizing compiler and make a reasoned judgment that it's still currently worth the trade-offs to stick with their own s…

> I wonder if any of these shops regularly measure the performance of their custom containers

You don't know? Maybe you should find out before slinging around accusations of cargo cultism.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#143

Post by andrewmcwatters »

krapp wrote: post #77

I'm not trying to be too critical, but the first thing I look for whenever I come across a new game engine is an actual game implemented in it. Unfortunately, almost none of these engines ever seem to get around to providing a MVP.

Bingo. Designing a game engine that has no dogfood project(s) just portrays it has no applied use, and hasn't ran into issues with its own design before.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#144

Post by mhh__ »

teknico wrote: post #8

It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).

IMO, Go is not sane.

Rust, however is great.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#145

Post by ryandrake »

lj3 wrote: post #142
ryandrake wrote: post #94

Earlier quoted context omitted.

> Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers This seems a little like cargo cultism. I wonder if any of these shops regularly measure the performance of their custom containers and compare with the standard library on a modern optimizing compiler and make a reasoned judgment that it's still currently worth the trade-offs to stick with their own s…

> I wonder if any of these shops regularly measure the performance of their custom containers You don't know? Maybe you should find out before slinging around accusations of cargo cultism.

Of course I don't know--that's why I said "I wonder". I have, however, worked in non-game-developing companies who eschewed the standard library, and when pressed the argument boiled down to: someone who worked here long ago said the STL was slow and therefore we don't use it. I am _wondering_ if it's the same story at other companies.

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#148

Post by mendeza »

dbartolini wrote: post #118
B1narySunset wrote: post #97

How long have you been working on this engine for?

I started with game engines well before I put this project on github in 2012.

Can you recommend any resources/books to learn game engine development? I would love to implement a mini one where I can rapidly prototype AR applications :).

Re: Show HN: Crown – A flexible game engine written from scratch in C++

#149

Post by meheleventyone »

thehardsphere wrote: post #139
aphextron wrote: post #134

Earlier quoted context omitted.

> You end up with frequent stop-the-world garbage collection pauses that freeze the screen for seconds at a time. Play any Unity game on the PS4 and you'll see it frequently. This is a coding problem, not an engine problem. A game should have almost no dynamic resource allocation.

Then what about Unity leads everyone who uses it to allocate dynamically, somehow, on every platform but Windows? If everybody makes the same coding problem, and the common denominator is one of their dependencies, it makes you wonder what's wrong with the dependency.

If you're genuinely interest the developers of Inside have a great presentation on how they hit a stutter free 60fps on all platforms, PS4 included.

https://www.youtube.com/watch?v=mQ2KTRn4BMI

I don't know what projects you're referring to specifically on the PS4 but I'd suspect the difference comes down to hardware spec on the PC masking the issue, it probably being the primary platform and/or lack of time to work on optimisation for the port.

It's the use of C#, which generally written in a manner that creates garbage and lack of experience with programming games that causes many people who use it to go wild with allocations. Both intentionally and by accident. These days you can actually get pretty far before it's ever a problem on a gaming PC. Unity is also incredibly accessible so more people with less technical chops are programming games without even opening the profiler.

Post reply on HN