Jump to content
  • Advertisement

l0calh05t

Member
  • Content count

    543
  • Joined

  • Last visited

Community Reputation

1800 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. l0calh05t

    Is there a working resolution...?

    While less likely in a gaming scenario, some people also use their monitors in portrait mode, so a 16:10 becomes a 10:16. But if you are also targeting mobile, you may want to support portrait mode anyways.
  2. Aside from code signing which is absolutely the best way to gain trust, no way around it, because it actually ties the piece of software to you / your company and protects it from manipulation, the small things like zipping it along with some documentation / license text / whatever and setting a proper file icon can help a bit. Everything else is building trust over time. To tell your users to "use more antivirus software" is certainly not the solution, because most antivirus tools do not play well with others (and some like McAfee behave more like malware themselves...).
  3. Also, due to the separation of allocate/deallocate and construct/destroy, the C++ allocators cannot directly use new/delete (makes sense if you consider that std::vector can allocate memory on reserve without constructing anything, which isn't possible with custom new/delete)
  4. Allocators are very ugly. For an aligned allocator, you could always use the one included with Eigen https://eigen.tuxfamily.org/dox/classEigen_1_1aligned__allocator.html
  5. Standard new (and therefore the default allocator as well), don't align by more than the maximum alignment of any built in types, and __m128 for example is not a C++ builtin type
  6. Many vector instruction sets offer masked operations nowadays. And with instructions like movemask you can make sure that only those branches that are in use are evaluated. So it really is more of a programming model thing than actual differences in hardware.
  7. The lengths of your inner and outer curves are different so each curve will cause your inner and outer u coordinates to drift apart. Compute your u along the center line instead.
  8. I prefer to follow what the standard library and boost do, i.e., No type prefixes, this includes I for interfaces snake_case for both functions and classes CamelCase for template parameters/concepts UPPER_SNAKE_CASE for macros/defines For members I usually just use snake_case as well, without an m_ prefix.
  9. Whoa, it ain't supported in any GL 3 level hardware.    You sure about that? DirectX uses the equivalent of GL_ZERO_TO_ONE, so hardware support is likely present. Driver support is a different matter though.
  10. The simplest way of making 2D textures seamless is shifting them by half along x and y and blending that with the unshifted version depending on distance from the edge (or manually stamping the edges away to maintain more detail). The cubemap version of that would, I believe, be to rotate by 45 degrees along all 3 dimensions, placing the corners in the centers of the faces.
  11. l0calh05t

    Spaghetti code

    @Kylotan and @Daixiwen what do you think are the problems/why does visual programming only work for simple tasks in your opinion? I kinda wonder if it's only the same mistakes being made in such environments like a lack of hierarchies (or maybe just the use thereof? although that labview image in the first post looks like there are hierarchical blocks but they are always displayed inline, never worked with it though, only simulink) or that some abstractions like repeating the same operation on multiple inputs are missing.
  12.  You could do it via a geometry shader couldn't you?   That shouldn't be necessary in most cases. For normals using the screen space derivatives of the position usually works well enough. Furthermore, both DirectX and OpenGL support "flat"/"nointerpolation" for vertex attributes. In such cases, the "provoking vertex" determines the value for the entire primitive (see https://www.khronos.org/opengl/wiki/Primitive#Provoking_vertex). You may need to duplicate a few vertices, but not all of them.
  13. Move away from Git and move to a centralized versioning system like Perforce or Subversion that doesn't have issues with large files? Also, DLL/EXE PDBs are "special" in that it is probably better to use a symbol server with source indexing instead.
  14. This. But mind you... first, you must be very careful not to confuse two very different things: Screen size (1080p, 4k, ...) and pixel density (72dpi, 96dpi, 150dpi, ...).   It's even worse. There's a third factor that is equally important: (expected) distance to screen. Mobile phones are held a lot closer (~40cm) to you than the distance to you 60" 4K TV at home (~3 m). Or your much closer 4K 27" PC screen (~60 cm?) What really matters isn't so much dpi as view angle per pixel. Just to underline the need for configurable scaling, because you might be able to query a screens pixel size and physical size, you can only guess wrt distance. But do base your initial scaling on system settings (Window DPI slider).
  15. Scalable vector graphics tend to work best. If you know the potential scaling sizes you can also get crisp lines. For example in Windows 10, the smallest scaling factor step is .25 so horizontal/vertical lines that are multiples of 4 px (reference/low res scale) wide and aligned to a 4px grid will be crisp, without blurred antialiased edges. If you do go the raster graphics route, I'd recommend assuming the highest current resolution and always scale down (you can potentially do this at load time, no need to keep the high res graphics in VRAM). And make sure to use a high quality scaling filter, not linear interpolation (another reason to do this once before copying to the GPU) You should however at least allow for scaling up as well, because higher resolutions will likely be available in the not-too-far future.
  • 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!