• Advertisement

Sponji

Member
  • Content count

    226
  • Joined

  • Last visited

Community Reputation

2505 Excellent

About Sponji

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. GLubyte array and getPixel function

    You are only multiplying y by the number of channels, so how about: int idx = (y * width + x) * channels;
  2. You're assigning texture coordinates to the first vertex 4 times and not setting the others at all?
  3. Yeah my bad, not sure what I was thinking, dunno why it looked so weird for me having a union with constructors. Didn't notice it was a linker error.
  4. How about struct Vec2f { union { struct { f32 x; f32 y; }; struct { f32 w; f32 h; }; f32 elements[2]; }; // ...
  5. Googled with "sdl2 mingw raiseexception" and it says that you should add this line before any calls to SDL:  SDL_SetHint(SDL_HINT_WINDOWS_DISABLE_THREAD_NAMING, "1");
  6. void function(const std::vector<std::unique_ptr<Base>> &v) {     // ... } void calling() {     std::vector<std::unique_ptr<Base>> v;     function(v); }
  7. parsing obj files

    https://www.gamedev.net/topic/663264-obj-file-problem/#entry5195460
  8. The documentation says that it doesn't modify the passed variable if the color isn't found, so you can just put up your own default values for the colors before trying to get them.
  9. Maybe Assimp just fails to load the ambient color, have you checked if those calls to aiGetMaterialColor return AI_SUCCESS?
  10. The model and animation seemed to work nicely for me, and the only modifications I made to that zip were just 1) that one quaternion line 2) adding that missing call to initWindow before creating the GL context 3) and adding glEnable(GL_DEPTH_TEST). And I realized that the mouse wheel worked after all, I just didn't expect it to update time directly :P
  11. Ok, I gave it a better try and seems like the main problem is in Model.cpp, line 263. glm::quat expects w,x,y,z for its constructor's parameters, and you've typed x,y,z,w. You should also probably enable depth testing somewhere with glEnable(GL_DEPTH_TEST). The model is still rotated 90 degrees by x-axis though, but that's some another problem. I'd suggest making helper functions for converting all the required types to glm (just like you have the convertMatrix function), I did it like this the last time I used assimp: static inline glm::vec3 vec3_cast(const aiVector3D &v) { return glm::vec3(v.x, v.y, v.z); } static inline glm::vec2 vec2_cast(const aiVector3D &v) { return glm::vec2(v.x, v.y); } // it's aiVector3D because assimp's texture coordinates use that static inline glm::quat quat_cast(const aiQuaternion &q) { return glm::quat(q.w, q.x, q.y, q.z); } static inline glm::mat4 mat4_cast(const aiMatrix4x4 &m) { return glm::transpose(glm::make_mat4(&m.a1)); } Also a tip for sending the bone transforms, instead of looping through the array, you can send everything at once, like this: glUniformMatrix4fv(glGetUniformLocation(program, "BoneMatrices"), transforms.size(), GL_FALSE, glm::value_ptr(transforms[0])); Hopefully this helped!
  12. CMake is totally fine, I use it on Linux too. And I don't mind messy code, but is this actually the version you described? I had to add a call to initWindow() and mouse wheel didn't seem to do much. Just tested it quickly though, I'll check this out better later today.
  13. Yeah, that could work, or did you find out the problem already?
  14. "The disadvantage is that WM_INPUT has no ballistics applied to its data, so if you want to drive a cursor with this data, extra effort will be required to make the cursor behave like it does in Windows. For more information about applying pointer ballistics, see Pointer Ballistics for Windows XP."   https://msdn.microsoft.com/en-us/library/windows/desktop/ee418864(v=vs.85).aspx   Too bad the pointer ballistics link is removed, though. Why do you want to use rawinput if you want the cursor position?
  15. I've been using SDL for years and I think it's just awesome to get stuff working crossplatform much easier. But of course it still takes time to get some specific things working in some weird situations. Probably took me a few days to get my little framework working with Emscripten the first time I used it, mostly because of a shader bug which only happened on Chromium.   I think you're in the right direction with designing it to work with different libraries, the final game under your framework/engine shouldn't care what library is creating the graphics contexts or processing input events or whatever. You can even make your own code for handling those later on, if it's really needed. Just don't spend too much time on making some random wrapper classes at first. Make it work with one library first and clean up if/when you realize something could be done better.
  • Advertisement