|
Even if GLSL isn't really recommended in Unity (kind of a pain to setup since Unity prefers DirectX on Windows), I still find this GLSL/Unity tutorial series really handy just to get the hang of shaders and how they work within Unity and materials and stuff.
|
# ? Feb 12, 2014 17:55 |
|
|
# ? Jun 7, 2024 07:45 |
|
So the new uGUI for Unity is currently in beta testing. I dunno if anyone saw this video yet? https://www.youtube.com/watch?v=GMtQB4am3Kw
|
# ? Feb 12, 2014 18:43 |
|
I'm making a platformer for a piece of uni coursework and the marks mentions this: "Game play is independent of platform capabilities (i.e. uses a model tick approach)". I've put a limit on the update loop to only update every so often so running too fast doesn't make it unplayable which might fulfil this but it still gets weird at low FPSs, and I don't know how to fix it. I've tried tying the player's movement to the delta time but it always ends up affecting the game play even more ie. changing the jump height. Any ideas on how that's done or have I already done everything I can just by capping the update loop?
|
# ? Feb 12, 2014 23:02 |
|
Praseodymi posted:I'm making a platformer for a piece of uni coursework and the marks mentions this: "Game play is independent of platform capabilities (i.e. uses a model tick approach)". I've put a limit on the update loop to only update every so often so running too fast doesn't make it unplayable which might fulfil this but it still gets weird at low FPSs, and I don't know how to fix it. I've tried tying the player's movement to the delta time but it always ends up affecting the game play even more ie. changing the jump height. Any ideas on how that's done or have I already done everything I can just by capping the update loop? If this is what I think it is, I see the same drat thing and I can't figure out what it is! Unity is saying I've got like 3000 fps for this little platform jumper but the physics time slice(it all happens in Update() which should be running 3000 times a second right?) seems like it's 30hz or something crazy low. So instead of nice smooth looking jumps, it jumps by millimeters(visually) on the screen. Motion blur helps a little but then it has faint trails. I never get that super smooth looking movement like other engines. Obsurveyor fucked around with this message at 23:17 on Feb 12, 2014 |
# ? Feb 12, 2014 23:13 |
|
Praseodymi posted:I've tried tying the player's movement to the delta time but it always ends up affecting the game play even more ie. changing the jump height. Any ideas on how that's done or have I already done everything I can just by capping the update loop? Instead of calculating his position based on his position in the last frame, calculate it based from the start of the jump?
|
# ? Feb 12, 2014 23:17 |
|
Yeah, I figure this is probably a bit of an edge case 'cause in platformers more than any other you have to have instant control over the player as well as smooth and predictable feedback. Eugh, I feel like I might end up making a class to handle input. The lecturer told us not to do it, but the guidelines point you towards a bullet hell shooter so I guess he didn't think it'd matter. Edit: do you mean use something like equations of motion to calculate height after the jump? Hmmmm, could do.
|
# ? Feb 12, 2014 23:20 |
|
Praseodymi posted:Eugh, I feel like I might end up making a class to handle input. The lecturer told us not to do it
|
# ? Feb 12, 2014 23:25 |
|
Well, he didn't say not to, he just said for what we were doing it'd probably be unnecessary, and for most people that seems to be right. I'm already storing a struct of bools for all the controls and then changing them depending on input for keyboard and controllers so I don't end up repeating myself, but I just kept it in the player class instead.
|
# ? Feb 12, 2014 23:30 |
|
Half the time I do controls in the player class, half the time it gets its own class. It depends upon the game complexity, yeah. Hmm, sounds like just having to apply timeslicing should do it. You may need to do some performance tests and benchmarks and see if the way you've got it set up to calculate the delta time is actually coming out properly, or maybe something is wrong with your physics calculation based on the delta? I'd be willing to bet whatever Unity function you're using to calculate the frame time isn't reliable. Above Our Own posted:I want to start getting into postprocessing. Are shaders what I need to look into? I have zero experience in this area. My toolkit right now is Unity and I'm more interested in 2D applications, but I really just want to expand my knowledge into this area so any general advice on where to get started would be appreciated. Yes! Shaders are how most everything is done in postprocessing nowadays (they're just programs that run on your GPU, 'shaders' are a misnomer really) They're pretty easy to get into and pretty fun to mess with. I've been playing with them in my spare time here and there. Just download a simple straight vertex shader and a texture lookup pixel shader and then start tacking on things here and there. Its all artistic stuff so I think the best way to learn is just to write a bunch of code and see what happens. Also check out examples of what other people have done here and there. But if you already understand programming GLSL/HLSL are easy to pick up, they're pretty much just subsets of C that are pretty restricted, and then go to town. I don't know anything about unity though. But if I were you I'd just download one of the shader lab programs or just write your own in C/C#/Java that just loads up your vertex and pixel shaders and then renders a quad, and then play with modifying those shader scripts. Or better yet render a cube so you can play with vertex shaders too. Zaphod42 fucked around with this message at 23:52 on Feb 12, 2014 |
# ? Feb 12, 2014 23:47 |
|
Obsurveyor posted:If this is what I think it is, I see the same drat thing and I can't figure out what it is! Unity is saying I've got like 3000 fps for this little platform jumper but the physics time slice(it all happens in Update() which should be running 3000 times a second right?) seems like it's 30hz or something crazy low. So instead of nice smooth looking jumps, it jumps by millimeters(visually) on the screen. Motion blur helps a little but then it has faint trails. I never get that super smooth looking movement like other engines. The other way of handling it is to set the "targetFramerate" value with something sane (like 60), but it's... finnicky, and not as trustworthy for all the same reasons you don't normally want to use vsync. EDIT: I'm glad that they're working on the UI, but that still looks miserable compared to NGUI. I hope it's still way, waaay in beta or alpha. Shalinor fucked around with this message at 00:01 on Feb 13, 2014 |
# ? Feb 12, 2014 23:50 |
xgalaxy posted:So the new uGUI for Unity is currently in beta testing. I havent seen it and I'm interested in where the GUI stuff is going but I'm thinking this isn't really supposed to be out in the wild. Description for the video reads: Uploaded on Jan 27, 2014 Please note that this video should not be shared beyond the Unity alpha and beta list. Sedgr fucked around with this message at 00:05 on Feb 13, 2014 |
|
# ? Feb 12, 2014 23:59 |
|
Shalinor posted:You guys both need to be using FixedUpdate() any time you're doing something related to movement/physics. It side-steps all of that. Don't forget to use fixedTime as your delta time value in there, instead of Time.deltaTime. Doesn't matter if it's FixedUpdate() or Update(), fixedDeltaTime or deltaTime, it still does the same thing.
|
# ? Feb 13, 2014 00:03 |
|
Obsurveyor posted:Doesn't matter if it's FixedUpdate() or Update(), fixedDeltaTime or deltaTime, it still does the same thing. Most of the "ugly Unity physics" thing comes down either to Unity developers being novices or, often, using CharacterController. Poor gravity settings also plays into it. CharacterController is technically at the heart of my movement, but I've layered a metric ton of logic on top of it to make it responsive, I run my own gravity, etc, and I still wish I hadn't started with it. Shalinor fucked around with this message at 00:11 on Feb 13, 2014 |
# ? Feb 13, 2014 00:07 |
|
Shalinor posted:Most of the "ugly Unity physics" thing comes down either to Unity developers being novices or, often, using CharacterController. Poor gravity settings also plays into it. CharacterController is technically at the heart of my movement, but I've layered a metric ton of logic on top of it to make it responsive, I run my own gravity, etc, and I still wish I hadn't started with it. It's pretty basic, it was just a test of CharacterController+platforming I was messing with. It must be CharacterController. Guess I'll have to figure out how to get rid of it. code:
Also: WTF did they do to MonoDevelop in the latest version of Unity. Obsurveyor fucked around with this message at 00:24 on Feb 13, 2014 |
# ? Feb 13, 2014 00:18 |
|
Interesting note on CharacterControllers, there is a beta of the new Unity standard assets and all of the various controllers in it (first person, third person, etc) don't use CharacterControllers but custom solutions. Might be a sign CharacterController as it currently stands is on the way out. Personally I find there are some weird gotchas with CharacterControllers and collision/physics and I hate any special snowflakes in my scene that don't behave like everything else.
|
# ? Feb 13, 2014 00:19 |
|
Shalinor posted:You guys both need to be using FixedUpdate() any time you're doing something related to movement/physics. It side-steps all of that. Don't forget to use fixedTime as your delta time value in there, instead of Time.deltaTime. Time.fixedTime == Time.deltaTime when you are inside a FixedUpdate call. However, I would use Time.fixedTime anyway for clarity.
|
# ? Feb 13, 2014 00:23 |
|
Are there any other pitfalls folks should be aware of when using Unity? I wasn't aware that CharacterController was a problem . Same deal with NGUI being superior. Are there other addons/components that should be used over the default? EDIT: And on that note, what is the consensus on networking? Some tutorials I've watched mention Photon. Are there other good options? Kaedric fucked around with this message at 02:55 on Feb 13, 2014 |
# ? Feb 13, 2014 01:45 |
|
Kaedric posted:Are there any other pitfalls folks should be aware of when using Unity? I wasn't aware that CharacterController was a problem . Same deal with NGUI being superior. Are there other addons/components that should be used over the default? There's nothing besides Photon or use Unity's built in. All Photon does is wrap a lot of Unity's base networking stuff. I guess a crazy option would be grab something like lidgren and roll your own and somehow work it into unity but hell if I know what it would look like after you got something.
|
# ? Feb 13, 2014 03:44 |
|
poemdexter posted:There's nothing besides Photon or use Unity's built in. All Photon does is wrap a lot of Unity's base networking stuff. I guess a crazy option would be grab something like lidgren and roll your own and somehow work it into unity but hell if I know what it would look like after you got something. I was under the impression that Photon was using their own networking DLL, since they've got their own cloud solution and such, and it was just designed to resemble Unity's built-in-networking API.
|
# ? Feb 13, 2014 06:38 |
|
Zizi posted:I was under the impression that Photon was using their own networking DLL, since they've got their own cloud solution and such, and it was just designed to resemble Unity's built-in-networking API. Unity's networking allows you to connect to any server so Photon swapped out that piece for theirs. It's still wrapping most of Unity's stuff but there's plenty more under the hood that's proprietary to Photon.
|
# ? Feb 13, 2014 14:50 |
|
poemdexter posted:There's nothing besides Photon or use Unity's built in. All Photon does is wrap a lot of Unity's base networking stuff. I guess a crazy option would be grab something like lidgren and roll your own and somehow work it into unity but hell if I know what it would look like after you got something. There's also uLink. The developer for the game "Rust" has been using it with decent success. There's a Photon Unity available, but I'm pretty sure you have to use it with their cloud based service which means you won't have a whole lot of control over the server itself. There's also a Photon Server that has nothing at all to do with Unity but allows you to have full control over the server so if you're wanting to do any kind of authoritative networking it would be a much better choice.
|
# ? Feb 13, 2014 22:16 |
|
Shalinor posted:The other way of handling it is to set the "targetFramerate" value with something sane (like 60), but it's... finnicky, and not as trustworthy for all the same reasons you don't normally want to use vsync.
|
# ? Feb 14, 2014 10:58 |
|
Rottbott posted:Huh? You should always use vsync unless you're profiling or the computer can't quite manage 60Hz.
|
# ? Feb 14, 2014 16:45 |
|
Hopefully variable refresh rate becomes adopted soon enough that vsync can just go away forever.
|
# ? Feb 14, 2014 18:01 |
|
Yeah -- it's the classic trade-off of "do I want to be a little bit wrong all the time, or a lot wrong but only occasionally". If your frame time is hovering at just around 15ms, then any sort of hitch will cause you to drop a frame, which results in a very perceptible (if not consciously noticeable) stutter. If you're well below that threshold, then you're probably fine with leaving VSYNC on.
|
# ? Feb 14, 2014 18:14 |
|
I'm trying to make a tile based scrolling game with a large (unlimited for the sake of argument) map size but I'm having problems finding the right engine to use or using the engines properly or something. First I used pygame and loading new parts of the map was wonderfully seamless but it seems to be geared towards games where not much of the screen changes and updating/scrolling the entire screen on windows bigger than 1024x768 gets very slow very quickly (trying to get reasonable performance on a 1854x1058 window). Then I migrated to pyglet which lets me use much bigger game windows as long as it draws the map as a small number of big sprites, but this causes big framerate dips when the game loads more parts of the map. On the other hand loading a small amount of small sprites at once is a lot smoother but also means that there are a lot more sprites in the batch so the batch.draw() routine becomes painfully slow. I really thought Pyglet would be the answer but I guess I overestimated the speed of batched sprite drawing? Now I'm considering using cocos2d since it is supposed to handle tiles pretty well but it seems like you either have to use either TMX or XML map file things which are going to require more effort to learn how to use, so I thought I'd ask here if i'm going about it the wrong way. Will cocos2d do this well? Should I use a different game engine? Stop trying to use python? It's kind of embarrassing not being able to smoothly draw a big 2d map in 2014 with a reasonable computer so what obvious thing am I sucking at? Ireland Sucks fucked around with this message at 08:14 on Feb 15, 2014 |
# ? Feb 15, 2014 08:09 |
|
Ireland Sucks posted:what obvious thing am I sucking at? The "obvious" thing with 2D is making sure you only use 1 texture atlas so that it can batch and if your map is effectively unlimited you'd want to be sure that it's culling the off-screen parts. Doing the cull yourself might help if the engine isn't expecting you to be drawing lots off-screen. Edit: How many tiles are we talking about on-screen?
|
# ? Feb 15, 2014 08:59 |
|
Look into a Quadtree and segment the map into that. Cull the quadtree by checking if it's within the screen region so you're only trying to render what's in the view. You can do the same but with updating objects if they get slow, disabling them from updating after they get a certain distance away. Edit: vvv Quadtree is basically this but even less math since you only have to compare ~4-16 quadtree sections on screen rather than a few hundred tiles, so see what's in range. It still won't really have any overhead either way though. Jewel fucked around with this message at 14:41 on Feb 15, 2014 |
# ? Feb 15, 2014 09:29 |
|
If cocos is expecting a tmx that means it's just expecting a map in the tiled map editor format, which is actually pretty cool and free. The batching suggestion is the right one, to start. Draw your tiles out of a single image instead of making the tiles out of separate elements. Culling can be as simple as putting the map in a 2d array and only rendering the section on screen, it's ultra easy math.
|
# ? Feb 15, 2014 13:27 |
|
Have you tried profiling? If that's not an option, some printf timestamp logging at key points can also shine a light. Performance analysis as a black box pursuit is pretty hard. :-(
|
# ? Feb 15, 2014 15:04 |
|
Flownerous posted:The "obvious" thing with 2D is making sure you only use 1 texture atlas so that it can batch and if your map is effectively unlimited you'd want to be sure that it's culling the off-screen parts. Doing the cull yourself might help if the engine isn't expecting you to be drawing lots off-screen. Don't use atlases anymore, they're old tech. Use an array texture.
|
# ? Feb 15, 2014 15:38 |
|
Suspicious Dish posted:Don't use atlases anymore, they're old tech. I was just in the middle of doing that
|
# ? Feb 15, 2014 16:48 |
|
Array textures are just a better replacement, modern replacement for atlases which remove the limitations of atlassing. Test your thing out using atlassing, and if they improve your performance, it shouldn't be too hard to switch over. Just a few calls here and there.
|
# ? Feb 15, 2014 16:55 |
|
Suspicious Dish posted:Array textures are just a better replacement, modern replacement for atlases which remove the limitations of atlassing. Test your thing out using atlassing, and if they improve your performance, it shouldn't be too hard to switch over. Just a few calls here and there.
|
# ? Feb 15, 2014 17:08 |
|
Yeah and how about mobile support? I just did some googling and the OpenGL 3.0 Texture Array page tells you to still use atlases, for certain cases.
|
# ? Feb 15, 2014 17:10 |
|
I'm considering a pretty simple game concept, with some similarity to Descent from the olden days, but with a third person view (and probably cartoonier graphics). Is there a decent way (that isn't really taxing) to make clear to the player in a third person view, the proximity of their character to surfaces? I know it's pretty common, especially with cartoony graphics, to do a circle-shadow on floors to better indicate relative positioning, but that would be weird to do the same thing onto walls and ceilings, wouldn't it? Is there anything commonly used for this?
|
# ? Feb 15, 2014 17:25 |
|
roomforthetuna posted:How's the support for array textures? I'm sure they're simpler to use right than atlases (which can be aggravating as gently caress when you start out, with getting bleed over from adjacent sprites etc.) but A. do people still have cards that won't do array textures, and B. if so is there some sort of failover built in other than also implementing atlases as a backup? EXT_texture_array has been in core since 3.0, and the spec says it was shipped on NVIDIA cards in 2006. Seems to also be in GLES 3.0.
|
# ? Feb 15, 2014 17:41 |
roomforthetuna posted:I'm considering a pretty simple game concept, with some similarity to Descent from the olden days, but with a third person view (and probably cartoonier graphics). Is there a decent way (that isn't really taxing) to make clear to the player in a third person view, the proximity of their character to surfaces? I know it's pretty common, especially with cartoony graphics, to do a circle-shadow on floors to better indicate relative positioning, but that would be weird to do the same thing onto walls and ceilings, wouldn't it? Is there anything commonly used for this? If you're going for something like Descent, where you have a ship, colored lights on the ship or something like that maybe? Colored light would be cast from your position onto nearby surfaces and intensify the closer you were to a surface or whatever. I don't know that I would call that a common solution but it would probably work in a similar way to the shadow technique you're talking about.
|
|
# ? Feb 15, 2014 18:17 |
|
Sedgr posted:If you're going for something like Descent, where you have a ship, colored lights on the ship or something like that maybe? Colored light would be cast from your position onto nearby surfaces and intensify the closer you were to a surface or whatever. I don't know that I would call that a common solution but it would probably work in a similar way to the shadow technique you're talking about. roomforthetuna fucked around with this message at 07:01 on Feb 16, 2014 |
# ? Feb 16, 2014 03:46 |
|
|
# ? Jun 7, 2024 07:45 |
|
Wow the textureatlas solution is so fast that it's as if moving the map doesn't affect the framerate at all. Thanks for the help!
|
# ? Feb 16, 2014 06:30 |