Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411276 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 11:02:42 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)General thread for quick questions
Pages: 1 ... 37 38 [39] 40 41 ... 69
Print
Author Topic: General thread for quick questions  (Read 132635 times)
oahda
Level 10
*****



View Profile
« Reply #760 on: July 11, 2016, 09:17:36 PM »

The good news is a lot of manufacturers are starting to go the route of clang so in the near future things should get a lot better.
I hope so!

The xboxone AFAIK is the same as the devkit.
That's a start! c:

What C++14 stuff do you use?
I've been partially inspired by this talk:





My engine requires a slightly more dynamic approach, so I can't go as wild with templates as this person did, but it can give you an idea of what I'm playing at. Basically trying to squeeze things into compiletime instead of runtime where I can.

Some of it is just sugar, like auto return types and auto lambda parameters, but I actually have a variadic foreach template to loop through and perform operations on the mixed type elements in a tuple which depends on an auto parameter in a lambda, and I'm fairly sure that would not work in C++11 at all. Maybe it could be rewritten somehow, trying to use the variadic parameters one by one instead, but I don't think so. At least not in a good way.

I'm using the type instead of index signatures of std::get which seem to be C++14 only. Might be possible to roll one's own in C++11. std::make_unique is easy to add manually at least. It does feel a little dirty to add custom stuff to the std namespace tho but if I don't put it there it kind of becomes forward (in)compatible in an ugly way, using custom stuff for things covered by STL in the next standard.

Haven't added that much stuff back yet into the new project, so I suspect I might find more neat uses along the way. It does make the code in general nicer at least.
« Last Edit: July 11, 2016, 09:38:44 PM by Prinsessa » Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #761 on: July 12, 2016, 07:24:37 PM »

Ah variadic templates are 14? I didnt realize that. I'll check out that video on one of my lunch hours.

I just started a new job where it's mandated to use modern c++ so it's about time I catch up Smiley
Logged

oahda
Level 10
*****



View Profile
« Reply #762 on: July 12, 2016, 09:10:33 PM »

Ah variadic templates are 14?
No, not the whole thing, but a few additional tidbits that can be quite useful.

I just started a new job where it's mandated to use modern c++ so it's about time I catch up Smiley
Yay for modern workplace!
Logged

JWki
Level 4
****


View Profile
« Reply #763 on: July 13, 2016, 06:04:09 AM »

Regarding the whole console topic, compilers for consoles are known for their bad support for modern c++, even when they support a feature they usually don't support it all too well - afaik, the last generation of consoles (xbox360, ps3) never got full C++11 support even.
Console developers tend to adopt modern C++ features only very carefully in general - usually console engines don't use exceptions, for example (well most game programmers don't use them on desktop either), because of various reasons, one of them being bad compiler support.
In general, when programming for a console, you have to embrace a different mindset than when programming for desktop - there's a reason why most console engines don't use the STL, either, at least not a big portion of it. It tends to have bad performance characteristics for console hardware - actually not the best characteristics for game programming in general, every container in there except for std::vector and those that use std::vector internally performs relatively bad for iteration and searching because of cache unfriendly memory layouts, which is somewhat better on x64/x86 because of more cache levels, but a real performance killer on last gen consoles and best to be avoided even on modern platforms - which is one of the factors that motivated Vitterios video that Prinsessa posted. However, templates in general are also avoided on consoles because compiler support for that isn't really top notch either, at least that's what I've been told about the last generation, I can imagine it's a bit better on the recent generation.

If your engine is really strongly dependend on modern C++ features, especially C++14 stuff, then you'll have a bad time porting it to a console platform unless that platform supports a recent version of the clang toolchain. At least from what I've gathered about compiler support on consoles. That's one of the reasons why veteran devs tend to avoid using all the newest features, because they have to care about all those platforms that don't support them.
Logged
Polly
Level 6
*



View Profile
« Reply #764 on: July 13, 2016, 06:22:55 AM »

