Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

371 Neutral

About chingo

  • Rank
  1. Just keep in mind that if you are linking against 3rd party libraries or use 3rd party source code in your project you will need to check what license they are distributed under and how that license impacts the licensing of your own code. I.e. you cannot just use any old open source library/code out there and assume automatically that you can distribute your program in binary only form without making your source code available under a specific license. Open source code is free as in free speech, not free as in free beer. If you are not using any such open source code/libraries or only use code/libraries distributed under a commercial or a very liberal license you'll be fine. 
  2. You can e.g. wrap your 'variadic function' inside a lambda function and make your exec function accept this lambda: #include <iostream> #include <functional> void ExecuteFunc(std::function<void()> fn) { fn(); } void Func1(std::string s) { std::cout << "Func1(" << s << ")" << std::endl; } void Func2(int a, int b, std::string s) { std::cout << "Func2(" << a << ", " << b << ", " << s << ")" << std::endl; } void main() { ExecuteFn([]() { Func1("foo"); }); ExecuteFn([]() { Func2(1, 2, "bar"); }); }
  3. One more option is to install VS2013 for Windows Express on the side and use that to debug your desktop exe. I did this for while and it worked. Haven't tried the community edition, it may be a better option nowadays.
  4. On Windows, HeapAlloc() and HeapFree() can be used instead of the runtime specific memory management functions (new/delete, malloc/free) to ensure that dynamically allocated memory is always freed from the correct heap. Using runtime specific versions, smart pointers and whatnot internally within a module/DLL is fine but if you pass these memory blobs out of the DLL to be freed elsewhere, you should consider HeapAlloc/HeapFree as a safe, although a bit cumbersome, option.
  5. Saying GOTO is harmful is like saying chopsticks are harmful. GOTO is a tool which is good for some things and not so good for others. Saying "GOTO can't be used ever for anything because it's bad, m'kay?" is silly.   Personally, I often prefer to use GOTO liberally while writing driver and other low level code in C. Here, I regularly write functions consisting of longish sequences of steps involving HW states and kernel resources. Each of these steps need to succeed and the only "else" action for any of the individual steps failing is to roll back everything done so far much more carefully than what I could get away with in "application/user mode code". Due to being limited to C, I can't rely on RAII, destructors, exceptions and stuff like that to clean up after me when something goes wrong.   Why not if-else or nested functions? A 25 step function would lead to 25 nested if-else statements or 25 nested function calls. I consider this worse from maintainability and "code esthetic" points of view than repeating 25 times "do something; if (failed) goto RECOVER;" with a roll-back section at the end of the function.   That said, I practically never use GOTO in/with higher level code/languages (C++, C#, Java, etc.) where I rely on the in-voque mechanisms of garbage collection, RAII, exceptions (and, like most user mode code developers, perhaps unconsciously, eventually the OS cleaning up my mess after my process crashes).  
  6. chingo

    Terrain patch border issue

    I had a similar issue with terrain patch borders in my hobby engine where the GPU interpolated the edges of my patches in a wonky way. After panicking and failing miserably with different texture addressing modes in my heightmap texture sampler, I got finally it: make the heightmap texture for a terrain chunk include one extra value on each side (i.e. make the texture contain N+2 values for a chunk of size N in both dimensions) and modify the texture coordinates in vertices accordingly (i.e. "skip" the outermost values outside the actual terrain chunk). The seams I had disappeared completely.   EDIT: And I think this is what AdeptStrain suggests come to think of it. Oh well...
  7. You can use the Visual Studio 2013 Express for Windows for debugging shaders from your desktop app. Use Open Project from VS2013 for Windows to open the executable (probably the Debug build) and you will be able to use the Debug|Graphics option just fine. I.e. the twist is that you develop using one VS version and debug using another.
  • Advertisement

Important Information

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

GameDev.net 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!