Doom 3 engine release and game code

[revelator]

hehe yeah the 6000 series was quite nice mine actually lasted untill i had the cash for a 8800gtx (was not wealthy in those days and that card costed an arm and a leg here in DK).
So that early ??? could have sworn i had a ti4200 back then but my memory might not be the best anymore (age heh).

[leileilol]

Geforce2 GTS worked in Doom3 as well. Too bad the Radeon7x00 didn't, but anyway that's only thanks to GF4MX's market saturation

[revelator]

Seems like a millenia ago since i had a geforce2 newer quite liked the MX cards, i still remember the MX4 version which where more or less dumped down geforce 3's and performed worse than a geforce2
The only radeon card i have left is the first version by ati and funny enough the only version i newer had problems with any games on though if i tried todays games it would probably burn

[tobis87]

reckless, I noticed this changed in VertexCache.cpp:

Code: Select all

     // copy the data
     block->virtMem = tempBuffers[listNum]->virtMem;
+    block->vbo = tempBuffers[listNum]->vbo;

     // mh code start
     if ((block->vbo = tempBuffers[listNum]->vbo) != 0)

Can't (block->vbo = tempBuffers[listNum]->vbo) in the if statement be replaced with block->vbo?

It would be nice if you could use some kind of revision control or provide broken out patches.

[revelator]

I do have a github account but im stuck with a very frustrating performance bug (especially on ATI cards) so i havent updated the repo yet
As for the VBO stuff listNum is probably the index number so removing it is not recommended.
The code is actually mh's

[tobis87]

I do have a github account but im stuck with a very frustrating performance bug (especially on ATI cards) so i havent updated the repo yet

Nice, maybe I am a bit too impatient.

As for the VBO stuff listNum is probably the index number so removing it is not recommended.
The code is actually mh's

I thought this http://pastebin.com/rHrwP0nA was the code from mh and the new stuff (FRAME_MEMORY_BYTES = 0x4000000 and the line) was from you.
Does it not mean that tempBuffers[listNum]->vbo is copied twice to block->vbo?

[revelator]

Ah aye i see what you mean indeed it does.

Should just be

Code: Select all

    // copy the data
    block->virtMem = tempBuffers[listNum]->virtMem;
    block->vbo = tempBuffers[listNum]->vbo;

    // mh code start
    if (block->vbo)

[mh]

It's copied twice yeah, but it's just setting a GLuint to a GLuint so it's not actually a problem, just minor code smell.

[revelator]

Patched my version by hand guess i overlooked this one the FRAME_MEMORY_BYTES was just an experiment with a larger pool to test if it helped with some of sikkmods heavier stuff.

Btw some have asked what the advantage was with my updated image handlers, turns out it fixes some custom skins which earlier led to them being rendered black or otherwise incorrect

like this fella ->

[ceriux]

hey i tried using the git for iodoom3 but it didnt seem to work. is there another doom3 engine i could try?

[revelator]

iodoom3 seems stillborn :/ theres been little to no activity on the site in several months.
Atm theres probably nothing prebuilt (besides my little project) but my version has a few performance bugs (mostly ATI related).
Else Dhewm3 is probably the engine with the most recent changes atm, but its incompatible with mods unless you got the option to recompile there game dll's against it (protocol change).

[ceriux]

that really sucks, id like to see new engines for doom 3 like there are so many for quake.

[revelator]

I think it will catch up but many devs are waiting for the BFG edition source code (less work fixing stuff)

[ceriux]

i heard they fixed up the network code in BFG?

[revelator]

They also moved the fps cap from 60 to 120 and the flashlight is now allways on (no need for ducttape mod anymore).
The renderer also had some house cleaning it seems.