Game Development Megathread

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

«‹›3 »

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Serenade posted:

Do Unity CustomEditors not work when they're from a dll?

Most of my coding is done in a managed plugin. I have a MonoBehaviour and a CustomEditor of that MonoBehaviour, but the editor only works if I manually copy the code files into the unity project rather than use them from the dll. Is this known functionality or is there some strange editor trick I'm overlooking?

How have you set it up? You need 2 dll's, and editor dll and a player dll. the editor dll needs to be placed in an Editor folder.

# ¿ Jan 21, 2017 17:57

Adbot: ADBOT LOVES YOU

# ¿ May 23, 2024 03:51

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Joda posted:

Does anyone here have any experience with ImGui? I'm using it to build my debug system, and was wondering if there was a way to create a scrollable multiline textbox for console output that isn't editable?

https://docs.unity3d.com/ScriptReference/GUI-enabled.html

# ¿ Jan 29, 2017 18:51

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Joda posted:

Thanks, but this is Unity's GUI system, not ImGui.

That's confusing because unity's inbuilt UI system is called IMGUI also

Sorry!
https://docs.unity3d.com/Manual/GUIScriptingGuide.html

# ¿ Jan 31, 2017 19:12

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Doctor Soup posted:

If your object is registered to a Unity event, you don't have to worry about the event keeping the object from being garbage collected because Unity uses weak references to store registered listeners and nothing will be called on or passed to the object once all other references are cleared (if it's a monobehavior then you'll also need to call Destroy on it or its game object).

This isn't true (I literally wrote the feature). When the system was being designed the idea was toyed with but abandoned due to the fact that they are generally used to mange UnityEngine.Object refs. Under the hood it uses normal delegates.

That being said, you can destroy UnityEngine.Object by calling destroy and the UnityEvent will clean that out (as we can check if the native side has been destroyed). Under the hood though, implicit weak references are not used.

# ¿ Feb 3, 2017 01:15

stramit: Dec 9, 2004; Ask me about making games instead of gains.

BirdOfPlay posted:

Fun fact: Unity purposely overloaded the null check to include cases of the attached GameObject being in the Destroyed state, so that it plays nicely with the managed side of the engine. See here for an explanation about it.

One of the dumbest things the engine does imo.

# ¿ Feb 3, 2017 01:42

stramit: Dec 9, 2004; Ask me about making games instead of gains.

I'd put money on the runtime upgrade landing not too far off.

# ¿ Mar 22, 2017 22:07

stramit: Dec 9, 2004; Ask me about making games instead of gains.

leper khan posted:

next year

quote:

So, in 2017.1 this will all ship as an option/experimental
Which means users can opt in and try stuff
If you opt in (per project) in 2017.1
You get all new. New runtime, C# 6, and .Net 4.6 class libraries
To be clear, an option in the normal build
Not a special build

Plans may change as this isn't in mainline yet, but 2017.1 beta should be available in a few weeks I think.

Only registered members can see post attachments!

# ¿ Mar 23, 2017 14:50

stramit: Dec 9, 2004; Ask me about making games instead of gains.

leper khan posted:

Any insight on if this has the same issues as the uwp .net core stuff?

Needing to replace all my threads with tasks, etc.

Are you referring specifically to unity + uwp + .net core? Yeah that was a rough one. I believe we are transitioning to IL2CPP there so you still get threads and all that nice stuff and don't need to change out your code.

What I'm talking about is full .net, not core .net... so should 'probably work mostly'.

# ¿ Mar 23, 2017 15:33

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Stick100 posted:

Thank you, this is awesome. Async and await will be a game changer for Unity devs.

I hear they generate a lot of garbage in the back end, I have not tested myself yet though

# ¿ Mar 23, 2017 15:52

stramit: Dec 9, 2004; Ask me about making games instead of gains.

xgalaxy posted:

Regarding async.

Is Unity going to provide a UnitySynchronizationContext. You can't do async (async, tasks, await) without a synchronization context. So either Unity provides one or we have to make our own that latches onto a Monobehaviour and write out all of that boilerplate code to make it work. I'd prefer Unity provide a default one.

This is what i've been told, not tested myself:
The context exists on another thread (not the main thread) so you can't do internal unity API calls on it (unless they are thread safe), when you wait on the task it will resume flow back on the main thread, so you can do any integration work / api calls at that time.

