• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

2224 Excellent

About Kaptein

  • Rank
  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. Yea the build folders are cleaned out each time, so unless there are some hidden files it should be empty
  3. 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. 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. 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. 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. 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. 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 :)