[##UnknownPlayer##]

I'm back!!! Been off and about in the Australian alpine area, but thankfully now that I'm back in my sheltered little city lifestyle, I can get back to working on the source code project (right after I get comfortable using a keyboard again )

Anyway, I'll be a little hazy for the first couple of days because my brother messed with my computer and managed to wipe a bunch of cookies and settings out (somehow ??? ) but I'll get right back into it ASAP.

[Galemp]

Huh? Who are you?

See, he's an Unknown Player... Unknown... get it? Ahh, never mind.

[RandomTiger]

Amongst other things he done some good work for the DX8 branch. Nice to see you back.. just when we need you as well

Hes been around longer than me I think, he just doesnt make as much noise

[Inquisitor]

He left?

[RandomTiger]

Yes. He had RL stuff to attend to so wasnt totally gone but wasnt able to help out with the code much. Having said that he still managed to crack off one of those fog bugs.

[##UnknownPlayer##]

Speaking of fog bugs, I read that you nailed the nebula lighting problems but at the cost of performance? My opinion is don't worry about it - we just follow the old paradigm of make it work, then make it work fast. I do forsee that a large area of graphics code may in fact have to be ported from the custom software transform and lighting to DX8 styled. This being the case, it sounds as though the entire engine might need another giant split put into it to facilitate this but let us keep OGL functionality in as well (since ultimately, it would be nice to offer a windows OGL choice as well).

[RandomTiger]

The code I put in is the same way it was done in DX5, put DX8 just doesnt like it one bit. Locking the back buffer is not something a fast program should be doing by the looks of it.

Once we have hardware fog it wont be an issue.
Its justs a shame we have to move onto HT&L without being able to merge DX8 back into the code cos of speed issues.

[##UnknownPlayer##]

Well so far it runs fine on my system (but given that, my system is uber-fast so you could probably be quite inefficient and get away with it).

Basically though, I'm thinking that we probably need to delay hardware T&L and instead go through and change the rendering code to use DX8 standard calls and structures etc.  BUT! Before we do this, we definitely need to have a meeting and decide the future directions of the engine, since to do hardware T&L will basically mean breaking the abstracted parts of the 3D engine.

[RandomTiger]

THeres a fair bit of HT&L that can be done without disrupting stuff, or at least can be done without a full structural change.

What do you mean by ' change the rendering code to use DX8 standard calls and structures etc'?

Woooo! 1000 posts!

[##UnknownPlayer##]

Probably should have phrased it better - basically we need to be getting rid of the custom software transform and lighting and let DX8 handle it. I suspect that would probably give us a nice speed boost.