That being said I've played a lot with the thing talked about here:
https://www.youtube.com/watch?v=lHoRY0Mi3kA&t=611s

This is a really exciting piece of tech and as nice as asyc / await is this is much more targeted for game development.

# ¿ Mar 23, 2017 19:01

stramit: Dec 9, 2004; Ask me about making games instead of gains.

https://docs.unity3d.com/ScriptReference/Light-cullingMask.html

This is a better way than shadows, you won't have the overhead or rendering shadows with this method.

# ¿ Mar 26, 2017 09:17

stramit: Dec 9, 2004; Ask me about making games instead of gains.

ApproachingInfinity posted:

Never mind, apparently MaterialPropertyBlocks do in fact break batching. In any case, unless your use is particularly extreme, you probably won't have any issue. Are you able to share screenshots of what you're thinking of doing?

There are two things here:

*Changing material
*Issuing a draw call

Using MaterialPropertyBlocks will result in one SetPass call (binding the material) and two draw calls, using the same material, it is a broken batch, but relatively inexpensive.

Using a differnt material will result in two SetPass calls, and two draw calls. The SetPass is expensive, so using MPB's is good.

Additional info: You can use instancing with MPB's if you write your shaders to do instance rendering (it's a big win), so you can get multiple objects into one draw call.
Additional Additional info: Disable dynamic batching unless you are a very very very low end mobile device. It's a net loss on performance on any modernish device, even if there are more draw calls.

Elentor posted:

It should be no news that the Unity API and consistency are not the closest friends.

Yeah

It's improving though. Internal API advisory board + fixing up old api's. poo poo takes time though.

# ¿ Apr 8, 2017 10:13

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Elentor posted:

Some stuff (Shuriken and UI comes to mind) is really non-intuitive though.

I think this comes from one of the big changes that has happened to engine features in unity over the past few years. For the longest time most systems in unity were relatively simple. Like audio or mesh API's. You would just configure some values and internally the c++ systems would use these values for configuration. In the newer systems there is much more 'integration' and communication between existing unity systems. For example in UI it needs to talk with rendering, physics (for raycasting), batching, mesh generation + others. This leads to these userfacing features needing many more hooks and touch points. This leads to more complex API. The way I think of it is at this stage it's not really an API, but a framework, and that ratchets up the level of complexity needed to operate with those systems.

quote:

Sorry if this comes up a lot - are you the same Strumpy who works for Unity?

Yes, I'm working on our new rendering framework at the moment

# ¿ Apr 9, 2017 08:27

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Elentor posted:

Any spoilers? My technical artist side gets really curious about these things.

https://github.com/Unity-Technologies/ScriptableRenderLoop

It's not a secret, we are just not talking about it a whole bunch yet because it's still immature. It's more programmer focussed than artist focussed. If you are on 5.6 and want to play with some graphics programming it's already available there

# ¿ Apr 9, 2017 09:57

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Elentor posted:

Strumpy, since you're working with the rendering pipeline directly - are there any plans to add native supersampling/renderscale?

You can supersample now by rendering to a 'larger' render texture then scaling on final blit. it's not the best thought. In the render pipelines you'll have explicit control over this and can do whatever you want with a minor amount of scripting.

quote:

Also, any way of being able to render outside the canvas to improve screen-space effects?

What do you mean my canvas in this question? And which screen space effects?

# ¿ Apr 20, 2017 12:08

stramit: Dec 9, 2004; Ask me about making games instead of gains.

BirdOfPlay posted:

It's on the roadmap for Unity 2017.1 (they're switching to a year-based numbering system for their majors now). It's currently in a public beta with a release set for next month.

yep, its opt in currently but it's the player options. i've been using it with no troubles.

# ¿ Jun 27, 2017 23:20

stramit: Dec 9, 2004; Ask me about making games instead of gains.

My big switch came when I started to get actually proficient at programming. It slowly changed from a thing that felt like a 'learning activity' to something that became my default activity. I massively minimized my game playing and switched to coding instead. At the very least just try and do 15-20 minutes a day... habit forming helps.

# ¿ Aug 7, 2017 14:54

stramit: Dec 9, 2004; Ask me about making games instead of gains.