In general, when programming for a console, you have to embrace a different mindset than when programming for desktop - there's a reason why most console engines don't use the STL, either, at least not a big portion of it. It tends to have bad performance characteristics for console hardware.

This Hand Thumbs Up Left On consoles you know exactly how much RAM you get to work with and which other processes are ( potentially ) running. It's a completely different situation from PC & mobile.
Logged
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #765 on: July 13, 2016, 07:27:41 AM »

Regarding the whole console topic, compilers for consoles are known for their bad support for modern c++, even when they support a feature they usually don't support it all too well - afaik, the last generation of consoles (xbox360, ps3) never got full C++11 support even.
Console developers tend to adopt modern C++ features only very carefully in general - usually console engines don't use exceptions, for example (well most game programmers don't use them on desktop either), because of various reasons, one of them being bad compiler support.
In general, when programming for a console, you have to embrace a different mindset than when programming for desktop - there's a reason why most console engines don't use the STL, either, at least not a big portion of it. It tends to have bad performance characteristics for console hardware - actually not the best characteristics for game programming in general, every container in there except for std::vector and those that use std::vector internally performs relatively bad for iteration and searching because of cache unfriendly memory layouts, which is somewhat better on x64/x86 because of more cache levels, but a real performance killer on last gen consoles and best to be avoided even on modern platforms - which is one of the factors that motivated Vitterios video that Prinsessa posted. However, templates in general are also avoided on consoles because compiler support for that isn't really top notch either, at least that's what I've been told about the last generation, I can imagine it's a bit better on the recent generation.

If your engine is really strongly dependend on modern C++ features, especially C++14 stuff, then you'll have a bad time porting it to a console platform unless that platform supports a recent version of the clang toolchain. At least from what I've gathered about compiler support on consoles. That's one of the reasons why veteran devs tend to avoid using all the newest features, because they have to care about all those platforms that don't support them.

True. Last gen definitely didn't really have much support.

