abelliqueux / 3dcam-headers Goto Github PK

t is not incremented, thus always 0.
This means that only the first mesh type is checked, and the following meshes are assumed to have the same type.
It works because the test mesh only has tris or quads, but won't work with mixed meshes.

This is an artifact from when working on the sprite rotation system.
Get rid of it !

After compiling out of the box, the example level seems not to load correctly.
Can't really figure out what's wrong here, posting two screenshots.

The gouraud cube seems to render fine but there's apparently some problem with texture loading, can't really figure out what's happening here.

EDIT: the real problem was just the crashing, the textures should be correct. Anyway switching to level 1 caused all kinds of graphical glitches before crashing.

Pressing jump in level 0 does not have any effect, in level 1 it cause an unaligned address error and crashes the application.
First appearance of the bug is in d850180

The XA playback cursor is dependant on framerate, hence increments too fast or too slow depending on scene.

When an object rotates, light should not rotate with it :)

Make the switch to gte inline functions for rendering.

See here for ref ; http://psx.arthus.net/sdk/Psy-Q/DOCS/Devrefs/Inlinref.pdf

When trying to load level0 on real HW, black screen, but level1 works.

Could be :

• Dependency on a pointer that's not honored by the content of the level file (physics ?).
• Something to do with the temporary use of a hardcoded mesh in the LEVEL struc : Removed with 8469e7a

  3dcam-headers/custom_types.h

  Line 133 in 92d05f2

  MESH * meshPlan; // This one is temporary

In order to improve rendering time, selectively apply texturing/lighting to primitives according to their p value.

Right now, we're using switch case to cycle through hardcoded level names.
Figure a way out for something more pretty.

If Far color / Horizon color is < 100 (0.10 in blender), the corresponding channel color will display as black.

Example level0.c file :

CVECTOR level0_BGc = { 100, 218, 216, 0 };

results in :

CVECTOR level0_BGc = { 0, 218, 216, 0 };

Might be an error in the linear to RGB conversion function.

Also could be due to psyq dpq calculation. See LibRef47.pdf, p.450 and LibOver47.pdf, p.133, "Light Source Calculation" :

LLM == Local Light Matrix
LLV  == Local light vector
LC    == Local Color
BK   == Back Color
FC   == Far Color
p     == interpolation coefficient

LLV = LLM * v0
LC = BK + LCM * LLV
v2 = (1 - p) * v1 * LC + p * FC

v0 -> vx, vy, vz
vl -> r, g, b
p
NormalColorDpq(): v2 -> r, g, b

This can be pre-calculated at runtime : https://github.com/ABelliqueux/3dcam-headers/blob/master/src/graphics.c#L43

With pre-rendered background, we could just set the tpage to bpp, x, y of the image in vram : 8bpp, 320, 0 by default for now.

if (fixed_BGs){
     ( (POLY_GT3 *) poly )->tpage = getTPage( 0, 0, 320, 0 );
}

But how do we now fixed BGs are used ?
We could use curLvl.camPtr->BGtim to determine the existence of the data, and even use prect to know x,y coords in vram,

if (curLvl.camPtr->BGtim){
     ( (POLY_GT3 *) poly )->tpage = getTPage( curLvl.camPtr->BGtim&0x3, 0, 
                                              curLvl.camPtr->BGtim->prect->x,
                                              curLvl.camPtr->BGtim->prect->y );
}

but do we want to add a function argument just for that ?

Might be due to a rounding error or something...
You can see through meshes at the seams when using interpolated animations :

Get this working.

Rendering performances can be improved if GTE commands 'nop'ing time is used for RAM > CPU d-cache verts data transfer.
See : https://github.com/ABelliqueux/nolibgs_hello_worlds/blob/main/hello_gte_opti.c

Ref : psyq/psx/sample/scea/GTE

This makes me look terrible.

I'll make it beautiful soon.

Make a PSn00bSDK version : https://github.com/Lameguy64/PSn00bSDK/