Kaptein

Members
  • Content count

    496
  • Joined

  • Last visited

Community Reputation

2224 Excellent

About Kaptein

  • Rank
    Member
  1. There should be a stack for each execution environment, so threads, fibers and interrupt handlers get their own. There is also separate stacks when switching to kernel simply for security reasons. Otherwise, I would only switch stack if I needed a really big one for something, and that hasn't happened yet. We just make regular function calls into DLLs, so it's all executing inside the same execution environment. I would assume DLLs also used the standard libraries for memory management, if the code in those DLLs make calls to new/delete or malloc/free then that's what's going to happen.
  2. CMake is insane on Windows

    Yea the build folders are cleaned out each time, so unless there are some hidden files it should be empty
  3. CMake is insane on Windows

    Unfortunately, it's the same output as before: it detects CLang 4.0.1 and then proceeds to MSVC EDIT: I tried cmake with MSYS, and I also get the same output: cmake -G "MSYS Makefiles" -DCMAKE_CXX_COMPILER=/c/LLVM/bin/clang++.exe -DCMAKE_MAKE_PROGRAM=mingw32-make .. ... /C/LLVM/bin/clang++.exe /nologo /DWIN32 /D_WINDOWS /W3 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 Even if I should find some hack to make this work, it shouldn't be behaving like this.
  4. I am trying to build with Clang on Windows for the first time. I usually use G++ but it creates large static files which irritate me. I also want to try CLang on windows, since I use CLang exclusively on Linux. There is nothing that seems to work to make it stop sending "MSVC-like" parameters to the compiler. How can I disable MSVC-detection? It clearly says: C:\Projects\dm2\clang>cmake .. -G "MinGW Makefiles" -DCMAKE_CXX_COMPILER="c:\\LLVM\\bin\\clang++.exe" -- The CXX compiler identification is Clang 4.0.1 -- Check for working CXX compiler: c:\LLVM\bin\clang++.exe -- Check for working CXX compiler: c:\LLVM\bin\clang++.exe -- broken ... c:\LLVM\bin\clang++.exe /nologo /DWIN32 /D_WINDOWS /W3 /GR /EHsc /D_DEBUG ... predictable output ... what's going on here? EDIT: I'm using newest CMake, newest LLVM for win64, newest MSYS and MinGW64. I am successfully building statically with G++ as of writing this.
  5. Profiling

    Yeah. live stack sampling is more of a "we don't have any other choice, because its hardware". It does have some positive traits though, eg. if the sampling source is bias-free then so are the samples. I'll defer to your experiences with full frame analysis. I always thought I would want to see data on a specific point and then "do things" in the game to figure out how that area changes in time-cost. Your answer on the cells seem right to me. Sounds like uniform voronoi grid thing I did ages ago. Thanks.
  6. Profiling

    Hey all, As the code slows to a crawl we have to instrument our binaries, but its been a while since I did programming on a platform that had options. I'm used to live stack sampling inside small kernels, and because of this I don't want to go back to the stone-age of fully instrumented executables. I had a look at CxxProf: https://github.com/monsdar/CxxProf/wiki/What-is-CxxProf%3F and it looks nice. Especially the part where you can pick and choose where it does the work. But, before I go ahead and do all this integration, what profilers do you use? Not to mention, CxxProf hasn't been updated in 3 years, although hopefully it still works well. Actually, I have to sneak in a second question. I'm dividing my levels into a grid of X*X cells so that I only have to iterate over the cells (X-1 to X+1, Y-1 to Y+1) to find nearby objects. Using a "hash" of the cell position to assign objects to cells, where each cell has a set of objects. Does this sound like a plan?
  7. I need some advice. After I changed my scripting language from in-memory C to Lua I've had numerous problems I've never encountered in other languages. Prototypes? Type signatures? Calling functions with any number of parameters? How do you deal with all the random bugs you can get that you have really no way of determining the cause of? If I call a function with one less parameter than it should have, I might just get a Lua error somewhere else in the script. At a later time. What do you do to make your code (which isn't bottlenecked at all, so there is tons of room to add checks and balances) more correct and more sane? If I scripted sanely in C I would rarely have these issues. For example any pointers passed between the engine and the script goes through a sanitizing stage where it actually checks if the pointer points to an actual valid existing entity. If it sounds like I am regretting the change, I don't know how to answer that. Lua can construct tables and pass them around, which is very nice, unlike C where I would have to malloc (and that is just not going to happen).
  8. I actually haven't tried that interface yet. All I wanted to do was pass a memory address to Lua, which Lua should interpret as opaque and just pass back as parameters to my engine interface. I will probably try the class-like method at some point and see how useful it is.
  9. sleep c++

    POSIX has usleep which can sleep for microseconds, although if the sleep is very short its probably just a pause loop. If you are using a non-decade-old compiler you'll also have access to: std::this_thread::sleep_for(std::chrono::microseconds(usec)); in C++, which will be portable.. if that means anything to you
  10. I solved this, for now, by passing uintptr_t around. Thought about putting the objects index into the 16 unused address bits, but I haven't needed it yet. It's very strange though, that LuaBridge can't pass even void* around. I would understand it if it tried to translate objects (I've seen the more complex usage), but void* should just be passed around as an opaque pointer, which is what it was designed as. Disappointing too. And why am I not Prime Members anymore
  11. Hey, I am currently using LuaBridge as the C++ interface to Lua, and I'm having trouble passing a simple pointer to Lua (as a unique identifier for an object) and then back again. The Lua script calls "object(...)" which returns a pointer, and the pointer is stored in a local: "local obj = tbl.object(....)". If I then proceed to use the variable obj for anything, it's always "nil". What's going on here? I would think this was the most basic and repeating pattern in Lua scripting to use memory addresses as identifiers as well as simplify access to engine internals. static Object* object(int x, int y, int w, int h, int floor) { auto obj = std::make_unique<Object> (gworld(), x, y, w, h, floor); gworld().objects().add(std::move(obj)); return obj.get(); } ... static void object_frame(LuaRef id, int tex, int x, int y, int w, int h) { printf("object_frame(%p, tex=%d)\n", id.cast<Object*> (), tex); } ... gns.beginNamespace("dm") .addFunction("object", object) ... local obj = dm.object(x,y, 8,8, 0) dm.object_frame(obj, gui.tex, 80 + 9*idx,0, 9,8) The value of id, which should just be a memory address, in the "object_frame" function is always nil.
  12. Scripting language

    Alright, so I went with LUA and MoonScript. Flexible enough for me. I like the simplicity of both, although the moonscript OO class syntax is kinda weird. At least it works. LUA seems to have OO capabilities in an unusual sense. And I don't have to choose. I can mix and mash moonscript and LUA as I please!
  13. Hey guys, I've been looking at AngelScript because I need a scripting language. I've previously been using TCC always, because it compiles to native code and its kinda fun to compile to memory.. Now I look at AngelScript, but it feels kinda weird. Only reason I know about AngelScript is I remembered it from gamedev.net a long time ago! :)   I don't really need tight integration, just need a language that can capture storage into lambdas (which of course TCC never could as its a C compiler), but im getting tired of the temporary storage issue. I have no intention of writing abstractions for storing event data. I would like the scripting language to solve this issue, otherwise why use it over TCC? :) I have also been considering just compiling the script with a C++ compiler, but no. It sounds horrible. There are people who would like to work with me, and I think they can do simple things in a scripting language, like create dialogue. Should I be using LUA instead? Any other recommendations? Any list of scripting languages that support anonymous struct functors? Thanks!
  14. Hey guys! I have done some thinking, and I can't see an obvious way to render my planar reflections without rendering "the mirror" first. My mirror is expensive to render twice, compared to just some planar equation. Hence the planar reflection. So, is there any way to write to the stencil buffer from say the shader rendering the mirrored objects? And then discarding say non-zero stencil values? Any quick example would be great.   EDIT: http://web.cse.ohio-state.edu/~hwshen/781/Site/Slides_files/reflection.pdf   I imagine I can somehow mark my reflected objects with stencil values, then when I draw my reflector I could discard non-zero stencil values... somehow.   EDIT2: I'm using clip planes, it seems like much a much simpler procedure, and just what clipplanes were meant to do! http://github.prideout.net/clip-planes/   ... Which means that with a constant water level (Y=64), all I need to do in the shader is gl_ClipDistance[0] = position.y - 64.0; with glEnable(GL_CLIP_DISTANCE0);
  15. C# seems good, but....

    I suggest Java or C#, since you won't get bogged down with all the complicated stuff that C++ has. Not to mention finding and utilizing all the right libraries just to get a window up. And setting up a toolchain. If you're gonna use C++, at least use multiplatform libraries and GNU compiler suite. If you just want to program inside of Windows for Windows, use C# for everything. It's going to take a long time (years) before you should even think about speed. Java and C# are not slow. It's just that C++ let's you do certain things manually, such as memory management and placement new. Which is an expert level topic.   Depending on what you want to achieve, or if you're like me, just want to program games - there are 1000 things to learn, which is why its not a good idea to start with something slow like C++. You'll want to learn about programming in general, data structures, object-oriented programming, basic memory management, lots of algorithms, linear algebra (which lets you do cool stuff like rotate objects), timestep/tick combined with physics, networking. And so on. So, it doesn't matter what language you choose. What matters if what you learn, and what you think is fun and interesting to do. Pick a language that is easy to get started with and has a gigaton of material. Avoid choosing a complicated language (C++), or one with less material to choose from (Basic derivatives). You don't want to get stuck on small things that don't matter.   Good luck :)