• Content count

  • Joined

  • Last visited

Community Reputation

236 Neutral

About idinev

  • Rank
  1. Viral Marketing from Tipp-Ex (Awesome!)

    I typed "hugs" ... and they did hug o_O drinks/kisses/kicks/fights/meets/moonwalks/cooks/eats/pwns
  2. When baking the texture, make it have an alpha-channel. With GIMP, dilate the texture, this will create the extra border. Blurs and such would do. But now I checked, Blender has a setting to increase that 1px border. It's in the Buttons_Window/Render_buttons/Bake/Margin. Increase that to 5-16 px (depending on the atlas size and complexity), and you'll be fine.
  3. Don't forget that there's the NDK, you can code in C++ with it. Beware of ANY extensions, and anything beyond GLES1.0 . The emulator and different real devices have completely different capabilities beyond the core. [Edited by - idinev on August 7, 2010 7:34:16 PM]
  4. There has been a Sixaxis driver since 2008. Improve your google skills :).
  5. Lines of code in a lifetime

    For 9 years, I have barely passed the 1 mil mark; even though lots of the time I was coding in asm initially. Furthermore, my LOC norm has been decreasing with time, but I'm getting much more work done with fewer lines. Before, I was cramming 2k-5k/day asm ; then 1k/day in C; now either just dozens per sitting or 1k-2k in Java/C++ 1-3 times per week. Spending most of the time polishing and designing UI to make it transparent. Thus, I feel productive only when not doing UI. Then, there's also refactoring and R&D. Typing 3k lines in a sitting, finding the patterns and optimal flow - to delete the 3k lines and minimize them into 300. Kinda sucks, as my boss rarely sees the 3k ones.
  6. No love for Java?

    I think I like Java... after 7 years of daily development with it for smartphones professionally. It's simplistic, and has some nice timesavers. C# and stuff may be more handy, but I haven't had any reasons to delve deeply into them; x86/ARM asm and C-style C++ are perfect for my hobbies and job. What I don't like is how shitty the GC in some phones/OSes is (300ms lockup to free-up 10 independent instances?? On a 500+ MHz device??) , or how extremely buggy some OSes are. At times I had to reimplement half the GUI input+visualization to combat extreme bugs or slowdowns that OS devs couldn't be bothered to fix for months/years. Anyway, every programmer has to pick their tools per task - whenever possible; not blindly stick to one tool/language.
  7. You've misunderstood the BGRA issue. It's not that gpus handle them natively, but that GDI/Windows requires pixels in BGRA order. Plus, this is an issue from 10 years ago; has been solved long ago. No perf difference between RGBA and BGRA.
  8. Deferred Shadows advantages

    Quote:Original post by IrYoKu1 I would never though that including these functions in hardware could impose such performance penalties. Things like dfdx and dfdy are internally necessary for texture-filtering: choosing the appropriate mipmap level (and anisotropy params), as the fragment-shader decides at what texcoord to sample from. Having dfdx and dfdy exposed as usable opcodes is just a free bonus :)
  9. First try removing stencil-related stuff, starting from: glBlitFramebufferEXT(0, 0, Width, Height, 0, 0, Width, Height, GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT, GL_NEAREST); It sounds like it's a bug in the drivers, though.
  10. Have two VBOs. - One containing pos.xz (and normals and texcoords, etc). Static VBO - one containing only pos.y . Dynamic VBO. Bind the attributes from both vbos, draw. In the vtxshader recombine.
  11. OpenGL VBOs and N-gons

    :( sorry, but it's embarrassingly obvious. Arrays.
  12. OpenGL VBOs and N-gons

    Create two copies of the data: one for the selection, and one triangulated and indexed for visualization.
  13. OpenGL VBOs and N-gons

    You don't need to improve anything or even use VBOs. Because you use several things that fall back to software and special-preprocessing in the driver. Thus, you're definitely not pursuing speed optimizations.
  14. Quote:Original post by MegaPixel glMultiTexCoord since I'm using cgfx if that can matter etc. Two flaws: - that's the pseudoinstancing. It's completely different from uploading uniforms!!!! Try uploading constants! - you're using cgfx; beware that some functions in Cg actually do glGetXXX() before uploading GL states. This was fixed after a specific recent Cg version iirc, but I'd use glslDevil or something to double-check.
  15. Timezones, heard of them? 3 hours without replies is long only for an IM chat. ---------- Do a test in GL without instancing at all. Just this: for(int i=0;i<64000;i++){ glUniformXXX(); // upload matrices glDrawElements(); } Search the forum for a recent topic on this same subject; there's some insight, For example, I've had GTX275 draw with GL 145k instances, @50fps, 14mil tri/frame, deferred render : be it with a simple uniform-upload/drawcmd loop or uniform-array instancing. (the latter leaving much more headroom for the cpu). GL is that fast.