Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

117 Neutral

About IvanK

  • Rank

Personal Information

  • Interests
  1. Thanks. I understand BC1 - BC7 compressions, I implemented them all in Photopea (in my own code, everything happens on the CPU). It is true, that if you want "the best" BCx compression (with the smallest error), it can be very hard to compute (especially in BC7). But in practice, having nearly-best compression is enough (if it was not, you would not use compression at all) and it can be computed in a real time just before sending the texture to the GPU. So I think that artists should store textures in JPG, and games should load JPGs, parse the raw data, compress into BCx and send to the GPU. BCx compressor can be a tiny library having about 10 kB, there is no need for any huge binaries from nVidia or ATI. Storing textures in JPG is better, because they are always smaller than DDS, while having the same quality. That is why I don't understand, why DDS files are created and distributed.
  2. Hi. I would like to show you my tool https://www.Photopea.com . You can use it as a viewer of .DDS files (works even on your phone). It supports BC1, BC2, BC3 (DXT1, DXT3, DXT5) and BC7 (DX10) compressions. I would like you to test it a little, if you have a minute. Next, I have a philosophical question regarding the texture distribution. I am new to this area. As I understand it, we want textures to be small "on the wire" (on a DVD / HDD / delivered over the internet). Next, we want them to be small in the GPU memory. I think it is clear, that any non-GPU-ish lossy compression (such as JPG or WebP) can achieve much better quality/size ratio, than any DXTx format (even zipped DXTx). So JPG or WebP is more suiteble for using "on the wire". I often see developers directly distributing textues in DXTx format (DDS files) "on the wire". The usual excuse is, that decoding JPG and encoding it into DXTx (at the moment of using the texture) would be too time-consuming (while DXTx can be copied to the GPU without any modifications). I implemented a very naive DXT1 compression into Photopea (File - Export - DDS) and it is surprisingly fast (1 MPx texture takes 80 ms to encode). So I feel like compressing textures (to DXTx) right before sending them to the GPU makes sense. So what is the purpose of the DDS format? Why do developers distribute textures in the DDS "on the wire", when there are better compression methods?
  3. IvanK

    Order of which to do things

    You definitely should go to some college or university. It is hard to learn everything by yourself.
  4. I think you can solve it in constant time on paper (or with one expression in your programming language), no need for loops
  5. Thank you. Promit: two-parameter "atan(y,x)" in GLSL is equivalent to "atan2(y,x)" in HLSL. There still is a black vertical line on left. Yours3!f : that is weird, I have no idea why it happens. Have you tried using Chromium?
  6. Hi guys, I am sorry, I don't have any real problem, I just wanted to show you what I have done during the last weekend and didn't find any good category for it and also I want to ask few questions. I have written a simple GLSL raytracer, which is rendered in browser using WebGL. http://frog.ivank.net Few interesting things about it: in Windows browsers it is 2x slower than in Linux or Mac OS, because all Windows browsers translate GLSL to HLSL and render it with Direct3D. It started to be 2x slower when I started to use a texture for environment. I really didn't expected that texture access is so "expensive". I also have 2 questions: When I map the image as environment and I want to get a texture coordinate from ray direction, I use "atan" function to get an angle float iPI = 1.0/3.14159265357; float cx, cy; cx = 0.5 - 0.5 * atan(dir.x, dir.z) *iPI; cy = 0.5 - asin(dir.y)*iPI; but there is a black vertical line appearing on the left side. Do you know how can I avoid that? It will be probably because of division by zero or something. So what do you think about it? Do you have an idea for any other "cheap" effects or objects, which will be nice looking, but keep my demo at 60 FPS?
  • 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!