ET: Legacy

[Indloon]

Will not change anything, and could be even worse, since ET doesn't support multicore.

Actually, ask INTEL developers for help

They always help with implementing multicore support

[Mateos]

In a game that doesn't support it?

[ailmanki]

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.

[Indloon]

In a game that doesn't support it?

It _WOULD_ support it, by asking help from Intel, so it is possible to implement multicore support.

[Gir]

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.

[Radegast]

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.

[Indloon]

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.

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.

[Gir]

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.

There is OpenMP

OpenMP (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, i believe Dushan Implanted this.

[Dushan]

There is OpenMP

OpenMP (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, i believe Dushan Implanted this.

I have only experimental code only atm. And ofc I will not share that code in my initial BETA release

[morsik]

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.

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)

[Indloon]

OpenMP (Open Multiprocessing) is an API that supports multi-platform shared memory multiprocessing programming in C, i believe Dushan Implanted this.

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?

[Radegast]

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.

[Radegast]

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.

[100zherBG]

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...

[Indloon]

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..

[Radegast]

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.

[Shownie]

Do you have Intel based mac support?

[Radegast]

Do you have Intel based mac support?

Not yet, but Morsik started working on Mac OS X support a few days ago.

[100zherBG]

Difficult installation for Debian amd64 (from new git repository - deb package): you need to download "libcurl3-gnutls" and "librtmp0" for i386 arch, unpack and copy "libcurl-gnutls.so.4", "libcurl-gnutls.so.4.2.0" and "librtmp.so.0" to "/usr/lib32"... at Debian repository isn't an official ia32 package for this files.

[Radegast]

Wow, is it that hard? I thought about creating a fake 64bit package for Debian 6 with libcurl compiled in statically, but I couldn't figure out how to pass arguments to the build system when using cdbs together with CMake in automatic OBS builds. If anyone knows how to solve this, here is my rules file:

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/cmake.mk #CMake hidden magic

By the way, do you have this bug on Debian?