Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Oct 2007
Offline Last Active Apr 02 2014 10:48 AM

Posts I've Made

In Topic: Inconsistency between XNA/DirectX and OpenGL rendering

30 March 2014 - 10:12 AM

Just wanted to weigh in with what the problem is/was...


Did you know XCode will take your png and modify it?  As part of the modification process, it premultiplies the alpha.  That's why this was happening.  I don't see any real way around it but to include pnglib in my project, or stop using pngs.


I've been programming for 20 years and this is the most infuriating thing I've ever seen.  The idea that they would MODIFY the data you're including in the bundle... and worse, they don't give you a way to turn it off.  There's notes on the web on how to turn it off, but none of them actually work.



In Topic: Inconsistency between XNA/DirectX and OpenGL rendering

29 March 2014 - 06:31 AM

Hi Erik,


I just tried the change from modulate to replace-- I got the dark rim on the unfiltered text as well doing that.


BUT, just flailing randomly, I tried this:



... and it seemed to work, at least for white stuff (haven't tried colored yet).


What are the implications of that?  That's not a correct alpha blend, is it?... maybe that's giving me additive, I don't remember.

In Topic: Inconsistency between XNA/DirectX and OpenGL rendering

29 March 2014 - 06:24 AM



Basically I have rectangles on the texture atlas-- so I'd say, for this image, draw with this texture rectangle.


The texture rectangle is modified on the OpenGL version-- so if I had rect=(0,0 - 10,10) on OpenGL it'll actually be rect=(.5,.5 - 9.5,9.5).  I have also tried rect=(.5,.5 - 10,10) and rect=(.5,.5-10.5,10.5) with those second two making it worse.  (Naturally all coordinates are converted to 0.0 - 1.0 by the width of the image itself).


So essentially it looks like:


Image rect is (0,0-10,10)
Fix it for OpenGL-- now rect is (.5f,.5f - 9.5,9.5)
Divide rect by width/height of texture to convert to 0-1


I also have tried kludging the actual draw positions onscreen, by adding .5 to them as well, with no luck.  Again, I've tried lots of combinations, everything from adding .5 to all four corners of the rect, to shrinking the rect by .5, and even tried expanding the rect by .5 as I randomly started lashing about for solutions.


* * *


For loading textures, at this time they're a simple PNG that I ensured had a white (invisible) background in photoshop.  For completeness, I tried drawing with no alpha and got white squares (if the background had been dark I'd have gotten the imprint of the letters over the background color).  Extra note: The utility I wrote to put the images onto the texture atlas automatically bleeds the pixel's rbg outward, so even without the extra step of going into photoshop to guarantee the white background, it SHOULD work.  But I did the photoshop thing for completeness.


I tried premultiplied alpha, but it didn't seem to help anything (it's easy to premultiply the alpha in my load pipeline)-- still got the rim. 


Extra wrinkle:  This is particularly frustrating because it worked at one point (I had this same fight a couple months ago, but it was easy to fix by simply adding the .5).  It stopped working after I accepted an update to OSX Lion.

In Topic: Same model, different UV's

10 March 2014 - 05:47 PM

Fan-freaking tastic.  Thanks a million Kalle!

In Topic: Same model, different UV's

10 March 2014 - 04:50 PM

In that case, the number of texture swaps might become prohibitive as well-- even if I write up a batching system.  The low end machine we're targetting is iPad2. 


This is probably the solution I'm going to go with, but I did want to exhaust my efforts first.  It does seem like a tremendous oversight to not have included some method of transforming UV in the pipeline.