|
StickFigs posted:Do I need to worry about obfuscating my Unity C# .dlls? I want to release a tool on the Asset Store soon and I'm going to compile my Editor .cs files into a DLL but I'm pretty sure someone could come along and decompile the DLLs easily and steal my work. They can, no-one cares about your stuff though.
|
#
?
May 9, 2016 22:31
|
|
|
|
| # ? Jun 9, 2024 08:12 |
|
|
StickFigs posted:Do I need to worry about obfuscating my Unity C# .dlls? I want to release a tool on the Asset Store soon and I'm going to compile my Editor .cs files into a DLL but I'm pretty sure someone could come along and decompile the DLLs easily and steal my work. Something like ILSpy will give you pretty much all the source code from a Unity dll with one click of the mouse. Even if you run it through an obfuscator first, there are deobfuscator tools that are just as easy to use. The reality is if someone wants to copy your stuff you cant stop them. But that applies to every piece of software ever made, so dont worry about it.
|
|
#
?
May 10, 2016 01:24
|
|
|
If you have code valuable enough to steal, you probably have lawyers to sue anyone who steals it.
|
|
#
?
May 10, 2016 01:50
|
|
|
Fair enough.
|
|
#
?
May 10, 2016 04:53
|
|
|
StickFigs posted:Do I need to worry about obfuscating my Unity C# .dlls? I want to release a tool on the Asset Store soon and I'm going to compile my Editor .cs files into a DLL but I'm pretty sure someone could come along and decompile the DLLs easily and steal my work. Also you'll get slammed on asset reviews if you release without source. It's expected to give source (or easy access) on almost every asset now (look at Probuiler or uFPS). Don't take that as a requirement or suggestion just info before you submit.
|
|
#
?
May 10, 2016 07:24
|
|
|
Not having source is pretty much a no sale for me. I buy stuff to save myself time and if something breaks or doesn't work the way I need it to, I want to fix/optimize it myself, not wait on an author that may have different priorities than me.
|
|
#
?
May 10, 2016 14:18
|
|
|
If I release as source is there a license I should apply to my code? I've only ever seen licenses on free code.
|
|
#
?
May 10, 2016 14:39
|
|
|
StickFigs posted:If I release as source is there a license I should apply to my code? I've only ever seen licenses on free code. The Unity Asset Store license covers you from what you're probably worried about but I think you can include your own licenses these days too.
|
|
#
?
May 10, 2016 15:15
|
|
|
TheresaJayne posted:For thos beginners, I found a website to help with some of the tricky ideas and concepts (in all languages) to do with games. - Even I fell short on a couple. hi hello thank you Easy is just far enough past my comfort level to be useful. Gonna be doin this a lot, probably.
|
|
#
?
May 10, 2016 16:35
|
|
|
leper khan posted:If multiple threads will be running, you should probably care about data races generally unless you can guarantee that only a single thread will interact with a given object/state. Locking code isn't that difficult, especially with RAII. I'll check on that. The multi-core stuff isn't my code, and was made by people who seem to know what they're doing technically, but I'm also thinking about generating more threads to do real-time loading, and I'm not sure if it would let another thread grab one of the entities it's loading. Locking down that particular thread should be super-easy, though, if I go with creating and destroying it as needed. I just asked in the C++ thread if that would be a performance-killer, I've never worked with multithreaded C++ before. Wait, looking into this some more, does the scheduler direct all the traffic? Seiken said I would need to write the code myself, but according to a thread on cplusplus, the scheduler organizes what gets put on each thread, so it seems like if the thread was occupied by the NPCs and their inventories being loaded, everything else would get shunted to the other thread. Or did he mean that after the loading was done, I would need to make the loaded stuff available to both cores? I don't really understand. 22 Eargesplitten fucked around with this message at 18:16 on May 10, 2016 |
|
#
?
May 10, 2016 17:46
|
|
|
22 Eargesplitten posted:I'll check on that. The multi-core stuff isn't my code, and was made by people who seem to know what they're doing technically, but I'm also thinking about generating more threads to do real-time loading, and I'm not sure if it would let another thread grab one of the entities it's loading. Locking down that particular thread should be super-easy, though, if I go with creating and destroying it as needed. I just asked in the C++ thread if that would be a performance-killer, I've never worked with multithreaded C++ before. You are responsible for ensuring that any shared memory doesn't get into an inconsistent state. As long as you don't do anything complicated, like have blocked threads help with computation, it really isn't that difficult. std::lock_guard is your friend. You're also responsible for joining or terminating the thread. The OS is responsible for scheduling how to get all the threads to proceed. You are responsible for deciding what the threads do. You probably don't need to worry too much about the scheduler, but you should be aware that any of your threads could be preempted for something more important for any amount of time.
|
|
#
?
May 12, 2016 03:34
|
|
|
22 Eargesplitten posted:I'll check on that. The multi-core stuff isn't my code, and was made by people who seem to know what they're doing technically, but I'm also thinking about generating more threads to do real-time loading, and I'm not sure if it would let another thread grab one of the entities it's loading. Locking down that particular thread should be super-easy, though, if I go with creating and destroying it as needed. I just asked in the C++ thread if that would be a performance-killer, I've never worked with multithreaded C++ before. Creating and destroying threads is pretty inefficient, especially for something that happens all the time like real-time loading. You might instead want to look into std::condition_variable and the event queue pattern. Essentially you just start another thread and keep it dormant until it needs to load something, then broadcast for it to wake up when it does. You transmit what you want the loader to do by sending messages to event queues which you can lock and unlock for reading / writing, and transmit back to the main thread when you're done with loading / unloading whatever. I used this approach for graphics streaming and it seemed to work okay, although it's not the only way to do it. More advanced approaches would involve having as many threads as you have cores and pooling processing between threads as much as possible, but that's something that you probably don't want to go into unless you want to squeeze as much performance as possible out of your code.
|
|
#
?
May 13, 2016 00:53
|
|
|
Purple Prince posted:I used this approach for graphics streaming and it seemed to work okay, although it's not the only way to do it. More advanced approaches would involve having as many threads as you have cores and pooling processing between threads as much as possible, but that's something that you probably don't want to go into unless you want to squeeze as much performance as possible out of your code.
|
|
#
?
May 13, 2016 01:49
|
|
|
Purple Prince posted:Creating and destroying threads is pretty inefficient, especially for something that happens all the time like real-time loading. You might instead want to look into std::condition_variable and the event queue pattern. Essentially you just start another thread and keep it dormant until it needs to load something, then broadcast for it to wake up when it does. You transmit what you want the loader to do by sending messages to event queues which you can lock and unlock for reading / writing, and transmit back to the main thread when you're done with loading / unloading whatever. Thanks, I'll look into that. I had been thinking about running two threads for most of the game and then keeping a third thread up for loading and removing stuff. That seems kind of similar, except it only activates the third thread when necessary. Does that give a performance boost over keeping it awake the whole time? If I'm reading the summary right, you can lock the whole queue until you want it to unlock and give the data to the program. That sounds like exactly what I need. The loading tends to take between 1/2 and 3 seconds on a single thread on a single core, so putting it on its own thread allowing multiple cores should still keep it close to that. The next thing up is also going to be optimizing how things are loaded, so that should help as well. I'm just getting started with this engine, but the people I work with have been giving me all sorts of ways the game is loading unnecessary stuff, which extends the loading time as well as bloating the game in memory.
|
|
#
?
May 13, 2016 03:39
|
|
|
If you just try something and know how to profile it, you'll figure out what works what doesn't probably faster than reading internet words. Use a profiler where you can see what's active on what processor core and you'll see stalls and bubbles and for the most part it should be really obvious. Make sure your file io makes sense too. A lovely hd should be able to read a hundred megs in a second. That's a good amount of high res textures or models.
|
|
#
?
May 13, 2016 03:59
|
|
|
Okay, I'll check on that part. I thought platter drives only had that kind of read speed on sequential data? It's definitely possible that the game is randomly generating a bunch of stuff about all of the entities at that point too. In the next couple days I should be able to get into that. I've been trying to build the whole solution to make sure everything's working, but I'm giving up on that and letting the lead sort out what could be making stuff work on his machine but not on the other programmers' machines. I'm just going to dig into it, try to set some stuff up, try building that part independently, and then if I get something working I'll send it to him to test. He builds in less than half the time I do, anyway. Is there a profiler that has an overlay? I only have one monitor. 22 Eargesplitten fucked around with this message at 08:13 on May 13, 2016 |
|
#
?
May 13, 2016 07:33
|
|
|
22 Eargesplitten posted:Thanks, I'll look into that. I had been thinking about running two threads for most of the game and then keeping a third thread up for loading and removing stuff. That seems kind of similar, except it only activates the third thread when necessary. Does that give a performance boost over keeping it awake the whole time? If I'm reading the summary right, you can lock the whole queue until you want it to unlock and give the data to the program. That sounds like exactly what I need. It's unlikely to have much impact on your game's performance, but it does make it play a lot nicer with everything else in memory: chances are you don't want your application hogging a whole core while sitting dormant. By blocking a thread you let the OS use the core which it'd otherwise be stealing resources from to do other stuff. And yeah, mutexes are symbolic locks so you can lock anything you want with them. My preference would be to only interact with the queue when sending / receiving notifications though. One of my current projects is a very similar system to what you're describing, and in that I use two queues, one for input to the loading thread, the other for output from the loading thread to the main thread -- this seems to help a lot with keeping messages under control.
|
|
#
?
May 13, 2016 09:41
|
|
|
Generally speaking you only want to use threading when it's absolutely necessary. If you can do everything on one core in a reasonable amount of time it's best to just keep it on one core. Parallel processing is always a gigantic headache that can produce nasty bugs that can be incredibly difficult to fix. Multithreading is especially prone to Heisenbugs.
|
|
#
?
May 14, 2016 14:19
|
|
|
ToxicSlurpee posted:Generally speaking you only want to use threading when it's absolutely necessary. If you can do everything on one core in a reasonable amount of time it's best to just keep it on one core. Parallel processing is always a gigantic headache that can produce nasty bugs that can be incredibly difficult to fix. Multithreading is especially prone to Heisenbugs. But most computers are at least dual core, its better if you can split calculations across cores to make it better - this is one thing that would make games work better on most platforms
|
|
#
?
May 14, 2016 14:56
|
|
|
TheresaJayne posted:But most computers are at least dual core, its better if you can split calculations across cores to make it better - this is one thing that would make games work better on most platforms That depends on how much your program is taxing the individual cores. Performance improvements don't matter if they aren't noticeable. For example if your game absolutely never uses more than 25% of the computational power of one core you don't need to multithread it and probably shouldn't. It's similar to improving the algorithms; if the game just plain doesn't push the processor at all you don't need to optimize it. Generally speaking (there are, as with all things, exceptions) if a program can get good performance on one core you run it on one core.
|
|
#
?
May 14, 2016 15:08
|
|
|
ToxicSlurpee posted:Generally speaking you only want to use threading when it's absolutely necessary. If you can do everything on one core in a reasonable amount of time it's best to just keep it on one core. Parallel processing is always a gigantic headache that can produce nasty bugs that can be incredibly difficult to fix. Multithreading is especially prone to Heisenbugs. Sorry if I already stated this, I've been talking about this in at least two threads. The game isn't fully open-world, but it is big enough that it has to load in any non-terrain / building assets as the player comes within a certain range. The way the devs made it, the game stops in its tracks until everything is loaded. I want to bring in a second thread to do the loading so the rest of the game can continue on without stuttering. There's also the option of having the loading happen between multiple frames rather than a single one, but that's run into some errors when it has to destroy something that it hasn't finished creating. It's a rare error, but it causes a CTD whenever it happens. It sounds like that might be caused by a data race itself, does that sound right? From what little I've been able to find about open world design, it seems like having a thread dedicated to loading isn't uncommon. I'm going to keep the possibility of having a second main processing thread in mind, but for now I think I'll just have the one thread that handles almost everything and the other that does loading. Stalker is generally CPU-bound rather than GPU-bound, so having multiple threads for the normal tasks might help, but it might not be necessary. We were also thinking about a 64-bit conversion, but odds are that won't really be necessary with the other improvements we're making, either.
|
|
#
?
May 14, 2016 18:16
|
|
|
Anyone using the Unity for the HTC Vice? Any scripts I should know/ be aware of? SteamVR is working and my headset works as it should, just wondering if there are some must have libraries.
|
|
#
?
May 14, 2016 18:27
|
|
|
22 Eargesplitten posted:The way the devs made it, the game stops in its tracks until everything is loaded. I want to bring in a second thread to do the loading so the rest of the game can continue on without stuttering. Since you're looking at Stalker, the bigger problem, which is considerably MORE complicated than parallelizing game objects, is that Stalker appears to use blocking IO everywhere. It's full of calls that amount to "give me the data for this resource" where "this resource" might require a cold load from disk. There are only 2 ways to change that to background loading: One is untangle all of it and get everything to pull from background-loaded resources. This type of change is usually very difficult because odds are that the game is totally permeated with code that can't handle the concept of a partially-loaded object. The other is to preload data into an in-memory file cache so those blocking loads just return a pointer instead of hitting the disk. Doing this also is very difficult because it involves figuring out the dependencies of the data that you want to load, modifying the game logic to load it in advance, and probably updating the game data with preload hints. OneEightHundred fucked around with this message at 20:46 on May 14, 2016 |
|
#
?
May 14, 2016 20:43
|
|
|
Threading is also difficult because Direct3D / OpenGL are not thread happy at all. You can rarely upload geo and textures from anything but your GPU thread. So naively throwing threads at it is not going to solve things.
|
|
#
?
May 14, 2016 23:38
|
|
|
Mr Shiny Pants posted:Anyone using the Unity for the HTC Vice? Any scripts I should know/ be aware of? https://www.assetstore.unity3d.com/en/#!/content/32647 Valve made this plugin for Unity for the Vive. I do not know for sure if they used it on the lab but I'm pretty confident the lab was built in Unity. I haven't watched this recently but believe they talk about it at length here: https://www.youtube.com/watch?v=4Gs5k2Fti1U
|
|
#
?
May 15, 2016 03:22
|
|
|
I'm working on a level-based Unity puzzle game set up so that each level is its own scene. This was great when levels were cleanly separate but I have been trying to add overarching puzzles (call me Jonathan Blow) which tie together individual puzzles and require the player to traverse multiple levels after they've beat them and arrange the levels themselves to solve the big puzzle. Anyways I tried saving an array of moveable game objects as well as my hero game object in the puzzle manager object and getting it to persist like so. Please be gentle I know I'm a bad programmer  Also I wrote it with drumsticks heuheu  code:code:This also has not gone well. I don't even know what this is:  So instead of keeping data i want to save across levels in the GameManager I'm thinking why not write that data to a xml file and get rid of the persistent game objects and just arrange all the changeable objects on load if a save exists in the xml file. But due to how bad this has gone so far I'm really not confident that this is the way I want to go. Also, I love the simplicity of making new levels with my old structure (copy paste a my blank level scene, change the name to PuzzleX, arrange stuff, and it's all ready to go). So my questions are: 1. Is saving an XML file with persistent data but keeping levels as scenes viable? Or would it be better to have one level scene and just save all the level data in an XML file and load whichever level I need? 2. What are the cross browser implications of saving data files? We are planning on windows mac ios and android. 3. Since we are releasing in under two weeks, should I stop trying to do new overarching puzzles and just keep every level a disparate scene and refine that? I feel like i'm choosing between more polished but derivative or less polished and more experimental which makes me lean towards the latter but I want to avoid a turd if possible... Thoughts? Any advice would be much appreciated 
|
|
#
?
May 15, 2016 13:23
|
|
|
Don't change core game concepts two weeks before release... Does the game gate the levels? Or do you have them all in memory at the same time?
|
|
#
?
May 15, 2016 15:29
|
|
|
OneEightHundred posted:I could say a lot about multithreading, but I don't think that it's really going to be your main problem. Setting up async IO by itself isn't that hard (unless you're using the Windows overlapped IO calls, which are kind of obtuse), and there are several ways to do it. So, why can't you just load the data from the HDD at the point it needs it? Do all of those requests have to go through the main thread for that? Mostly-unrelatedly, I was under the impression that it did store a ton of unnecessary stuff in memory, which is why it bloats up to 3gb so quickly. Not NPCs and such, but stuff like weapon data and models.
|
|
#
?
May 15, 2016 17:42
|
|
|
22 Eargesplitten posted:So, why can't you just load the data from the HDD at the point it needs it? [snip] Hard drives are one of the slower things a program can rely on, especially if it's not solid state.  From the chart, it's roughly ~20ms to read a megabyte from a spinning disk (and I'm not sure if that includes the 10ms disk seek), which makes maintaining 60fps not-really-possible and would cause a game to stutter. Edit: so people try to load it in advance, and yeah, that means it all has to sit in memory. Maybe with Stalker, they couldn't safely fit everything into RAM at the same time? rarbatrol fucked around with this message at 21:19 on May 15, 2016 |
|
#
?
May 15, 2016 21:10
|
|
|
22 Eargesplitten posted:So, why can't you just load the data from the HDD at the point it needs it? Do all of those requests have to go through the main thread for that? Mostly-unrelatedly, I was under the impression that it did store a ton of unnecessary stuff in memory, which is why it bloats up to 3gb so quickly. Not NPCs and such, but stuff like weapon data and models. The short version of the original post though is that if a function call needs to load data from disk and that data is used immediately when the function returns, which looks like is how all of Stalker's IO works, then it will block the thread for however long it takes to get it from disk. If that requires a seek, that's about 9ms, which is half a frame at 60ms every time you do it. OneEightHundred fucked around with this message at 21:52 on May 15, 2016 |
|
#
?
May 15, 2016 21:20
|
|
|
Where are you reading Stalker's source code? Did they release the engine?
|
|
#
?
May 15, 2016 21:34
|
|
|
Suspicious Dish posted:Where are you reading Stalker's source code? Did they release the engine? edit: After looking into it some more, it looks like it's probably a leak, so removing the link. OneEightHundred fucked around with this message at 21:48 on May 15, 2016 |
|
#
?
May 15, 2016 21:40
|
|
|
Does that apply to Clear Sky and COP? I loved those games, if people can do even more with it, that's cool. Edit: Oh 
|
|
#
?
May 15, 2016 21:49
|
|
|
rarbatrol posted:Edit: so people try to load it in advance, and yeah, that means it all has to sit in memory. Maybe with Stalker, they couldn't safely fit everything into RAM at the same time? It's also possible that the relevant information is loaded and terrain is stored in memory but entities, bad guys, and such are not. Doing it that was is a matter of paring down the information as much as possible and discarding what isn't needed long-term. You can, for example, remember where Stalky McStalkerton is standing but remove from memory his model, his AI, and even what he's carrying if that stuff never changes then load it later. That's also a job for object pooling; you load stuff into memory then modify it depending on what you want to be there. So object 1 is Shooty McBandit one minute then later is Stalky McStalkerton. An hour later you head back to base and it's Fat Russian Guy Stuck in Box. I have no idea if that's actually how the game works but you know, it's a possible solution. This works if you have prefabs and stuff can be copies of each other. In that kind of game you could have a "human" model (or more likely "male human" and "female human") with morph channels, different skin textures, and different equipment models that are slapped together. That lets you eat less memory because everything is copies of prefabs. Then your pool of objects is just combinations of those. Then you only need to remember things like if Stalky McStalkerton has a different color of skin, a bigger head, a smaller stomach, and a different shirt than Fat Russian Guy Stuck in Box. If that's still too big there's always chunk loading the way stuff like Minecraft handles it. Unload chunks that get too far away and load needed chunks as necessary but only render them when they're fully loaded. It has its issues and can chug or lag a bit, especially on old computers, but still useful for huge, open worlds.
|
|
#
?
May 15, 2016 22:26
|
|
|
OneEightHundred posted:
Well, in that case I'm sure all I was given was legally reverse-engineered from what's available in the download. AFAIK, STALKER does do what the guy above me was saying about keeping track of where characters are and moving them / having them do their normal actions, but removing most assets until they are needed. On the other hand, they have a mesh for each experience level of each faction (8-9 factions with 4 levels each) and special meshes and textures for each unique NPC. And each time they need a new texture applied to a mesh they load a new instance of the exact same mesh. And they store data for all weapons until loading a save or switching zones, regardless of whether there are even any instances of it left in the game world. Why wouldn't having the hard drive access on a different thread than the rest of the game prevent the stuttering? I would think the rest of it would keep going while the other thread is accessing the HDD.
|
|
#
?
May 16, 2016 00:35
|
|
|
I would assume having that on a different thread should help as well. Race conditions shouldn't matter since I would think you'd request the resources from the hard drive far enough out that they'd be loaded in by the time you try to access them.
|
|
#
?
May 16, 2016 01:02
|
|
|
Yeah, on a single core it tends to take at most 3 seconds, even in the hugest load areas outside of a hub, so even with dual cores it shouldn't take long enough to have any sort of pop-in. In most cases it takes less than half a second for the 4-6 entities it tends to load in at once.
|
|
#
?
May 16, 2016 02:05
|
|
|
Mr Shiny Pants posted:Don't change core game concepts two weeks before release... Hmm I don't think so, but I'm not exactly sure. I mean all the scenes are in the project and it grabs them as it needs them, so they aren't in memory at one time? I thought about it some more and I think i'll just nuke the enemies and push blocks after you beat a level and that limits what I need to save dramatically so I can just use UserPrefs. Going to give this a try...
|
|
#
?
May 16, 2016 08:22
|
|
|
Can anyone remember how planar reflections work (or find a writeup)? I'm finding mostly writeups for "all the tech that came way, way after planar reflections that makes it look cooler" when, no, I really do just want a perfectly reflective floor that puts up incredibly unrealistic mirror reflections. Specifically, what is throwing me off is remembering which axis change, when creating a mirrored wall VS a mirrored floor. Most especially though, the distortions/UVs involved in mapping the resultant offscreen RT to the floor look like black magic. Surely there's a simple mathematical explanation for those, right? I mean I know the effect is a bit of a hack, but man. Here's the math for the camera mirroring:  ... and here's the shader for the floor:  ... which comes from a UE4 "just copy this and it works! no don't bother trying to parse it, just copy-paste!" tutorial for a mirrored wall. Whereas I need a mirrored floor, so, yeah. The camera mirroring is relatively straightforward, if slightly obnoxious to get my head around, but the shader is... I don't even know where to begin. Lots of weird distortions there. (EDIT: I'm probably going to cheap out and just do a dumb mirroring approach by negating the Z coord, which should work fine, but that doesn't help me with figuring out what's going on in that shader) Shalinor fucked around with this message at 17:37 on May 16, 2016 |
|
#
?
May 16, 2016 17:28
|
|
|
|
| # ? Jun 9, 2024 08:12 |
|
|
Why are you so worried about race conditions with asset loading? This is a really straightforward scenario. Load stuff in on a thread and let the main thread know it's ready. Everything needs to eventually go to the main thread because that's the only safe place to upload data on GL/DX.Shalinor posted:Can anyone remember how planar reflections work (or find a writeup)? To create a reflection matrix, you can do a bunch of linear algebra or just google "reflection matrix about a plane" which is probably going to give you a much better answer than I can. Remember that your triangle winding will be flipped -- if you look at something in a mirror, clockwise becomes counter clockwise. This is going to get a mirrored view of your scene, but that's not exactly what you want. You want some surface to be reflecting light using that data. So you need some way to combine it with the surface shader of the reflective object. If you perfectly reflected the camera, the sample point for your reflective object is just going to be the same pixel coordinate as an rendered pixel of the object. I.e. if you overlayed the reflected scene over the object, you'd see the correct reflection point. Remember that the screen space pixel is probably going to be different from the UV texcoord. Idk how unreal does its texcoords but GL's (0, 0) viewport origin is in the bottom left vs DX's top right. Usually I just try one way and if it doesn't work I try it the other way. I don't know unreal that well but it probably gives you a pixel coordinate in your shaders somehow. You might want to make your own camera reflection node if this doesn't exist... that node mess doesn't look like fun, and the math isn't hard. I mean, it's not even math, it's probably just copy pasting something from stack exchange. Sex Bumbo fucked around with this message at 18:46 on May 16, 2016 |
|
#
?
May 16, 2016 18:30
|
|