leper khan posted:

Unity�s canvases are also really easy to lay out UIs in. And typically not hard to wire up after the fact. There are some things that are missing from the ugui, but it�s mostly straightforward to work with.

Most of the problems I�ve seen people have with UIs in unity stem from them not wanting to adapt their workflow to the editor. Unity was designed to keep you in the editor as much as possible. This is a feature, not a bug. As soon as you adapt to the mindset that the editor is what matters, your code gets much simpler and things fall into place much easier.

Feels good to hear this

I ended up as the lead developer of the Unity UI system (through no fault of my own) and there are parts of working on that project that still haunt me. There are some great bits (eventing system, anchoring system, extensibility) and some really really nasty bits (auto layout system, under performing batching). That being said there are two groups of people I talk to with opinions on it, some people really really love it and think it's the best thing ever, and other think it's the worst thing unity has ever shipped. It really comes down to what people expect out of the box. We set the goals for the project to be a highly extensible system that users can customize for their projects.... a lot of people just wanted a massive library of premade widgets...

# ¿ Dec 5, 2017 16:38

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Elentor posted:

I do however have trouble with the event system and how the whole thing is highly dependent on you anchoring stuff on the interface. Simple things like arbitrarily detecting clicks via code are a lot more obtuse than they should be.

Agree. Some design decisions are not too entrenched to toll back without breaking user projects

# ¿ Dec 5, 2017 17:16

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Veni Vidi Ameche! posted:

Do you have recommendations for educational resources for someone who's thinking about making his entire puzzle game out of UI elements?

Sorry, I moved away from that project about 3 years ago and back into graphics development. Lately I've had my hands in Post processing, scriptable rendering, and 'secret project' (announced next week for 18.1).

Suspicious Dish posted:

As a Tool engineer I really wish I could do the same things in the editor with your panels but it really feels I'm just given OnGui and told "go". Moving outside of the default Unity Editor Widgets is really scary.

Easiest most low impact way is to get in on https://docs.unity3d.com/ScriptReference/PropertyDrawer.html Not too scary, pretty isolated and you can start to make your normal inspectors look really good. We have some heavily improved Tool UI API's coming very soon and I've been using them for my current project.

# ¿ Dec 8, 2017 14:52

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Elentor posted:

It's not a joke but Strumpy said a year or so ago that the functionality to implement it might come up in the SRPs.

I think there might have been a slight misunderstanding. The feature won't come with SRP, but you'll be able to implement it yourself on-top of SRP yourself. There are a number of papers that describe the technique (https://docs.nvidia.com/gameworks/content/gameworkslibrary/graphicssamples/d3d_samples/antialiaseddeferredrendering.htm). That being said now in the world of PBR, one of the biggest issues is specular aliasing that won't be fixed with deferred MSAA. It's the main reason TAA exists now.

quote:

I ask about SRPs in Discord from time to time because their documentation is not exactly up-to-date but no one knows anything about it, it's like the black box of Unity features as it is. So I have no idea if the functionality is there or not.

I'll even settle for an answer like "it's never coming, Elentor, we thought about it and realized that the tools won't be available."

Yeah, so it's experimental. Scheduled release is 18.1. I was literally writing docs for it yesterday.

# ¿ Dec 9, 2017 21:37

stramit: Dec 9, 2004; Ask me about making games instead of gains.

Obsurveyor posted:

*sigh* 1 step forward, million steps back. They really should be integrating less stuff into the editor and pulling poo poo out, not more and more.

Shipped via package manager so it's basically optionally there and can be updated out of stream with Unity main product.

# ¿ Feb 16, 2018 15:32

Adbot: ADBOT LOVES YOU

# ¿ May 23, 2024 03:51

stramit: Dec 9, 2004; Ask me about making games instead of gains.

OneEightHundred posted:

Real-time ray tracing is in my "I'll believe it when I see it" pile with voxels and blockchain.

The real advantages of the new tech going to come from what it can do on the tooling and workflow side while the hardware catches up over however long it takes to become reality.... and even if it stays; just for tooling (fast lightmap bakes), baking lighting on level load instead of part of the build, or allowing (non prohibitive) lightmapping in procedural games... I'm all for that.

# ¿ Mar 26, 2018 06:38

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

«‹›3 »