|
Suspicious Dish posted:Assuming you're drawing the same number of primitives you can use glVertexAttribDivisor to advance vertex attribs per-divisor but it sounds like that's not what you want. Consider glMultiDrawElementsIndirect if you're afraid of CPU draw call overhead but that won't let you rebind textures between. I try to get by with rigid body animations, so that amounts to updating the animating instance matrices on the CPU then sending those over. I think if I were doing this with real animations I would look up the bone matrices from a UBO or something. I imagine it would then be hard to have models that are playing different animations to share the same draw call, but that's a very hypothetical problem for me right now. If I understand glMultiDrawElementsIndirect, that's pretty much what I'm looking for. My textures are typically pretty small (512x512), i imagine a graphics card that has support for glMultiDrawElementsIndirect is also gonna support texture sizes around 8192, and I can fit pretty much my entire scene's worth of textures into that.
|
# ? Dec 13, 2018 21:02 |
|
|
# ? May 26, 2024 03:57 |
|
Sounds good then! Try using a texture array for the scene textures instead of an atlas so that you don't see filter artifacts around the edges
|
# ? Dec 13, 2018 21:31 |
|
j.peeba posted:I don’t recall that Steam has that rule specifically in their terms. I do know that Valve strives actively towards what they call fair treatment of their customers though but then again that’s not unique to Valve either. I'll just keep it on permanent "sale" then. Nothing wrong with a sale.
|
# ? Dec 13, 2018 22:12 |
|
I'm writing a little renderer using bgfx, and I'm wondering what an appropriate way to abstract/model different "Materials" (the data associated with uniforms in my shader program per mesh/entity). I've tried to avoid using polymorphism + RTTI since I'm trying (perhaps stupidly) to do things the "Data Oriented Design" way, and not use inheritance + pointers since that will make it hard/impossible to ensure data locality. I get that trying to apply DOD for my toy rendered is probably stupid and unnecessary but I think this is defensible... I don't know how to model the uniform data that's going to be associated with each entity if each shader program expects different uniforms. Currently I just have different structs for each Material, and a generic "Mesh" object that accepts the material class as a template arg, but this means that the Entity (which is associated with the Mesh) is also going to have to care about this. One approach I thought of is just having different arrays for the different types of materials and referencing them by index, but that's also not really going to enable data locality... unless the loop that issues draw calls is moving through arrays sorted by material type. Right now I'm tempted to just say "gently caress it" and just ignore preserving the data locality for these "material" objects, but before I did that I wanted to see if I was a) making things way too complicated for myself or b) missing something totally obvious.
|
# ? Dec 14, 2018 02:46 |
|
Welcome to designing and building a material pipeline. It depends on what you want your artists and VFX people to author in. If you want them to author in shading language, you'll need some way to parse out the shading language and get its input parameters (or match them up in the engine). If you can do this in a shader graph, you can generate the inputs and outputs and parameters yourself. As much as you can, standardize on inputs and outputs, and only allow customizing through hooks you integrate in your base shaders. So, for a vertex shader, you might have bone matrices and a VP matrix in your uniforms, and that's basically it. Your hook might be allowing pre-bone and post-bone modifications of the vertex position. In some of my work, I have a cbuffer/UBO named "cb_MaterialVertexParams" which contains all of the artist-controlled parameters special to that material. My shader compiler looks for a buffer of that name, re-packs the cbuffer/UBO for the target platform, and generates reflection data and controls engine-side. So when that material is chosen, those UBOs can be hooked up. Engine just fills in the data in the cbuffer in the right offsets, and it works. This is divorced from "cb_EngineVertexParams" which contains bone/VP. It's never *that* clean in practice, and I have several hacks littered throughout, but that's the basic gist. How this works with bgfx, I don't know. I find that abstraction layers like that mostly get in my way, so I try to avoid them.
|
# ? Dec 14, 2018 03:10 |
|
Epic Store influences developers to pull Steam releasesquote:Some game developers are pulling their upcoming releases from the Steam page entirely, or choosing to make their titles a timed exclusive with the Epic Games Store.
|
# ? Dec 14, 2018 13:21 |
|
https://twitter.com/abhinav_Demkeys/status/1073523972195737600 Might be useful for the Unity devs here.
|
# ? Dec 14, 2018 15:21 |
|
Absurd Alhazred posted:https://twitter.com/abhinav_Demkeys/status/1073523972195737600 Wow this is really cool. If I understand it correctly, it could be very useful for quick debugging.
|
# ? Dec 15, 2018 05:49 |
|
Suspicious Dish posted:Welcome to designing and building a material pipeline. Hmmm this is something I didn't think about at all, but feels like an enormous project in and of itself. It made me realize how naive my hard coded set of materials + shaders system is! Fortunately, I think for my purposes, hard coded shaders will work just fine. I've also decided I will be saying "gently caress it" and using ABC + pointers to let me use different material types. You're right about bgfx. It provides an abstraction on the platform-specific APIs but that also means transpiling shaders and the lack of any sort of DX12/Vulkan style resource binding model for shader resources. Thanks for the help!
|
# ? Dec 18, 2018 02:03 |
|
xzzy posted:Epic is gonna trigger some kind of reckoning. Either Steam has been taking way too much money and they've got a Scrooge McDuck sized money bin somewhere, or Epic is taking way too little money and they're going to put themselves out of business trying to undercut. Third-party sites like itch.io and GOG have become more prominent, Discord announced their own store, most major online PC games had already switched to their own storefront+launcher, most of the major publishers are already operating their own stores, EA bailed completely a while ago, and Activision has started bailing as they shift their catalog over to Battle.net. The other facet is that Steam is so oversaturated now that it's been doing less and less for the promotion of games, which has become the big bottleneck to selling them, and the more that developers rely on other avenues to promote the game, the less it matters where the game is sold. One thing that could really throw a wrench in things is if Unity follows suit and creates their own store. OneEightHundred fucked around with this message at 17:36 on Dec 18, 2018 |
# ? Dec 18, 2018 07:55 |
|
OneEightHundred posted:One thing that could really throw a wrench in things is if Unity follows suit and creates their own store. Oh god, that sounds like a terrible idea! I bet someone is working on it right now.
|
# ? Dec 18, 2018 18:03 |
|
Stick100 posted:Oh god, that sounds like a terrible idea! I bet someone is working on it right now. Galaxy brain: put the store on the Unity asset store as an asset so anyone can buy it and set up their own digital distribution store. All you'd need is a few text fields for your cloud server API of choice and your payments handler!
|
# ? Dec 18, 2018 18:30 |
|
TooMuchAbstraction posted:Galaxy brain: put the store on the Unity asset store as an asset so anyone can buy it and set up their own digital distribution store. All you'd need is a few text fields for your cloud server API of choice and your payments handler! Only interested if I can run my Unity asset store store on top of Epic's new backend services.
|
# ? Dec 19, 2018 00:35 |
|
Does anyone know a rough and easy "importing JSON into Unity" guide? I've got something working that will create Unity objects from data in a JSON file, but I'd like to have many objects in one file and turn those into a List<> of said objects. edit: reading more, this seems like a more complex question than I'd originally thought, and people have made paid assets that solve it? I think this is a problem to come back to when I've learned more C#. jizzy sillage fucked around with this message at 03:10 on Dec 19, 2018 |
# ? Dec 19, 2018 02:23 |
|
jizzy sillage posted:Does anyone know a rough and easy "importing JSON into Unity" guide? I was working on this issue myself recently. Unity has a built-in JSON serializer, but I couldn't get that to work with my JSON file. Instead, I just used the free JSON.net for Unity asset (https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347). My JSON-parsing code was this: code:
|
# ? Dec 19, 2018 04:12 |
|
Monoclinic posted:I was working on this issue myself recently. Unity has a built-in JSON serializer, but I couldn't get that to work with my JSON file. Instead, I just used the free JSON.net for Unity asset (https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347). My JSON-parsing code was this: Okay, rad, I'll give it a shot later. Thanks very much.
|
# ? Dec 19, 2018 04:46 |
|
jizzy sillage posted:Does anyone know a rough and easy "importing JSON into Unity" guide? Oh hey! My theme music started playing! I rolled my own that I'm not too keen on trying to distribute; the bridging between the standalone code and Unity is fiddly all by itself. Turning a bunch of Unity objects into JSON is far from the hard part in this entire topic. Heck, I think Unity itself can just vomit the whole scene like that, right? But allow me to regale you with some situations to consider that I have paid for in blood already:
In very coarse terms, this is some of the stuff I did: 1. I created an API of customer serializers for all serializable MonoBehaviours that are scanned one first use and then assigned to each serializable MonoBehaviour. This is probably the tamest part of this whole thing. 2. I created a scene cache structure from temporary storage. When a scene change happens, the old scene is put in the cache. 3. Saving a game means copying the cache to the assigned save location. 4. Loading a game means loading the assigned location into the cache and changing to current scene to the cache's "active" scene. 5. I have additional metadata on some game objects to determine if they are local or global. Global objects include the player and are saved in a separate section. Global data can migrate between scenes. Local data cannot. So if a serializable, local gameobject is found when I load the original scene, but I have no data for it, that means it's gone. I had to add a mechanism to propagate global/local flag changes so if the player picked up or dropped an inventory item, it would stay or get carried accordingly. I think I was told that Skyrim does something similar, and that's really a bad thing to say to a single developer here that wants to make a game instead of a serialization system. Edit: Let's say your not as stupid as me and want to pare this waaay back. Some strong suggestions: 1. Use a fixed save data structure and just save very key bits 2. Save only at prescribed places or points If you want to save whatever whenever then think about your life decisions first.
|
# ? Dec 19, 2018 05:13 |
|
Yeah, uh, holy poo poo. I only half learned what serialization even is today, so all of that is a long way down the line. I have a JSON file that defines a bunch of items. I want to import that file, read it, and create a List<> containing those item definitions. I'd like the player (me) to be able to add new items to the bottom of the JSON file (while the game is closed) and have those then get added to the List<> of available items when the game is opened. Currently the game doesn't exist, I'm just practicing a few different solutions to features I'd like to include (this one being the ability to add new items manually).
|
# ? Dec 19, 2018 05:58 |
|
Unity's json deserializer has the peculiar limitation of not being able to read an array of objects at the root level of the json file. You can make it work by putting the array inside of another serialized object, like this:code:
code:
code:
|
# ? Dec 19, 2018 06:27 |
|
Wow, that's cool! Turns out I was getting pretty close to that solution, so thanks very much for laying it out
|
# ? Dec 19, 2018 07:16 |
|
jizzy sillage posted:Wow, that's cool! Turns out I was getting pretty close to that solution, so thanks very much for laying it out Yeah if you're data and the points where you have to work with it are very regular, then the amount of shenanigans you have to undergo goes way down. You'll still have to worry about the scene transition if you have to load a new scene, and the timing problems that might arise from it. You're better off seeing what that's like early if you know you're going to be moving back and forth between scenes in Unity; some people don't even bother using Unity's scenes and just do everything within technically one scene.
|
# ? Dec 19, 2018 21:44 |
|
Most things I’ve seen use additive scene loading.
|
# ? Dec 20, 2018 03:08 |
|
Is there a goon gamedev discord where I can ask short and stupid questions, like this one?
|
# ? Dec 20, 2018 10:27 |
|
the goon game jam discord: http://discord.gg/UwXZtgJ
|
# ? Dec 20, 2018 11:53 |
|
Great, thanks. I've joined, and will start asking stupid questions post haste.
|
# ? Dec 20, 2018 23:37 |
|
xzzy posted:Epic is gonna trigger some kind of reckoning. Either Steam has been taking way too much money and they've got a Scrooge McDuck sized money bin somewhere, or Epic is taking way too little money and they're going to put themselves out of business trying to undercut. Steam has a Scrooge McDuck sized money bin. You do realize Gabe is a multi-billionaire right? And it's not because Half Life was successful.
|
# ? Dec 22, 2018 18:06 |
|
Unity question: I'm working with a simple 2D turn-based game where there's units on a map, each unit has individual properties I have to save and load, etc. The units use SpriteRenderers. The problem I'm having is that different units have different sprites. Like, the Sprite type, each unit has its own graphic file it needs to display so that it looks like what it is. The problems are twofold: 1) There are no good ways to save/load Sprite data. Everyone on the first page of Google recommends using the Resources folder and saving/loading the path to the appropriate asset, which Unity explicitly tells everyone not to do. 2) I want to have unit recipes as ScriptableObjects, but the code that creates a new battle doesn't live anywhere near a MonoBehaviour, and so can't easily get a reference to the right ScriptableObject without doing Resources stuff. The absolute best idea I have at the moment is to put a public reference to the SO on my singleton MB so I can access it through static space, but then I'm stuck adding new public fields every time I make a new type of unit. I've considered an array of structs, but that involves tracking the correct index for the unit, which seems prone to misery. Is there some smarter way of doing this that I haven't considered?
|
# ? Dec 24, 2018 01:56 |
|
LordSaturn posted:I've considered an array of structs, but that involves tracking the correct index for the unit, which seems prone to misery. Is there some smarter way of doing this that I haven't considered? There's a library you can get that lets you create scriptable Dictionaries -- if you use that, you can use this solution, but have a Dictionary with an enum for the keys and your struct for the values, so you don't have to track the index any more. That's the approach I'm taking, though caveat emptor I'm only on my first Unity project too so this might be a terrible idea for reasons I don't yet understand.
|
# ? Dec 24, 2018 09:46 |
|
LordSaturn posted:Unity question: I don’t think you want a singleton MonoBehaviour. Separately, the thing you probably are looking for is a prefab per unit type. Then hook up the ScriptableObject to the associated prefab and have a MonoBehaviour on that prefab load relevant data, including the texture, from the SO. If you want something a bit more generic, you could have a SO that maps an enum type to other SO’s and reference the mapping object on your prefab. Then you don’t need to maintain a bunch of prefabs for each unit. All you need to do is pass the correct enum value to initialize the MB.
|
# ? Dec 24, 2018 15:00 |
|
Whybird posted:There's a library you can get that lets you create scriptable Dictionaries -- if you use that, you can use this solution, but have a Dictionary with an enum for the keys and your struct for the values, so you don't have to track the index any more. Is it this? I'm don't want to solve this problem the way you did, if only because it'd mean maintaining an enum and a dictionary in parallel, which I don't love, but this looks really useful for other problems I have. leper khan posted:I don’t think you want a singleton MonoBehaviour. I don't think we're on the same page about what I'm trying to do, but I'd feel rude not acknowledging your post. Thanks anyway! For now I've gone with the Resources folder, because it'll probably be fine for the scope of this particular project. Also, someone in the other thread mentioned Addressable Objects, which sound like exactly what I want, but aren't in the version of Unity I have.
|
# ? Dec 25, 2018 20:04 |
|
I'm thinking of making a little something for gamepad-specific tooltip icons to embed in my Unity GUIs as a guide on what to hit to do what. I'm thinking I should use a GameObject with an Image or a Sprite as a base but I wonder if there's anything else. Can I integrate something with TextMeshPro to detect tags and convert them into the little button images I would use as guides? I'm pretty sure the image/sprite thing is the way to go but I want to know if there's any other neat things I should explore.
|
# ? Dec 27, 2018 09:07 |
|
Rocko Bonaparte posted:I'm thinking of making a little something for gamepad-specific tooltip icons to embed in my Unity GUIs as a guide on what to hit to do what. I'm thinking I should use a GameObject with an Image or a Sprite as a base but I wonder if there's anything else. Can I integrate something with TextMeshPro to detect tags and convert them into the little button images I would use as guides? TextMesh Pro has that functionality built in: http://digitalnativestudios.com/textmeshpro/docs/sprites/
|
# ? Dec 27, 2018 10:09 |
|
Triarii posted:TextMesh Pro has that functionality built in: http://digitalnativestudios.com/textmeshpro/docs/sprites/ Hmmm that is half of the solution; I still need to translate my controller action to the actual Sprite. It sounds like I have to hack at TextMesh Pro to do that, but it seems possible to give it a custom tag that I can then translate. I want the indirection since I'd like to take a stab at remapping controls and supporting multiple platforms.
|
# ? Dec 27, 2018 15:06 |
|
I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side. I have tried dividing the penetration vector with the velocity value at the time of the collision, and this fixes this particular problem, but also brings other more serious bugs. Am I missing something obvious, or will I have to use an entirely different way to resolve this issue? GIF provided where the problem is seen, around the end of the video. The console is displaying the penetration vector during each collision in each frame. The player box turns red when there's a collision, and the green line is the velocity vector. The thicker it is the higher the magnitude.
|
# ? Dec 27, 2018 15:30 |
|
Rocko Bonaparte posted:Hmmm that is half of the solution; I still need to translate my controller action to the actual Sprite. It sounds like I have to hack at TextMesh Pro to do that, but it seems possible to give it a custom tag that I can then translate. Different platforms require different builds. It’ll be easier to swap a couple assets at build time than do the thing you’re thinking of.
|
# ? Dec 27, 2018 15:39 |
|
Pseudo-God posted:I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side. This is one of many reasons why I advise people to not write their own physics if they can possibly avoid it. Collision response is a super complicated issue and you're never going to get all the kinks ironed out. For your specific issue, you can try things like sweeping the AABB along its velocity vector and using that as the collision polygon, though of course it's no longer an AABB if you do that. You can also say "ok, there was a collision, I'm going to back the colliding objects out along their velocity vectors and then step forward in smaller increments to get a minimal overlap." But invariably you're going to find other edge cases where your collision response glitches out. About the best you can hope for is to get it to the point where all of the glitches are possible only with specific arrangements of colliders that you can simply omit from your game.
|
# ? Dec 27, 2018 15:53 |
|
Pseudo-God posted:I am having an issue with my collision resolution code for my 2D platformer. I am using only AABBs for by objects, and in case of a collision, I calculate the penetration vector and translate the player object along the smallest axis of the penetration vector. This works very well, but there is a literal edge case that I am having trouble solving. If a player hits the ground from the top with enough speed, he will be embedded in the ground such that the smallest axis will actually be the horizontal one, and will slip on the side. That’s when you say things like “if the player is falling the depenetration vector is always up”
|
# ? Dec 27, 2018 16:03 |
|
TooMuchAbstraction posted:This is one of many reasons why I advise people to not write their own physics if they can possibly avoid it. Collision response is a super complicated issue and you're never going to get all the kinks ironed out. For your specific issue, you can try things like sweeping the AABB along its velocity vector and using that as the collision polygon, though of course it's no longer an AABB if you do that. You can also say "ok, there was a collision, I'm going to back the colliding objects out along their velocity vectors and then step forward in smaller increments to get a minimal overlap." The reason I am doing everything from scratch is to experiment with a novel networking model for web apps (UDP in JavaScript), and none of the existing engines fit my needs. The physics in the game will be very simple, and the existing engines had behavior that was unsuitable or too complex. Instead of sweeping the AABB continuously, I can generate a fixed number of them along the path from the old position to the new, and use the results of the earliest collision as the "true" result. This will not fix the problem definitely, but will push the speed at which the slipping occurs beyond the one that is available ingame.
|
# ? Dec 27, 2018 16:08 |
|
Rocko Bonaparte posted:Hmmm that is half of the solution; I still need to translate my controller action to the actual Sprite. It sounds like I have to hack at TextMesh Pro to do that, but it seems possible to give it a custom tag that I can then translate. I would say that, rather than hacking TextMesh Pro to understand that <button="attack"> translates to some particular sprite, instead have a method in your input manager that says "get me the sprite tag corresponding to the attack button" (probably pass in the action in as an enum) which would return <sprite="SquareButton"> if you're using a PlayStation controller with square bound to attack, or <sprite="AButton"> if you're using an XBox controller with that as your attack button, etc. Then call that function and insert it into your string when you want to tell the player how to attack something.
|
# ? Dec 27, 2018 16:10 |
|
|
# ? May 26, 2024 03:57 |
|
The simplest way to do this is to project movement separately for the horizontal and vertical axes. Project from the two edges of your player character in the vertical direction, and if you bump, you lose all vertical momentum. Do similar from the horizontal direction. Don't use shorthands like "the smallest penetration vector", they have no physical analog. The "correct" way to do this is to project each edge of the character along the velocity vector. Grab a copy of Real-Time Collision Detection if you're serious about building this sort of thing, it's the best tome on the subject.
|
# ? Dec 27, 2018 18:06 |