• Content count

  • Joined

  • Last visited

Community Reputation

2456 Excellent

About vstrakh

  • Rank

Personal Information

  • Interests
  1. 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.
  2. 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/
  3. 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.
  4. 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.
  5. C++ 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.
  6. C++ 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.
  7. 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()
  8. 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.
  9. how to parse obj file?

    Doesn't matter. See Wavefront Object specs pdf: https://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf
  10. 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.
  11. Creating levels with Tiles

    Can it be that you're creating each tile as separate entity, and then draw every tile with a separate draw call? That's, probably, the only thing that could drop fps drastically. removed stuff that looked offending.
  12. SDL_TTF crashes c++ program?

    This code would crash if no "Sans.ttf" file could be found in app's current working directory. It doesn't crash otherwise for me. Check what's result from `TTF_OpenFont()`, is it null or a valid pointer.
  13. SDL_TTF crashes c++ program?

      Now it might be anything, since it's your actions. You'll have to show minimal crashing example, which we can build and test. Maybe you didn't initialize library properly, or misused it in some other way.
  14. Build issues with CL and GLFW

    Is there something that doesn't allow you to build your project using visual studio's projects/solution files? It just might be faster to create a solution with projects for all the libs you want linked statically. You will have those libs automatically rebuilt in whatever settings your main project require. It worked for me, including freetype and other opensource libs.