The Big Programming Thread - Page 492
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
CorsairHero
Canada9491 Posts
| ||
|
Ethenielle
Norway1006 Posts
Anyway, for the class that I expose to the user it looks something like this:
Then whenever the user adds a light to the scene, the engine would create an internal PointLight class which stores additional information that only the engine needs to know about, and it would also register a callback with the exposed class. Something like this:
And then the rendering would obviously only operate on the internal class. So then I get the benefit of hiding these engine-only relevant variables from the user, but in their stead there is this "mysterious" array of callbacks. Ideally, the class I expose to the user would just be a POD class. Maybe that's not possible without constantly polling/updating dependent variables, though. I hope that was maybe a bit clearer explanation of my problem...? ![]() | ||
|
Nesserev
Belgium2760 Posts
| ||
|
mcc
Czech Republic4646 Posts
On June 20 2014 03:05 Ethenielle wrote: After reading about the observer pattern, I think that's pretty much what I'm doing now. Anyway, for the class that I expose to the user it looks something like this:
Then whenever the user adds a light to the scene, the engine would create an internal PointLight class which stores additional information that only the engine needs to know about, and it would also register a callback with the exposed class. Something like this:
And then the rendering would obviously only operate on the internal class. So then I get the benefit of hiding these engine-only relevant variables from the user, but in their stead there is this "mysterious" array of callbacks. Ideally, the class I expose to the user would just be a POD class. Maybe that's not possible without constantly polling/updating dependent variables, though. I hope that was maybe a bit clearer explanation of my problem...? ![]() I am very confused by this design. Why don't you have just one Light class and hide what you want to hide by making it private ? Plus ideally make that class immutable, or at least clone it on Engine:AddLight if you really need to. | ||
|
Ethenielle
Norway1006 Posts
On June 20 2014 06:56 Nesserev wrote: It might be a bit rude even though I mean no offense, and it's only based on a hunch, but do you even understand how a graphics engine is supposed to work? EDIT: Now that I think about it, asking this question doesn't help in any way... from what you've described about your engine so far, it just seems that the design of your engine is rather flawed. Great advice, thanks. You're the reason I ask for help. | ||
|
mcc
Czech Republic4646 Posts
On June 21 2014 00:24 Ethenielle wrote: Initially that's what I did. But the engine needs access to those private variables for rendering, so then I had to friend the engine. I didn't like that, so that's why I ended up splitting the class in two, and that leads to the whole callback messy situation, which isn't good either. What I meant that maybe you should have the Light structure just as POD structure. The whole concept of reacting to changes that the user makes later seems flawed. User should just create the Light structure, call AddLight by passing the structure in and that is it. Your engine should not react to changes to that struct that happen after the call to AddLight. You can achieve it either by cloning or by making the struct immutable. Another way would be to just not expose any class at all and just expose AddLight and pass all necessary info in parameters. If you want to allow user to change the Light structure later, you can just return from AddLight a handle that he can later use in SetLight_x(handle, value) or Setx(typedHandle, value). You avoid dealing with all kinds of nasty surprises by more strictly controlling change to those variables. | ||
|
urboss
Austria1223 Posts
On June 19 2014 01:41 Ethenielle wrote: That's what I'm doing, but the internal classes have to know whenever the user changes something in the public class, thus the callbacks. Which I don't like.. the user shouldn't know about that, either. Why not use an abstract class and derive the public class from it? | ||
|
nunez
Norway4003 Posts
if you want a good case study of an interface using callbacks you can peep boost asio! in f.ex async_read they take the callback functor as a templated argument with a pre-specced signature: template< that alleviates the need for the 'exposed class' and instead you ask the user to provide a functor satisfying your signature. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
Shield
Bulgaria4824 Posts
| ||
|
phar
United States1080 Posts
As a meta point in software development, it is good to develop a thick skin to questions that seem overly blunt. A lot of people aren't trying to be mean, they just might not present things in super nice ways. People are also often very willing to teach and explain things, because helping other people understand how things work is the only way any shit gets done in software. Modern software is way too big and complex for any one person to do alone. Sometimes a question "do you know how X works?" is literally just that - a query to see how much knowledge/experience you have on a specific topic, so people can help you learn more. (Of course sometimes people can take it too far) On June 21 2014 10:43 darkness wrote: Has anyone got any experience with Java 8? Is there anything that is 'must learn'? I've seen lambda expressions, but they seem weird to me; not verbose enough. No direct experience yet, because my company has yet to bless java 8 for production environments, and I haven't had any time to dick around with experimental stuff. That said, can't wait for lambda expressions. Gonna remove a lot of bullshit anonymous classes that you have to hack in to do stuff that shouldn't be super hard to write. Also interested to see what tooling I'm gonna have access to around type annotations, though my guess is it's gonna be years out for me ![]() I was just joking with a co-worker today - "What if the powers that be directing java are secretly haskell fanatics, and by java 12 we suddenly get full blown functional goodness?" http://res.cloudinary.com/readnuts-com/image/upload/c_fit,h_350,w_350/jayr9ifjyl9ztmjflk32.jpg :\ | ||
|
Ethenielle
Norway1006 Posts
On June 21 2014 03:06 urboss wrote: Why not use an abstract class and derive the public class from it? I'm not sure how this would help...? The issue is that the engine needs to know about variables the user shouldn't know about. It's hard to answer because it's the 3846th time I get an unqualified "your code sucks" without any further help. I have no previous experience with writing graphics engines, I spent a couple of months reading through Frank D Luna's Game Programming with DirectX 11, which was ok for getting started I suppose but it had so many holes I spent an equal amount of time just googling stuff. Anyway, that's that. If I knew exactly how to craft a graphics engine I probably wouldn't be asking. Anyway, we went from my code sucks to callbacks and internal classes suck. Could you help me with how I am supposed to design the public interface for say a light or sprite? mcc Not sure I am a fan of having setters for every property directly in the engine, I mean from a user point of view it would be hard to find the relevant setters for a given class, and from a maintenance point of view you suddenly have a colossal class chock full of irrelevant setters/getters. And having looked around at various other engines, they all seem to use a Light/Sprite/whatever class which you can work with in an intuitive manner. Maybe the "best" solution really is to put all relevant variables in their respective class and friend the engine...? Even though friend is anathema. Anyway, I appreciate you guys taking the time to help me out. Thanks! | ||
|
spinesheath
Germany8679 Posts
On June 21 2014 18:36 Ethenielle wrote: Maybe the "best" solution really is to put all relevant variables in their respective class and friend the engine...? Even though friend is anathema. Friend is one of the better options C++ has to offer in terms of encapsulation. You shouldn't overuse it and you should know damn well what you are doing, like with everything else C++. But there really is no reason to hate on friend. Whether it's the right tool for you task, I don't know. Didn't do much work in that area. | ||
|
Manit0u
Poland17496 Posts
On June 21 2014 10:46 phar wrote: ^ As a meta point in software development, it is good to develop a thick skin to questions that seem overly blunt. A lot of people aren't trying to be mean, they just might not present things in super nice ways. People are also often very willing to teach and explain things, because helping other people understand how things work is the only way any shit gets done in software. Modern software is way too big and complex for any one person to do alone. Sometimes a question "do you know how X works?" is literally just that - a query to see how much knowledge/experience you have on a specific topic, so people can help you learn more. (Of course sometimes people can take it too far) No direct experience yet, because my company has yet to bless java 8 for production environments, and I haven't had any time to dick around with experimental stuff. That said, can't wait for lambda expressions. Gonna remove a lot of bullshit anonymous classes that you have to hack in to do stuff that shouldn't be super hard to write. Also interested to see what tooling I'm gonna have access to around type annotations, though my guess is it's gonna be years out for me ![]() I was just joking with a co-worker today - "What if the powers that be directing java are secretly haskell fanatics, and by java 12 we suddenly get full blown functional goodness?" http://res.cloudinary.com/readnuts-com/image/upload/c_fit,h_350,w_350/jayr9ifjyl9ztmjflk32.jpg :\ Screw Haskell, LISP is where it's at ![]() | ||
|
Shield
Bulgaria4824 Posts
So for example:
I'm just wondering if I'm not doing some major bullshit. It's my own project, so I have no constraints about what I code. Edit: I know the classic Factory pattern usually involves a static method but I decided not to pass arg1 and arg2 every time, and not every listener needs both at the same time. | ||
|
bangsholt
Denmark138 Posts
Have you heard of MVC? One view has one controller. One controller can have more views. Why would you have a controller per component? If it's because you have overlap in usage, you can always extend on a base class that provides the shared functionality. | ||
|
billy5000
United States865 Posts
| ||
|
Nesserev
Belgium2760 Posts
| ||
|
berated-
United States1134 Posts
On June 24 2014 10:56 billy5000 wrote: Got a question about eclipse. We have a workspace that consists of many projects, and there's a bit of a delay. Ideally, I would like to load a single project on eclipse rather than loading all of them. So instead of the root being the workspace, it would be the project. Is there a way to do this? Where is the "bit of delay" you are trying to get rid of? Sorry if you have already tried this, or if this isn't where your delay is, but, have you tried closing the projects you aren't using? I've had 75+ projects in a workspace and if a lot of the projects were open it would bog it down, but if you just close the projects you aren't using then everything was fast. | ||
|
billy5000
United States865 Posts
On June 24 2014 20:32 berated- wrote: Where is the "bit of delay" you are trying to get rid of? Sorry if you have already tried this, or if this isn't where your delay is, but, have you tried closing the projects you aren't using? I've had 75+ projects in a workspace and if a lot of the projects were open it would bog it down, but if you just close the projects you aren't using then everything was fast. I didn't know about closing projects, thanks! | ||
| ||