Ps4 uses clang (just googled it and apparently it's public information). AFAIK it's pretty similar to standard clang if not exactly the same. I bet porting to ps4 would be relatively painless on the c++ front. I imagine the time consuming portion would be writing a libgcm platform layer for rendering/input etc.

http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain.pdf

Xbox obviously uses MSVC which IS improving quickly these days so outside of one other console it doesn't seem too bad Smiley

In regards to the STL. A lot of the reasons it isn't used are historical from when there was no guarantee that even a vector would be contiguous in memory (among other things). That's probably a motivating factor for things like EASTL and STLPort.
Logged

oahda
Level 10
*****



View Profile
« Reply #766 on: July 13, 2016, 07:49:05 AM »

Nintendo seemed to be using at least some STL stuff based on what little look I had at the docs before I realised it wasn't actually free.
Logged

JWki
Level 4
****


View Profile
« Reply #767 on: July 13, 2016, 08:24:34 AM »

Well yeah a lot of it is historical - but even today the STL often doesn't offer the level of control that console devs require - and that can matter on desktop as well by the way. For example, MSVCs implementation of the STL containers is particulary hideous - std::map for example, in Microsofts implementation, will allocate memory every time you call insert(), even when the element you're trying to insert already exists in the container (they allocate the node first, then try to insert it and free it if that fails) - and stuff like that shows up in the profiler. I think this example was something they found in Unitys render code during refactoring because it slowed down some code paths - Unity uses std::map for material property blocks or something like that.
It's unspecified behaviour like that which causes most game studios to maintain their own libraries instead of using STL (besides general not-invented-here syndrom).
Logged
InfiniteStateMachine
Level 10
*****



View Profile
« Reply #768 on: July 13, 2016, 07:19:49 PM »

Well there's that and the fact most game studios that don't use a third party engine couldn't afford to swap out their low level frameworks for stl.

I'm personally not a huge fan of the STL but it does have one very very important positive quality. It's standard Smiley


For the Unity thing. So windows performance was a lot worse due to MSVC's map implementation but other platforms didn't have that issue?
Logged

oahda
Level 10
*****



View Profile
« Reply #769 on: July 13, 2016, 08:46:22 PM »

Ugh, that's so annoying. Why are there even different implementations? It's like web development with its cross-incompatibilities all over again.
Logged

InfiniteStateMachine
Level 10
*****



View Profile
« Reply #770 on: July 13, 2016, 10:07:12 PM »

Yeah it's weird when you think about it. If it's written in C++ why would each compiler have a different implementation?

My guess would be that maybe MSVC had to implement theirs differently because they had template support issues earlier in the compilers life.

Another guess might be that the compiler writers implement some parts of STL in assembly. Although that sounds kind of silly if you spend all your time microptimizing while letting your actual algorithm go up in complexity.  Corny Laugh
 
Logged

JWki
Level 4
****


View Profile
« Reply #771 on: July 13, 2016, 11:13:45 PM »

I looked up the original post on Aras' site: http://aras-p.info/blog/2015/12/11/careful-with-that-stl-map-insert-eugene/
I left the URL raw because it's funny.
As a tl;dr: the behavior in question is not limited to msvc, on some xcode versions you get the same thing.
And to why there's multiple implementations, that's the same reason why there are multiple implementations of OpenGL or Vulkan -the C++ standard is only a spec, it's the responsibility of the compiler vendors to provide the implementation. And because that kinda sucks sometimes, there's stuff like stlport.
Logged
oahda
Level 10
*****



View Profile
« Reply #772 on: July 14, 2016, 12:00:22 AM »

I guess g++/MinGW is the only one that's sort of available everywhere (at least the three major computer systems)? Or are there others? I still use LLVM on OS X, tho...
Logged

JWki
Level 4
****


View Profile
« Reply #773 on: July 14, 2016, 01:26:30 AM »

Well the Clang toolchain can theoretically be compiled for Windows, and there's actually a feature in new Visual Studio versions that lets you use Clang as your compiler - I'm however not sure how experimental that still is. (Clang is the C/C++ frontend for LLVM). So you can use that on all three platforms somehow, and that'd actually be the better choice over GCC as Clang tends to support modern features sooner than all the others compilers, at least in the past, and also gives INCREDIBLY helpful error and warning messages - there's a reason Googles C++ ecosystem is all based around Clang. I'm not sure on how the quality of the produced assembly differs between GCC and Clang but I'd dare to say Clang may produce cleaner assembly however that's purely speculative.
I would love to be able to just use Clang everywhere out of the box as I still couldn't be bothered to try and get it running on Windows because I kinda hope with one of the next VS releases they'll introduce Clang as simple drop in option or something like that.
However, I can't comment on the quality of their STL implementation - that'd be libc++ I think? Never looked into that I tend to just generally avoid STL if I can. I've even written my own versions of std::vector before because I wanted something with a better allocation interface, however writing containers is pretty painful if you want to support non-POD types properly and exploit move semantics to their full potential. It takes a lot of testing to catch all kinds of corner cases and I might fall back to using at least std::vector, maybe with some custom allocators (even though STLs allocator interface is pretty insane and not in the good way).

Never use std::dequeue though. They took what should be a simple ringbuffer and made it something horrible.
Or std::map. There's std::unordered_map, the API is the same and it's always faster.
Or std::list.
And think carefully about whether you need dynamic strings in your project.
Logged
zilluss
Level 1
*



View Profile
« Reply #774 on: July 14, 2016, 01:44:41 AM »

VS 15 actually has an option "Clang 3.7 with Microsoft Codegen".
As for the STL stuff: there's a Github project from EA that contains a lot of alternatives for STL classes, programmed with consoles in mind: https://github.com/electronicarts/EASTL
Logged

@zilluss | Devlog  Hand Point Right
JWki
Level 4
****


View Profile
« Reply #775 on: July 14, 2016, 02:25:12 AM »

VS 15 actually has an option "Clang 3.7 with Microsoft Codegen".

Ah I didn't know they already put that option in in the release version. Gonna try it next time I setup a smaller project.
Logged
oahda
Level 10
*****



View Profile
« Reply #776 on: July 14, 2016, 02:32:09 AM »

Right, I just remembered why I use LLVM on Mac: stuff might depend on Cocoa (or w/e) Obj-C things here and there.
Logged

oahda
Level 10
*****



View Profile
« Reply #777 on: July 14, 2016, 07:57:36 AM »

Anybody savvy on Emscripten and using C++ for WebGL? Any gotchas? Can I convert just about anything? Just... info. I'll be reading online of course, so I'm mostly just wondering about your personal stories or impressions. And as always my most important question will be: does it do C++14?

EDIT: Can answer the last question myself now after trying it out: C++14 works just fine. Hand Thumbs Up Right
« Last Edit: July 16, 2016, 11:53:55 PM by Prinsessa » Logged

oahda
Level 10
*****



View Profile
« Reply #778 on: July 16, 2016, 11:57:44 PM »

So I've been wanting for a long time to offer a cloud service for my game to make it possible to stop playing on any device and pick the game up again on another. Today I found out about Google's cloud service Saved Games, which does seem to work not just on Android with a Java API and iOS with an Objective-C API, but any application—PC, mobile, w/e—that uses C++ thanks to that version of the API.

But maybe that's just a common C++ API for mobile and won't work properly on games for PC (or consoles..?) even tho they use C++? I'm getting the impression that it would work (at least on PC, maybe not consoles?), but I can't find any loud and clear yes anywhere. So I'm asking here. Does anybody know, who can give me that unambiguous and clear yes (or no...)?
Logged

dlan
Level 1
*



View Profile
« Reply #779 on: July 17, 2016, 04:05:44 AM »

Anybody savvy on Emscripten and using C++ for WebGL? Any gotchas? Can I convert just about anything?

Off the top of my head based on the port of my C engine, here's the obstacles when using Emscripten:

- No thread support, there is an experimental support for pthread available, but it's only working with firefox nightly. Web worker could serve as an alternative, but it forbid any state sharing between thread, and you have to compile the code you want to run in parallel separately from your main application.

- The default filesystem is read only. you have to use a specific filesystem named IDBFS if you want to save data on user browser local storage. Also, load / write operation work asynchronously in this case, so you will have to refactor your code to take that in account.

- The download and the loading of the generated javascript + the assets file could take a long time, The main bottleneck is usually the time needed to dowload and execute the javascript file, since it could be dozen of Mo, even with all optimisation on, The asset file, which basically contains your entire filesystem must be loaded entirely before execution. There is some way of streaming assets explained in the Emscripten documentation (Synchronous-Virtual-XHR-Backed-File-System-Usage) but that require a bit of setup on the server part to make it work.

- Few oddities with SDL_audio / Webaudio, had trouble making the sound work properly if the SDL stream parameters where different from the audio card setup (difference in sample frequencies) SDL conversion didn't work well.

- When it come to WebGL, as long as you are sticking to OpenGLES 2 / GLSL version 100, you should be fine. The only oddity I remember is that WebGL is less forgiving when it come to texture size, had texture that failed to load on WebGL that actually work fine with Android GLES, I end up packing everything in a 2048*2048 texture to make the problem go away.

- By default, Emscripten use double for all floating point variables, could lead to rounding error in your code, more info here : FAQ rounding error float variables

There is probably more, but these are the main obstacles I ran into when I ported my code. I also played around with OpenFrameworks, and made a small application around it, mainly to try out the Javascript <-> C++ communication part, could be a good example to see how it work.
https://github.com/dlan-fr/ofLive

Also don't forget to look at the portability guideline on the Emscripten web site:

http://kripken.github.io/emscripten-site/docs/porting/guidelines/portability_guidelines.html

Edit:

Almost forgot about that, all you libraries must be statically linked to your main application, you can't use dynamic linking with Emscripten, which also rule out any dlopen call.
« Last Edit: July 17, 2016, 04:25:27 AM by dlan » Logged
Pages: 1 ... 37 38 [39] 40 41 ... 69
Print
Jump to:  

Theme orange-lt created by panic