Jump to content
  • Advertisement

l0calh05t

Member
  • Content Count

    594
  • Joined

  • Last visited

Community Reputation

1821 Excellent

About l0calh05t

  • Rank
    Advanced Member

Personal Information

  • Role
    Programmer
  • Interests
    Audio
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Probably still F.E.A.R (1)s planning system Check out http://alumni.media.mit.edu/~jorkin/goap.html for a list of other games that use GOAP.
  2. Yes, just pointing out that it doesn't address what i meant (even if it addresses what I wrote literally) I'm also all for const correctness, I just don't like writing members twice for const correctness. Also const should be the default anyways ;) It's not about compilers being dumb. Sorting members for reduced padding would be trivial. But the spec doesn't allow it
  3. A lot of the "additional runtime stuff" is clean error checking and unicode support. Strip only helps because cargo builds with symbols, even in release mode (and Linux isn't quite up to the level of Windows wrt separate debug symbol support). There is a (slightly out of date) github page that lists some approaches to reducing file size even further: https://github.com/johnthagen/min-sized-rust
  4. Nonsense (at least on Windows). I have built Rust applications using Win32 API and dynamically loading functions that used less than 200 kB. And a hello world is approximately the same size as in C++.
  5. Yes and no. First, the "this->" is optional (in most cases, except some more exotic template dependent name resolution cases) which is a huge difference. And second, you cannot even optionally have something like "Foo * this" in your parameter list. And now just imagine we could have "auto && this" in our parameter list, and no longer needed separate const and non-const versions of members like begin(), end() and data(). Or those nasty trailing "const", "const &", "&", "&&" specifiers on member function declarations.
  6. Funny, I wish C++ had an explicit this/self like Python or Rust!
  7. l0calh05t

    OpenGL compute shader problem

    A diagram can be helpful to better convey the concept, but you still need to properly define it. In any case, I think we are diverging a bit from the original topic of this thread Besides, I have to continue working on my dissertation
  8. This is completely untrue for centralized VCSs like CVS, Subversion, or Perforce and only applies to DVCSs like git. This is also untrue of most VCSs. Most VCSs (including git) store snapshots, not differences. While these are stored efficiently using compression and referencing unchanged files (svn) or blocks of content (git), they are still snapshots. The only exceptions I know are darcs and pijul. The main problem with binary file diffs for size reduction (semantic diffs are a separate issue) and compression isn't even that they are binary, but that they are often already compressed (jpgs and pngs for example), so a small change might change almost everything.
  9. Standard algorithms are great too, but too many people don't use them for no good reason (probably lack of understanding). And destructors are by far the most important and best C++ feature. What I like the least about C++: Non-destructive moves require almost anything that requires a limited resource to be "nullable". Followed by the signed/unsigned conversion rules. Also that std::endl doesn't do what it says it does (well, it does, but it also does something unexpected by 90%+ of C++ programmers).
  10. l0calh05t

    OpenGL compute shader problem

    That is odd, I have never experienced this. Normally potential reviewers should be clear from the "related work" section of your paper. That section should mostly consist of peer reviewed papers though, if not that will earn you a quick rejection. I can't really suggest any journals, as it is outside my domain of expertise. Some reviewers can be a bit unfriendly, especially if it is anonymous/they believe it is anonymous. But I had a quick look at your manuscript and I am sorry to say that i am not surprised that it got rejected. Your abstract isn't really clear, you cite no related work, you assert things without proving them or citing a proof, you do not motivate why you are looking at the topic/why anyone should care about it, you do not really make it clear what your contributions are (and it's difficult to guess, as there is no related work section), and the core of the paper consists of a snippet of code and some images (with numbers of unclear origin in the captions).
  11. l0calh05t

    OpenGL compute shader problem

    You do not need credentials to get your paper published. Most high quality academic journals and conferences use a double blind review process, so if you "credentials" are the issue it is probably not a good venue in the first place If you try to publish at a conference, you have to be able to afford the registration fee and the trip to the conference, though.
  12. Have you had a look at https://docs.microsoft.com/en-us/windows/win32/medfound/about-dxva-2-0 and https://stackoverflow.com/questions/19846770/how-do-i-use-hardware-accelerated-video-h-264-decoding-with-directx-11-and-windo?
  13. If you have the world space position, sure, you can (estimate) the near and far planes: Take three points on the near plane to form a plane and compute the distance between the plane and the camera position, that should give you zn (unless you have something weird like a oblique near plane going on http://www.terathon.com/gdc07_lengyel.pdf). Do the same with three points on the far plane for zf. If you definitely don't have any off-center projections, you can also just take a point on the near and far plane at the center of your screen and just compute the distance between those points and the camera position. All of this will fail if the view matrix contains any scaling/shear components.
  14. No, it does not. Think about the following: Do zn and zf vary if the camera moves? The z component of the view frustum corners in world space do vary when the camera moves.
  • 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!