GDNet+ Basic
  • Content count

  • Joined

  • Last visited

Community Reputation

1149 Excellent

About xycsoscyx

  • Rank

Personal Information

  • Interests
  1. OpenGL Quake3 ambient lighting

    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 Quake3 ambient lighting

    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. 2D Sprite SDF Tool

    Just to note, all of the steps in the link that Hodgman posted are not specific to Photoshop, you can do the same thing with free software like Gimp. If you just want a command line method, you could perform the same steps via ImageMagick as well, potentially all from a single command line.
  5. 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.
  6. 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).
  7. 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.  
  8. Moire' patterns

    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).
  9. ground quad and ground texture sizes

    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.  
  10. Linked list adventure

    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.
  11. dissolve effects (shader) on an image

    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).
  12. Malware link in adverts

    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?
  13. difference of materiall and shader

    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.
  14. simple game build

    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!
  15. What to do besides fencing?

    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!