Custom NPC Graphics darker than they're supposed to be

[Animebryan]

I'm creating custom npcs as blocks so that gravity applies to them, but the graphics for the npc, which are made from SMW Cave Blocks, come out darker than they're supposed to be in the editor. Does anyone know what causes this?

[deice]

could you post what your lua/txt/ini files look like? there might be an issue with the settings.

[Animebryan]

The ini file:

Spoiler: show

[npc]
name = "4x4 SMW Cave Block"
group = "Super Mario World"
category = "Block"
image = "npc-751.png"
description = "A 4x4 Cave Block that falls from above."
gfx-offset-x = 0
gfx-offset-y = 0
gfx-width = 128
gfx-height = 128
physical-width = 128
physical-height = 128
grid = 32
grid-offset-x = 0
grid-offset-y = 0
frame-style = 0
frames = 1
frame-delay = 128
foreground = 0
animation-direction = 0
animation-bidirectional = 0
custom-animation = 0
container = 0
contents-id = 0
have-special = 0

The Lua file:

Spoiler: show

Code: Select all

--NPCManager is required for setting basic NPC properties
local npcManager = require("npcManager")

--Create the library table
local sampleNPC = {}
--NPC_ID is dynamic based on the name of the library file
local npcID = NPC_ID

--Defines NPC config for our NPC. You can remove superfluous definitions.
local sampleNPCSettings = {
	id = npcID,
	--Sprite size
	gfxheight = 128,
	gfxwidth = 128,
	--Hitbox size. Bottom-center-bound to sprite size.
	width = 128,
	height = 128,
	--Sprite offset from hitbox for adjusting hitbox anchor on sprite.
	gfxoffsetx = 0,
	gfxoffsety = 0,
	--Frameloop-related
	frames = 1,
	framestyle = 0,
	framespeed = 8, --# frames between frame change
	--Movement speed. Only affects speedX by default.
	speed = 0,
	--Collision-related
	npcblock = true,
	npcblocktop = true, --Misnomer, affects whether thrown NPCs bounce off the NPC.
	playerblock = true,
	playerblocktop = true, --Also handles other NPCs walking atop this NPC.

	nohurt = true,
	nogravity = false,
	noblockcollision = false,
	nofireball = true,
	noiceball = true,
	noyoshi = true,
	nowaterphysics = false,
	--Various interactions
	jumphurt = false, --If true, spiny-like
	spinjumpsafe = false, --If true, prevents player hurt when spinjumping
	harmlessgrab = false, --Held NPC hurts other NPCs if false
	harmlessthrown = false, --Thrown NPC hurts other NPCs if false

	grabside=false,
	grabtop=false,

	--Identity-related flags. Apply various vanilla AI based on the flag:
	--iswalker = false,
	--isbot = false,
	--isvegetable = false,
	--isshoe = false,
	--isyoshi = false,
	--isinteractable = false,
	--iscoin = false,
	--isvine = false,
	--iscollectablegoal = false,
	--isflying = false,
	--iswaternpc = false,
	--isshell = false,

	--Emits light if the Darkness feature is active:
	--lightradius = 100,
	--lightbrightness = 1,
	--lightoffsetx = 0,
	--lightoffsety = 0,
	--lightcolor = Color.white,

	--Define custom properties below
}

--Applies NPC settings
npcManager.setNpcSettings(sampleNPCSettings)

--Register the vulnerable harm types for this NPC. The first table defines the harm types the NPC should be affected by, while the second maps an effect to each, if desired.
npcManager.registerHarmTypes(npcID,
	{
		--HARM_TYPE_JUMP,
		--HARM_TYPE_FROMBELOW,
		--HARM_TYPE_NPC,
		--HARM_TYPE_PROJECTILE_USED,
		--HARM_TYPE_LAVA,
		--HARM_TYPE_HELD,
		--HARM_TYPE_TAIL,
		--HARM_TYPE_SPINJUMP,
		--HARM_TYPE_OFFSCREEN,
		--HARM_TYPE_SWORD
	}, 
	{
		--[HARM_TYPE_JUMP]=10,
		--[HARM_TYPE_FROMBELOW]=10,
		--[HARM_TYPE_NPC]=10,
		--[HARM_TYPE_PROJECTILE_USED]=10,
		--[HARM_TYPE_LAVA]={id=13, xoffset=0.5, xoffsetBack = 0, yoffset=1, yoffsetBack = 1.5},
		--[HARM_TYPE_HELD]=10,
		--[HARM_TYPE_TAIL]=10,
		--[HARM_TYPE_SPINJUMP]=10,
		--[HARM_TYPE_OFFSCREEN]=10,
		--[HARM_TYPE_SWORD]=10,
	}
);

--Custom local definitions below


