|
oahda
|
 |
« Reply #500 on: January 28, 2016, 04:02:58 AM » |
|
I know I've referenced LazyFoo before on SDL stuff. SDL2 was pretty badly documented when it was new, but it seems to be okay now. 55 lessons is quite impressive!
|
|
|
|
|
Logged
|
|
|
|
|
gimymblert
|
|
« Reply #501 on: January 28, 2016, 06:30:27 AM » |
|
Great post Princessa!
|
|
|
|
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #502 on: January 28, 2016, 06:35:26 AM » |
|
\o/
|
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #503 on: January 28, 2016, 07:53:02 AM » |
|
+1. Completely agree with everything in that whole post. Especially the philosophies.  Only thing I'd suggest is that if you are targeting consoles then modern C++ needs to be handled carefully. You may even need an STL replacement in some cases. Between platform support and keeping it simple I try to not use C++ features if I don't have to. Often this means I end up writing "C+" aka C with namespaces. |
|
|
|
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #504 on: January 28, 2016, 07:57:04 AM » |
|
Oh, right. Didn't think of consoles. I sort of... expected the ones that do use C++ to have caught up at this time as well, I guess. Is there somewhere I can look up exactly what language and version that gets used for, say, Wii U (I think I've heard that's C++?), 3DS (C or C++?), PlayStation 3/4 (C++?) and Xbone (C#?)?
|
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #505 on: January 28, 2016, 08:06:57 AM » |
|
Oh, right. Didn't think of consoles. I sort of... expected the ones that do use C++ to have caught up at this time as well, I guess. Is there somewhere I can look up exactly what language and version that gets used for, say, Wii U (I think I've heard that's C++?), 3DS (C or C++?), PlayStation 3/4 (C++?) and Xbone (C#?)?
I think probably not due to SDK NDA's The problem with the consoles is many of the modern ones will claim to use modern c++ but then you find out there's some part of STL or C++ feature they don't support or even worse they do support it but their native library function that does something similar is WAY faster. So you really limit your performance if you use the STL (if they even support it). |
|
|
|
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #506 on: January 28, 2016, 08:10:06 AM » |
|
I wonder what the easiest workaround would be... Lightweight wrappers that #ifdef the current system and declare members of the right kind and provide a portable interface? Sure is a lot a better than #ifdefing every time you need to use a container...
|
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #507 on: January 28, 2016, 08:11:41 AM » |
|
A common thing to do is handle that stuff in your build system. One header then N cpp files. Unfortunately due to how differently the consoles function you will probably end up with 2 headers though (the general and a specific).
|
|
|
|
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #508 on: January 28, 2016, 08:16:09 AM » |
|
I think I'll just stay away from consoles for now. I've always preferred them to PC's when it comes to playing, but developing for PC's is a lot nicer... Plus with gamepad support these days it can be made to feel like a console game anyway.
Not worth it to be tied to a silly NDA and perhaps a cost, and the risk that the console becomes obsolete before the game is finished, until I already have a nearly finished game and know the current consoles and their languages at that time and can evaluate whether it's worthwhile or even possible to fix the engine up to support them without too much of a hassle.
|
|
|
|
« Last Edit: January 28, 2016, 08:27:15 AM by Prinsessa »
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #509 on: January 28, 2016, 08:20:36 AM » |
|
That's a good idea. Unless I already had some deal with a console maker I would do the same. Deploying and testing on consoles is a huge pain compared to the wonderfulness of a PC.
It's really too bad modern consoles can't just be used as devkits by anyone.
|
|
|
|
|
Logged
|
|
|
|
Polly
Level 6
|
|
« Reply #510 on: January 28, 2016, 08:23:43 AM » |
|
Only thing I'd suggest is that if you are targeting consoles then modern C++ needs to be handled carefully. You may even need an STL replacement in some cases. Between platform support and keeping it simple I try to not use C++ features if I don't have to. Agreed! Orthodox C++ for the win  |
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #511 on: January 28, 2016, 08:28:56 AM » |
|
Only thing I'd suggest is that if you are targeting consoles then modern C++ needs to be handled carefully. You may even need an STL replacement in some cases. Between platform support and keeping it simple I try to not use C++ features if I don't have to. Agreed! Orthodox C++ for the win I never knew it had a proper name haha. Also holy shit, that example of Boost::Geometry on what not to do is a nightmare. If you were to paste that in a post here I would have thought it was a joke. |
|
|
|
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #512 on: January 28, 2016, 08:32:23 AM » |
|
It's a funny idea, but I'm enjoying the newer features of C++ way too much to ever do something like that...  Also if I wait even longer before I ever attempt making my engine support consolse, hopefully their API's will have been modernised as well by the time I do so... |
|
|
|
|
Logged
|
|
|
|
|
Cheezmeister
|
|
« Reply #513 on: January 28, 2016, 11:50:48 PM » |
|
Also holy shit, that example of Boost::Geometry on what not to do is a nightmare. If you were to paste that in a post here I would have thought it was a joke.
Thanks for pointing that out. I glossed over it and almost missed out on a good laugh! Seriously, how does double distance(mypoint const& a, mypoint const& b) turn into template <typename G1, typename G2>
inline typename distance_result<G1, G2>::type distance(G1 const& g1, G2 const& g2). Where did we go wrong!? |
|
|
|
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #514 on: January 29, 2016, 02:48:16 AM » |
|
I'm still a bit tripped up by inline because some people sort of seem to suggest that it's never necessary, or might even slow things down..? I use it for functions like these for now since I've heard so many conflicting opinions instead of facts, but it would be nice to finally know for sure... I use a template for that function in my engine too but only one type and not some weird "distance_result::type"; I just return T...  |
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #515 on: January 29, 2016, 05:51:59 AM » |
|
inline is a funny keyword. It's generally best not to try to make that optimization up front. Of course it's required for avoiding multiple symbol definition errors in some cases so it does have a purpose. There are os-specific inline macros that can be a "stronger" suggestion (lol) like __FORCE_INLINE but don't worry about it.
|
|
|
|
|
Logged
|
|
|
|
|
ProgramGamer
|
|
« Reply #516 on: January 29, 2016, 05:56:42 AM » |
|
One thing's for sure, you can never make an inline recursive function.
Seems to be more of an optimization tool than anything though. What cases exist where that would be necessary?
|
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #517 on: January 29, 2016, 05:58:32 AM » |
|
One thing's for sure, you can never make an inline recursive function.
Seems to be more of an optimization tool than anything though. What cases exist where that would be necessary?
The one I listed in my previous post is the only one I can think of offhand. Avoiding a multiple symbol error for a definition in a header in namespace scope. I think in some cases you technically can have an inline recursive function depending on how it's written. |
|
|
|
« Last Edit: January 29, 2016, 06:07:52 AM by InfiniteStateMachine »
|
Logged
|
|
|
|
|
oahda
|
|
« Reply #518 on: January 29, 2016, 06:26:33 AM » |
|
Can't you just fix the multiple definitons with a header guard anyway?
|
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
|
« Reply #519 on: January 29, 2016, 06:33:53 AM » |
|
Can't you just fix the multiple definitons with a header guard anyway?
That's a different issue and you should always include a header guard. I remember thinking the same thing every time I run into the problem. The issue is that before that work is done it appears multiple times in different compilation units if it isn't inlined. Guards only protect for the same translation unit. Here's a stack overflow on the subject. Look at the second response. http://stackoverflow.com/questions/14425262/why-include-guards-do-not-prevent-multiple-function-definitions |
|
|
|
|
Logged
|
|
|
|
|
Developer
