Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 10/06/19 in all areas

  1. 2 points
    @lawnjelly If it goes well, I'm considering either: Changing repository status to public on my server (maybe fork it to Github) Publishing that ray tracing library as a library (with few examples) Writing some articles about ray tracing dynamic scenes The library I'm using (a custom one) is OpenCL based renderer - it doesn't have hard syntax (it might need a review or two - and maybe updating the interface after the project - as I'm adding classes/methods whenever I need them for this project). I'm currently busy making and animating a daemon from hell. 100% programmer's art.
  2. 1 point
    The main advantage is that it's fool-proof, i.e. it fails at compile-time if you pass it a non-array type such as a pointer, whereas the sizeof trick silently produces incorrect results. // This function looks like it takes a fixed-size array as argument, but it really takes a pointer. void f(int a[10]) { std::cout << sizeof(a) / sizeof(a[0]) << "\n" << std::flush; // Silently produces incorrect result. std::cout << array_size(a) << "\n" << std::flush; // Fails at compile-time. }
  3. 1 point
    "b" registers are for D3D10 and above (SM 4.0+), and "c" registers are for D3D9 (SM 2.x and 3.0). In D3D9 era the shader programming model exposed a set of constant registers, and you would set those registers one at a time using functions like SetPixelShaderConstantF. The shader would then use the values of those constants when when executing. For D3D10 and Shader Model 4.0 the constant registers were scrapped, and replaced with constant buffers. Instead of dealing with 1 constant register at a time, you would instead create buffer resources of arbitrary size (up to 64KB or so) and bind the entire buffer to a single slot/register. The "cb" register is used for these constant buffer slots when the shader assembly needs to read from a particular buffer. Confusingly even though the assembly refers to the registers as "cb", in HLSL you use "register(bX)" to specify which register you want the constant buffer bound to.
  4. 1 point
    Not really for standard behavioral AI. The problem is primarily that it doesn't scale well as you add more potential actions with objects. The search space explodes geometrically as you add more things to do. Also -- and likely worse -- you have to re-plan anytime anything in the state space changes and invalidates one of your nodes. So not only do you have huge search times, most of that is going to get thrown away on many of your think cycles. Now multiply that across a lot of agents.
  5. 1 point
    Hi, I seriously doubt this could ever work. First, your assembly is for real mode. Just because you changed the header to "32 bit OS", doesn't make the code valid in protected mode, hence the syntax errors most likely. Second, even if you fix the syntax errors, that code is calling real mode BIOS functions, which are not and never were available in protected mode. Third, if you have a new machine, chances are good there's no BIOS at all, as it's using UEFI. Unless you configure a legacy CSM, then even if you switch the CPU mode back to real mode you couldn't use those interrupts. Fourth, if you could fix everything I've listed so far, even then that assembly code is using VGA IO registers directly, something that modern video cards won't like or respect. Chances are good that this code would simply crash unless you have an old VGA-compatible video card. To help you understand the situation: real mode: 16 bit operation mode of the CPU, which allows accessing 64K of memory at once, and 1M tops with segmentation. protected mode: 32 bit operation mode of the CPU, which allows access to 4G of memory, and provides memory protecion (hence the name). The CPU's internal operation is fundamentally incompatible with real mode (different stack alignment, existence of interrupt descriptor table, existence of privilege levels etc. etc. etc.) BIOS: a program stored in a ROM which was compiled for real mode. It provides so called interrupt services, like int 0x10 and int 0x16 you try to use. UEFI: successor to BIOS, which does not provide any real mode services of any kind. New machines have only this, and maybe, if you're lucky, they have a special CSM module installed, which provides a legacy compatibility mode for BIOS. IO registers: special address space in the CPU, independent to the memory, in which all peripherals has an address (or more addresses) and which is accessible regardless to the CPU mode. A certain video card standard, the Video Graphics Array used the port 0x3C8. Other newer standards, like SVGA, XGA or XWGA however does not. Some cards emulated the VGA modes and IO ports to retain compatibility, but that's long gone by now. Modern cards doesn't even support "teletype output mode" any more, which you try to set with SetTextMode_near, only linear frame buffers. Cheers, bzt
  6. 1 point
    Well, the good news is that it's all open source and you can read the code yourself! (It's kind of high in interface abstraction, though, making it harder to follow 😞 ) Dpeending on which flavor you're using: https://github.com/SignalR/SignalR https://github.com/aspnet/SignalR
  7. 1 point
    In a good OO design, this doesn't happen. The Circle class Must be the representation of a circle in the geometric sense and nothing else. It cannot be allowed to depend on something that isn't geometry, such as a spatial index, a Canvas, or a file. This is called the "single responsibility principle": forcing together multiple responsibilities means creating tensions when anything changes. Should derive from a Shape interface or abstract class, together with other shape types. This makes clear that there are functions that apply to any shape (e.g. computing area, perimeter, bounding shapes), and operations that only make sense for circles (e.g. construct a regular polygon with the same center and the same area and a given number of sides, which can be useful as an approximation) In practical terms: The renderer should find a way to treat all shapes the same way (e.g. if the Shape interface offers a point containment test and a bounding convex polygon the renderer can test samples inside the region of interest) or segregate different Shape subclasses by their different rendering methods (e.g. scanline rendering of circles, scanline rendering of whole convex polygons and scanline rendering of a triangle decomposition of nonconvex polygons) A spatial index should probably deal with Shapes and their bounding shapes only. Serialization could be allowed in Shape classes because it's so basic and intrusive, but keeping it outside would be cleaner.
  8. 1 point
    I definitely agree that OOP can be easily abused and I posted examples that were contrived to make OOP look bad. I guess my major problem is the way OOP is taught. I feel like most new programmings come into programming trying to solve everything with OOP and do it poorly.
  9. 1 point
    My beef with OOP is the "OP" part. Objects are fine, but they are just one of many tools. When I was programming in C in the 90s, I often found myself making a struct like this: typename struct { int width; int height; Pixel *data; } Image; Then I would write a bunch of functions (FillWithColor, DrawPixel...) that would have a first argument of type `Image *'. Then there would be a function to allocate memory in the `data' field, and a function to deallocate it. In essence, that and a bit of syntactic sugar (so instead of `DrawPixel(my_image, 40, 50, red)' you can call `my_image.drawPixel(40, 50, red)') is all an object is. It's tidy to think of the struct and these functions as part of the same thing, and the fact that C++ will call destructors for you automatically and at easy-to-predict times is wonderful. But to approach program design by trying to shoehorn everything into this paradigm is a terrible idea. Use the tools that are appropriate for the problem at hand. Lately I've become a fan of the signal-slot paradigm to try to keep dependencies down to a minimum.
  10. -1 points
    A renderer instance is a global state. This can lead to flickering colors caused by other people's modules. Turning off one module can break completely unrelated features. Adding a base class Renderable is easy, but removing it two years later will break things. Then you somehow ended up with seven layers of inheritance and have no idea which function will be called because they all have the same name. You'll later see that you needed Printable, Listener, Serializable, FactoryConstructable, et cetera and create more helper classes trying to wrestle the growing complexity. Compile time type safety goes out the window when you don't have time to implement virtual methods for all 47 types, so you end up leaving an error message in the base class. Then you realize that you never needed polymorphic storage to begin with and can drastically reduce the number of heap allocations that caused memory leaks and cache misses. A basic API using overloads and templates then brings back type safety and allow customers to call the API from another programming language using simple type prefixes, so don't add inheritance just because you can.
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
    Arslan Ahmed Bhutto
  • 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!