Author Topic: Rendering Fields - Incorrect transparency logic  (Read 2672 times)

dangarfield

  • *
  • Posts: 26
    • View Profile
Rendering Fields - Incorrect transparency logic
« 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



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


myst6re

  • *
  • Posts: 639
  • Light King of the Savegame - Field Master - FF8.fr
    • View Profile
    • FF8.fr
Re: Rendering Fields - Incorrect transparency logic
« Reply #1 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.

dangarfield

  • *
  • Posts: 26
    • View Profile
Re: Rendering Fields - Incorrect transparency logic
« Reply #2 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]
}

leanagagen

  • *
  • Posts: 1
    • View Profile
Re: Rendering Fields - Incorrect transparency logic
« Reply #3 on: 2020-11-18 01:52:05 »
Pleased to hear it!