|
dizzywhip posted:Feel free to correct me if I'm wrong about any of this or if I'm doing something stupid -- like I said, I don't have a whole lot of experience with this sort of thing. Any resources on this subject to help me get up to speed would be really appreciated too, ideally not super long and dry if possible. Install macports, with it install pkg-config & SDL. You can then run 'sdl-config --cflags --libs' which spits out everything you need to feed to clang to compile SDL.
|
#
?
Mar 15, 2014 07:53
|
|
|
|
| # ? May 11, 2024 19:39 |
|
|
Okay, with everyone's help plus some more googling I uh...think I got the base SDL library working, at least on OS X. I'll need to set up a Windows build once everything's working. I ended up building SDL from source, configuring it with --enable-static and --disable-shared and installing it directly into a subfolder of my project directory. Then I used the generated sdl-config executable to get the correct flags for the compiler. It builds and runs fine now, so I just need to figure out how to do the same thing for SDL_image and SDL_mixer. This whole process has been pretty unpleasant, but at least it's a good learning experience. ZombieApostate posted:I already had a sizable project when I tried to organize everything into the project folder and it was a nightmare to move it all and make sure it was linking to the proper files again, so I wouldn't really say it's too early to worry about it. It isn't super complicated now, but it can be later. Yeah, this is exactly the sort of thing I want to avoid when I'm crunching to finish the game and there are a ton of files to deal with. As frustrating as it is right now, I imagine it would be several times worse at that point.
|
|
#
?
Mar 15, 2014 10:48
|
|
|
dizzywhip posted:I'm just getting started with making a game with C++/SDL2 and I'm struggling with getting my build system set up. I'm using Clang on OS X and I want to eventually deploy to both Windows and OS X, maybe Linux too I guess. I've written a good amount of C-related code, but it's always been in a context where the build system was already handled for me, so I've kind of skated by with a bare minimum of knowledge on how compiling, linking, and properly using third-party code in general work. - Licensing prohibits static linking (eg. LGPL). This isn't a problem anymore with SDL2 which switched to zlib licensing, since some platforms require static linking (eg. iOS). - They're normally distributed in that format, and are much easier to manage and update. To make a statically-linkable library you usually have to compile it from source yourself, which can be a huge PITA. - Compiling standalone C++ libraries yourself (eg. Boost) is an even bigger PITA as they require linking with the STD C++ lib and will need different versions for every config (Debug/Release/etc) and can't conflict with other C++ libraries. Luckily SDL2 is a C library so this isn't a concern. The build process should be the same in both cases, it's the library that's different (you have to compile it differently to make it static-link or dynamic-link). Programs can even use a mix of static/dynamic libraries. For distributing your code, you'll usually want to point other coders to the required libraries and let them set it up as necessary. Otherwise just include everything needed in your codebase, set up your build system appropriately, and save everyone the trouble (though it's usually frowned upon to have dependencies directly in your codebase since it can clutter your version control and people might need different versions/updates/platforms/etc.) For distributing your executable, if everything is statically-linked, you're good to go. If it's dynamically-linked then: - Windows: Just put the library DLLs next to the executable. Don't forget MingW/VS runtimes if necessary. - Mac OS X: Just put the library Frameworks in the App bundle of your executable. - Unix-likes: Global libraries rule, and users need to get them and set them up appropriately for their distro to run your executable. Most of the time this is done through the package manager which has all the common libraries (like SDL & co.), so just tell your users to get those and they should be set. Optimally you'd wanna wrap your game in a package too, so this whole dependencies/installation procedure is handled automatically, but this depends on how you're distributing it. Note that in this case you're at the whims of whatever library version the distros have, which isn't a problem 90% of the time, but watch out for that 10%. If you have some esoteric library not available in package managers, you'll have to point users to the website so they can set it up and configure it themselves.
|
|
#
?
Mar 15, 2014 16:50
|
|
|
SupSuper posted:- Unix-likes: Global libraries rule, and users need to get them and set them up appropriately for their distro to run your executable. Most of the time this is done through the package manager which has all the common libraries (like SDL & co.), so just tell your users to get those and they should be set. Optimally you'd wanna wrap your game in a package too, so this whole dependencies/installation procedure is handled automatically, but this depends on how you're distributing it. Note that in this case you're at the whims of whatever library version the distros have, which isn't a problem 90% of the time, but watch out for that 10%. If you have some esoteric library not available in package managers, you'll have to point users to the website so they can set it up and configure it themselves. As an alternative, you often see third-party libraries shipped with the main binary, and a wrapper script used to set LD_LIBRARY_PATH so that things are found. Especially for libraries that aren't strongly versioned, or which have meaningful compile-time flags, this can be a lot easier for users and yourself. It's also basically what's necessary if you want your own code to exist in a shared library anywhere, or take along middleware that is. Last I played games on Linux this is what was done for anything that wasn't extremely common, including libraries where a distro probably had *a* version of libfoo, but maybe they hadn't upgraded to libfoo-1.74 yet, or maybe they only offered one that was too new. If you have the source around for use in your Windows and Mac builds, I'd do this. You can use pretty much the same build mechanics as for Mac, and then have the wrapper script set LD_LIBRARY_PATH to include the directory containing the binary and ancillary libraries at startup. I lost many many precious weeks of my youth to loving around with Linux distro versioning and oh-you-didn't-compile-with-that-backend-gee-thanks, albeit not in a game context, and I'm now pretty firmly in the "bundle anything that's not totally standard" camp.
|
|
#
?
Mar 15, 2014 19:40
|
|
|
Thanks everyone for all your help. I'm starting to understand things much better now. The last hiccup that I'm running into is getting SDL_mixer to work. It builds fine, but during configuration it can't find any of the external libraries it uses to load different audio formats. For example:code:
|
|
#
?
Mar 16, 2014 05:25
|
|
|
If you're going to develop cross-platform, then you're really going to want to actually have the platforms you're developing for to test it on. If you try to develop a full-featured game in C/C++ and just trust that it runs, then I guarantee you that when you try running your cross-compiled executable on another platform, it will either not start or crash immediately because of some OS-specific thing you didn't know that you had to do, or because of some bug that was concealed by implementation differences.
|
|
#
?
Mar 16, 2014 10:33
|
|
|
Subjunctive posted:As an alternative, you often see third-party libraries shipped with the main binary, and a wrapper script used to set LD_LIBRARY_PATH so that things are found. Especially for libraries that aren't strongly versioned, or which have meaningful compile-time flags, this can be a lot easier for users and yourself. It's also basically what's necessary if you want your own code to exist in a shared library anywhere, or take along middleware that is. Last I played games on Linux this is what was done for anything that wasn't extremely common, including libraries where a distro probably had *a* version of libfoo, but maybe they hadn't upgraded to libfoo-1.74 yet, or maybe they only offered one that was too new. If you have the source around for use in your Windows and Mac builds, I'd do this. You can use pretty much the same build mechanics as for Mac, and then have the wrapper script set LD_LIBRARY_PATH to include the directory containing the binary and ancillary libraries at startup. 
|
|
#
?
Mar 16, 2014 19:15
|
|
|
Has anyone here used WebSockets and HTML5/JS to develop real time games? How did it work out? I want to develop an RTS and use HTML5 and JS to do it, but I have no idea how the networking will work out, or whether WebSockets is suitable for this kind if game.
|
|
#
?
Mar 17, 2014 12:52
|
|
|
Pseudo-God posted:Has anyone here used WebSockets and HTML5/JS to develop real time games? How did it work out? I want to develop an RTS and use HTML5 and JS to do it, but I have no idea how the networking will work out, or whether WebSockets is suitable for this kind if game. I had not heard of WebSockets. This changes things. Anyway, you'd be fine using it for your communication stack. It looks like it brings almost normal networking to javascript. The complicated bits will be on the server side. Specifically you'll have to have either a single process per game that coordinates between the different users (you'd tie the WebSocket from a user to this process using your server language) or you're going to need some interesting IPC going on. On the client side, I worry more about capturing the mouse for an RTS. The network programming on client is just a matter of sending updates from that user and processing updates from the server (from other users). How you package those updates is up to you.
|
|
#
?
Mar 17, 2014 14:31
|
|
|
TodPunk posted:I had not heard of WebSockets. This changes things. Anyway, you'd be fine using it for your communication stack. It looks like it brings almost normal networking to javascript. The complicated bits will be on the server side. Specifically you'll have to have either a single process per game that coordinates between the different users (you'd tie the WebSocket from a user to this process using your server language) or you're going to need some interesting IPC going on.
|
|
#
?
Mar 17, 2014 15:11
|
|
|
Pseudo-God posted:Has anyone here used WebSockets and HTML5/JS to develop real time games? How did it work out? I want to develop an RTS and use HTML5 and JS to do it, but I have no idea how the networking will work out, or whether WebSockets is suitable for this kind if game. I made a hilarious tech demo using websockets to feed vector drawing instructions to an HTML5 thin client, and the results were fast enough for a playable multiplayer experience. It's pretty fast. https://github.com/JohnEarnest/VectorLand https://github.com/JohnEarnest/VectorLand/tree/master/websockets
|
|
#
?
Mar 17, 2014 16:55
|
|
|
Apparently Unity 5 is going to be announced at GDC. Probably going to shoot for end of year release I would imagine. uGUI is in beta right under Unity 4.6 beta 5. Hopefully they don't pull a fast one and move uGUI into version 5.
|
|
#
?
Mar 17, 2014 19:12
|
|
|
xgalaxy posted:Apparently Unity 5 is going to be announced at GDC. Probably going to shoot for end of year release I would imagine. They won't move it to 5. It's a feature they promised for 4.X The leak only said the main features of 5 as far as we know are new lighting and shader stuff. Not as huge as 4's mecanim and directx 11 support IMO. edit: Looks like it's been officially announced DeathBySpoon posted:Unity 5 Revealed Calipark fucked around with this message at 00:01 on Mar 18, 2014 |
|
#
?
Mar 17, 2014 19:36
|
|
|
xgalaxy posted:Apparently Unity 5 is going to be announced at GDC. Probably going to shoot for end of year release I would imagine. At GDC now. The new GUI is 4.6 main feature. 5 preorders up now, list of stuff in slides so far: - 64 bit editor - physx upgrade - speed tree - navmesh improvements, mostly in the ui - macanim stuff - integrated advertisements api - new asset bundle building api - new audio system - webgl - ubershader - deferred renderer - HDR input pipeline And lots more now on their site. Will update if they say a date.
|
|
#
?
Mar 18, 2014 18:44
|
|
|
SpeedTree?? loving finally goddamn about time.
|
|
#
?
Mar 18, 2014 19:03
|
|
|
octan3 posted:5 preorders up now, list of stuff in slides so far: This is hands down the best news.
|
|
#
?
Mar 18, 2014 20:24
|
|
- physx upgrade
|
Yodzilla posted:SpeedTree?? loving finally goddamn about time. It sounded like it's really easy to import and use, unfortunately no demo of it was shown. As for a date for 4.6 and 5.0 - "I don't like giving out dates as we always find ourselves with work still to do when the date arrives" soooo sometime next year it is.
|
|
#
?
Mar 18, 2014 21:02
|
|
|
$600 limited time upgrade but I'm currently not spending money to buy a car in May/June.  quote:As for a date for 4.6 and 5.0 - "I don't like giving out dates as we always find ourselves with work still to do when the date arrives" soooo sometime next year it is.
|
|
#
?
Mar 18, 2014 21:34
|
|
|
Obsurveyor posted:Yeah, the "welp, it could happen at any time and then our special pricing is going away, hahahah suckers!" really sucks.  Last time (2012), Unity 4 went final in December. Seems reasonable to expect a similar timeframe this year.
|
|
#
?
Mar 18, 2014 22:57
|
|
|
Do they let you get hands on the new GUI at GDC? I'd be curious if it is still a generic version of NGUI or if it has been reworked completely. I also think its lame Unity doesn't at least give tentative dates. No developer likes to be pinned down for releases but it is silly not to at least say which quarter you are aiming for.
|
|
#
?
Mar 19, 2014 00:18
|
|
|
Obsurveyor posted:$600 limited time upgrade Is that only from 4, or is there also a deal from 3? I just dusted off my 3 license and haven't upgraded yet.
|
|
#
?
Mar 19, 2014 00:25
|
|
|
Subjunctive posted:Is that only from 4, or is there also a deal from 3? I just dusted off my 3 license and haven't upgraded yet. They said the $600 price for Unity 4 to Unity 5 is limited to when they start shipping Unity 5. I assume it goes up to $750 at that point. According to the site, 3 to 5 is $750 already, edit: oh and I think you get 4 immediately. Obsurveyor fucked around with this message at 00:34 on Mar 19, 2014 |
|
#
?
Mar 19, 2014 00:31
|
|
|
FuzzySlippers posted:Do they let you get hands on the new GUI at GDC? I'd be curious if it is still a generic version of NGUI or if it has been reworked completely. They said that the current version of the GUI is running at their booth but I'm not sure if it's something we can play with. I'll have a look tomorrow. I'm a 2dtk person myself so can't compare it to NGUI right now, it looked really easy to use but isn't going to have many components from the look of it. I'll have a look at NGUI tonight to compare if I do get to play with the new GUI stuff tomorrow.
|
|
#
?
Mar 19, 2014 00:54
|
|
|
octan3 posted:They said that the current version of the GUI is running at their booth but I'm not sure if it's something we can play with. I'll have a look tomorrow. The idea behind the first release new GUI is to get the framework and event system right. A lot of work has been spent in areas such as the layoutsytem, canvas batching, editor tools, performance, memory allocation considerations, and integration with mecanim. On top of this there are a number of components that will ship with the GUI such as buttons and sliders and scrollviews and some others. The framework for the GUI is designed in such a way as to be very easily extensible, so adding custom components should not be too difficult. The new UnityGUI shares some familiarity with NGUI (conceptually mostly), but is quite a different beast and has evolved in a different direction from what NGUI is. One of the things I'm quite happy about the new gui framework is that it provides a nice and common base that packages like DFGUI and NGUI can build upon. They can add and have their custom components, as well as custom workflows while still leveraging the new Unity things under the hood.
|
|
#
?
Mar 19, 2014 02:19
|
|
|
I'm hoping Unreal announces a new UDK for UE4 at GDC, with better terms for indies. Unity could use some competition IMO.
|
|
#
?
Mar 19, 2014 16:18
|
|
|
xgalaxy posted:I'm hoping Unreal announces a new UDK for UE4 at GDC, with better terms for indies. If they'd fix, we'd have a two horse race again, which'd be fantastic.
|
|
#
?
Mar 19, 2014 16:47
|
|
|
Shalinor posted:UDK's terms really aren't the issue, it's UDK's rigidity. It's a great engine if you're making an FPS or a 3rd person action game, but anything else is obnoxious as hell without source access. #gameenginehorserace 
|
|
#
?
Mar 19, 2014 16:52
|
|
|
Shalinor posted:UDK's terms really aren't the issue, it's UDK's rigidity. It's a great engine if you're making an FPS or a 3rd person action game, but anything else is obnoxious as hell without source access. Considering they are gutting UnrealScript entirely and moving to a C++ game DLL w/ Kismet I'm hopeful that the engine becomes more flexible towards different types of games.
|
|
#
?
Mar 19, 2014 17:09
|
|
|
And here it is:quote:Anyone can gain access to Unreal 4 by subscribing for $19/mo for access to everything. xgalaxy fucked around with this message at 17:16 on Mar 19, 2014 |
|
#
?
Mar 19, 2014 17:11
|
|
|
That's pretty loving radical.
|
|
#
?
Mar 19, 2014 17:16
|
|
|
Whoa whaaaaaat!? I guess that's one way to fight unity...
|
|
#
?
Mar 19, 2014 17:22
|
|
|
xgalaxy posted:And here it is: Given the gnashing over Unity 5's pricing on Twitter, this couldn't have been better timed. I think I'll stay Unity for now, but it's nice to have choices again! 
|
|
#
?
Mar 19, 2014 17:28
|
|
|
Don't forget that Sony also announced that they're working with YoYo Games to make Game Maker natively compatible with the PS4 and Vita. That's pretty rad!
|
|
#
?
Mar 19, 2014 17:28
|
|
|
Shalinor posted:Oh drat. Thank you, gods of Unreal, for hearing our prayers. I woke up this morning and typed that in this forum like a hour before it happened. I'm the game dev Nostradamus. EDIT: BTW. My powers of future telling are saying to me that Valve Source 2 Engine will be a similar model to Unreal. xgalaxy fucked around with this message at 18:15 on Mar 19, 2014 |
|
#
?
Mar 19, 2014 17:31
|
|
|
Are they removing the ability to just download and play around for free? I have an old version of UDK on my computer that I've been meaning to check out. That is an advantage of Unity to let you at least get failure with it before committing any money. Still, $20 is so cheap that I don't mind paying for a bit just to learn.
aeiou fucked around with this message at 18:17 on Mar 19, 2014 |
|
#
?
Mar 19, 2014 18:15
|
|
|
Aras Pranckevičius(Unity's graphics/shader bloke) has put up his GDC talk on his website. Slides/notes.
|
|
#
?
Mar 19, 2014 18:16
|
|
|
xgalaxy posted:EDIT: Here's hoping Source 2 is actually a new engine and not another layer of upgrades bolted on top of code that traces all the way back to Quake. I'm all for code reuse and Valve has certainly gotten good mileage out of Source, but I am so goddamn tired of their content creation tools. I suspect they're in for a rude awakening if they expect anyone to put up with another 10 years of making maps in Hammer and dragging tga files on top of vtex.exe.
|
|
#
?
Mar 19, 2014 19:23
|
|
|
CryEngine is getting into the mix: http://www.cryengine.com/news/crytek-announces-its-cryengine-as-a-service-program
|
|
#
?
Mar 20, 2014 00:06
|
|
|
And the Rift 2 is a hugely hugely important announcement too. This in particular.  Valve worked with the Rift to make prototypes, and valve ended up making one with head tracking. This turned out to solve almost all motion sickness problems in their entirety, along with providing more tracking in games. Everyone who tried it had astoundingly positive reviews, and it seems rift ended up polishing it enough for release! Very exciting! Jewel fucked around with this message at 00:14 on Mar 20, 2014 |
|
#
?
Mar 20, 2014 00:10
|
|
|
|
| # ? May 11, 2024 19:39 |
|
|
Jewel posted:And the Rift 2 is a hugely hugely important announcement too. The low persistence display apparently came out of Valve research on motion sickness too.
|
|
#
?
Mar 20, 2014 01:24
|
|
