Timeline for Decoupling classes from the user interface
Current License: CC BY-SA 4.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 18, 2018 at 21:36 | comment | added | user321630 | "Here's my info and my pics, you figure it out. I'ma too lazy to be bothered with the nuances of your limitations. I'ma hand you info instead of telling you what to do. You have a reliable history of rendering stuff beautifully on ancient hardware and selling lotsa stuff. I trust you. You're still using B&W cameras that require manual photo exposure in 2018? Whatever, I like your photos anyway. Here's my info. Thanks, goodbye!" And we're inverting the dependencies in that case. | |
| Dec 18, 2018 at 21:30 | comment | added | user321630 | That's also tied to coupling. if I'm da boss telling renderers what to do, then I'm responsible for having the most information (and I'd mostly likely fail because I don't have the details and nuances of all the different hardware I'm telling the rendering pros to use to render me). I don't have that level of knowledge. A pro implementing a renderer on a PSP has that type of knowledge. He can say, "All right, you want to be rendered as a beautiful volumetric but we can't afford raymarching. We'll try this technique instead," And I'm like, "Whatever! Just make me look good for da ladies." | |
| Dec 18, 2018 at 21:01 | comment | added | user321630 | With cutting-edge rendering concerns on disparate platforms, disparate hardware capabilities, it's too hard to design something where I'm the boss and tell it what to do. It's much easier for me to say, "Hey, I'm a cloudy/foggy thing with greyish watery particles like this, and try to make me look good please, don't capture my neck which I haven't shaved lately", and let the renderer figure out how to render me in a way as beautiful and as real-time as possible given the limitations it's working with. Any attempt to tell it what to do will almost certainly result in a counter-productive path. | |
| Dec 18, 2018 at 20:58 | comment | added | user321630 | With the cripple if I just give them directions to the store instead of telling them to "run to it", they might then figure out/build that they can use/build a futuristic light cycle or molecular/transporter to get there and do an awesome job. But if I'm telling them how to do it, like "hey you, go sprint to store" then they might take 4 hours to get there and hand me back groceries that didn't really match I wanted. So we're avoiding being the "boss" to designs that are tricky, we're avoiding telling them what to do, in favoring of letting them figure out what to do. | |
| Dec 18, 2018 at 20:55 | comment | added | user321630 | Put yet another way, being a boss and telling someone specifically what to do requires more understanding of how they can effectively do it, otherwise they might run into deadends and be lost/confused. If, instead, say, we just hand them information and give them some breathing room to do what they need to do most effectively, then they have way more freedom to figure out what they need to do given their specific constraints (their physical limitations, if they're a cripple, or what not -- I don't tell them to "run to the store", I give them directions to the store and they figure it out) | |
| Dec 18, 2018 at 20:54 | comment | added | Steve Chamaillard |
Ok i think I got it now. Basically you're saying that such concerns (i.e hardware) are so high level that making low level objects such as a BillBoard depend on those would be really hard to do ? Whereas a IRenderer is high level already and could depend on these concerns with a lot less trouble ?
|
|
| Dec 18, 2018 at 20:51 | comment | added | user321630 | ... that's an implementation concern. You might still abstract and use all sorts of OO goodies and polymorphism to implement the renderer. The different is that it depends on the world because it's so difficult to design in a cross-platform way. The world doesn't depend on it while it faces the need to change in design repeatedly as it tackles all kinds of new hardware it didn't encounter before. | |
| Dec 18, 2018 at 20:50 | comment | added | user321630 | >> You'd make a OpenGLRenderer that knows how to draw any type of IBillBoard ? I hate the commenting character limits! But I mean that's getting towards implementation details of the renderer. The renderer might be able to get all the info it needs like what texture to use and what position in world space to render any billboard, and a billboard doesn't necessarily break down to multiple subtypes in implementation (if it did then the renderer still just needs a world position and texture to render from it). As for whether we use a giant switch statement or not... | |
| Dec 18, 2018 at 20:44 | comment | added | user321630 |
@SteveChamaillard If I'm still communicating poorly, then think of what it takes to design the one Lord of the Rings abstraction to rule them all that provides abstract rendering functionality which works on everything from PSP to PS4 to 32-core ridiculous gaming PC, and why no one has managed to do it successfully yet. There's no "QT" sort of thing as far as developing cutting-edge real-time graphics, because that's so hard to abstract and make cross-platform. But effectively if we're trying to design an abstract IRenderer which can be implemented for all platforms, we are trying to do that
|
|
| Dec 18, 2018 at 20:40 | comment | added | user321630 | Whereas if you don't even bother with such things and make the renderer discover the volumetric parts of your scene, it can do whatever it needs to do in its particular implementation to render such volumetrics as well as it can given the limited hardware capabilities and APIs of whatever hardware/APIs the renderer subtype is designed to work with. | |
| Dec 18, 2018 at 20:39 | comment | added | user321630 |
@SteveChamaillard If what I'm saying is not clicking then think about how to implement an IRenderable with a high-level render_volumetric function, and how easy/hard that would be to design/implement when some hardware might be capable of voxel cone tracing while such techniques would be way too expensive on others while unifying them under the same interface. That is freaking hard, if not impossible. Even designing that one function/method might require a genius-level of design that sees things no one else has seen in the industry to unify it.
|
|
| Dec 18, 2018 at 20:37 | comment | added | user321630 | ... to render, which at least eliminates that boatload of communication and the coupling that comes along with it. | |
| Dec 18, 2018 at 20:37 | comment | added | user321630 | There's so much information the concrete renderer needs, so to speak, to do things efficiently/effectively (information about both your game engine and the underlying rendering back end capabilities), that you're either communicating at such a high-level (volumetric->renderer) that the renderer is basically being handed all the information of the game objects in your engine to it (which it could query itself without all the dependencies to it) only to do what it would otherwise do the other way around without such a complex design, or we invert the dependencies and have it figure out what... | |
| Dec 18, 2018 at 20:32 | comment | added | user321630 | Whereas if you had such volume primitives requesting to render themselves, either their operations are so high-level that they're basically specifying themselves to render (which makes no difference except roundabout redundancy and further coupling), or the renderer abstraction is incapable of really doing things the most effective way possible on the PSP (at least without doing backflips, which it wouldn't need to do if the dependencies were inverted). | |
| Dec 18, 2018 at 20:30 | comment | added | user321630 |
@SteveChamaillard The difference is, say, PSP (limited hardware) must handle volume primitives using old school screendoor transparency and a different ordering of rendering evaluation: digitalrune.github.io/DigitalRune-Documentation/media/…. When you have one central RendererPsp which knows the high-level abstractions of your game scene, it can then do all the magic and backflips it needs to render such things in a way that looks convincing on the PSP....
|
|
| Dec 18, 2018 at 20:28 | comment | added | Steve Chamaillard |
I cannot seem to grasp the idea of "invert the dependencies away from the things that are difficult to design", are you talking about inheritance only ? Using the example of PSP / OpenGL, you mean instead of making a OpenGLBillboard, you'd make a OpenGLRenderer that knows how to draw any type of IBillBoard ? But would it do that by delegating logic to IBillBoard, or would it have huge switches or IBillBoard types with conditionals ? That's what I find hard to grasp, because that doesn't seem maintainable at all !
|
|
| Dec 18, 2018 at 16:32 | history | edited | user321630 | CC BY-SA 4.0 |
added 13 characters in body
|
| Dec 18, 2018 at 16:25 | history | edited | user321630 | CC BY-SA 4.0 |
added 910 characters in body
|
| Dec 18, 2018 at 16:20 | history | edited | user321630 | CC BY-SA 4.0 |
added 910 characters in body
|
| Dec 18, 2018 at 16:10 | history | edited | user321630 | CC BY-SA 4.0 |
edited body
|
| Dec 18, 2018 at 16:00 | history | edited | user321630 | CC BY-SA 4.0 |
added 176 characters in body
|
| Dec 18, 2018 at 15:41 | history | edited | user321630 | CC BY-SA 4.0 |
added 152 characters in body
|
| Dec 18, 2018 at 15:35 | history | edited | user321630 | CC BY-SA 4.0 |
added 38 characters in body
|
| Dec 18, 2018 at 15:25 | history | edited | user321630 | CC BY-SA 4.0 |
added 600 characters in body
|
| Dec 18, 2018 at 15:17 | history | edited | user321630 | CC BY-SA 4.0 |
added 10 characters in body
|
| Dec 18, 2018 at 15:11 | history | edited | user321630 | CC BY-SA 4.0 |
added 1099 characters in body
|
| Dec 18, 2018 at 14:59 | history | edited | user321630 | CC BY-SA 4.0 |
added 84 characters in body
|
| Dec 18, 2018 at 14:54 | history | edited | user321630 | CC BY-SA 4.0 |
added 84 characters in body
|
| Dec 18, 2018 at 14:48 | history | answered | user321630 | CC BY-SA 4.0 |
