|
Holy poo poo! I've been wanting to jump ship but I liked C# too much. Thank you based UE4 
|
#
?
Oct 24, 2014 01:57
|
|
|
|
| # ? Apr 24, 2024 11:29 |
|
|
As someone who just bought Unity Pro not two months ago, I humbly request that UE4 stop fixing all the things that I didn't like about it tia
|
|
#
?
Oct 24, 2014 02:04
|
|
|
what didn't you like about it?
|
|
#
?
Oct 24, 2014 03:51
|
|
|
Onion Knight posted:Holy poo poo! I've been wanting to jump ship but I liked C# too much. Thank you based UE4 Oh hell YES! I know you won't be able to use this for mobile/embedded, but I think I've just changed my platform of choice to UE4 for Windows/OSX/Linux and I'll worry about the rest later. UE4 is great (the editor/lighting blows Unity 4 out of the water although Unity 5 might fix a couple of those) but C++ killed my productivity.
|
|
#
?
Oct 24, 2014 04:47
|
|
|
The King of Swag posted:Remember that with floating point numbers, unless they're calculated in exactly the same fashion, they probably aren't the same. In theory I should be calculating it the same every time but this is probably what is going awry. Thanks! I think the solution is to just stop using floats. There's actually no reason I can't use an int for the positions since the grid position doesn't actually need that precision and I was just using them because the example I had used for reference did.
|
|
#
?
Oct 24, 2014 09:06
|
|
|
Yodzilla posted:Do you have UnityScript in your project? If so it'll create a fourth project or whatever and throw an error. Get rid of any UnityScript and that should go away. That was it! I was using some old Unity post-effects for bloom. I ported the stuff I needed to C# and it runs like a charm. Thanks!
|
|
#
?
Oct 24, 2014 15:40
|
|
|
I can't put my finger on exactly why (maybe the newfound focus on services instead of a quality engine?), but this Gamasutra interview with the new Unity3D CEO, has left me with an even bleaker outlook for the future of Unity than I already had.
|
|
#
?
Oct 24, 2014 19:05
|
|
|
The King of Swag posted:I can't put my finger on exactly why (maybe the newfound focus on services instead of a quality engine?), but this Gamasutra interview with the new Unity3D CEO, has left me with an even bleaker outlook for the future of Unity than I already had. ... which, as it happens, is going to push the pricing model more in favor of UE4. UE4's only real "downside" is that your engine cost is an ongoing concern rather than a single fixed price. If Unity's pricing adopts a similar over-time ramping curve, the graph comparing the cost of the two over time is going to start closing even more. It's already pretty drat close, when you account that a scaling revenue typically means a scaling team typically means a scaling number of Unity Pro licenses. EDIT: I was bored, I like math, so I assembled some graphs a while ago to compare the costs. It turns out it just doesn't matter until your revenues hit the multi-millions, at which point you can actually re-negotiate your UE4 contract with a lower rev-share % that would even FURTHER pinch those graphs together - and unity adopting a F2P pricing model will push its line up to match. Shalinor fucked around with this message at 19:47 on Oct 24, 2014 |
|
#
?
Oct 24, 2014 19:20
|
|
|
Has anyone been noticing problems with the Unity web player and Chrome, recently? A couple of months back (there may have been a Chrome update around this time), I started noticing the Unity web player becoming unstable. It would sometimes partially load, then never finish, and sometimes give me a blank playing area. On some occasions, a reload would fix the problem, on some occasions it would not. Even more annoying is that every time I load a Unity web player application, it causes problems with Windows UI elements. Right-click menus and dropdown menus fade in slowly and leave behind artifacts. Like, if I right-click on the desktop and select a menu item, that menu item gets permanently pinned to the screen on top of everything else. I can semi-fix this by killing dwm from the Task Manage, but it usually comes back as soon as I use another context menu. This makes testing no fun. I can use Firefox, but as soon as I try to run anything in Chrome, I start getting menu artifacts everywhere. How does Unreal Engine stack up against Unity as far as 2D goes? Unity is finally getting to a point where I don't need to drag in three different 2D helpers from the Asset Store to make things work.
|
|
|
#
?
Oct 24, 2014 19:33
|
|
|
You know. The biggest win, for me anyway, of the Unreal Engine + C# announcement is the fact that the integration is based on the 'latest' Mono platform and C# language features. That means PCL support. That means task, await, and other async support. That means improved performance from the better garbage collector and better code generation of the compiler. A whole world of libraries are opened up with the PCL support. So much win over Unity it isn't even fair.
|
|
#
?
Oct 24, 2014 19:44
|
|
|
What's the deal with the async physics scene in UE4? What's it do? Can I take advantage of it? I've recently added some destructable components (https://www.youtube.com/watch?v=iRCPQkIi4vg) and they can slow down the game a bit once they're just sitting on the ground. Can I put them to "sleep"? Also I've added a time dilation (bullet time) "effect" into the game (people are saying it's difficult to control, honestly they just need to get better but this is a training bra) but it doesn't work on my build, only when I'm in the editor.. Well, it kinda works, but not well or as it should. Any ideas?
|
|
#
?
Oct 24, 2014 20:08
|
|
|
God I love using UE4! I love "playing", loving around, you know. My blocks of destructable meshes are built with a procedural wall generator which is getting more and more complex as time goes on, and since I can put options on it which are available from the editor. In my wall generator I can make it destructible or not, it can have many colours or not (which you can set) which are assigned randomly (but using a seed so you can "set" it), make them sporadic (not every block is filled), change to glass materials, change all the material parameters (roughness, metallic etc). The best part is how easy it is to do all of this. I've set up a few master materials with a lot of their parameter names shared* so when I swap between my general master material and translucent/glass material, my blueprints work flawlessly because they fail silently if I try to assign the opacity to the general material for example, so I don't have to worry and just freely have an opacity slider on my BP in the editor which works if it's on glass mode and not if it's not. I've built a booster material with the "additive" lighting property, and use the built in BlackBody function so when I need, in my BP I create a dynamic instance of that material, assign it to a mesh and then very easily just change the "temperature" parameter with a timeline (so I don't have to handle ramping up and down, just drew a line) and it does the rest! Since the BlackBody built in thing not only gives colour but gives a vector with >1 value it creates a bloom effect (I am a sucker for that poo poo) because HDR is built in from the ground here, and because I have the Light Propagation Volume going and set up, it injects that light into the LPV so it lights up the environment with GI! Not lights to fake the effect, it just works And because I set this up once, I am free to use it over and over and so when I built a rocket, it's very simple to add that booster material and set a timeline and boom, neat effect! * After doing early games I realised I only needed a few materials with flexible parameters and since you can add switches you can get by with few master materials, especially since I'm not using textures as such but doing everything just with material nodes like colour, roughness, metallic, specular, etc Sorry for the excitement, this stuff might seem like child's play to you, but it's so amazing to me! Also because I'm not just watching someone else do it but it's so simple for me to do it myself echinopsis fucked around with this message at 20:50 on Oct 24, 2014 |
|
#
?
Oct 24, 2014 20:48
|
|
|
The King of Swag posted:Remember that with floating point numbers, unless they're calculated in exactly the same fashion, they probably aren't the same. This is a 
The Laplace Demon fucked around with this message at 21:03 on Oct 24, 2014 |
|
#
?
Oct 24, 2014 21:00
|
|
|
The Laplace Demon posted:This is a True; I just came up with these numbers off the top of my head and I'm not about to memorize a set of common numbers which aren't exactly representable, but the point does still stand. You cannot rely on floating point number comparisons, unless you're using fuzzy comparisons.
|
|
#
?
Oct 24, 2014 21:06
|
|
|
xgalaxy posted:You know. The biggest win, for me anyway, of the Unreal Engine + C# announcement is the fact that the integration is based on the 'latest' Mono platform and C# language features. You have to sign up, I've been informed I can get the bits early next week. If/when I get it working I'll report back. Also just an FYI UE4 Mono currently only connects to the BluePrint objects and APIs so you might still need C++ for certain things. They anticipate rebuilding Shooter game in C# early next week.
|
|
#
?
Oct 24, 2014 21:15
|
|
|
Stick100 posted:You have to sign up, I've been informed I can get the bits early next week. If/when I get it working I'll report back. Also just an FYI UE4 Mono currently only connects to the BluePrint objects and APIs so you might still need C++ for certain things. First steps; once this matures, I can easily see it becoming a first class language within UE4, able to access all the same features C++ does. Particularly because if you read the website, they also talk about another Xamarin project, that auto-generates bindings from C++ to C#.
|
|
#
?
Oct 24, 2014 22:28
|
|
|
Has anyone used the lua plugin for UE4? I couldn't tell if its just proof of concept or ready for usage.
|
|
#
?
Oct 24, 2014 22:42
|
|
|
While I'm well aware that the C# framework for UE4 is a long ways off before it's fit for production use, there's no time like the present, so I've registered an account with Epic and bought a subscription. I probably won't get to play around with it much until after tomorrow, but I'm confident I'll be able to get rolling with it nearly as fast as I did when I started using Unity.
|
|
#
?
Oct 25, 2014 03:22
|
|
|
The King of Swag posted:While I'm well aware that the C# framework for UE4 is a long ways off before it's fit for production use, there's no time like the present, so I've registered an account with Epic and bought a subscription. I probably won't get to play around with it much until after tomorrow, but I'm confident I'll be able to get rolling with it nearly as fast as I did when I started using Unity. As noted before you have to get permission from the Xamarin team to down load the C# -> UE4. Until then you won't be able to use this, you might already have access but if not it will be until at least next week. They sent out an email saying they anticipated to a very low response and to do a bunch of steps manually. Apparently they got a MUCH better response then anticipated and determined they need to build systems. From the newletter (only current form of Mono -> C# communication). "Hello XXX, Yes, it is manual. We were expecting a small amount of requests, and have our assistant just set the license up, but that clearly did not scale. So we are setting up the infrastructure now (right now ;-) to batch send them. Miguel" TLDR: Sign up for access, and expect to wait until next week.
|
|
#
?
Oct 25, 2014 04:42
|
|
|
Stick100 posted:As noted before you have to get permission from the Xamarin team to down load the C# -> UE4. Until then you won't be able to use this, you might already have access but if not it will be until at least next week. They sent out an email saying they anticipated to a very low response and to do a bunch of steps manually. Apparently they got a MUCH better response then anticipated and determined they need to build systems. Oh, I understand that; I won't even be touching that until the project matures. As I said in a previous post, I actually have much more experience in C++ than I do C#, it's just that I don't want to be tied to a platform that has no possibility of ever supporting C#. Xamarin has shown that where there is a will, there's a way, and although not ready now, it will be someday. So I may as well start learning how to use UE4 now, and simply going back to putting up with C++ for the time being.
|
|
#
?
Oct 25, 2014 05:11
|
|
|
I appear to have attracted the attention of one of the UE4 C# devs on Twitter, so might have some credible info on "mobile? consoles?" soon. Does anyone with more UE4 or C# 4.4 experience than me what to suggest some specific smart questions I could ask, that'd drill into its relative limitations?
|
|
#
?
Oct 25, 2014 08:43
|
|
|
What's that twitter yo?
|
|
#
?
Oct 25, 2014 09:17
|
|
|
FuzzySlippers posted:In theory I should be calculating it the same every time but this is probably what is going awry. Thanks! This doesn't matter for hashing, but for future reference, "abs(a - b) < 1e-5f" is basically == for floats.
|
|
#
?
Oct 25, 2014 11:19
|
|
|
Cheston posted:This doesn't matter for hashing, but for future reference, "abs(a - b) < 1e-5f" is basically == for floats. I'm always unsure of the precision to use when comparing floats. Thanks for the 1e-5f tip! Edit: vvv Oh! Jewel fucked around with this message at 13:03 on Oct 25, 2014 |
|
#
?
Oct 25, 2014 11:54
|
|
|
Cheston posted:This doesn't matter for hashing, but for future reference, "abs(a - b) < 1e-5f" is basically == for floats. This is effectively a == b for anything above 100 if you're using floats.. See how 243 != 243 using bad_equals(a, b). Use something like |a - b| < eps * (1 + max(|a|, |b|)), where eps = 100 * FLT_EPSILON ≈ 1e-5f for floats (or everything just to be safe, an intermediate result could always have been stored in a float  ).EDIT: Or use doubles for everything and don't think about this until you're comparing numbers in the millions, etc. The Laplace Demon fucked around with this message at 13:04 on Oct 25, 2014 |
|
#
?
Oct 25, 2014 12:48
|
|
|
Read this and his other articles if you actually want to have understanding of how floats work and what to (not) do with them: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
|
|
#
?
Oct 25, 2014 14:07
|
|
|
The thing to watch out for with floating point numbers, is that unit of least precision based comparisons break down at numbers < 1, and absolute tolerance comparisons break down at very large numbers, with them growing continually less effective as the number increases in magnitude (in base 2). At sufficiently large numbers, 1 ULP can be considerably larger than your absolute tolerance. Floating point numbers aren't so scary or hard, that you need to replace them with integers wherever possible (as I've seen some people do). You just need to understand their faults, and how to wrangle them so that those faults don't effect you.
|
|
#
?
Oct 25, 2014 17:06
|
|
|
echinopsis posted:What's that twitter yo? "@glassbottommeg any specific questions? We can answer. Our company focuses on mobile, so that's next. We are also ps4/Xbox devs" "@migueldeicaza Basically I'm curious how using this affects a studio's ability to do mobile and console ports. Does it complicate it at all?" "@glassbottommeg for mobile, it does not add more complexity that you would already have. For consoles, we need to finish ports." "@glassbottommeg we have Mono on ps4; Now working on Xbox" "@migueldeicaza @glassbottommeg have you tried running it through emscripten as well, for the HTML5 port? (it's a long shot, but I'd love it)" "@DaveVoyles @glassbottommeg it will need special support from Mono to compile to JS as a target - long story" ... so from where I'm sitting, this certainly seems there enough to seriously consider. Porting being impossible as a result of using it was my only real concern. People that care about web builds might feel differently, but that's not me, yay.
|
|
#
?
Oct 25, 2014 19:32
|
|
|
See I was doing all that in my Equals and Comparison methods and so forth but that didn't help the hashing which I'm still not 100% sure how to fix. Should I have chopped the float before hasing? Now that I've changed my GridPosition struct to just use int for x and y no more problems anyway though. Float precision wasn't gaining me anything in this case.
|
|
#
?
Oct 25, 2014 20:29
|
|
|
Miguel is awesome. I can verify this.
|
|
#
?
Oct 25, 2014 21:07
|
|
|
It seems that the UE4 license doesn't automatically cover using the Xamarin C# stuff. I don't like that. It limits the applications of C# versus C++ and blueprints unless you want to pay separately.
|
|
#
?
Oct 26, 2014 01:19
|
|
|
Inverness posted:It seems that the UE4 license doesn't automatically cover using the Xamarin C# stuff. I don't like that. It limits the applications of C# versus C++ and blueprints unless you want to pay separately. If Epic has any business sense they will be talking to Xamarin to work out something ASAP. C# support is the last remaining road block for a whole mess of people.
|
|
#
?
Oct 26, 2014 01:26
|
|
|
Jon93 posted:If Epic has any business sense they will be talking to Xamarin to work out something ASAP. I can certainly see Epic winning over a large chunk of Unity's market share, if they supported C# to the same extent as they support C++ and Blueprint. If they did, there'd frankly be very little reason to stick with Unity aside from finishing an existing project. I've noticed that as time has gone by, community support and documentation are touted more and more as the biggest benefits of Unity, but as the UE4 community grows and matures, I see that benefit dwindling. Especially since I'm going through the official UE4 shakedown videos now, and they're very high quality compared to the getting started videos provided by Unity.
|
|
#
?
Oct 26, 2014 07:46
|
|
|
What's the big benefit of C# over C++? familiarity? it can't be efficiency or speed (perhaps in writing, not execution) To me, personally, it's like, if you don't like C++, why not get stuck into BluePrints. surely it's going to be a similar level to c#? Anyway, the word on the UE4 forums isn't as positive as it is here, makes me question how worthful it is. Honestly, I'm glad I'm using blueprints. coding is for chumps and children with adhd
|
|
#
?
Oct 26, 2014 08:36
|
|
|
echinopsis posted:What's the big benefit of C# over C++? familiarity? it can't be efficiency or speed (perhaps in writing, not execution) C# is really really pleasing to look at after staring at C++ (both of which I work with regularly) and also compiling is a complete nonissue. It also gives way better stuff like reflection and you don't have to deal with pointers and etc. It's basically a relief on the mind to be able to do what you want instead of wrangling syntax. Also for work outside of unreal; no worry about having to link libraries. Plus; if you get a compilation error in C# it actually tells you the exact problem and is usually fixable instantly. Oh and finally; resharper is super friendly and helps you code so much faster. Edit: "it can't be efficiency or speed (perhaps in writing, not execution)" basically this. No it's not as efficient as C++, but for most things you don't need the efficiency of C++ unless you're making something that's really down to the wire and needs a lot of optimization. For general game projects and tests and making GBS threads around, C# is more than enough speed. For an AAA open world ultra-realistic mmo game with a 500 million dollar budget; sure, don't use C#. Jewel fucked around with this message at 09:12 on Oct 26, 2014 |
|
#
?
Oct 26, 2014 09:10
|
|
|
echinopsis posted:What's the big benefit of C# over C++? familiarity? it can't be efficiency or speed (perhaps in writing, not execution) At its core, C# is really just another take on an object-oriented C based language. In fact, I tend to look at it like an amalgamation of the object-orientation models of C++ and Obj-C (the original object-oriented C based language). Although there are a few fundamental differences between how you program in C# and C++, they're actually very similar to each other. Coming from C++ to C#, I picked up the language in a day, and had a solid grasp of all the major differences between the languages before a week had gone by. So we're clear, solid grasp does not mean experienced; it just means you know what it does, and when/why to use it. I could spend a year playing with reflection, and never truly master it. Needless to say, visual programming is an entirely different beast, and comparing it to C# or any other traditional programming language is comparing apples to giraffes. Though they seek to accomplish the same goals (implement game logic), they're so fundamentally different, any comparison is meaningless. If you've never had experience with a native non-garbage-collected language before, I can see the transition from C# to C++ being tougher, but not that much tougher. Honestly, anyone capable of learning C#, is fully capable of learning C++. The reason I and so many others push so hard for C# though, is that C# has a much faster iteration loop. It's faster to write code in (generally because you aren't fiddling about with headers, cleaning up memory and other tasks C# just handles), and it's faster to compile (by a wide margin). Just because I know this will come up at some point; C# isn't really that much slower than C++ (with modern .NET/Mono framework versions). Relative performance varies depending on exactly what you're doing, but they're close enough to each other that your algorithm or code design will be the limiting factor (and not the language), frankly every time. We aren't writing kernels or drivers here; we're not even writing a renderer (UE4 already takes care of that for us). We're creating logic for video games, where the algorithms used almost entirely dictate execution speed. Delaunay triangulation of a complicated mesh isn't limited by your language, it's limited by the algorithm efficiency. echinopsis posted:Anyway, the word on the UE4 forums isn't as positive as it is here, makes me question how worthful it is. I hope you aren't talking about this thread, which unfortunately is a pot of misinformation. The King of Swag fucked around with this message at 09:24 on Oct 26, 2014 |
|
#
?
Oct 26, 2014 09:21
|
|
|
echinopsis posted:To me, personally, it's like, if you don't like C++, why not get stuck into BluePrints. surely it's going to be a similar level to c#? there's a big difference between visual programming and using a real language capable of defining abstractions UE4 already has to expose stuff as a custom object model - to blueprint, for module apis, sync and so on. writing c++ in it is even more of a hassle than normal c++ because of this; not only do you have headers and so on but also a bunch of macros which are the 'true' semantics. being able to author or extend gameplay in a language with memory management and a modern compilation model is made extra attractive by comparison.
|
|
#
?
Oct 26, 2014 09:50
|
|
|
It's clear I don't know jack poo poo. Welp. Thanks for all the replies, it's very interesting, and shows me much of a world that I don't understand at all. For me personally, I'm super glad I can get what I need done with BluePrints, but now have a bit more of a clue why you'd want to sit somewhere between C++ and the BluePrints. I hope the Epic dudes don't do an epic fail and pick up on this. So with C++ does it require you to still do a lot of the manual poo poo like memory management? I've never had to deal with that (my closest experience is C on arduino) so I can see how that'd be a bucket of poo poo, given how free I feel with BluePrints to work on the logic/game and not worry about anything else at all (almost*) *while adding meaningless bullshit to my game I am finding slowdowns, I have been immune until recently having a relatively decent PC, so eventually I run into slowdowns and think "what do I need to fix this" and etc etc. realise my smoke effect was draining the CPU so I had to kill the "cool effect", etc. nice insight to gaming in a way maybe
|
|
#
?
Oct 26, 2014 10:29
|
|
|
echinopsis posted:I hope the Epic dudes don't do an epic fail and pick up on this. this biggest epic fail? this pun. gently caress you
|
|
#
?
Oct 26, 2014 10:30
|
|
|
|
| # ? Apr 24, 2024 11:29 |
|
|
echinopsis posted:It's clear I don't know jack poo poo. Welp. Thanks for all the replies, it's very interesting, and shows me much of a world that I don't understand at all. Yes, C++ requires you do manage your memory manually. You get to pick whether you define your memory on the stack or the heap, and you choose when to allocate it and free it. If you free it and then use it again later, it might fail some of the time or you might get lucky and still have some pieces of the old structure in it. If you don't free it your program will slowly accumulate memory until it reaches a Stallman-esque mass of tangled, slightly aged, stinky memory. Great power, great responsibility, and all that. EDIT: I CARNT SPALL.
|
|
#
?
Oct 26, 2014 17:16
|
|
