New wolfet.exe using ET-GPL and ET-xreal

[tdkxeon]

Edited November 11, 2011 by tdkxeon

[SunLight]

nice screenshots.

 

lol

Now i know u didnt do anything !

Well, if you had read my posts as accurately as I had read yours, then you would have realized straight away that I didn't compile it...

 

Now I tried to compile it with smp support, but no luck, since they haven't finished it yet on Linux, in fact that #ifdef is missing on windows

$ git grep -w SMP
src/engine/unix/linux_gl3imp.c:#ifdef SMP
src/engine/unix/linux_gl3imp.c:SMP acceleration
src/engine/unix/linux_glimp.c:#ifdef SMP
src/engine/unix/linux_glimp.c:SMP acceleration
src/engine/win32/win_gl3imp.c:SMP acceleration
src/engine/win32/win_glimp.c:SMP acceleration

and I get a:

Sys_Error: R_InitUnitCubeVBO: FIXME SMP

if I start et... nevermind, good luck for you, bad luck for me...

 

back to topic:

have you fixed the missing body bug?

 

p.s.

5. old et runs on open cl graphics, new on runs on open gl which is much more advanced

Could you explain in layman's terms that open cl thing? I was under the impression that et has always been opengl, or it's a typo?

 

edit:

p.p.s.

I compiled it on windows as well, same error if I try to activate smp, R_InitUnitCubeVBO: FIXME SMP, so no multithreading for now, not even on windows, it was true that they didn't finish it yet.

Edited November 11, 2011 by SunLight

[tdkxeon]

yup fixed the skeleton issue, now i can see whole body !!

 

and i hate layman so no.

 

ur doing some thing wrong

describe exactly what ur doing starting from where u downloaded the package and what is in it.

[SunLight]

yup fixed the skeleton issue, now i can see whole body !!

 

and i hate layman so no.

 

ur doing some thing wrong

describe exactly what ur doing starting from where u downloaded the package and what is in it.

I'm happy you fixed that problem. gl with your work.

 

---

[begin ot long clarification]

About hating layman, just don't bother, I only meant that I don't think ET is (or ever was) open cl, so I wondered where you found that piece of information, and if you could share. That's all. And maybe while you are there, any infos about that 1.4gig file being for quake wars?

 

You still say that I am doing something wrong, the problem is, you are the one who hasn't either read or understood my posts since the beginning. Not that they are particularly relevant or interesting, but either you don't read a post, or if you read it at least try to read it thoroughly. Or maybe my English is not good enough, sorry for that, it's not my native language.

 

- You first told me that I compiled it wrong, instead I clearly stated in one of my first posts that I had used their binary from sourceforge, and still not compiled anything (later I compiled it both for win and Linux).

- You said that I had a compile error, and I was so naive not to realize it and I used an old version, while I said I had completely removed the beta (so I had no traces of the old version).

 

You totally ignored what I said about r_smp (I guess you have heard about that setting, right?), and the fact that it's not implemented yet, so no separate thread is created. The reason why it says:

Trying SMP acceleration...

...failed.

is because on Linux (and I tried that binary (Linux) first), that section is in the middle of a #ifdef SMP, and SMP is not defined by default, so there is just a dummy function that returns false, without creating any thread. It fails 'by design' in their source code.

 

On windows that #define is not there, but r_smp is not fully implemented either, in fact if I do /r_smp 1 /vid_restart, I get the other error (R_InitUnitCubeVBO: FIXME SMP)

 

When I compile on Linux, after changing the makefile to #define SMP, I get that error too.

 

So I didn't make any compilation error whatsoever, that r_smp fail is due to the fact that they didn't finish it. In original ET it was only in the Linux code and there was no trace of it in the win version, now they copied it to win as well, but still it's not implemented properly.

Of course if someone has never heard of r_smp 1, he won't even attempt to set it and try multithreading, so no error will be shown.

 

So the only wrong thing I did was hoping that they had fixed what they didn't fix at all, that is having a separate thread for the renderer, and maybe that if I compiled it with -DSMP it could be at least partially working. That's all.

 

As regards the source where I took it, I cloned it with git from this repository:

git://xreal.git.sourceforge.net/gitroot/xreal/ET-XreaL

[end ot]