Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

HexiDave: Mar 20, 2009

I don't know if it's been stressed, but UE4's Blueprint system is integrated pretty much everywhere in the engine: animation, materials, networking, logic, gameplay, physics, level loading (including streaming content), particles, and more I'm probably forgetting. I've been working on a game with Descent-like flying and implementing a flight model with synchronized multiplayer combat took about a day just using Blueprints. You can debug them - any instance running (including server) - with breakpoints/watches just like a regular IDE, and it's all done visually through the connections between the Blueprint nodes.

I program for a living and I've done a ton of C++, but I've barely had to do any for this project - it's mostly just internal settings that aren't exposed via Blueprints. That said, I've been able to do minor bug-fixes and extensions to the Blueprints to make life easier, and even that doesn't require a lot of code. It's a really nice change of pace and it lets me get to what I wanted in the first place: make games.

Unity, on the other hand, threw roadblocks in my face pretty regularly - and at really weird times. I was trying to implement a different network system for some basic communications that Unity didn't support, and debugging it was absolute hell (even with UnityVS). It all just felt disjointed and sloppy, like they got everything to function and completely forgot to go back and clean up. Conversely, debugging in UE4 in C++, I can use breakpoints while the editor is running, or I can just build a debug version for gameplay code so the editor runs with optimizations. It works very naturally to me, coming from a C++ background.

Another big area of difference is in the editor. In Unity, people talk about getting the grid-snapping plugin off the asset store, but it's available by default in the UE4 editor - including vertex snapping. A lot of the things you'd expect in an editor are there for UE4, and you don't have to shell out $1500 to change the theme. Errors and warnings are generally verbose and help explain what's going on, it's good about just letting you get rolling (it includes a lot of useful content you can easily migrate to your own project), and it's got a good system for network testing (including dedicated, headless server support out of the box). Basically, a lot of things you need paid plugins to do in Unity are free and integrated into UE4 already.

I've worked with a number of game engines in the past (and made a few), and I've just been extremely happy with UE4.

# ? Aug 5, 2014 03:27

Adbot: ADBOT LOVES YOU

# ? May 11, 2024 10:05

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Jo posted:

I don't think I'm storing a reference to the player in the Unreal code, am I? I _am_ in the Unity code because it makes it faster to check the transform. In the UE code, if I gave the item to whatever pawn collided with APickup, is there a chance a non-player character could pickup the item, or are the pawns solely players?

If my Unreal 2.5 memory is right, and if it still applies to 4, a Pawn is an Actor with a Controller. That Controller can be AI or human.

Above Our Own posted:

Using C++ instead of C# is a big turn off for me. I haven't touched C++ in years, so maybe I'm wrong, but I really don't like to imagine going back. Verbose code is demoralizing for me to work in. I also really enjoy component systems, so I think I'll wait out Unity 5.

I'm thinking I need to pick up Unreal for C++ experience. I've been trying to get a new job in the industry and there's still a lot of C++ requirements out there, and I haven't used C++ at all professionally.

# ? Aug 5, 2014 03:31

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Dang, I wish I could run UE4 on my Mac.* Guess I'm gonna be using Unity for a while.

*Without it pegging the CPU and heating up so much that it might begin to form the core of a star

# ? Aug 5, 2014 15:47

Obsurveyor: Jan 10, 2003

nite time dinosaur posted:

Dang, I wish I could run UE4 on my Mac.* Guess I'm gonna be using Unity for a while.

*Without it pegging the CPU and heating up so much that it might begin to form the core of a star

