Jump to content
  • Advertisement

Cararasu

Member
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

158 Neutral

About Cararasu

  • Rank
    Newbie

Personal Information

  • Role
    Programmer
  • Interests
    DevOps
    Education
    Programming

Social

  • Github
    Cararasu
  1. You can load the Library manually with the LoadLibraryA/LoadLibraryW function. With the handle of the loaded library, you can get a pointer to your function with GetProcAddress. All three are located in Kernel32.dll. More information you can find in the Windows-documentation: https://docs.microsoft.com/de-at/windows/desktop/Dlls/using-run-time-dynamic-linking The difference between the LoadLibraryA and LoadLibraryW function is how the library-filename is encoded. The A-version takes regular ASCII characters and the W-version takes wchar_t which is a 2-byte character.
  2. As far as I can tell Raspberries all support OpenGL ES 2.0. I do not think there are drivers that natively support OpenGL 3.0 for their graphics chips themselves. But in case you want the functionality without worrying about performance you can always get Mesa-library which falls back to software rendering in case features are is not supported. https://www.mesa3d.org/
  3. Cararasu

    Int vs. Float Graphics Programming

    Incidentally I thought about the same question for the last few days. The following answer is what I came up with: While it is true that there are only 3 integer values between -1 and 1 it is still possible to get a much higher resolution. Just think of UNORM and SNORM. UNORM means integers are normalized values in the range [0,1] and SNORM in the range [-1, 1]. e.g.: Using this you can subdivide the range into 2^32 parts with a 32-bit integer and not just 3. The big problem is that with this you can not represent values outside of the range. Therefore representing positions with U/SNORM integers does not make much sense. As you are restricted to a very narrow range. Another more sensible way would be to split one distance unit into smaller ones. For example, you can split one meter into 1 million parts. That will create a very fine-grained grid of possible positions. Snapping to the grid will not really be noticeable. With 32-bit numbers, you get a very big grid(40km x 40km) and with 64-bit integers it is quite enormous(10^10km x 10^10km). At first glance that sounds fine. The problems with integers are that you want it to be fine-grained, but you still want to be able to calculate with them. The bigger the numbers the bigger the problems. Take floating-point numbers as an example: Adding a very low number to a very large number may lead to no change at all to the large number. Nonetheless, floating-point numbers work well if you are careful. While floating-point numbers get inaccurate if there is a large discrepancy between the 2 numbers, integers freak out completely if you multiply 2 large numbers. Let's explain with a little example: With the previously defined grid let us calculate the distance between 2 points. The difference vector is (1*10^6, 2*10^6, 0) which corresponds to (1 meter, 2 meters, 0 meters). We now have to calculate the square root of 10^6^2 + 2*10^6^2 + 0. This results in the square root of 3*10^12. 10^12 is approximately 2^40 which cannot be represented in a 32-bit number and therefore gets cut of after 32-bits and the resulting square root gets some completely unpredictable value. This effectively limits us to 16-bit values which are not very accurate. If there is ever the need to multiply 3 numbers of that scale then we already need 60-bits to represent it which already nearly overflows in a 64-bit integer and our points are just a few meters apart nearly at the center of the world. With bigger numbers the problem gets only worse. A 1km distance means a squared value of approximately 2^60. 10km means 2^66. Switching to 64-bit values helps a bit but that only gives us safe values up to 32-bit. Another possibility is to cast up to 128-bit numbers for each calculation and cast back down to 64-bit at the end. This could work but 64-bit multiplication is already not easy(is there a 64-bit multiplication instruction on x86-64? I have not found any. Not even in the SSE instructions) and 128-bit calculations are even more complicated. Especially on 32-bit systems. 128-bit multiplication is probably still faster than a double precision floating point multiplication, but for every multiplication we might overflow our value which might spell disaster. TLDR: I would say the problems in floating point calculations is the lack of precision which is not so bad. Problems in integer calculations are completely wrong results because of overflows which is very bad.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!