Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About yyam

  • Rank

Personal Information

  • Role
  • Interests


  • Twitter
  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ah no wonder I wasn't getting any traffic from this page! I fixed the link.. Thank you! Yeah I really like how cute the hedgehog turned out
  2. Very late reply, but thank you! You were right about the reserved words!
  3. Hey there! I released my game, Hedgehogs Can Fly, on GameJolt today! It's a cute, 2D physics-platformer where you try to fling a hedgehog through tricky levels to get to the finish line. I wrote it from scratch in C++ with SFML. There are multiple types of terrain each with different properties and effects making for some interesting level design. The physics/level code also allows for free-form terrain that isn't constrained to a tile grid. The levels are loaded from color-coded image files, I have an entry in the devlog on the GameJolt page explaining how it all works! If these screenshots look cool, visit the GameJolt page here (With Trailer Video!) Screenshots incoming... Have a nice day
  4. I'm starting out learning graphics programming with DX11 and Win32 and so far I haven't found many quality resources. At the moment I'm trying to string together a few tutorrials (some based on DX10) to try and learn the basics. The tutorial I was reading used a D3DX function to compile shaders but as far as I understand, this library is deprecated? After some digging, I found the D3DCompileFromFile() function which I'm trying to use. Here is my c++ code: HINSTANCE d3d_compiler_lib = LoadLibrary("D3DCompiler_47.DLL"); assert(d3d_compiler_lib != NULL); typedef HRESULT (WINAPI *d3d_shader_compile_func)( LPCWSTR, const D3D_SHADER_MACRO *, ID3DInclude *, LPCSTR, LPCSTR, UINT, UINT, ID3DBlob **, ID3DBlob **); d3d_shader_compile_func D3DCompileFromFile = (d3d_shader_compile_func)GetProcAddress( d3d_compiler_lib, "D3DCompileFromFile"); assert(D3DCompileFromFile != NULL); ID3D10Blob *vs, *ps; hresult = D3DCompileFromFile( L"basic.shader", NULL, NULL, "VertexShader", "vs_4_0", 0, 0, &vs, NULL); assert(hresult == S_OK); // Fails here hresult = D3DCompileFromFile( L"basic.shader", NULL, NULL, "PixelShader", "ps_4_0", 0, 0, &ps, NULL); assert(hresult == S_OK); FreeLibrary(d3d_compiler_lib); In the failing assertion, hresult is 'E_FAIL', which according to MSDN, means: "Attempted to create a device with the debug layer enabled and the layer is not installed." I'm a bit lost at this point. I am also not 100% sure my D3DCompileFromFile signature is correct... It does match the version on MSDN though. Any ideas as to why this might be failing? I tried putting in the wrong file name and got (as expected) hresult == D3D11_ERROR_FILE_NOT_FOUND. So at least this is some indication that I haven't totally screwed up the function call. For reference, here is the shader file. I was able to compile it successfully using an online HLSL compiler. struct VOut { float4 position : SV_POSITION; float4 color : COLOR; }; VOut VertexShader(float4 position : POSITION, float4 color : COLOR) { VOut output; output.position = position; output.color = color; return output; } float4 PixelShader(float4 position : SV_POSITION, float4 color : COLOR) : SV_TARGET { return color; } Thanks for your time
  5. Thank you so much! Really great info, clears up a lot! Thanks everyone, you'll probably see me again when I screw something up
  6. 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
  7. 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());
  8. 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.
  9. 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
  10. yyam

    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.
  11. yyam

    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
  12. 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

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!