Need help with SetTexture()

[Ledii]

Hey, so I'm trying to learn about how the frames work. So I want to get a image up on the screen.
I have already created a main frame where i put all the other frames of my addon so that I can hide and show all at the same time easily.

The problem I'm having is that there is not very many good tutorials on how to do this and any ways to find out what properties and methods all different objects have. And When I try to load the image I keep getting a green square!

I have this file setup:
AddOns(folder)
> MyAddon(folder)
> > code.toc(file)
> > code.lua(file)
> > Textures(folder)
> > > test.tga(file)

And my code to get the image showing on the screen is like this...
MakeFrame() is a function I made that just assigns the parameters into the wanted frame and returns the result. (Don't worry about this, it works as intended)

local newTex = MakeFrame("ScrollFrame", "FW_Icon", {100, 100}, {100, -150}, mainFrame, nil, nil)
local tex = newTex:CreateTexture(newTex:GetName() .. "_Image", mainFrame)
tex:SetAllPoints()
tex:SetTexture("Interface\\AddOns\\FrameWork\\Textures\\test.tga")
print(prefix .. "Loaded " .. '"' .. tex:GetTexture() .. '"')

I did a google search on "wow lua settexture green" and tried everything i found. No use though.

[semlar]

If the path to the image is correct, it will still fail if the image's dimensions are not a power of 2, or if it's not an actual blp or tga file.

I can't tell if your addon is called FrameWork (like it is in the path) or MyAddon like you described in your post, make sure your path is right.

edit: What I mean by powers of 2 is the width and height have to be something like 32, 64, 128, 256, 512.

[Phanx]

If anything you described is working in-game, then the file paths and names you posted are fake -- your listed TOC file name "code.toc" does not match your listed folder name "MyAddon", so WoW cannot possibly be loading that file as an addon. Posting fake file paths, fake file names, or fake code is worse than posting nothing at all, because people who are trying to help you assume you're posting real stuff, and everyone's time gets wasted. >_<

Originally Posted by Ledii local tex = newTex:CreateTexture(newTex:GetName() .. "_Image", mainFrame)

Not related to your question, but you don't need to waste CPU time calling :GetName() -- you can just do "$parent_Image" and the "$parent" token will automatically be replaced by the name of the frame you are creating the texture on. This also works for font strings, animation groups, and animations.

Also, the second parameter to CreateTexture should be the layer on which the texture is drawn. I don't know what value your mainFrame variable contains, but if it's not a string naming a valid draw layer, it will (at best) result in your texture being on the wrong layer or maybe even (at worst) break your texture.

Finally, I know you said your MakeFrame function is working, and using a "factory" function like that is fine, but please for the love of kittens (or whatever cute things you have a soft spot for), don't waste memory creating and discarding tables like that. Just pass the values in sequence, or pass nil to skip a value.

[Resike]

function TextureBasics_CreateTexture(texture)
	-- Create a frame
	local f = CreateFrame("frame", "TextureBasics")
	-- Frame Strata ("Background", "Low", "Medium", "High", "Dialog", "Fullscreen", "Fullscreen_Dialog", "Tooltip")
	f:SetFrameStrata("Medium")
	-- Frame Strata level (0 - 20)
	f:SetFrameLevel(0)
	-- Frame Width
	f:SetWidth(128)
	-- Frame Height
	f:SetHeight(128)
	-- Frame Alpha
	f:SetAlpha(0.90)
	-- Frame Position
	f:SetPoint("CENTER", 0, 0);
	-- Create a texture on the frame
	local t = f:CreateTexture("Texture", "Background")
	-- Set the texture
	t:SetTexture(texture)
	-- Texture Width
	t:SetWidth(128)
	-- Texture Height
	t:SetHeight(128)
	-- Blend Mode ("Add", "Alphakey", "Blend", "Disable", "Mod")
	t:SetBlendMode("Disable")
	-- Texture Strata ("Background", "Border", "Artwork", "Overlay") and Sublevel (-8 - 7)
	t:SetDrawLayer("Background", 0)
	-- Texture Rotation (0 - 360) (Note, not all textures like to be rotated)
	t:SetRotation(math.rad(15))
	-- Coloring (r, b, g, a)
	t:SetVertexColor(1, 0, 0, 0.75)
	-- If you rotate it you need multiply the frame's width and height by sqrt(2)
	f:SetWidth(sqrt(2) * t:GetWidth())
	f:SetHeight(sqrt(2) * t:GetHeight())
	-- Mirror it
	local ULx, ULy, LLx, LLy, URx, URy, LRx, LRy = t:GetTexCoord();
	--t:SetTexCoord(URx, URy, LRx, LRy, ULx, ULy, LLx, LLy); -- Inverse X
	--t:SetTexCoord(LLx, LLy, ULx, ULy, LRx, LRy, URx, URy); -- Inverse Y
	--t:SetTexCoord(LRx, LRy, URx, URy, LLx, LLy, ULx, ULy); -- Inverse XY
	t:SetTexCoord(ULx, ULy, LLx, LLy, URx, URy, LRx, LRy); -- Normal
	-- Put the texture on the frame
	t:SetAllPoints(f)
	-- Show it
	f:Show()
end

TextureBasics_CreateTexture("Interface\\PVPFrame\\Icons\\PVP-Banner-Emblem-10")

You can draw more texture ingame with command:

/run TextureBasics_CreateTexture(texture)

If you rotate icons from the game you gonna get a glitch:

/run TextureBasics_CreateTexture("Interface\\Icons\\Ability_Ambush")

https://github.com/Resike/TextureBasics

[SDPhantom]

Another possibility that wasn't explained here, did you close the game client completely and restart it? If you create or move files around in the WoW folders while the game is running, it will not be able to pick up the new files until it's been restarted.

The texture turning green is an indicator that there's something wrong with the image file, either it's encoded wrong, dimensions are invalid, or the file could not be found or didn't exist at the time the game client started.

WoW is very picky about its textures. The image needs to be encoded as a 32-bit TGA (TGA with alpha layer). Most image editors only encode 24-bit TGAs. The dimensions are required to be a power of 2 between 8 and 512 inclusive. These do not need to be the same, for example, you can have a 256x128 sized texture image.





On another note:

Originally Posted by Resike local ULx, ULy, LLx, LLy, URx, URy, LRx, LRy = t:GetTexCoord(); t:SetTexCoord(ULx, ULy, LLx, LLy, URx, URy, LRx, LRy);-- Normal

I seriously hope you're not really doing this.

[Resike]

Originally Posted by SDPhantom Another possibility that wasn't explained here, did you close the game client completely and restart it? If you create or move files around in the WoW folders while the game is running, it will not be able to pick up the new files until it's been restarted. The texture turning green is an indicator that there's something wrong with the image file, either it's encoded wrong, dimensions are invalid, or the file could not be found or didn't exist at the time the game client started. WoW is very picky about its textures. The image needs to be encoded as a 32-bit TGA (TGA with alpha layer). Most image editors only encode 24-bit TGAs. The dimensions are required to be a power of 2 between 8 and 512 inclusive. These do not need to be the same, for example, you can have a 256x128 sized texture image. On another note: I seriously hope you're not really doing this.

Well i just ctrl+c-d it from my addon, it's just a showcase tho. :P

[Ledii]

Originally Posted by semlar If the path to the image is correct, it will still fail if the image's dimensions are not a power of 2, or if it's not an actual blp or tga file. I can't tell if your addon is called FrameWork (like it is in the path) or MyAddon like you described in your post, make sure your path is right. edit: What I mean by powers of 2 is the width and height have to be something like 32, 64, 128, 256, 512.

The image is 100x100, probably why then... That sounds like a very stupid rule in order to make images work. There are probably reasons it is like that, but it's ok. I can probably try resize it. Stupid stupid though -_-

[Ledii]

Originally Posted by Resike Well i just ctrl+c-d it from my addon, it's just a showcase tho. :P

Yes, I did read up on that, and found out about the restarting.
The requirement of having to have a dimension of power 2 is the dumbest property I have ever heard though. How am we supposed to find that out easily -_-

[Ledii]

Yeah, it was the image resolution that did it... I changed it from 100x100 to 64x64. Having to use a resolution tht is a power of 2 is anoying though.

[Resike]

Originally Posted by Ledii Yeah, it was the image resolution that did it... I changed it from 100x100 to 64x64. Having to use a resolution tht is a power of 2 is anoying though.

I'm pretty sure it's needed for some rendering issue or something like that, it doesn't mean you can't scale or change height and width of the texture or the texture's frame after you loaded it.

[Phanx]

If your actual image is 100x100, increase the canvas size to 256x256 with your image in the top left corner, leaving 156px of blank space below and to the right of it. Then in-game do:

texture:SetTexture("path\\to\\your\\texture")
texture:SetTexCoord(0, 100/256, 0, 100/256)

... to show only the 100x100 region you actually care about. You don't have to resize your image and lose quality.

[Seerah]

Ooorrr.... instead of 256x256, he could use 128x128.

[SDPhantom]

Originally Posted by Resike Originally Posted by Ledii Yeah, it was the image resolution that did it... I changed it from 100x100 to 64x64. Having to use a resolution tht is a power of 2 is anoying though. I'm pretty sure it's needed for some rendering issue or something like that, it doesn't mean you can't scale or change height and width of the texture or the texture's frame after you loaded it.

It was actually a limit on the use of hardware mode on older video cards used back in the day when vanilla WoW was being developed. Keep in mind this was 10-15 years ago.

[Resike]

Originally Posted by SDPhantom It was actually a limit on the use of hardware mode on older video cards used back in the day when vanilla WoW was being developed. Keep in mind this was 10-15 years ago.

Still, not updating stuffs like that cause tons of incompatibily and prefomance issues in the game, also the current wow api and proably the c code too is like the windows registy, full with useless outdated crap, but nobody dares to delete anything, bacuse they have no clue what could it cause.

[SDPhantom]

As far as PC component manufacturers go, all hardware should be backwards compatible. They even went great lengths to make USB keyboards and mice detectable in computer BIOS and also provide backend support for outdated OSs that didn't have USB capabilities. This is just an example, not what is the case here.

As far as outdated code causing increasing performance and incompatibility issues, that's completely bogus. All outdated code would do is continue the same exact performance grade throughout its use and not take advantage of new features that would come along. Just because hardware mode no longer requires a power of 2 dimension, it doesn't mean it's now slower than it used to be or that the card would refuse a texture that is, for example, 256x256 in size.

When you take incompatibilities into account, upgrading to a brand new feature means you're relying on something that only a handful of new equipment would handle and you practically force the entire user base to either upgrade their systems or stop playing. In an economy like this, not many people can afford to do that and would have to cancel their subscriptions. I know of a few people myself that dropped their subscriptions just because they couldn't afford the monthly fee anymore.