source

[Koroljov]

Can we not read the source of jPCT? I am trying to write a 3d engine in jave for years, I have been able to create something, but it still doesn't work good.

[koroljov]

No it really doesn't matter that the source isn't up to date or that it's a real mess. I can read any code in 21 programmer languages, I just want to know how it works. (I'll decompile it anyway, but that is very difficult).

[koroljov]

I just read decompilation is not allowed. Sorry i won't decompile it.

[koroljov]

Can't you tell some names of the used algorithms so I can seek them on the internet? How can it work so quick in full screen? How many divisions are there in the inner loop of the application? How is it clipped? How can you make a color lighter or darker? Do you really have to get the r g b -values, edit them and put them in 1 int again with lots of << and >> operators?

[EgonOlsen]

Can't you tell some names of the used algorithms so I can seek them on the internet? How can it work so quick in full screen? How many divisions are there in the inner loop of the application? How is it clipped? How can you make a color lighter or darker? Do you really have to get the r g b -values, edit them and put them in 1 int again with lots of << and >> operators?

Sorry for the late reply, but i was on a trip to sweden for two weeks. The inner loop for a point-sampled pixel looks like this

Code Select Expand

for (int tx=x+yPos; tx<=end; tx++) {

  if (zbuffer[tx]>iz) {
     col=texels[((((t1&texClampU)>>18)+(((t2&texClampV)>>18)<<shift)))];

     r=(((col>>16))*(srI>>10))>>16;
     g=(((col>>8)&255)*(sgI>>10))>>16;
     b=((col&255)*(sbI>>10))>>16;

     if ((r&0xffffff00)!=0) { r=(255>>(byte) (r>>28&8)); }
     if ((g&0xffffff00)!=0) { g=(255>>(byte) (g>>28&8)); }
     if ((b&0xffffff00)!=0) { b=(255>>(byte) (b>>28&8)); }
 
     pixels[tx]=b|(g<<8)|(r<<16);
     zbuffer[tx]=iz;
  }

  t1+=dus;
  t2+=dvs;

  srI+=delr;
  sgI+=delg;
  sbI+=delb;

  iz+=delz;
}

In the inner loop, the subspans are linear interpolated, so no division is needed here. In the loop that does the subdivision, no division is needed too because it has all been replaced by multiplying with 1/(whatever).
I don't know where to look on the net for a better description, because it's simply the way i'm doing these things for ages now.
Please note that this is the inner loop of the SoftGL-Renderer which requires some multiplications and supports texture-wrapping from version 0.92 (to be released...) on, so it's a bit slower than the Legacy-Renderer, but not much.

[Koroljov]

Vielen Dank.

It is very interesting. It is much faster than using
u =  (i*(Vz*Oy-Vy*Oz) + j*(Vx*Oz-Vz*Ox)+(Vy*Ox-Vx*Oy))/(i*(Vy*Uz-Vz*Uy)+j*(Vz*Ux-Vx*Uz) + (Vx*Uy-Vy*Ux))
and
v = ( i*(Uy*Oz-Uz*Oy) + j*(Uz*Ox-Ux*Oz) + (Ux*Oy-Uy*Ox))/( i*(Vy*Uz-Vz*Uy) + j*(Vz*Ux-Vx*Uz) + (Vx*Uy-Vy*Ux))

[EgonOlsen]

It is very interesting. It is much faster than using
u =  (i*(Vz*Oy-Vy*Oz) + j*(Vx*Oz-Vz*Ox)+(Vy*Ox-Vx*Oy))/(i*(Vy*Uz-Vz*Uy)+j*(Vz*Ux-Vx*Uz) + (Vx*Uy-Vy*Ux))
and
v = ( i*(Uy*Oz-Uz*Oy) + j*(Uz*Ox-Ux*Oz) + (Ux*Oy-Uy*Ox))/( i*(Vy*Uz-Vz*Uy) + j*(Vz*Ux-Vx*Uz) + (Vx*Uy-Vy*Ux))

Obviously... :wink: