• Advertisement

yyam

Member
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About yyam

  • Rank
    Newbie

Personal Information

  • Interests
    Business
    Design
    Programming

Social

  • Twitter
    yyamdev
  • Github
    yyamdev
  1. Thank you so much! Really great info, clears up a lot! Thanks everyone, you'll probably see me again when I screw something up
  2. Hello! I want to get into graphics programming so I've started learning DX11 but I'm not sure if it's the best choice to learn first. Obviously the end goal is to know as many as possible, but we all have to start somewhere. My first question is should I start by learning one of the newer, lower level, "bleeding edge" APIs like Vulkan/DX12, or should I start with DX11/OpenGL? I heard some people say that Vulkan/DX12 aren't really THAT much harder than the others but I've also heard the opposite. My thinking for choosing DX11 was that it was going to be easier and it would give me some good base knowledge to go and learn the more complicated APIs later. My second less important question is should I start with the DX or GL size? I've heard that DX is more programmer friendly and is easier to debug so will be better for beginners, is this true? A bit of background on my competency: I feel like I have a good knowledge of C and C++, I've completed a handful of games with SDL and SFML and I do embedded C programming as a job. My 3D math is lacking but I feel like it's something I can learn. Thanks for your help
  3. [C++]Ways to access functions of other class

    This works: This ensures that CameraWorks::Update doesn't depend on global state. (Like it would in method 1 with "extern Player *player") Having functions depend on global state is generally considered a bad idea because it makes your code less flexible and makes it harder to reason about quickly. It's less flexible because now this function __needs__ a globally defined Player object to do it's work and it becomes harder to move code around to refactor. It makes the code harder to reason about because instead of just having the keep this function in your head, you now have to know about the entire global state that it uses too. This can be hard to keep track of correctly and you can often forget things that it depends on, leading to bugs that are hard to track down. Maybe your program doesn't exhibit these problems, but I've found that they crop up as the project gets larger. The next thing I'd say that it's a bad idea for your camera to depend on a Player object to know where it has to point. In the code you provided you're not really doing anything player specific. If I were writing it, I'd try to keep the camera from having to know about the Player class, even if that's the only thing it's used for. It de-couples your classes, keeps your code flexible and it's one less include file! I'd also move the cutscene logic to a separate function, and rename it for clarity: void CameraWorks::FollowObject(Vector3 position, Vector3 direction, camType type) { switch (type) { case camType::DEFAULT: pos = position - direction * 5 + Vector3(0, 5, 0); mViewport->Set(pos , position + Vector3(0,4,0)); break; case camType::AIM: pos = position - direction * 4 + Vector3(1, 3.5f, 0); mViewport->Set(pos, position + Vector3(2, 3.5f, 0)); break; } } // Later on... camera.FollowObject(player->GetPlayerPos(), player->GetPlayerForward(), player->GetCurState());
  4. I tried your code in windows and can confirm it draws the white rectangle, shame I don't have a mac to debug this with D: Another thing I notice is that your're linking to SDL2main and I believe that's only necessary on platforms that don't use a unix-style entry point. (See this) I Doubt it would do anything but have you tried not linking to that? If that doesn't work then I'd suggest trying to get a minimal program going that just clears the screen to red or something just so you're 100% sure it's not a code issue.
  5. What exactly happens? Do you just get one color on the whole screen? Does the window even open? One thing I notice is that you're calling SDL_RenderClear and then filling in the background color. SDL_RenderClear actually fills in the screen so you shouldn't need the extra FillRect. See this
  6. Advice Youtube tutorials/Online courses

    By all means watch tutorial videos if they help you get started. I agree with everyone else though, you'll do your best/deepest learning when experimenting on your own.
  7. Learning Making my First game

    I would recommend using Unity. It has a massive community and good documentation/tutorials. It's accessible to beginners while being good enough for pros. You'll learn a lot using it. Your enthusiasm is great. One thing to remember is that your first game isn't going to be good, even if you manage to spend 4 years on it! You start out by first making simple games that take weeks and slowly work your way up to making complex games that take years. Good luck and have fun
  8. If I understand correctly your mesh just shoots out "Mesh Changed" events whenever it needs to, and other systems are essentially 'subscribed' to these events? It sounds like this isn't a bad way to solve the problem. The mesh doesn't know/care about what happens to other systems when it updates, seems like a good separation of concerns to me. Maybe someone more experienced with graphics programming can chime in with their experience. Considering this method doesn't seem obviously bad, I think whats most important is to keep working but pay close attention to how this decision is affecting the rest of your project. If your code starts getting messy because of this, make the call and refactor. Best practices can only take you so far, often times the "best" way to solve a problem depends a lot on the specifics of your project. Developing a good sense of objectivity and awareness of your architectural decisions is invaluable The best way to do that is to bite the bullet and make some decisions!
  • Advertisement