Image borders randomly flickering
Monkey Targets Forums/Desktop/Image borders randomly flickering
| ||
| Hi, After months and months of just reading here, I am trying to start a real project using Monkey. I have this piece of example code It shows a (badly drawn and animated) guy moving across the screen while moving his arms and legs (using image rotation). When I compile it to HTML5 it runs OK. When compiling to Windows Desktop target using MinGW, the images' borders tend to flicker (not always the same parts of the body are involved). When I set the limbs' rotation to 0, the display is fine. Scaling the pictures seems to alter the borders too (borders appear while they should not).  My PC is a 2009 Lenovo S10 notebook running Windows XP. The graphic chipset is an Intel 945 Express. I have no other test machine right now but when trying some similar piece of code on my PC at work it seemed to work OK. What's wrong and what should I do? Thanks, |
| ||
| OK I've been reading this http://www.monkey-x.com/Community/posts.php?topic=1559 this http://www.monkey-x.com/Community/posts.php?topic=2134 or this http://www.monkey-x.com/Community/posts.php?topic=5359 But image padding imagechargee = LoadImage("tete2.png", 1, imagechargee.XYPadding = 2) doesn't seem to change anything... |
| ||
| How are the PNGs? created? It may be a problem.in the files? |
| ||
| Thanks Ziggy The images were PNGs made using Gimp. I've tried replacing them with simple shapes also made with Gimp, getting the same results. Should I change any parameter while saving the PNGs? |
| ||
| I get this strange feeling that certain intel integrated chips don't play well with Monkey, but I have nothing to validate this feeling save for a few anecdotal reports. Have you tried testing your code on a different machine? |
| ||
| Hi and thanks for advice I've tested it today on a PC at work with an integrated Intel chip (haven't checked which chip) and it worked well. But well, now it seems to work on my machine too. I first tried to manually add a transparent border around each image using Gimp, but it didn't change a thing. Then, I discovered that Image.XYPadding parameter and tried to use it but without removing the padding around my PNGs. I got the same result. At last, I realized that I was in fact using two padding methods instead of just one. So I removed the extra borders around each picture and kept a 2px padding using Image.XYPadding... And the random lines around the pictures disappeared. So even on my very low tech miniPC I finally got it to work (apparently), but it seems as if I have to try everything I code on many different machines to see what happens. EDIT : ahem still doesn't work. I've changed the dimensions of the GLFW window in the Config file just to see what happens, and the lines show up again. |
| ||
| Maybe if you can provide a sample with media somehow we can take a proper look to this issue? |
| ||
| Thanks in advance! Monkey code + data folder here : https://www.hightail.com/download/ZUcyaklxUENEa1hSc01UQw This is just some example code, my original code leans on (the great) Ignition X framework but the scaling/rotation issue is just the same whether I use iSprites, iEngines, iPlayfields and so on, or just Mojo code. |
| ||
| see other thread |
| ||
| see other thread |
| ||
| Well thanks for sharing Nori! From what I understand there are basically two minimal steps : 1/ add padding at the top and at the left of the picture, either by using something like Gimp or the XYPadding way. 2/ simply draw the image while keeping in mind that it should be drawn a bit more on the left and on top. If these are the only two basic steps to draw any picture somewhere on the screen (no matter if it's exactly where I want it to be, or if it makes the code look weird), I'm already doing this and the weird borders still appear. Am I missing something important? I'm really sorry but at the moment, I don't quite get how your ApplyFlags code works, it's something I've never seen before :$ Is it simply a way to get things more automated? |
| ||
| 1/ add padding at the top and at the left of the picture, either by using something like Gimp or the XYPadding way. Yes, by using Gimp. I know of no equivalent XYPadding way, because XYPadding makes Mojo use the texel coordinates + 1, which is different. The idea behind this is - as marksibly described - that the GPU might grab a texel that lies outside. Where the idea of drawing a transparent padding is, that the GPU might do anything at the polygon edges, no matter how hard you try, so simply extend it by the transparent area, which hardly can fail. Both ways are pretty much incompatible. The latter might look likely to fail with transformations, but afaik it just works without problems. 2/ simply draw the image while keeping in mind that it should be drawn a bit more on the left and on top. Yep, but when creating a pixel perfect game, it's more convenient if Mojo handles the padding under the hood, either the XYPadding or the drawn padding, so I thought Mojo really would need a patch. If these are the only two basic steps to draw any picture somewhere on the screen (no matter if it's exactly where I want it to be, or if it makes the code look weird), I'm already doing this and the weird borders still appear. Am I missing something important? Yep, you're maybe doing this already...but probably with some helper function that does x-1, y-1 somewhere? I'm trying to avoid modifying the game code except for replacing the XYPadding flag by a DrawPadding flag. I guess if there are really still weird borders and the inner area is ok, it should be possible to remove the weird borders by adding more padding that is drawn (not XYPadding). Though, a way to still mess this up is having semi-transparent edges/padding, which become other colors when blended. The ApplyFlags etc. is part of modules/mojo/graphics.monkey and I thought adding 1 to the .tx and .ty (translation for Image handle) would be the simplest/fastest patch. What bothers me is that for a CreateTransparentPadding flag (to leave image files without padding at all), the surface loading would have to be modified and this is different code on each platform. On Android iirc that code even creates an opaque padding, probably for use with XYPadding. That part would be hard to modify. I guess in the end it should be possible to just use images as they have been exported and then only use hypothetical flags DrawPadding and CreateTransparentPadding and get rid of all badly transformed border pixels. |
| ||
| see other thread |
| ||
| I get the same output as yours on your test file, and indeed the way to get it right is to modify the picture file itself and not to add padding using XYPadding, thanks for that. When running my own example code, however, adding any amount of padding to my pics and setting XYPadding to 0 doesn't change a thing. The borders appear and disappear in some situations, but there is still no way for me to avoid it completely, while most people seem to fix it by just adding padding... |
| ||
| Can you upload your project again? |
| ||
| Hi again Here is another link : https://www.hightail.com/download/ZUcyb2VGaTEzMWxWeHNUQw The test pictures and animations look terrible, sorry about that, but that's not what matters here. I've added a 4px border to every image, but I get the same results as when using borderless images... Thanks for trying to find out what's going on. |
| ||
| Ah, ok, the only way I could reproduce your problem was commenting these two out. //glTexParameteri( GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_EDGE ); //glTexParameteri( GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_EDGE ); And by using outside texel coordinates it would probably look a bit like that too. But I've no clue why your card does this. :I I didn't really see that your problem was different, so I'll move my jaggy-fix to another thread, sorry for that. |
| ||
| Apparently from what I read on various topics here and there, unsolvable OpenGL issues only happen on a few machines, but like many of us I am targeting people (specifically, speech therapists :) ) who mostly don't care at all about computers, and are likely to own very low-specs and/or outdated office machines, with the cheapest Intel chips around, and I'm not comfortable at all with the idea of just refunding unhappy customers instead of giving them what they expected. A few thousand copies of my first two softs, which I both made using BlitzMax, have been sold to this day, and there have been very few complaints about reliability, bugs, and so on, whatever machine, old or new, they were running on. I really enjoy Monkey, even more than BlitzMax, it's cleaner and more powerful, and I don't intend to give up, but that unreliable desktop target is a real issue. Maybe targeting HTML5+Mobile would be the right solution? Anyway, thanks a lot to you Nori and everyone here for spending so much time helping us all and keeping the community alive. |
| ||
| Just found by accident that on this site http://www.opengl.org/wiki/Common_Mistakes they use three calls instead of two like Mojo does: glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE); glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE); #define GL_TEXTURE_WRAP_R 0x8072 glTexParameteri(GL_TEXTURE_CUBE_MAP, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE); Maybe there's something up with that R? I don't even know what it stands for, maybe you can add that line to mojo.glfw.cpp and see. |
| ||
| Hi, Thanks Nori, Unfortunately, adding #define GL_TEXTURE_WRAP_R 0x8072 glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE); (without having a clue what I'm doing) to mojo.gflw.cpp doesn't change anything... :( Some of us will have to to live with those annoying image borders... |
| ||
| Hi I found some kind of indirect solution by changing my Intel chipset's 3D settings, more precisely by turning the "force s3tc texture compression" parameter ON. (default position being OFF). I'm afraid what seems to be working on my computer won't necessarily be what will work on anyone else's machine, but that's rather promising anyway... (NB the code I'm using right now includes 2px XYPadding, and the images I'm using don't have padding.) |
| ||
| try to avoid NPOT textures, specially on older or laptop gpu chipset (and at all) i had this problem often on openGL and also on monkey glfw, check if the images got a power of 2 size in pixels (like 32x32, 64x512 and so on), maybe this helps. for me this helped once i had a similar problem. At all maybe you should consider to pack all your body parts into 1 bigger image, and use a array or something to hold the cordinates of your body part. Or try out my module wich can load this information from ini files and draw single parts with differend size as if they were normale image frames: http://www.monkey-x.com/Community/posts.php?topic=6033&post=69093 something to read about the power of 2 texture problem: http://www.opengl.org/wiki/NPOT_Texture http://gamedev.stackexchange.com/questions/7927/why-would-you-use-textures-that-are-not-a-power-of-2 specially this is maybe exacly what you got: "•There could be edging artifacts caused by mip-map interpolation, your 25x25 texture might have a black fringe where pixels were added to stuff it to 32x32 size." |
| ||
| Hi Salmakis Thanks a lot for helping. Changing the dimensions of the arms, legs, torsos, heads and so on to 128, 256, 512 and so on indeed seem to solve the problem. When displaying NPOT images along with POT images, NPOT images' edges flicker while POT images' edges don't. So using POT textures definitely looks like the right solution. My code and my pics don't need to be changed much. Plus your ImageMap class seems to be very handy, I'll try it very soon. Thanks again everyone, I learned a lot from all the answers in this thread. [EDIT : Now I'm only using power of two images in my game, and I can confirm that all the bugs are gone. Using POT images is quite as easy as using NPOT images, and looks like a good habit to have when aiming at Windows Desktop]. |
   |