Jump to content
  • Advertisement

vstrakh

Member
  • Content Count

    260
  • Joined

  • Last visited

Community Reputation

2456 Excellent

About vstrakh

  • Rank
    Crossbones+

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Audio
    Programming

Recent Profile Visitors

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

  1. vstrakh

    Help disassembling laptop

    Yep, they are. But the guy pulls cables quite brutally. Definitely not the proper way to disconnect those.
  2. Well, there's already a lot of formats as simple as this one. Wavefront OBJ would be the one closest in simplicity, and widely supported by modeling sw. It doesn't support per-vertex color officially, but that won't stop some sw (namely MeshLab, MeshMixer) from exporting it. Still, drawing the models as a list of verts without indexing (to reuse verts) is quite suboptimal. I mean, it's totally ok for a bunch of rectangles, but bad for a bigger models with smooth surfaces. You'll find that later you'll want to add indexing, normals, texture coordinates. It will require changing your format and your modelling tool, etc. So the obvious choice would be to write the importer for reading few formats that already has required info and is supported by many authoring tools. You still might want to have your own format, but only if it makes your files loaded significantly faster, preferably without any processing. It should be as close to the real hardware needs as possible. That means binary, with data formats which is supported by target hw - no doubles or half-floats for coordinates, using 16-bit indices, vertex alignment, etc. I.e. it will be a "dump" of actual vertex/index buffers, as required by hardware you're aiming for.
  3. Don't. There's crap, this guy has nothing to do with the gamedev.
  4. vstrakh

    POSIX thread resume and suspend

    Seems it was there in Solaris, but not in Linux: https://www.ibm.com/developerworks/systems/articles/porting_linux/
  5. A single tiny AVR/PIC chip would be more than enough, and would work from a single coin cell battery (or 3 button cells), consuming some nanoamps in sleeping mode. I wonder though why it must be a bunch of discrete elements instead of a single microcontroller. The components count is already too high for such a toy.
  6. Did you try other codecs, more suitable for lower bitrates? OGG files was mentioned already, but OGG is just a container. The audio stream would be compressed with specific codec, and Vorbis is typically associated with OGG. It's much better than MP3, but probably not any better than AAC. But check also if Opus codec is supported by your target platform (still within OGG container). They claim that Opus is much better than the other "general sound compression" competitors at lower bitrates: http://opus-codec.org/comparison/
  7. It should be all about heuristics used and tie-breakers. Visit Amit Patel's site about pathfinding, there's tons of options considered, with many examples. Here's one of related links: http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#breaking-ties , see pic in Diagonal distance section.
  8. vstrakh

    Optional arguments confusion

    That optional argument "const FLOAT *dashes" is a pointer. Means you can either supply actual data - array with dashes lengths, or not supply anything. For pointers/arrays that means passing zero/nullptr. You can't omit it in a sense of C/C++ optional arguments, but you can some give data or not, that's what "optional" means in this case.
  9. vstrakh

    GNU gettext not working

    putenv() should be in "stdlib.h". On windows there's _putinv() function in same stdlib.h. In my old app I had to undefine __STRICT_ANSI__ define before including stdlib.h when building for windows, can't remember now which building environment required that, probably mingw32.
  10. There's _putenv() on windows
  11. vstrakh

    GNU gettext not working

    Call setlocale(LC_ALL, "") and do putenv() with LANGUAGE environment variable set to desired language. Apparently gettext checks environment variables when choosing translation.
  12. Worked with it long ago with no problems, used in a portable win32/linux app. See quick tutorial here: http://www.labri.fr/perso/fleury/posts/programming/a-quick-gettext-tutorial.html The main "problem" you can hit with gettext - is when you want to change language explicitly. It's important to call setlocale(LC_ALL, "") and have LANGUAGE environment variable set to desired language. Normally gettext returns translations depending on system's settings, so if you want to change language from within the app - just putenv() LANGUAGE var explicitly. Also pay attention to .mo files final location. It must be as described in tutorial, e.g. "top_translations_dir/language/LC_MESSAGES/domain.mo". In bold there's your language (en/fr/ja, etc), and text domain, top_translations_dir is location passed to bindtextdomain()
  13. vstrakh

    parsing obj files

    When you have vertex normals, you don't average them. Something like weighted averaging needed only when you calculating normals on your own, because there's no normals data in obj file. Now you must construct all vertices with all corresponding data (just like that, combined value of position/texture_coord/normal), then build index, removing duplicate vertices, i.e verts that has all the same pos/tex_co/norm. In the end there might be more verts in your vertex buffer than there's 'v' directives in obj file, and that's normal. The first thing you must accept - is that 'v' directive does not create your final vertex. It only describes position in space. Resulting vertex is a combination of all data from all v/vt/vn streams. Face vertex index in 'v' stream will tell about source vertex identity (same index means physically same point, while different indices means unrelated verts even if those are in same position), but that's needed only when you reconstruct normals, so shouldn't bother you at the moment.
  14. vstrakh

    how to parse obj file?

    Doesn't matter. See Wavefront Object specs pdf: https://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf
  15. vstrakh

    SDL_TTF crashes c++ program?

    Working directory could be anything, and probably you don't need to know that at all. What you need to know is where .exe file located, so resources could be read by the path relative to .exe location. See SDL_GetBasePath() function: https://wiki.libsdl.org/SDL_GetBasePath Place your assets near exe file, maybe in subdirectories. Then open it by concatenated name - base path and asset file name.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!