thats the same experience i've made - lxdream is nearly unusable for commercial games, but it somehow works best for homebrewed stuff.
I'm aware that the dreamcast emulators don't emulate the hardware properly and use many workarounds for performance.
there is an elf file attached (game data is compiled in, romdisk), runs in lxdream. if converted to cdi it also runs in redream and reicast. but does not run on real hardware. i mean it boots, you see it runs, but graphics are garbage...
i can post some code later, but i really need to clean up the renderer file as there are a lot unused functions, but only a handful are used. same goes for the physics code
how the game loop works right now is as following:
load data
run loop:
- update physics
- set properties (matrices etc, op poly drawing) for 3d perspective
- draw all op polys
- set list to tr polys
- draw particles (smoke effects)
- set up for 2d (keep tr poly list)
- draw hud
a little specific for actual drawing stuff:
all models are split to "material groups". each group has an material (opengl style) attached and a vertex and index array.
vertices in the array are as following
float x,y,z
norm x,y,z
texcoord u,v
-> 32 bytes
the index array are simply unsigned shorts as triangle strips, but ushort max value (65535) is used as "primitive restart". (works on most opengl implementations, linux here, and the vertex format is opengl friendly, on dc no opengl ís used though)
each material group vertex buffer is copied into a temporary buffer first using s-queues.
the copy has the vertex format
float x,y,z,u
float nx,ny,nz,v
the u-coord changes position, each vert 32 bytes
lighting is done for the (up to) 32 verts.
lighting functions are assembly, the before mentioned format allows it to do everything lighting related in 64bit FP mode without switching (1x fschg at the beginning and 1x at the end of the function)
for each light the float a,r,g,b values are accumulated and saved in a second temporary buffer. after proccessing each light the values of this buffer are packed to int32 and saved to original vertex data replacing one of the normal values (so normal.x becomes argb color...)
lighting is an implementation of opengls fixed pipeline. the separate functions would be for directional light with specular, dir light without specular, point light with and without specular... (spotlight not implemented yet)
after lighting the vertex format is
float x,y,z,u, v, color (packed as int32), unused, unused
(still 32 bytes)
copying is done in batches of 32 verts.
copy 32 verts, light 32 verts, copy next 32 verts, light 32 verts etc
if all material group vertices are copied and lighting applied - draw stuff
z-near clipping is activated before based on bounding box intersecting the near plane. the clipping implementation isn't the most effective ( it splits to triangles instead of tristrips, i've tried another implementation, but i still haven't figured out the occasional winding order switching there :/ )
drawing is done with the pvr kos direct render functions, no assembly here. no dma either (I havent tested dma yet). but each vertex is 32 bytes everytime.
attachment:
