|
Orzo posted:Question about 2D graphics stuff, blending modes. My particular implementation is DirectX, but I'm guessing this applies to OpenGL. Instead of subtracting based on a gradient sprite using a texture lookup, why not just use a simple distance formula which is probably less expensive, smoother, scales better, and can easily be adjusted on the fly? You can probably just render the top layer with a shader that has a "LightPosition", "LightRadius", "LightStrength", "LightColor" you pass in (at least for a single light, if you wanted to do more you could get fancier), which would basically just do a simple alpha knockout, showing what's underneath (Since it's always on top there's no sorting issues to worry about with alpha).
|
#
?
Apr 11, 2013 06:13
|
|
|
|
| # ? May 11, 2024 23:25 |
|
|
Orzo posted:Question about 2D graphics stuff, blending modes. My particular implementation is DirectX, but I'm guessing this applies to OpenGL. Just use shaders. You're using shaders, right? You definitely don't need Layer 1; that's just multiplication by a constant in the fragment shader You probably don't need Layer 2 either depending on what you're doing. Unless your light sprite is really complicated you can probably do this without needing to render to an intermediate 'light' texture. Just calculate the value directly in the shader and multiply. If your light sprite is really complicated such that you actually need multiple passes to render it then you can use an off-screen texture, I guess. seiken fucked around with this message at 12:39 on Apr 11, 2013 |
|
#
?
Apr 11, 2013 11:55
|
|
|
seiken posted:Just use shaders. You're using shaders, right? Oh yeah what the heck you don't need to render a black rectangle on top with alpha cutout, I'm being an idiot. Apply a postprocess shader to the render target with this and that's basically it.
|
|
#
?
Apr 11, 2013 12:04
|
|
|
Is there a decent free engine that supports input devices like the Razer Hydra, or something like a Hillcrest freespace sensor? I know Blender Game Engine is a ...thing... and it supports the Hydra, but a cursory look at it seems to indicate it's going to be a frustrating mess to use. I love Unity, but they've crippled the Free version by not supporting peripherals like that, and even if I had the spare $1,500, it would be hard to justify at a hobbyist level. I might save up for it eventually, but right now I've got parts for a cheap DIY VR headset on the way, and wanted to experiment a bit.
|
|
#
?
Apr 11, 2013 14:27
|
|
|
Thanks for the advice.Jewel posted:Instead of subtracting based on a gradient sprite using a texture lookup, why not just use a simple distance formula which is probably less expensive, smoother, scales better, and can easily be adjusted on the fly? You can probably just render the top layer with a shader that has a "LightPosition", "LightRadius", "LightStrength", "LightColor" you pass in (at least for a single light, if you wanted to do more you could get fancier), which would basically just do a simple alpha knockout, showing what's underneath (Since it's always on top there's no sorting issues to worry about with alpha). Shalinor posted:Render #1 and #2 to an off-screen buffer. #1 is the base layer, write / no z / no alpha. #2 is blended over the top of that additively. Then take the composite buffer and render it over the regular scene buffer multiplicatively. seiken posted:Just use shaders. You're using shaders, right?
|
|
#
?
Apr 11, 2013 14:37
|
|
|
Orzo posted:Thanks for the advice. Why would it be more complex? Instead of just using light value = 1/d^2 or whatever you just use a spotlight formula, which has been made countless times in 3D, and is pretty easy to port the same logic to 2D. Just checked quickly to find an example, look at this: http://www.java-gaming.org/topics/2d-lighting-tribulations-with-shaders/24683/view.html
|
|
#
?
Apr 11, 2013 14:56
|
|
|
Okay, point taken for that particular shape, but what about totally arbitrary shapes? It just seems much simpler and flexible to render lights as sprites when a framework for extensive sprite manipulation is already in place.
|
|
#
?
Apr 11, 2013 15:13
|
|
|
Orzo posted:Okay, point taken for that particular shape, but what about totally arbitrary shapes? It just seems much simpler and flexible to render lights as sprites when a framework for extensive sprite manipulation is already in place. EDIT: VV treating individual lights as alpha sprites will be less efficient than using actual lighting algorithms. It just won't matter unless you've got 200 odd lights and 500ish sprites rendering at a time, and maybe not even then. For a standard Zelda game with Zelda scene complexity, the optimization would likely not even be noticeable. It would also matter a great deal if you were on mobile hardware, but you're obviously not. Basically - you'll be fine unless you have plans to zoom the camera out and show Total War-scale mass combats with light casting explosions. Shalinor fucked around with this message at 15:55 on Apr 11, 2013 |
|
#
?
Apr 11, 2013 15:23
|
|
|
Shalinor posted:Your "everything is a sprite" approach probably won't scale well to large-scale scenes. That said, if you don't care, there's no reason to complicate it. Edit ^^^^^^^ Okay, thanks, yeah, you correctly diagnosed the situation, I won't be zooming way out to show a ton of things. Although the camera is dynamic, I don't plan on zoooming out to a level that would show more than about 25 tiles in each axis, so the order of sprites is a few thousand, and the number of lights is probably on the order of 10 or so. Orzo fucked around with this message at 17:24 on Apr 11, 2013 |
|
#
?
Apr 11, 2013 15:34
|
|
|
Make it an awesome deferred renderer, but with sprites. I worked on a partially finished one for a space action game game I was twiddling with, it was pretty awesome. Each sprite also had a height-map and material textures, rendered to a g-buffer just like you might with a 3D scene. I was even toying with directional lighting for the sprites based on the height map. It ended up being sort of a pseudo-voxel thing, almost. I'd love to see someone technically competent do it for real. 
Unormal fucked around with this message at 18:03 on Apr 11, 2013 |
|
#
?
Apr 11, 2013 17:56
|
|
|
Haha, that sounds cool, but I'm afraid I have too much other work to spend time with super advanced graphics tech. Plus, for my requirements, I'm not sure what that buys me that the other solutions don't.
|
|
#
?
Apr 11, 2013 18:32
|
|
|
SlightlyMadman posted:Yep, the idea is basically a 2D game but with a 3D camera you can move and pan around things. I recently bought the Unity3d Plugin uni2D and it works great: http://forum.unity3d.com/threads/142608-Uni2D-tool-A-new-amazing-way-to-create-2D-games-in-Unity!! In that same link you can see demo videos on how it works. I am currently working on a project using it and its working out great... Some highlights include:
They have recently released version 2.0 of the plugin.
|
|
#
?
Apr 11, 2013 19:23
|
|
|
On a separate note, does anyone know how to connect Unity to a SVN? Is that something you can do with the "free" unity or do I have to buy pro?
|
|
#
?
Apr 11, 2013 19:28
|
|
|
badr posted:On a separate note, does anyone know how to connect Unity to a SVN? Is that something you can do with the "free" unity or do I have to buy pro? It works pretty well with an SVN if you go into edit..project settings..editor and set it to "metafiles". http://docs.unity3d.com/Documentation/Manual/ExternalVersionControlSystemSupport.html It's (very) useful to note that only the ProjectSettings and Assets folders "matter" to Unity (at least when you have metafiles enabled). Those are the only folders you want in your SVN, and if something goes horribly wrong with your project, you can delete all the other folders and unity will regenerate the rest of the associated crap. As a corollary, if you're copying it over to another system for building (to build for iOS, for instance) you only need to copy the Assets and ProjectSettings folders (and usually only Assets, if your project settings haven't changed). I've actually had copying the other sub-folders over cause weird issues in my builds.
|
|
#
?
Apr 11, 2013 19:33
|
|
|
badr posted:I recently bought the Unity3d Plugin uni2D and it works great: That's definitely cool, but if I wanted to make a purely 2D game, I'd just use pygame. I finalized my terrain generator last night though! Got my angles and heights perfect, and I think I've got a really cool and dynamic map together. Now the hard part, I'm going to start with drawing roads. I've googled around a bit, and it sounds like I need to create a road mesh, and then break it into triangles and tile those triangles across the board? I get the feeling this is going to be tricky.
|
|
#
?
Apr 11, 2013 19:41
|
|
|
SlightlyMadman posted:That's definitely cool, but if I wanted to make a purely 2D game, I'd just use pygame. I finalized my terrain generator last night though! Got my angles and heights perfect, and I think I've got a really cool and dynamic map together. With that plugin you can make a 2D game and you can add depth as well (2D game with 3D Elements)... Did you look at the videos? The game Dungelot (https://www.dungelot.com) was made with Uni2D. Can you post screenshots of what you are trying to do?
|
|
#
?
Apr 11, 2013 21:52
|
|
|
badr posted:With that plugin you can make a 2D game and you can add depth as well (2D game with 3D Elements)... Did you look at the videos? The game Dungelot (https://www.dungelot.com) was made with Uni2D. I don't have any screenshots beyond the terrain generation, but the closest example to what I'm working on is probably the Anno games. Basically I have a static terrain that I want to allow the player to drop things on top of.
|
|
#
?
Apr 11, 2013 22:26
|
|
|
SlightlyMadman posted:Now the hard part, I'm going to start with drawing roads. I've googled around a bit, and it sounds like I need to create a road mesh, and then break it into triangles and tile those triangles across the board? I get the feeling this is going to be tricky. I'm pretty sure we're working on the exact same game because guess what I've been researching the past few days?  I haven't had time to dig in and check if it's actually usable, but my current plan is to look into the Unity 3 plugin "Road/Path Tool": http://www.sixtimesnothing.com/road-path-tool/ Mostly because it's proven to work in Unity, and they let you download source. It relies on what basically everyone else relies on for making roads, that being bezier curves. It also has some code for smoothing terrain around the roads which is also interesting.
|
|
#
?
Apr 11, 2013 22:31
|
|
|
What is everybody trying to make the next SimCity since EA failed at the latest attempt?
|
|
#
?
Apr 11, 2013 22:35
|
|
|
SuicideSnowman posted:What is everybody trying to make the next SimCity since EA failed at the latest attempt? Looks like! (my target is a little lower: I just want to re-implement the original SimCity in Unity, minus the tile based requirements)
|
|
#
?
Apr 11, 2013 22:37
|
|
|
SuicideSnowman posted:What is everybody trying to make the next SimCity since EA failed at the latest attempt?
|
|
#
?
Apr 11, 2013 22:53
|
|
|
OneEightHundred posted:A self-answering question.
|
|
#
?
Apr 11, 2013 23:05
|
|
|
xzzy posted:Looks like! Haha yeah I'm working on a cross between SC2000 and the Anno games. I actually came across that same tool yesterday, but it's only available for Unity 3, and I've been building everything so far in 4.
|
|
#
?
Apr 11, 2013 23:20
|
|
|
SlightlyMadman posted:Haha yeah I'm working on a cross between SC2000 and the Anno games. I actually came across that same tool yesterday, but it's only available for Unity 3, and I've been building everything so far in 4. Yeah but the code is really close, I suspect a lot of it can be C&P'd. The value to me is more that it's a working implementation, which makes it easy to learn from.
|
|
#
?
Apr 11, 2013 23:43
|
|
|
SuicideSnowman posted:What is everybody trying to make the next SimCity since EA failed at the latest attempt?
|
|
#
?
Apr 12, 2013 01:51
|
|
|
SupSuper posted:I'm surprised nobody's taken advantage of the original SimCity code yet. I haven't looked at it, but software development was a bit different back then. I doubt much of that code was written for readability or flexibility, so much as for fitting on a single 5 1/4" floppy disk.
|
|
#
?
Apr 12, 2013 03:05
|
|
|
SupSuper posted:I'm surprised nobody's taken advantage of the original SimCity code yet. I actually am.. though I've only gotten as far as implementing the random map generation code in Unity. The java port has very readable code.
|
|
#
?
Apr 12, 2013 05:48
|
|
|
Ok, so first of all I might be going about this wrong, but I am trying to make a Beat 'em Up type game in Unity with 2D Toolkit. Anyway, I did some googling and saw a method where you put the camera at a 30 degree angle and then put your sprites at a 30 degree angle. Like this:  For some reason the floor renders over the player though. Like this:  Again I might be going at this all wrong, but I have no idea why it is doing this. I keep having problems in Unity, I might just switch to Game Maker and try it out. Suran37 fucked around with this message at 06:11 on Apr 12, 2013 |
|
#
?
Apr 12, 2013 06:00
|
|
|
Try setting the camera's sortmode to ortographic: Camera.mainCamera.transparencySortMode = TransparencySortMode.Orthographic;
|
|
#
?
Apr 12, 2013 06:13
|
|
|
Svampson posted:Try setting the camera's sortmode to ortographic: I assume I am supposed to put that in a script on the camera itself. In which case I put it in the Start() method and it doesn't seem to have done anything. For the record it also renders under the floor texture in the scene view as well, not just the game view. Suran37 fucked around with this message at 06:34 on Apr 12, 2013 |
|
#
?
Apr 12, 2013 06:30
|
|
|
Unormal posted:Make it an awesome deferred renderer, but with sprites. I worked on a partially finished one for a space action game game I was twiddling with, it was pretty awesome. Each sprite also had a height-map and material textures, rendered to a g-buffer just like you might with a 3D scene. I was even toying with directional lighting for the sprites based on the height map. It ended up being sort of a pseudo-voxel thing, almost. I'd love to see someone technically competent do it for real. Project Eternity is trying something like that. With rendered scenes painted over rather than sprites but similar shaders I imagine. https://www.youtube.com/watch?v=AUleDEFkUtE
|
|
#
?
Apr 12, 2013 06:41
|
|
|
Suran37 posted:Ok, so first of all I might be going about this wrong, but I am trying to make a Beat 'em Up type game in Unity with 2D Toolkit. You're doing it right, but it's a problem with zsorting large planes in perspective projection. I ran into the same thing recently, I solved it by manually setting the render order on sprites, which was a pain, and fairly limiting, but worked ok. I'm on my phone so I don't have the exact information at my fingertips but it involved setting the render queue on each individual material. This is a non issue with orthographic perspective, but you'll miss out on some cool perspective effects.
|
|
#
?
Apr 12, 2013 12:18
|
|
|
superh posted:You're doing it right, but it's a problem with zsorting large planes in perspective projection. I ran into the same thing recently, I solved it by manually setting the render order on sprites, which was a pain, and fairly limiting, but worked ok. I am actually using the tk2dCamera which only has orthographic perspective.
|
|
#
?
Apr 12, 2013 15:21
|
|
|
Suran37 posted:Ok, so first of all I might be going about this wrong, but I am trying to make a Beat 'em Up type game in Unity with 2D Toolkit. Obviously the draw order isn't working quite as expected - in my experience with unity (using my own Sprite implementation, not 2D toolkit), in order to get sprites to always draw in the correct order you should be drawing sprites using a shader that has ZWrite turned on. This looks like the results you get when you try and draw close together sprites with a shader that has ZWrites turned off (as most of the standard unity shaders do). As your floor is solid - if you set that to work with a shader without transparency that might fix the issue as well - I've only ever seen it occur where two semitransparent objects overlap.
|
|
#
?
Apr 12, 2013 16:13
|
|
|
I think I'm going to give up on anything fancy for roads at the moment, and just go back to my original though of tiled planes on a grid. That will make it easier to work out my game logic anyways. Now that I'm ready to start letting the player draw stuff on the screen though, I need to get my house in order and clean up all my proof of concept code. The dilemma I've run into is how to best coordinate my scripts with each other. Are there best practices for this in unity? I have a terrain generation script, a UI and camera control script, and will now want to make a separate script to control my main game logic. Should I just centralize everything in the game logic script and add it as a property to the other scripts? Or vise-versa? Does Unity have some sort of event or delegate framework I can hook into?
|
|
#
?
Apr 12, 2013 16:21
|
|
|
If you google around, most people seem to suggest putting an empty in your game world and attaching a script to it, putting all your logic in the Update() function. This seems like bad design to me, but what do I know.
|
|
#
?
Apr 12, 2013 16:27
|
|
|
It's not the greatest design in the world, but it is very convenient. The alternate solution is for Unity to build scripts you can attach to the scene itself (can you do this?) rather than being associated with a GameObject. But there's really no drive to do that when you can just create invisible 'controller' objects.
|
|
#
?
Apr 12, 2013 16:39
|
|
|
xzzy posted:If you google around, most people seem to suggest putting an empty in your game world and attaching a script to it, putting all your logic in the Update() function. Yeah, the thought of that is pretty horrifying to me honestly. I thought one of the big advantages of Unity was the ability to split things out into reusable components? Maybe the best approach would be to create a script as a singleton and put all my game state and business logic methods in that, so my various scripts wouldn't have to be aware of each other, as long as they'd all share a reference to that one central script?
|
|
#
?
Apr 12, 2013 16:50
|
|
|
SlightlyMadman posted:Yeah, the thought of that is pretty horrifying to me honestly. I thought one of the big advantages of Unity was the ability to split things out into reusable components? I also don't know why you'd take all game logic out of individual objects and stuff it into a singleton-type thing.
|
|
#
?
Apr 12, 2013 17:27
|
|
|
|
| # ? May 11, 2024 23:25 |
|
|
Orzo posted:How does having an invisible GameObject that runs scripts an servers as a 'controller' of sorts prevent you from reusing components? That invisible object could be a prefab. I guess I don't understand your objection. It's not the fact that it's attached to a GameObject, so much as that it all has to be in a single function in a single script. I'd prefer to split things out into separate scripts by function, so I have one script for UI, one script for terrain generation, one script for AI, etc. edit: Unless you're saying it doesn't? I was replying to xzzy's suggestion of "putting an empty in your game world and attaching a script to it, putting all your logic in the Update() function." If you're saying it is possible to have separate scripts interact with each other, that brings me back to my original question: how do I do that? The notion of having a singleton would be that any script can call a static "getInstance" function and have access to it. It would in turn reference several other child classes, not have all of the logic stuffed into a single class. SlightlyMadman fucked around with this message at 17:57 on Apr 12, 2013 |
|
#
?
Apr 12, 2013 17:53
|
|