I studied the "lighting system" of some Seta games which have a rewritten fast3d ucode (completely rewritten but full compatible gbi wise with fast3d)
I was thinking that I got wrong by saying that the lighting was working correct in HLE but actually....
i have some doubts
See the screen in Pachinko 365 Nichi:
LLE

HLE:

I see a color difference.
Do you?
Stunning is the hair, color is really different. HLE is too bright, LLE is darker overhaul.
Same in Eiko St Andrews


The difference so small is impossible to notice unless you're comparing HLE/LLE side by side. Is it worth looking into it?
I spent already a lot of time on it :)
thinking about it the "lighting system " only appears when the players arrives in Eikou. Would it be a way to manage the framebuffer/colors buffer? Wild idea for the time being.
@olivieryuyu it does look darker in LLE. Out of curiosity, how did you notice the slight difference? I find it impressive that you discovered this, because I wouldn't have noticed unless i looked at both at the same time.
some Seta games have a rewritten fast3d ucode (completely rewritten but full compatible gbi wise with fast3d)
I noticed that a long time ago, notably because the Y was reversed.
I am trying to get in the ucode i am trying to develop an optimized way to do lighting
I was curious the Seta microcode which does something completely different and for which neither Sergey or me have a clue about.
I was curious the Seta microcode which does something completely different and for which neither Sergey or me have a clue about.
Could you explain it in details here? The Seta microcode does really weird computations instead of traditional lighting. I don't understand what is it, but someone else may find it out.
We discussed somewhat about it in the Discord64 server, you may want to check #n64_dev there
Here how lights seems to work
top of modelview matrix:
1 2 3
4 5 6
7 8 9
n = sqrt((1 + 4 + 7)虏 + (2 + 5 + 8)虏 + (3 + 6 + 9)虏) * 0x1BB (???)
We change the elements of the top of the modelview matrix
1/n 2/n 3/n
4/n 5/n 6/n
7/n 8/n 9/n
multiply this new matrix with the normals
multiply 3. by the the light directions
add each elements of 4. together
multiply 5. by the colors of the light
I can notice that the ambient light shares the same value for R, G and B
I can notice that the unique light shares the same value for R, G and B
Completely senseless to me.
Its very much a speed optimization. Smart. I guess its done to save on multiply ops.
I would say step one is calculating some norm of the matrix and, thus, step two is normalizing it.
Compatible norms satisfy for some vector norm. I'm guessing that the idea is to have the results of modelview matrix times vertex normal almost normalized and thus skip normalizing normal vectors (at world coordinates). You get this by using a normalized modelview matrix and normalized vertex normals (at model coordinates).
The result would be faster lighting (normalizing one matrix is faster than normalizing many vectors) but less realistic lighting, as normal vectors won't be exactly normalized.
Ideally one should use a compatible norm, but it seems to me the algorithm is prioritizing ease of calculations. I would say those computations result in the L12 norm. Notice I said L12 and not the more standard L21. There's also the nuance of the hardcoded multiplication.
The rest of the steps seem standard to lighting computation.
Hope this helps.
i believe you could be right :)
Most helpful comment
I would say step one is calculating some norm of the matrix and, thus, step two is normalizing it.
Compatible norms satisfy
for some vector norm. I'm guessing that the idea is to have the results of modelview matrix times vertex normal almost normalized and thus skip normalizing normal vectors (at world coordinates). You get this by using a normalized modelview matrix and normalized vertex normals (at model coordinates).
The result would be faster lighting (normalizing one matrix is faster than normalizing many vectors) but less realistic lighting, as normal vectors won't be exactly normalized.
Ideally one should use a compatible norm, but it seems to me the algorithm is prioritizing ease of calculations. I would say those computations result in the L12 norm. Notice I said L12 and not the more standard L21. There's also the nuance of the hardcoded multiplication.
The rest of the steps seem standard to lighting computation.
Hope this helps.