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

Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

open-std.org

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#31

Post by mreiland »

yoklov wrote: post #8

The allocator support in C++11 and, from what I've seen, the proposed allocator support in C++1y/z/whatever still leaves a massive amount to be desired. Polymorphic allocators solve what's basically a non-problem for games (ABI boundary problems) while introducing huge other issues. Alignment is a PITA but not really a pressing IMO. The real issue is stuff like rebind and the requirements to call destructors (which d…

I'm not a game developer, but I experienced something similar to that when playing around with SFML. Their texture objects adhere to RIAA, so copy constructors will copy the texture from GPU memory to main memory, copy it to another location in main memory, re-upload it to GPU memory, then destroy the original texture and the memory it took up when copying to main memory.

I asked about it and the response I got was basically "It's RIAA, that's how you do C++". The worst part is they have a caching system underneath that tracks OGL handles across different objects, and it's even safe for access by threads.

But whoever designed their texture class chose not to use it.

So when I read your description I understand where you're coming from a bit. I'm not sure I understand why you couldn't just avoid using destructors, but I've honestly never tried to use a C++ allocator for anything as I've never needed control quite that tight for anything I do.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#32

Post by mreiland »

pavlov wrote: post #22
shin_lao wrote: post #20

Earlier quoted context omitted.

Could you explain why you think std::vector is useless?

Like I wrote in my comment, it doesn't seem to be used in the real-world projects and SDKs that I deal with.

Not if those projects/SDK's have to interface with C, but that's just the reality.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#33

Post by EpicEng »

NickPollard wrote: post #27
EpicEng wrote: post #12

Earlier quoted context omitted.

>It's certainly what most software people are working on, and it is probably where the plurality of the money is made. Not sure where you got those ideas, but they're not even remotely true. Enterprise, while boring as all hell, is _huge_. The largest software vendors are (consistently) Microsoft, Oracle, IBM, and SAP[1]. According to Gartner, software was a $407.3B industry in 2013, and enterprise driven companies a…

You misread that chart; The video game industry pulled in $887M in the US in One Month (February) of 2014. For scale, bear in mind that GTA5 made worldwide revenue of $1billion in it's first three days. If we go by Gartner[1], the games industry was predicted at $93billion in 2013. That's over 21%, so a couple of orders of magnitude more than 0.21%. [1]: http://www.gartner.com/newsroom/id/2614915

You're right; I can't tell where exactly that 407B number comers from. It's irrelevant though in the context of what I was refuting, i.e., the claim that "most" software devs are in the game industry, which is ridiculous.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#34

Post by yoklov »

mreiland wrote: post #31
yoklov wrote: post #8

The allocator support in C++11 and, from what I've seen, the proposed allocator support in C++1y/z/whatever still leaves a massive amount to be desired. Polymorphic allocators solve what's basically a non-problem for games (ABI boundary problems) while introducing huge other issues. Alignment is a PITA but not really a pressing IMO. The real issue is stuff like rebind and the requirements to call destructors (which d…

I'm not a game developer, but I experienced something similar to that when playing around with SFML. Their texture objects adhere to RIAA, so copy constructors will copy the texture from GPU memory to main memory, copy it to another location in main memory, re-upload it to GPU memory, then destroy the original texture and the memory it took up when copying to main memory. I asked about it and the response I got was b…

Well, you can avoid using desctructors, but then you can't use the majority of the STL, so what's the point? (This is basically what I do anyway)

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#35

Post by mreiland »

yoklov wrote: post #34
mreiland wrote: post #31

Earlier quoted context omitted.

I'm not a game developer, but I experienced something similar to that when playing around with SFML. Their texture objects adhere to RIAA, so copy constructors will copy the texture from GPU memory to main memory, copy it to another location in main memory, re-upload it to GPU memory, then destroy the original texture and the memory it took up when copying to main memory. I asked about it and the response I got was b…

Well, you can avoid using desctructors, but then you can't use the majority of the STL, so what's the point? (This is basically what I do anyway)

You don't have to tie resource lifetime to object lifetime, that's the mistake the SFML folks made.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#36

Post by panic »

yoklov wrote: post #26
panic wrote: post #17

Earlier quoted context omitted.

Games have been a huge driving force behind tech from the beginning. For example, Unix only exists because Ken Thompson wanted to port his game Space Travel to the PDP-7.

Is this true? That's a great piece of trivia if so.

Yeah, see http://en.wikipedia.org/wiki/Space_Travel_(video_game)

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#37

Post by JSnake »

fit2rule wrote: post #15
doctorpangloss wrote: post #3

It's actually kind of fascinating that the HN shortened title omits "games," which is really what this document focuses on. Specifically the document investigates "EASTL", i.e. the Electronic Arts STL, and how its learnings can be applied to the common STL. The actual title: "Towards improved support for games, graphics, real-time, low latency, embedded systems." These little pieces of censorship—that's not a sign th…

> censorship It is censorship in the sense that the original authors' intention is modified to exclude the 'game' factor, but then .. why is this happening in the first place? Why do you think the editing-OP decided to omit this aspect? > "pushed out of gaming" There are a couple of schools of thought about 'games programmers' and 'game systems' which can be plotted with wide variance, yet have some interesting point…

>Why do you think the editing-OP decided to omit this aspect?

I didn't.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#38

Post by yoklov »

mreiland wrote: post #35
yoklov wrote: post #34

Earlier quoted context omitted.

Well, you can avoid using desctructors, but then you can't use the majority of the STL, so what's the point? (This is basically what I do anyway)

You don't have to tie resource lifetime to object lifetime, that's the mistake the SFML folks made.

Right, my point is that I typically don't really want to tie memory lifetime to object lifetime either. So the whole of RAII is not a great fit, outside of a couple edge cases.

Re: Towards improved C++ support for games, graphics, real-time, embedded systems [pdf]

#39

Post by mreiland »

yoklov wrote: post #38
mreiland wrote: post #35

Earlier quoted context omitted.

You don't have to tie resource lifetime to object lifetime, that's the mistake the SFML folks made.

Right, my point is that I typically don't really want to tie memory lifetime to object lifetime either. So the whole of RAII is not a great fit, outside of a couple edge cases.

RAII is about resources, not memory. If you don't want to tie memory lifetime to object lifetime then don't. That's the entire point of things like smart pointers.

That's exactly the issue SFML had. This idea that RAII implies tying resources directly to an objects lifetime. It doesn't.

Post reply on HN