[QUOTE=Gir;401361]
Big Drops in Frames as you go down the Engine tree, ET the Slowest
ET also suffered from Huge FPS Drops e.g, Radar, even on good hardware.[/QUOTE]
Thats why i changed ET.exe onto quake3.exe ;DD after changing et uses 2 cores instead of 1 ;DD
[QUOTE=Gir;401361]
Big Drops in Frames as you go down the Engine tree, ET the Slowest
ET also suffered from Huge FPS Drops e.g, Radar, even on good hardware.[/QUOTE]
It is because of the rendering code, it must be rewritten. And its on CPU rendering.
However, these are in mind:
Port ET rendering to dynamic voxelization rendering.
Using OpenGL 4.x series.
Using OpenCL api( only good for AMD currently ) for maximum performance and gives a access to GPU,CPU and even for DSP.
SVO(Sparse Voxel Octree) for models, this says good bye to polygons count, mostly if the hardware can handle it :D.
Support for diffuse, indirect specular light, mostly like in Frostbite 2.
Support for GLSL shaders.
Using IBO instead of VBO.
And so on, it is huge amount of work on ID3, but whatever, worth trying.
Will not change anything, and could be even worse, since ET doesnât support multicore. So it could mess up and you can have spikes on your lag-o-meter⌠Thatâs why everyone turns off the Threaded Optimization.
Actually, ask INTEL developers for help 
They always help with implementing multicore support 
Forget 2.55 ⌠forget also 2.60x.
Write the next version, backward compatibility is nice but overrated.
Just dont even bother about it. If its possible to run 2.55 - ok, if not - ok.
Even if we told every player to update to 2.60b, many of them are unable todo so.
Once the new version has features people really want to have, they are going to tell there playerbase how to install the new ET.
The only thing which should continue to work, are the existing maps.
At least ⌠I donât see the value in supporting ET 2.55 ⌠- I can already see it in 20 years still lurking these forums ⌠we should have told em 20 years ago to update, instead of keeping compatibility.
Lastly for a proper anti-cheat to work, ET 2.55 is useless.
It WOULD support it, by asking help from Intel, so it is possible to implement multicore support.
Why would you ask help form Intel ?? , you need someone whom is an expert on the Quake 3 Engine, but with âVertex Buffer Objectâ, the GPU does the does all the Rendering Work in Parallel.
No need for Dual Core.
On the Audio Side, there is âXaudio2â , which works best on Windows 7/Vista, and as much less latency then the Old
ET Audio API and SDL and also benefited Brink when SD used it.
(digibob)
The old audio code used to submit buffers to DirectSound in large chunks, think it was around 90ms or soâs worth of sound at a time. Since the game code tic ran at 30hz (33ms), this meant that whenever the game code submitted a new sound, there could a variable delay before the sound actually started playing. This took a lot of juggling to work around, and in the end I still wasnât hugely happy with the solution.We have moved over to using the XAudio2 API now however, which is a much nicer API to work with, especially as a lot of the annoying fiddly bits are handled for you. Write once, compile twice (it runs on the 360 as well!) is also very handy, as it cuts down on the number of APIs we have to support, and thus, the code we have to write.
I think we are getting a little offtopic here :-). If I am not mistaken all of the things that were mentioned either are or will be implemented in OpenWolf by Dushan. As Gir pointed out, there are many small bugs on the client side in ET:L that really need to be fixed before we even start to think about adding major features such as renderer rewrite or different sound system support. Well, maybe there is a feature that Iâd like to see in ET:L soon and that is crash reporter, because saying that our client randomly crashes on Windows is not quite helpful without any other information.
Btw, r_smp was fixed by moving to SDL (needs to be compiled in), so although I canât say that ET:L is fully multithreaded app, at least renderer can now be run in a separate thread.
[QUOTE=Gir;401408]Why would you ask help form Intel ?? , you need someone whom is an expert on the Quake 3 Engine, but with âVertex Buffer Objectâ, the GPU does the does all the Rendering Work in Parallel.
[/QUOTE]
Because implementing CPU multicore support is not that easy as you think.
It is useful for lets take a example: physics⌠things what arenât connected with rendering.
Btw, there is not such thing as Vertex Buffer Object. There is a buffer object, which is a linear array of GPU-controlled memory that you can allocate. And you can use that buffer object for many different things.
So you may use a buffer object for both vertex and element/index data. You can also use the same one for pixel transfers, transform feedback, and even uniforms.
Well, Iâm done here, brb,gl.
[QUOTE=Indloon;401423]Because implementing CPU multicore support is not that easy as you think.
It is useful for lets take a example: physics⌠things what arenât connected with rendering.
Btw, there is not such thing as Vertex Buffer Object. There is a buffer object, which is a linear array of GPU-controlled memory that you can allocate. And you can use that buffer object for many different things.
So you may use a buffer object for both vertex and element/index data. You can also use the same one for pixel transfers, transform feedback, and even uniforms.
Well, Iâm done here, brb,gl.[/QUOTE]
There is OpenMP
OpenMP (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, i believe Dushan Implanted this.
[QUOTE=Gir;401443]There is OpenMP
OpenMP (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, i believe Dushan Implanted this.[/QUOTE]
I have only experimental code only atm. And ofc I will not share that code in my initial BETA release
[QUOTE=Gir;401408]
On the Audio Side, there is âXaudio2â , which works best on Windows 7/Vista, and as much less latency then the Old
ET Audio API and SDL and also benefited Brink when SD used it.[/QUOTE]
But SDL is here for multiplatform. If we implement audio systems manually, we have to do that with Linux ALSA, and OS X CoreAudio too. Too much work for something that already works ok. (-;
There are many other things that needs to be fixed, so⌠thatâs the very very lowest priority (99.9% never be done ;P)
[QUOTE=Gir;401443]
OpenMP (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, i believe Dushan Implanted this.[/QUOTE]
Even more interesting than OpenMP, would be OpenCL. Heterogeneous computing is exploding with the implementation of GPGPU architecture on gfx chipsets. For high perf. computing stuff, that stuff is pretty neat. You should download one of the OpenCL SDKs and play with it! (I personally recommend AMD APP SDK 2.6.) OpenCL also ties in to OpenGL so that you can mix the two technologies for some insane processing. Heterogeneous computing is where mainstream programming is going.
Btw, isnât it better to use OpenAL for sound?
We have OpenAL backend and you can compile it in, but it is even more bugged than the SDL one.
As I said before, at this point we need to start focusing on stability rather than new features.
Ideas to let people know about ET:L 2.70
muessli proposed an interesting idea to provide a simple way for our users to edit ET:L installer. One scenario comes to my mind: you have a clan and you want to give your members a package which includes the base game, maps, mods and any pk3s you use on your clan server and set a shortcut to autoconnect to your server. It could be as easy as editing a single file and we could even mirror the custom installer on our official etlegacy.com server.
Also, if you are a server owner we could add your main server to Favourites in the ingame server browser in exchange for telling your players about ET:L, e.g. provide a link on your webpage or ingame announcement. (deleting a server from favourites takes 2 seconds, so it shouldnât annoy anyone)
We arenât anywhere near a stable release yet, but these are some ideas we could use when we will be.
Hi,
I have connect to server with PunkBuster but server kicked me with error âPB must be enabledâŚâ Tested on two servers with same result. My PB is on (cl_punkbuster 1) and my etkey is an original created before PB stop working for ET. All work fine on ET-2.60b and same servers. My system is a Linux/Debian testing (wheezy) 64-bit and ET:L is a etl-2.70-git20120504-linux-static-i386.tar.gz, PB donât loaded in console (some blue text normally).
Heelp pleaseâŚ
100zherBG,ET:Legacy donât have support for Punkbuster.
The Punkbuster was removed from the source code of ET, because Punkbuster isnât open-source anti-cheat.
And so it donât have support for it, as OpenWolf,ET:XreaLâŚ
We now have deb packages for Ubuntu 12.04. I wrote a short guide which takes you step-by-step through the installation process: Installing ET:L on Ubuntu 12.04. Soon there will be packages for OpenSuse, Debian and Fedora. These are nightly builds, which means they get automatically compiled every day from our repository, so it is as bleeding edge version as it gets.
