PDA

View Full Version : engine



dkdd
May 4th, 2011, 18:01
@mefistotelis, since you're the author of KeeperFX, i guess it's you who i should ask things about DungeonKeeper engine. So...

Can you tell me how the engine handles world (object) space -> screen space (3D to 2D) conversion,clipping, etc?
Where (in code) does the engine calculate this projections (and where does it specify perspective projection matrix)?
Is the original render fully software-ish?
How (and where) does it render textured 3D surfaces? (perspective correct software textured polygon render?)

mefistotelis
May 4th, 2011, 18:46
Can you tell me how the engine handles world (object) space -> screen space (3D to 2D) conversion,clipping, etc?
Such conversion is called rendering, but I guess you already know that. I'm not sure what are you asking about.


Where (in code) does the engine calculate this projections (and where does it specify perspective projection matrix)?
Look at engine_render.c. Check the routines draw_view() and draw_frontview_engine().
The common idea of the rendering:
- from the in-game objects and walls, a list of simple elements to be rendered is created (it's named "drawlist" and stored in "buckets")
- The drawlist is parsed and elements are drawn with correct order and parameters.


Is the original render fully software-ish?
Yes. And I intend to keep it this way.


How (and where) does it render textured 3D surfaces? (perspective correct software textured polygon render?)
Low-level polygon rendering routines are stored in bflib_render_*.c. Unfortunately, the original code was highly optimized and partially written in ASM, so currently the routines are only in ASM form, too. Most of the rendering is made in draw_gpoly(), and the other routine (trig()) is mostly used for shadows and simpler elements. But both functions work in a similar way.
Fanfact: In Syndicate Wars (earlier Bullfrog game), there was only trig() routine, and it was used to render everything on screen.

dkdd
May 5th, 2011, 08:25
hehe, now that's some ASM rendering code :) damn they were good at optimizing in those days...

how does the engine handle rendering through direct3d? (multiple render-paths? does it create vertex arrays etc..?)


is this "the same" engine that was used in populous 3?

mefistotelis
May 5th, 2011, 12:01
how does the engine handle rendering through direct3d? (multiple render-paths? does it create vertex arrays etc..?)
I didn't analyzed the Direct3D version. But I doubt it's very advanced - after all, hardware acceleration wasn't very mature back then.


is this "the same" engine that was used in populous 3?
I'm pretty sure it's the same, maybe a bit updated engine. But I didn't analyzed Populous in detail - I made conclusions mainly based on look of the game.

jomalin
May 5th, 2011, 17:50
Unfortunately, the original code was highly optimized and partially written in ASM...

mefisto, this means you need to "port" this code part to C to allow KeeperFX to be portable, isn't it?

mefistotelis
May 5th, 2011, 18:28
mefisto, this means you need to "port" this code part to C to allow KeeperFX to be portable, isn't it?

To be portable to non-x86 CPUs, yes. But it doesn't influence portability between OSes on x86.

dkdd
September 21st, 2011, 12:28
ok, some time has passed since last post in this thread...

I'd like to know what's the state of rendering system? Have all drawing routines been rewritten?

dkdd
October 4th, 2011, 20:23
Question...

is the size of the terrain texture atlas (tmapaXXX.dat, 256x2176) hardcoded into engine? Or could we supply higher resolution texture atlas? How is this texture accessed? By absolute texture coordinates or by relative (relative meaning that each texture side goes from 0..1).