Qhimm.com Forums

Miscellaneous Forums => General Discussion => Topic started by: dangarfield on 2020-08-18 18:55:58

Title: Rendering Fields - Incorrect transparency logic
Post by: dangarfield on 2020-08-18 18:55:58
I'm having two problems working with fields, this is the first of them, please can you help?

It's to do with the treatment of 0x000000 colours from the palettes, which depending on the bit mask should be transparent, but I can see in Makou Reactor, you get the correct colour. Here's an example:

2 images, One is Makou Reactor output, the second is my attempt. Map - mds5_1
(https://i.ibb.co/L000jHs/makou-1.png)
(https://i.ibb.co/fCdgr8Z/dg-1.png)

Note: This is purely one tile on one layer. There are no other tiles that render in the destination position so all of the data has to be in the tile / palette. The example below are the first two pixels in the top left corner of the top left tile.

Tile details:
 Tile 383
 x destinationX -256 -> normalisedOverlayX 0
 y destinationY -256 -> normalisedOverlayY 0
 depth 1 z 4095 (eg tile.id)
 palette 3 (paletteId)
 texture sourceX 0 sourceY 128 -> 0,0 bytePosition 65536
 layer 0 z 4095 id 4095
 param 0
 state 0
 blending 0
 typeTrans 0

Pixel at tile position 0,1 is perfect:
 x 0 1 -> 1
 y 128 0 -> 0
  textureByteOffset 32769
  textureByteID 1 (ref to page/palette)
  paletteByte 4261 -> 0x0010A5
  color usePalette=true
  hex { r: 41, g: 41, b: 33, a: 255, hex: '292921' }

Pixel at tile position 0,0 is wrong:
  x 0 0 -> 0
  y 128 0 -> 0
  textureByteOffset 32768
  textureByteID 224 (ref to page/palette)
  paletteByte 0 -> 0x000000
  color usePalette=true
  hex { r: 0, g: 0, b: 0, a: 0, hex: '000000' }

Current logic for textureByteValue to hex is:

let COEFF_COLOR = 255 / 31 // eg translate 5 bit color to 8 bit
const getColorForPalette = (bytes) => { // abbbbbgggggrrrrr
    const color = {
        r: Math.round((bytes & 31) * COEFF_COLOR),
        g: Math.round((bytes >> 5 & 31) * COEFF_COLOR),
        b: Math.round((bytes >> 10 & 31) * COEFF_COLOR)
    }
    color.a = color.r === 0 && color.g === 0 && color.b === 0 ? 0 : 255
    color.hex = `${stringUtil.toHex2(color.r)}${stringUtil.toHex2(color.g)}${stringUtil.toHex2(color.b)}`
    return color
}

I was currently thinking about whether this is black or fully transparent, eg using the alpha bit above, but the desired pixel is a dark brown (around 0x302921) and there are a number of other pixels that follow this pattern also.

What am I missing? Can you point me in the right direction please. Even if it's just pointing towards a few lines of Makou Reactor. Whilst I've been through it a number of times, I can't easily see the answer. Thanks

Title: Re: Rendering Fields - Incorrect transparency logic
Post by: myst6re on 2020-08-19 07:52:47
Please look at this documentation: https://translate.google.com/translate?sl=fr&tl=en&u=https%3A%2F%2Fwikisquare.ffdream.com%2Fff7%2Ftechnique%2Ffield%2Fbg

After the keyword "PALETTE", you have several bytes that change the behavior of the first color of the related palette. That's strange I know, I know.
Title: Re: Rendering Fields - Incorrect transparency logic
Post by: dangarfield on 2020-08-19 09:34:12
Perfect, solved it within 30 seconds after looking at this document.

In this instance, the answer was getting the FIRST pixel from the tiles' specified palette if the texture-palette-pixel was 0x000000.

eg I'm intentionally using and improving Kujata json objects

paletteItem = flevel.palette.pages[tile.paletteId][textureByte]
if (paletteItem.r === 0 && paletteItem.g === 0 && paletteItem.b === 0 && paletteItem.a === 0) {
  paletteItem = flevel.palette.pages[tile.paletteId][0]
}
Title: Re: Rendering Fields - Incorrect transparency logic
Post by: leanagagen on 2020-11-18 01:52:05
Pleased to hear it!