• 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.

xycsoscyx

GDNet+ Basic
  • Content count

    455
  • Joined

  • Last visited

Community Reputation

1149 Excellent

About xycsoscyx

  • Rank
    GDNet+

Personal Information

  • Location
    Seattle, WA, USA
  • Interests
    |programmer|
  1. OpenGL

    Here's a good description of the light volume part of the level format: http://www.mralligator.com/q3/#Lightvols Here's an interesting article talking about actually trying to use the light volumes for rendering: http://www.sealeftstudios.com/blog/blog20160617.php
  2. It looks like TransformFrustum only takes a single value as a scale, so even though the matrix supports full XYZ 3d scaling, this just breaks it down to 1D scaling, so the X scale is used for all XYZ values. Oddly, if you look inside the TransformFrustum call, it actually creates a full XYZ 3D vector from the single scale value, then uses that with its internal transformations. It seems like the function should just take a XYZ scale to begin with, instead of converting from/to.
  3. OpenGL

    Quake 3 used a light grid, it's a 3D grid of precomputed lights that it creates during map compile time, then find the closest N lights for the dynamic models that it is rendering. It then just uses simple vertex lighting from that set of lights for that model. This is just for dynamic models though, the scene itself is all precomputed lightmaps (though they are toggled/adjusted to achieve more dynamic effects, like a rockets light trail). The Quake 3 code is readily available online, you can look it over yourself to get an idea of how they did it/
  4. http://www.xsquawkbox.net/xpsdk/mediawiki/XPWidgetFunc_t   Looks like you need intptr_t instead of long for the parameters, most likely whatever compiler settings you are using (64bit?), intptr_t is not a long.
  5. What's actually going on with the screenshot?  It's a little hard to tell because of the saturation, but it looks as though you are doing lighting first, then subtracting the shadows over top of that?  If that's the case, then you need to flip it around a bit.  Shadows should restrict what a light contributes to the scene, not subtract from it after doing all lights.  Each shadow casting light source will only add to the non-shadowed area of the scene, so the shadowed areas still get the full light from other sources affecting that area (instead of looking like the shadow is dulling down the additional light sources).
  6. Keep in mind that a rendering engine is far removed from a game engine.  Typically, the game engine will contain a rendering engine, but that should only be a small part of the entire game engine.  Beyond that, a software rendering engine really isn't necessary for actual rendering, it's great to know how things work under the hood, but learning D3D/OGL/Vulkan/etc is going to be more applicable to modern game development than a software engine.  A software rendering engine is great for doing CPU occlusion culling though, but there you're working entirely with depth and visibility and pure optimizations to improve performance.  
  7. Instead of assigning each tile one of the images at random, what about using all 4, then having a vertex weight for each.  This will let all 4 tiles surrounding a vertex use the same weight (to prevent seams), but then you randomly distribute the weights per vertex (or use noise, or etc) to break up the look per quad.  The downside though is that you're dnow doing a lot more texture fetches, 4 blended together vs 1 that varies per tile.   I just realized you said about texture splatting, which is basically what I'm suggesting.  Instead of using a separate texture for the splat though, you could just use additional vertex data for the blend weights (even just a single RGBA value).
  8. What about detail mapping, cover the large terrain with one texture, then add a repeating detail map after that.  The larger texture should prevent any patterns, while the detail map mostly improved the detail closer up so that things aren't as blurry.  Rastertek has a good series of terrain articles, including one specifically about detail mapping.  
  9. First off, wanting to use C over C++ is perfectly acceptable, just don't confuse the reasons why.  Don't also confuse C over STL; C++ is not STL, STL is a standardized library to aid in development, but it's built on top of C++ itself.  You can develop in C++ without ever needing to use STL.   - I have no idea what internally happens in the implementation of the std library and after a look at the source: i seriously do not wanna know. Why do you need to know what happens internally?  Playing the devils advocate a little here, but the fact that it's pure headers means you can understand it, it's just a (very) complex beast.  Wanting to use C over C++ doesn't magically make your code cleaner or the implementations more accessible/readable either, neither does C over STL.   - I always do programming in a object oriented fashion and wanted to do it differently now: Seeing the other side too Is your original example really an example of the other side?  Composition over inheritance are two pretty distinct paths and separate, but using STL over reinventing the wheel doesn't really seem productive unless you're a beginner wanting to learn the how.  Even C over C++ isn't really seeing the other side, C++ offer numerous features over C, but that doesn't mean you are forced to use those features.   - I want to have full control over memory and all systems in my game -> Nothing should be a blackbox Again, allocators, they're actually not overly complicated and let you have (admittedly mostly) full control over memory.  I will note that because of potential performance impacts, allocators are not as fully customizable as originally envisioned, but they do allow creating pools for allocating from, just like your examples.   - I do not want to be forced to any programmings patterns whatsoever (Ctor, RAII, Singleton, Templates, Interfaces, Classes, New/Delete etc.) Note that singletons are the only real pattern in that list, the rest are either idioms or features of the language.  While you are forced to use some of those features when using STL, you're not forced to use all of them (singletons, new/delete, interfaces, raii).  Again, STL is a tool to help replace common code that (invariably) gets used anyways, you accept that you're using templatized classes when using STL.  Those classes themselves do have constructors, but you don't have to create constructors for your own types when using STL.  STL also doesn't require or prevent usage of raii, singletons, interfaces, new/delete, etc.  That's entirely up to you on how to want to use what STL provides.   - Zero initialization is great, even though its a c++ feature Zero initialization only makes sense when things need to be zero.  I only have a handful of classes that actually need to be all zero, and even then I still prefer member initialization because it makes the code a lot cleaner and more readable.  You don't even need to search for the constructor body, you just see the initial value right at declaration.   - static_cast is nice, but i still prefer the C way for game development The C way of casting is ambiguous, which I can imagine is a big reason why they added different casts in C++.  I actually wish there were a compiler option to error on C style casts (is there?), since I still tend to use them without noticing, especially for simple data types.  They're quicker to write and quicker to crash, I like the explicit and single purpose nature of C++ casts so that I can prevent issues.  I actually don't see why you'd want to use C style casts in game development, when typically you do want every little bit of performance games that you can get.  Someone please correct me if I'm wrong, but using explicit casts and type conversions is going to offer greater gains than relying on the ambiguous C style cast.  At the very least, the compiler will choose the correct cast and do the same thing, but then that's entirely up to the compiler (and may change between compilers?).   - I want to be not afraid of pointers and memory anymore, which i was 5 years ago What does fear/lack of fear of pointers and memory have to do with it?  You don't use STL because you're afraid of pointers or memory, you use STL because you don't want to reinvent the wheel.  You can write your own code to handle allocation/traversal/release of everything (or use other existing code), or you can use STL, or even a multitude of other libraries.  STL is just a tool to aid in development, same as your own code samples, same as EASTL.   - I am not afraid to write complex code Then you shouldn't be afraid of using STL, which doesn't really decrease the complexity of code if you're already using boilerplate helpers.  It's just a tried and tested alternative to your own ad hoc code.  I'd say that adding macros and an array of independent functions ends up leading to more complex code, but honestly to each their own on that point.   - I do not want to just write less code by the cost of abstraction, making it harder to read, less understable What do you mean abstraction though.  You're already trying to abstract out the linked list implementation into a set of independent functions, which is the same thing that stl::list does.  Using STL has the advantage of making everything self contained, accessing a list works on the list itself, no casts, no independent functions, etc.  Unifying the containers also has a huge advantage, everything has a begin/end/size/clear/etc, you can iterate over the container the same way regardless of what type of container you are using.  If you want to switch to using a vector instead of a list, you just change the type, as long as you're not using list specific operations then everything down river works exactly the same.   - You think much more about memory, performance and the hardware when doing low level programming -> You learn a ton STL doesn't prevent you from learning about memory, performance, or hardware.  I don't think STL does anything in terms of hardware actually, that's still entirely up to you.  I was recently looking more into SIMD, that requires learning about the hardware, the compiler, etc.  It also required learning about allocators in STL to support proper alignment to store the data.  Thinking about performance still applies when using STL too, using STL doesn't instantly bottom out your performance.  STL has wide range of functionality, but the most common still seems to be the containers, using STL containers over your own implementation doesn't change anything else in your application, you still have to look into performance issues, bottlenecks, etc all the same.
  10. There's a range of things you could do, I assume you are talking about the Doom style fade effect between levels?  You could setup a basic sand simulation inside a compute shader, you'll basically flip between two targets, read the source, run the simulation, write the results to the destination, then flip them and run again next frame.  Each pixel becomes a particle with a color and starting position, then just apply gravity.  If you add a pass to each particle, you can setup a gradient so that the bottom pixels are heavier (fall quicker sooner), and add a random weight factor across the board (or based on average/max/etc color) so that things don't fall uniformly.  Then each particle gets set back as a pixel on the destination, and anything blank gets cleared out using alpha (or color keying/etc).
  11. I just got a similar redirect, to a site stating that my computer was infected and I can pay to have the viruses removed.  I have put gamedev on my adblocker whitelist for a while now, but have gotten these kind of ad redirects thanks to not blocking the popups.  I appreciate that they are taken care of and that the site admins try to keep up on these kind of things, but I have ad blocker for this very reason, if I have to disable ad blocker to view this site (without the built in nag), but this site gives me reason to want an ad blocker, then what am I supposed to do?
  12. In terms of Unity, a shader defines HOW things get handled.  It defines the pixel programs and whatever passes may be needed, and how the input data (meshes typically) are displayed on the screen.   For something like forward passes, shaders need additional properties like albedo, normal maps, roughness maps, etc.  These are variable and can change frequently, despite the core shader itself staying the same.  The material fills in those properties for the shader that it is linked to, so that everything you display can look different.
  13. http://newtondynamics.com/forum/newton.php   Newton Dynamics, it's a physics library that includes a demo sandbox with car/vehicles, and it uses OpenGL for the sandbox.  The latest (in development) version has a pretty impressive car, including a working model of the internals to actually simulate the vehicle.  The previous versions used a more common ray cast vehicle, which still works, but lacks realistic features like drifting (which of course is important).   Viola!
  14. I like to randomly strip out sections of code to see if it improves the build times.   :)   Sometimes it's so fast, it's as if it doesn't even build at all!
  15. Álvaro's solution is great because it's easy to extend, really he's just using a split function twice.  The first split separates elements at the ; character, then the second split separates the substrings at the : character.  You could rework that into a single function that returns a vector of strings split by a delimiter.  You could then split by the ; character first, then for each element in the vector split by the : character.