--Register events
function sampleNPC.onInitAPI()
	npcManager.registerEvent(npcID, sampleNPC, "onTickNPC")
	--npcManager.registerEvent(npcID, sampleNPC, "onTickEndNPC")
	--npcManager.registerEvent(npcID, sampleNPC, "onDrawNPC")
	--registerEvent(sampleNPC, "onNPCKill")
end

function sampleNPC.onTickNPC(v)
	--Don't act during time freeze
	if Defines.levelFreeze then return end
	
	local data = v.data
	
	--If despawned
	if v.despawnTimer <= 0 then
		--Reset our properties, if necessary
		data.initialized = false
		return
	end

	--Initialize
	if not data.initialized then
		--Initialize necessary data.
		data.initialized = true
	end

	--Depending on the NPC, these checks must be handled differently
	if v:mem(0x12C, FIELD_WORD) > 0    --Grabbed
	or v:mem(0x136, FIELD_BOOL)        --Thrown
	or v:mem(0x138, FIELD_WORD) > 0    --Contained within
	then
		--Handling
	end
	
	--Execute main AI. This template just jumps when it touches the ground.
	
end

--Gotta return the library table!
return sampleNPC

The txt file:

Spoiler: show

gfxoffsetx=0
gfxoffsety=0

width=128
height=128

gfxwidth=128
gfxheight=128

speed=0

score=0

frames=1
framestyle=0
framespeed=8

playerblock=1
playerblocktop=1
npcblock=1
npcblocktop=1

grabside=0
grabtop=0

jumphurt=0
nohurt=1

noblockcollision=0
cliffturn=0
noyoshi=1

foreground=0
nofireball=1
noiceball=1
nogravity=0

harmlessgrab=0
harmlessthrown=0
spinjumpsafe=0

isshell=0
isinteractable=0
iscoin=0
isvine=0
iscollectablegoal=0
isflying=0
iswaternpc=0
isshoe=0
isyoshi=0
isbot=0
isvegetable=0
iswalker=0

lightoffsetx = 0
lightoffsety = 0
lightradius = 128
lightbrightness = 1
lightcolor = white
lightflicker = false

[deice]

now that's puzzling. i've copied all the files directly and made an npc graphic using smbx's basegame tile graphics and it displays just fine for me both in-game and in the editor. there aren't any section settings or the like that could cause this to my knowledge, so maybe it's an issue regarding the image itself?

here's the image i have, try using it and see if it changes anything on your end:

[Animebryan]

Well, the color issue was fixed, but I noticed that the size is unorthodox. The original I made was literally a 4x4 block (128px x 128px). This one here is 180x180, making it about 5.5 blocks long & tall. However, the right & bottom sides don't reflect the actual graphic, but that might be because all my files have the graphic set at 128x128. I also used the actual SMW Cave Blocks to make up the graphic so I don't know why the color darkened for me but not for you.

[deice]

This one here is 180x180, making it about 5.5 blocks long & tall.

problem with postimg, for some reason selecting "don't resize my image" doesn't exactly work consistently with the preview it generates, oh well.
if you're able to resize it on your end without aliasing getting in the way that should hopefully be the end of it, but i can't say what the original issue might've been.

[Animebryan]

It did it again! This time with a custom BGO:



I wanna know why! I wanna I wanna I wanna know WHY?!

Edit: I found a way to fix it. Had to reduce the "precision" to 8 bit & convert png to gif. Then reconvert the gif back into a png. Editor no longer makes the image darker. But I still want to know WHY it does that? Does it have something to do with bits rendered or something?

GIMP has the following options for Precision:
8 bit integer
16 bit integer
32 bit integer
16 bit floating point
32 bit floating point

I have no idea what these mean or refer to (perhaps like 8 bit NES & 16 bit SNES graphics), although, the graphic still looked 16 bit (SNES style) even after setting it to 8 bit integer.

[Hoeloe]

Those actually don't mean anything like the "8-bit/16 bit game graphics" there. Those refer to the bit depth of each pixel. Even with 16-bit SNES graphics, that "16-bit" actually doesn't have much to do with the graphics processing itself, it's more to do with the console's internal data buses. With NES graphics, you only actually have 2 bits per colour, which index a palette. SNES has I believe 4 bits per colour, also indexing a palette. With 8 bits per colour, you can represent 256 different shades of colour. 16 bit allows you to represent 65536 shades, and 32 bit allows you to represent 4294967296 different shades. As for the difference between "integer" and "floating point", that just refers to the type of data being stored - integer being a whole number, and floating point allowing fractional values. Though the number of distinct shades is still defined by the bit depth, the distribution of these may change, since floating point is more accurate at smaller values. Frankly though I have no idea why this happens, I've never seen this occur anywhere else, but it seems to be tied to your image editing program rather than the game so much. It's possible that the editor expects either integer or floating point pngs, and you're providing it with the opposite, so it's interpreting the values incorrectly. Try saving the file as just 32 bit integer directly, and see if that helps.