forums.ps2dev.org

http://home.tele2.fr/~fr-51785/ps2_initial_fantasy.zip (3D)

I will try to make a little RPG, but will take time. Until then, enjoy the 3D.
(will be probably my last contribution to ps2 scene : pc0/ps3/360 are waiting...)

I've tried to use saotome's vulib the best way I could to create a small 3D rendering loop able to render an object directly coming from 3DSMax (its texture has to be loaded separately but mapping points are correctly used from 3DS file). I'm quite happy with current result (198.000 vertex/frame).
Obtained with combination of quad buffer technic, total vu1 data memory usage trick (allows 1 dma ref=1 batch) & mad vcl optimization of main loop (22 cycles, 1 light source, clipping working, texture mapping).

But can probably be improved still a bit...
Just need some intelligent normals variation to activate gouraud now.
Dr Fortuna's NoDraw flag idea is ready to use, to eventually have intelligent mixes of independant triangles and stripped triangles at once.

Preliminary 3D calculations done through vu0 thanks to ooPo's math3D library, already included in ps2sdk. Costs really nothing in time.

Interesting point for beginners is that you can, once vu1 has finished its part of rendering, continue drawing with gsKit. Stats are displayed that way.

A performance bar shows the time spent by vu1 rendering in a frametime.
(Goal is to not reach opposite border of screen and stay at 60 fps).

Have fun!

Other useful older stuff:
http://home.tele2.fr/~fr-51785/ps2_qbert.zip (2D sprites)
http://home.tele2.fr/~fr-51785/ps2_pong.zip (wiimote)
http://home.tele2.fr/~fr-51785/ps2_afl_pktdrv.zip (packet driver)

I've updated archive.
- Added Fuselage .3DS file for those who don't have 3DSMax (big file...)
- Forgot to remove two useless instructions
Now vu1 loop really executes in 22 cycles : 216.000 vertices/frame

New update.
Now UV format conversion is made in mesh.c instead of vu1 loop
Current performance : 250000 vertices/frame (19 cycles spent in loop)

Hey there,

Just letting you know you should add 1 << DMA_CHANNEL_GIF as an additional argument of the dmaKit init routine.

I've fixed up some dma_wait_fast stuff and this new argument is required so it knows which channels to involve in the fast wait.

It should help speed things up a little bit if gsKit is spending a lot of time waiting for transfers to complete.

Also, I've been planning on doing some full VU1/3D intergration for gsKit for ages... but sadly have not got around to it yet.

Enjoy!

Thanks for the info!

About having gsKit using vu1, I don't know...
I mean I was happy to have vu1 all for myself so I could optimize vu1 code madly...

Well, you can always stick with the PATH3 gsKit... (gsKit 0.3 AKA gsKit 1.0)

The new gsKit is the same API and all, but uses VIF and VU1, but also will allow you to upload/run your own VU1 microcode and pack your own DMA lists offline, etc.

I'm hoping that, while it'll be a bit different than what you are used to now, it'll make VU1 much more accessible for people and should still intergrate well with folks who want to really push the hardware.

Also, I'm having gsKit manage stuff like mskpath3 texture sync for you, which should make things a lot easier for people who want to write cool 3D demos without having to kill themselves trying to get all of the nasty bits working.