You know that if your computer can't run the processor full out, there's something wrong, right? Computers aren't like cars, you can't damage the hardware by just running software(assuming you're not overclocking).

# ? Aug 5, 2014 15:50

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Obsurveyor posted:

You know that if your computer can't run the processor full out, there's something wrong, right? Computers aren't like cars, you can't damage the hardware by just running software(assuming you're not overclocking).

My concern wasn't so much that the computer would get damaged. It was more that when I tried running the editor, it was making my fans run at maximum speed and the computer, a retina macbook pro, was so hot it was painful to touch. I wasn't even doing anything in the editor. Can't imagine what would happen if I tried to do anything.

It doesn't look like I'm the only person experiencing this issue:
https://answers.unrealengine.com/questions/78066/perfomance-of-the-editor-on-my-mac-book-pro-retina.html
https://answers.unrealengine.com/questions/13370/high-cpu-usage-on-mac-editor-barely-usable.html

# ? Aug 5, 2014 16:16

Stick100: Mar 18, 2003

nite time dinosaur posted:

My concern wasn't so much that the computer would get damaged. It was more that when I tried running the editor, it was making my fans run at maximum speed and the computer, a retina macbook pro, was so hot it was painful to touch. I wasn't even doing anything in the editor. Can't imagine what would happen if I tried to do anything.

It doesn't look like I'm the only person experiencing this issue:
https://answers.unrealengine.com/questions/78066/perfomance-of-the-editor-on-my-mac-book-pro-retina.html
https://answers.unrealengine.com/questions/13370/high-cpu-usage-on-mac-editor-barely-usable.html

I had the same in Windows (rMBP). In 4.3 they are introducing settings let you cut back actions in the editor. Most critically for when on battery and not in game. You said you were doing "nothing" but the editor just keeps running the game constantly it like the game never stops just the perspective changes to the editor camera.

Unity does the same thing in the editor just your scene is probably much simplier so Unity isn't running your GPU/CPU full out like UE4.

# ? Aug 5, 2014 16:51

Dirty: Apr 8, 2003; Ceci n'est pas un fabricant de pates

nite time dinosaur posted:

My concern wasn't so much that the computer would get damaged. It was more that when I tried running the editor, it was making my fans run at maximum speed and the computer, a retina macbook pro, was so hot it was painful to touch. I wasn't even doing anything in the editor. Can't imagine what would happen if I tried to do anything.

It doesn't look like I'm the only person experiencing this issue:
https://answers.unrealengine.com/questions/78066/perfomance-of-the-editor-on-my-mac-book-pro-retina.html
https://answers.unrealengine.com/questions/13370/high-cpu-usage-on-mac-editor-barely-usable.html

That still sounds like a problem with the computer. Your computer shouldn't be getting too hot to touch.

# ? Aug 5, 2014 17:42

xzzy: Mar 5, 2009

Unfortunately that's SOP for Macbooks.

# ? Aug 5, 2014 17:44

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Anyone heading off to Unite 2014 this year? I'd love to meet some more game devs.

# ? Aug 5, 2014 17:56

Stick100: Mar 18, 2003

xzzy posted:

Unfortunately that's SOP for Macbooks.

You can't make computers that small without some compromises. I still think the rMBP/Air are the best hardware but if you use a rMBP + discrete at full throttle for long it will get extremely hot and throttle down the CPU.

# ? Aug 5, 2014 18:10

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Stick100 posted:

I had the same in Windows (rMBP). In 4.3 they are introducing settings let you cut back actions in the editor. Most critically for when on battery and not in game. You said you were doing "nothing" but the editor just keeps running the game constantly it like the game never stops just the perspective changes to the editor camera.

Unity does the same thing in the editor just your scene is probably much simplier so Unity isn't running your GPU/CPU full out like UE4.

All I had was the default blueprint project loaded. I'm sure the engine was running and things were happening, but what I meant was, I as a developer was doing nothing, and typically a computer that is working very hard to maintain an idle state isn't going to handle any kind of load required to be productive.

Dirty posted:

That still sounds like a problem with the computer. Your computer shouldn't be getting too hot to touch.

I mean, it wasn't hot enough to burn me or anything else, it was just hotter than I'd like my computer, especially a laptop made of metal, to be. The whole chassis is a heatsink, so.

I've done multi-core compiles of large scala projects on this computer without it making a sound. It seems that UE4 was really pushing my GPU (the nvidia one) just to render a couple chairs and a table with a skybox, and it also seems like this is a known issue that should not be happening.

# ? Aug 5, 2014 19:20

Dirty: Apr 8, 2003; Ceci n'est pas un fabricant de pates

nite time dinosaur posted:

I've done multi-core compiles of large scala projects on this computer without it making a sound. It seems that UE4 was really pushing my GPU (the nvidia one) just to render a couple chairs and a table with a skybox, and it also seems like this is a known issue that should not be happening.

I guess. It just seems odd to me - your graphics card is there to be used. I get that UE4 is clearly doing something wrong, and it shouldn't be pushing your GPU that hard, but your GPU won't work any harder than it's designed to. So if it's going at maximum output and the fans are kicking in... I don't know, is that so bad? I guess what I'm saying is that it sounds like you're saying you're stuck with Unity because UE4 makes your machine heat up a lot, but your machine should be designed with tolerances in mind for that sort of thing.

Dirty fucked around with this message at 19:40 on Aug 5, 2014

# ? Aug 5, 2014 19:34

Obsurveyor: Jan 10, 2003

Yeah, you paid a premium for the power of a MacBook Pro but, essentially, you aren't ever using it to its potential. You may as well have purchased a cheaper model.

# ? Aug 5, 2014 20:19

evilentity: Jun 25, 2010

Thats what you get when you do workstation job on a laptop. Get a bt keyboard and you wont burn yourself.

# ? Aug 5, 2014 21:00

FuzzySlippers: Feb 6, 2009

poemdexter posted:

Anyone heading off to Unite 2014 this year? I'd love to meet some more game devs.

We're in the middle of moving to Seattle anyway so it would be easy but I haven't decided on whether to shell out for a ticket. Anyone go previously and have thoughts?

# ? Aug 5, 2014 21:57

Harvey Mantaco: Mar 6, 2007; Someone please help me find my keys =(

evilentity posted:

Thats what you get when you do workstation job on a laptop. Get a bt keyboard and you wont burn yourself.

Pfft running unity fine on my surface 3

# ? Aug 5, 2014 22:07

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Dirty posted:

I guess. It just seems odd to me - your graphics card is there to be used. I get that UE4 is clearly doing something wrong, and it shouldn't be pushing your GPU that hard, but your GPU won't work any harder than it's designed to. So if it's going at maximum output and the fans are kicking in... I don't know, is that so bad? I guess what I'm saying is that it sounds like you're saying you're stuck with Unity because UE4 makes your machine heat up a lot, but your machine should be designed with tolerances in mind for that sort of thing.

It's fine that the computer goes to 100% sometimes. I get that. It just seemed like it was going to be painfully slow when I actually started using it. Is this a difficult concept, or am I missing something where everyone who uses UE4 has their GPU cranking at 100% the entire time it's running?

Obsurveyor posted:

Yeah, you paid a premium for the power of a MacBook Pro but, essentially, you aren't ever using it to its potential. You may as well have purchased a cheaper model.

Yeah, cause you would know whether or not I ever play games or use any other 3d accelerated software on it... :rolleyes:

# ? Aug 5, 2014 22:15

Obsurveyor: Jan 10, 2003

nite time dinosaur posted:

It's fine that the computer goes to 100% sometimes. I get that. It just seemed like it was going to be painfully slow when I actually started using it. Is this a difficult concept, or am I missing something where everyone who uses UE4 has their GPU cranking at 100% the entire time it's running?

Yeah, cause you would know whether or not I ever play games or use any other 3d accelerated software on it...

UE4 is "3d accelerated software" but somehow it's not a valid use of your machine? The resources it needs are the resources it needs, just like the games you're running. That may require the use of 19% or 52% or 100% of your GPU depending on the speed and resources of the hardware. This usage may also generate heat and run the fans.

# ? Aug 5, 2014 22:19

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Obsurveyor posted:

UE4 is "3d accelerated software" but somehow it's not a valid use of your machine? The resources it needs are the resources it needs, just like the games you're running. That may require the use of 19% or 52% or 100% of your GPU depending on the speed and resources of the hardware. This usage may also generate heat and run the fans.

Okay gee I guess you're right!

# ? Aug 5, 2014 22:29

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

nite time dinosaur posted:

Yeah, cause you would know whether or not I ever play games or use any other 3d accelerated software on it...

So you're okay with games pushing your laptop to 100% but not UE4?

You know UE4 is a game engine right? What are you complaining about exactly, that the editor uses your GPU? The editor renders a pretty accurate view of the screen, which is pretty handy for working on levels and not having them end up looking different with in-game lighting and stuff. UE4 even lets you hop right into your game from the editor; because its running the game. For most developers that's worth it, because they have fancy rigs anyways. You're not really intended to do level editing on a laptop, but you can. Its just gonna push your GPU to 100%, but that's okay?

# ? Aug 5, 2014 22:32

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Zaphod42 posted:

So you're okay with games pushing your laptop to 100% but not UE4?

You know UE4 is a game engine right? What are you complaining about exactly, that the editor uses your GPU? The editor renders a pretty accurate view of the screen, which is pretty handy for working on levels and not having them end up looking different with in-game lighting and stuff. UE4 even lets you hop right into your game from the editor; because its running the game. For most developers that's worth it, because they have fancy rigs anyways. You're not really intended to do level editing on a laptop, but you can. Its just gonna push your GPU to 100%, but that's okay?

I naively thought that the editor would likely require more resources when I was interacting with it. Apparently I was mistaken.

# ? Aug 5, 2014 22:34

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

nite time dinosaur posted:

I naively thought that the editor would likely require more resources when I was interacting with it. Apparently I was mistaken.

It has to render regardless. If you disabled the viewport it'd probably speed up a decent bit.

Also aren't you complaining about the absolute amount of resources it uses, not the relative amount when you're not using it? I dunno something about that post just doesn't parse very easily. Like you're trying to say something funny but it just really isn't working.

# ? Aug 5, 2014 22:39

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Zaphod42 posted:

It has to render regardless. If you disabled the viewport it'd probably speed up a decent bit.

Also aren't you complaining about the absolute amount of resources it uses, not the relative amount when you're not using it? I dunno something about that post just doesn't parse very easily. Like you're trying to say something funny but it just really isn't working.

Thanks, I'll try that.

And no, I was ambiguous in my complaint. I mistakenly thought that it would be obvious that I meant that not doing something anything in the editor shouldn't be maxing out my modern, fast computer. It never crossed my mind that people would assume I don't know how computers work and was afraid it would actually explode or something.

# ? Aug 5, 2014 22:51

Inverness: Feb 4, 2009; Fully configurable personal assistant.

It depends on what you mean by "not doing anything in the editor". If you mean minimizing it or not having it focused, yeah I'm sure there is room for optimization there if UE4 doesn't do it already. If you mean having it activate but just not moving your mouse doing any input then that will not help as much because, unlike your typical desktop application, the GUI is rendered by the engine at some high FPS and redrawn constantly just like anything in the game.

# ? Aug 5, 2014 23:21

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Inverness posted:

It depends on what you mean by "not doing anything in the editor". If you mean minimizing it or not having it focused, yeah I'm sure there is room for optimization there if UE4 doesn't do it already. If you mean having it activate but just not moving your mouse doing any input then that will not help as much because, unlike your typical desktop application, the GUI is rendered by the engine at some high FPS and redrawn constantly just like anything in the game.

Doesn't that seem weird to you? I mean, why would it be rendering, as fast as it can (probably much faster than the refresh rate of the display if it's getting hot doing a simple scene on a fairly powerful laptop) a non-moving scene in an editor pane?

I get that it's nice to be able to reuse the engine code that you use to render a game, and that a lot of people like their games to render more frames than they're actually going to see for some reason, but it still seems kind of lazy and stupid to not at *least* slow the FPS down to the display refresh rate in the editor. And really an editor shouldn't be redrawing at all unless something changes. Can it really be so hard to make this small concession to users' graphics cards / power supplies / air conditioners?

# ? Aug 5, 2014 23:51

Inverness: Feb 4, 2009; Fully configurable personal assistant.

Jo posted:

I don't think I'm storing a reference to the player in the Unreal code, am I? I _am_ in the Unity code because it makes it faster to check the transform. In the UE code, if I gave the item to whatever pawn collided with APickup, is there a chance a non-player character could pickup the item, or are the pawns solely players?

As for the raycast, you're right. I shouldn't have said that. I do still have work to do on that code, though. It's not "complete" in the sense that I haven't overridden any collision overlap function or implemented the check to see if someone's inside.

Both players and AI characters can have pawns.

quote:

The Unity example is checking to see if the distance from the player is less than the pickup threshold, yes. I get that it means the player could theoretically pick up an item through a wall, but that fix is a raycast away. Wouldn't a sphere collider in the Unreal example also have the same problem of picking up things through walls? Why is a sphere collision 'more correct' than checking the distance?

Well you could also make the sphere bump the wall so it never intersects, in which case you can't pick it up through the wall. A sphere collision is more correct because you're letting the physics system handle the details when it comes to collision checking instead of manually performing checks every frame for a specific actor. You shouldn't be referencing the player directly like that. Instead you would check whatever pawn collided with the sphere to see if it is eligible for pickup. The existing physics system is also integrated with the editor, blueprinting, and whatever else uses it.

quote:

I think it's not an unfair comparison. I'm showing what it takes to have an object which is visible, has physics, and can be picked up (or have a pickup function be called) in Unity and in Unreal. The means by which they need to have this done are different, yes, but I think it qualifies well my argument that Unreal has more 'boilerplate' code to get things going. I can't just make a component and attach it to an object. I need to either make a new object, subclass an object (maybe rework my hierarchy), or fiddle with Unreal's component system (which I haven't tried yet). It's not so much that C++ is more verbose than C# (it is, but that's not really why the example is longer), it's because when I make an object in Unreal I need to define my Mesh object, my collision primitive, set the possibly overridable OnPickup function, and do all sorts of other things rather than add another behavior onto an object which has all these. The difference in length stems from (I'd estimate) 50% component versus inheritance and 50% C++ vs C#.

But that was my point, right? It takes longer to do stuff in Unreal because you have to write more.

Yeah it does take longer to do certain things in Unreal, but then, as I said, you're doing more. Unity both does a lot for you and limits what you can do, as far as I know. It's a tradeoff.

The reason I didn't feel it was a fair comparison is because both engines have existing systems for handling collision that you were not using. Raycasting every frame on a specific player reference seems like just about the worst way to do it. I'm sure the Unreal code would end up larger but it'd still make a better comparison if you were doing it properly for both.

Now then, I was just looking through the code for the newest ShooterGame example project for UE4, and found a pickup class that demonstrates just what we were talking about :
ShooterPickup.h
ShooterPickup.cpp
ShooterPickup_Ammo.h
ShooterPickup_Ammo.cpp

# ? Aug 6, 2014 01:52

Azazel: Jun 6, 2001; I bitch slap for a living - you want some?

I believe UE4 setting an OSX machine on fire (at least as of 4.1.1) was a known issue acknowledged by Epic.

Edit: Right, the second answers link nite time dinosaur posted was what I was thinking of.

Azazel fucked around with this message at 02:38 on Aug 6, 2014

# ? Aug 6, 2014 02:34

Jo: Jan 24, 2005; Soiled Meat

Inverness posted:

The reason I didn't feel it was a fair comparison is because both engines have existing systems for handling collision that you were not using. Raycasting every frame on a specific player reference seems like just about the worst way to do it. I'm sure the Unreal code would end up larger but it'd still make a better comparison if you were doing it properly for both.

That's true. I guess I could have an extra collider in Unity and use the OnCollisionEnter. I hadn't thought about that when I wrote it, but it would make the Unity code shorter. I'd just override the OnCollide or OnCollisionEnter. No need to raycast or any of that. That balances out the demo and Unity still ends up being less code. Again, this is just a side-effect of mostly component based versus inheritance based. That's what leads me to say Unreal Engine requires more boilerplate: to add functionality to what we'd think of as an in-game object, you need to subclass an object with the functionality, rather than simply making a component. I believe the latter leads to shorter code and faster development, but allows people to make bad decisions and doesn't punish lazy programming.

Inverness posted:

Now then, I was just looking through the code for the newest ShooterGame example project for UE4, and found a pickup class that demonstrates just what we were talking about :
ShooterPickup.h
ShooterPickup.cpp
ShooterPickup_Ammo.h
ShooterPickup_Ammo.cpp

The code I posted for the Unreal example was actually from Unreal's site. https://wiki.unrealengine.com/Introduction_to_UE4_Programming_-_3_-_Creating_the_Base_Pickup_Class

# ? Aug 6, 2014 03:28

Inverness: Feb 4, 2009; Fully configurable personal assistant.

Jo posted:

That's true. I guess I could have an extra collider in Unity and use the OnCollisionEnter. I hadn't thought about that when I wrote it, but it would make the Unity code shorter. I'd just override the OnCollide or OnCollisionEnter. No need to raycast or any of that. That balances out the demo and Unity still ends up being less code. Again, this is just a side-effect of mostly component based versus inheritance based. That's what leads me to say Unreal Engine requires more boilerplate: to add functionality to what we'd think of as an in-game object, you need to subclass an object with the functionality, rather than simply making a component. I believe the latter leads to shorter code and faster development, but allows people to make bad decisions and doesn't punish lazy programming.

That's true. I think Epic realizes that components are a superior model, but the problem is they have way too much code to just flip over to using them. They've been slowly moving actor code into components as time goes on. There is a tremendous difference between UE3 and UE4 code when it comes to that.

But still, remember that you're making your PickupHandler MonoBehavior to add in your code that actually works with the components. That is equivalent to the subclassing in Unreal in regards to where your component-using logic is going. Making an actor subclass with logic that uses components attached to it isn't that much different from making a component subclass that uses components attached to a common actor. Though of course the actor subclass is more limited in how you use it compared to a component.

Inverness fucked around with this message at 03:42 on Aug 6, 2014

# ? Aug 6, 2014 03:37

HexiDave: Mar 20, 2009

roomforthetuna posted:

Doesn't that seem weird to you? I mean, why would it be rendering, as fast as it can (probably much faster than the refresh rate of the display if it's getting hot doing a simple scene on a fairly powerful laptop) a non-moving scene in an editor pane?

I get that it's nice to be able to reuse the engine code that you use to render a game, and that a lot of people like their games to render more frames than they're actually going to see for some reason, but it still seems kind of lazy and stupid to not at *least* slow the FPS down to the display refresh rate in the editor. And really an editor shouldn't be redrawing at all unless something changes. Can it really be so hard to make this small concession to users' graphics cards / power supplies / air conditioners?

The trick would be knowing when something isn't happening - which isn't trivial with the game-rendering view. Material effects and more are continuously running in the view because you want to know what you're looking at, and things like motion blur and "bloom"/tone mapping happen AFTER movement over a period of frames. I have my editor open right now and I can see the skybox moving, and if I turn my camera a bit into the sun it will take a few seconds to adjust the coloration.

nite time dinosaur:
You can hit Ctrl + R (or go to the viewport, hit the little drop-down button, and uncheck "Realtime") to turn constant rendering off, though - see if that helps with your rendering problems.

# ? Aug 6, 2014 04:03

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

HexiDave posted:

nite time dinosaur:
You can hit Ctrl + R (or go to the viewport, hit the little drop-down button, and uncheck "Realtime") to turn constant rendering off, though - see if that helps with your rendering problems.

Oh good, so it's not that hard to make the concession to not heating up graphics cards.

# ? Aug 6, 2014 04:16

The King of Swag: Nov 10, 2005; To escape the closure,
is to become the God of Swag.

Some of you may remember from a few weeks back when I was posting about my UnitOf, unit of measurement conversion library that I was working on. Well, after getting sidetracked with my Fuzzy Logic library (which despite being free, sadly has less than two dozen downloads after two weeks on the Asset Store), I've gone back to working on the UnitOf library. Most of the hard work for the library had already been done from the other week; the remaining work is largely just the tedious stuff (writing all the unit conversions themselves), and polishing. The only actual hard part left to solve was the unit of measurement to displayable string, which I'm happy to say now works.

Given a format string and a unit of measurement, it'll generate a string which nicely prints the measurement, not just in the specified unit, but also in dividing units. The system goes another step further to select the best fitting unit for the format string and measurement you present it.

code:

Length testLength = Length.Meters(15.250004);

Debug.Log(testLength.ToString(UnitOfLength.Meters, "U3d2S"));
Debug.Log(testLength.ToString(UnitOfLength.Meters, "u3d2s"));

Debug.Log(testLength.ToString(UnitOfLength.Yards, "U3d2S"));
Debug.Log(testLength.ToString(UnitOfLength.Yards, "u3d2s"));
Debug.Log(testLength.ToString(UnitOfLength.Yards, "d3S"));

Outputs:
15 m, 25 cm, 4 �m
15 m, 2 dm, 5 cm // dm is decameter

16 yd, 2 ft, 0.39 in
16 yd, 2′, 0.39″
16 yd, 2 ft, 393.858 mil

Here's the format arguments:

S -- Display symbols for units. Omitting this argument and s means that no unit symbols will be displayed.
s -- Display secondary symbols instead of primary symbols (S). Examples of secondary symbols are � for degrees, and ″ for inches.
U# -- How many units the measurement can be split into, with # replaced by the number. Dividing units are smaller units that can be used to split up the larger unit. U3 used with a measurement of 3.324 meters, would produce "3 m, 32 cm, 4 mm". Omitting this and u# means that the measurement will be divided as many times as possible.
u# -- Same as U#, but allows the use of uncommonly used units in addition to the more common units available. The previous example with uncommon units used, would instead output "3 m, 3 dm, 2.4 cm".
D# -- The absolute number of decimal places to display, with # replaced by the number of decimal places. Omitting this argument and d# defaults to the same behavior as d#, with the maximum supported number of decimal places.
d# -- The max number of decimal places to display, with # replaced by the max number of decimal places. Omitting this argument defaults to the max number of decimal places supported by Math.Round.

P.S. I pride myself a bit on writing code that doesn't allocate any memory unless it absolutely needs to, just because of how terrible the GC for Unity's Mono is. Even after two days of optimization (both performance and code wise), the ToString/formatting methods still allocate a (relatively) lot of memory and perform multiple boxing operations per call. Working with strings in general is part of it, but the complexity needed to accomplish what you see above contributes to the problem too. Maybe not surprisingly, but there's a lot of work that needs to go into both format string and output string parsing to make everything work, not to mention the calculations that need to go on to decide the proper units to display as the unit of measurement is divided down.

The King of Swag fucked around with this message at 04:33 on Aug 6, 2014

# ? Aug 6, 2014 04:18

Dirty: Apr 8, 2003; Ceci n'est pas un fabricant de pates

nite time dinosaur posted:

It's fine that the computer goes to 100% sometimes. I get that. It just seemed like it was going to be painfully slow when I actually started using it. Is this a difficult concept, or am I missing something where everyone who uses UE4 has their GPU cranking at 100% the entire time it's running?

Okay. You originally said that the problem was that the computer got "hotter than I'd like", that it was "was so hot it was painful to touch" and you "can't imagine what would happen if I tried to do anything". I don't think it's unreasonable to assume that your misgivings were about heat. And it looks like I'm not the only one who got that impression.

# ? Aug 6, 2014 08:51

nite time dinosaur: Sep 12, 2011; this is what you get when you mess with us

Dirty posted:

Okay. You originally said that the problem was that the computer got "hotter than I'd like", that it was "was so hot it was painful to touch" and you "can't imagine what would happen if I tried to do anything". I don't think it's unreasonable to assume that your misgivings were about heat. And it looks like I'm not the only one who got that impression.

Yeah, it's totally on me that there was confusion.

# ? Aug 6, 2014 15:10

The King of Swag: Nov 10, 2005; To escape the closure,
is to become the God of Swag.

So I'm apparently really bad about betting on the wrong horse; I purchased Daikon Forge not that long ago, and now it's announced that they're no longer developing it and it has been removed from the Asset Store: http://www.daikonforge.com/forums/threads/now-disappeared-from-the-asset-store.2235/

While the Asset Store is very much "buyer beware", I can't help but feel cheated. Daikon Forge was not a cheap asset, so purchasing it only to have it discontinued shortly after is really lovely.

# ? Aug 7, 2014 02:31

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Yeah that's sucks but I guess it's like any other piece of software. I'm not familiar with the plugin but reading those forums you linked makes the author seem really dodgy.

# ? Aug 7, 2014 02:36

The King of Swag: Nov 10, 2005; To escape the closure,
is to become the God of Swag.

Yodzilla posted:

Yeah that's sucks but I guess it's like any other piece of software. I'm not familiar with the plugin but reading those forums you linked makes the author seem really dodgy.

Daikon Forge was the other major alternative to NGUI.

# ? Aug 7, 2014 02:39

The King of Swag: Nov 10, 2005; To escape the closure,
is to become the God of Swag.

Sorry to double-post, but this is serious bullshit. Because Daikon Forge has been pulled from the Asset Store, it's been purged from my purchase history (others are reporting the same), which means that since I don't have a local copy of the last version, I can't even continue to use that. I didn't lose money on a product that's no longer supported, I've thrown my money into a god drat hole and have nothing to show for it.

I know for a fact that it won't do any good, since the asset store licensing agreement explicitly states that this is something in their right to do, but I'm going to get a hold of them and demand my money back, anyway, if only for piece of mind.

# ? Aug 7, 2014 03:08

Yodzilla: Apr 29, 2005; Now who looks even dumber?

Beef Witch

Ah okay. Well that definitely sucks then.

# ? Aug 7, 2014 03:10

Adbot: ADBOT LOVES YOU

# ? May 11, 2024 10:05

FuzzySlippers: Feb 6, 2009

You can try but Unity's position is that refunds can only happen at the asset author's discretion.

It's a shame these code assets aren't in a locked repo or something and people could try to continue to patch and submit their modifications for the benefit of other registered users. I'm actually not sure what an alternative asset store setup would look like but this straight cash for zipped code setup feels like it could be improved.

I switched back to NGUI from DF when the authors were talking about having to do a bottom up rewrite to fix some of their persistent problems. Daikon has an easier setup but NGUI 3.x is fine once you get passed the initial pain.

# ? Aug 7, 2014 03:27

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »