[OUTDATED] 2.99.5.20080903 pre-alpha build
- Spazzy McGee
- Sergeant Major
- Posts: 1405
- Joined: Mon Mar 21, 2005 4:59 pm
- Location: Planet MoFo, Sheffield Division; United Kingdom
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
I have compiled bzflag version 2.99.5... on Ubuntu 8.04 and I am NOT getting "double jumps" when pressing the tab key more than once while in the air. Also the "i" key works for me to spawn.
The one thing I don't like is that the radar now treats a mesh as a 1 dimensional layer. I can't see any difference in height on a mesh map on the radar. This may work for boxes and pyramids, but a mesh needs to have some definition as well. I am using the Enhanced Radar. Normal, Fast, and FastSorted don't do any better with meshes. Have a look at this post for a better explanation. It is essentially the same problem:
http://my.bzflag.org/bb/viewtopic.php?p ... ht=#115208
I would like to see a radar that takes the mesh height differences into account and displays them accordingly.
The one thing I don't like is that the radar now treats a mesh as a 1 dimensional layer. I can't see any difference in height on a mesh map on the radar. This may work for boxes and pyramids, but a mesh needs to have some definition as well. I am using the Enhanced Radar. Normal, Fast, and FastSorted don't do any better with meshes. Have a look at this post for a better explanation. It is essentially the same problem:
http://my.bzflag.org/bb/viewtopic.php?p ... ht=#115208
I would like to see a radar that takes the mesh height differences into account and displays them accordingly.
- Blazing King
- Private First Class
- Posts: 82
- Joined: Thu Mar 09, 2006 9:26 pm
-
- Private First Class
- Posts: 1290
- Joined: Sun May 16, 2004 10:19 pm
- Location: Spain
- Contact:
- Mucho Maas
- Private First Class
- Posts: 515
- Joined: Tue Sep 21, 2004 5:14 pm
Just a question.
The BZFlag 3.0 Wiki states:
The BZFlag 3.0 Wiki states:
does this mean that hit detection will/is moved to the server? what implications will this have regarding lag?Additional features are planed to be moved server side, including shot, hit, and death detection
"meet the new fo0 , same as the old f0o ... no no no .. don't get fo0'ed again ... " - The Who
- Mucho Maas
- Private First Class
- Posts: 515
- Joined: Tue Sep 21, 2004 5:14 pm
Still, would this mean that a tank explodes when a server sees a hit, meaning i could be exploding when I think i have dodged it?
Or will hit detection use lag unrolling for targeted tanks?
I am just thinking this may change the gameplay a lot.
Or will hit detection use lag unrolling for targeted tanks?
I am just thinking this may change the gameplay a lot.
"meet the new fo0 , same as the old f0o ... no no no .. don't get fo0'ed again ... " - The Who
no, you would have both the server and client do the tests and only have the server arbitrate disputes.
the first part of this is ensuring that the shot paths and tank paths can be matched on the client and server. current research is showing that shots can be done this way. Once we are sure that everything is in sync, the disputes between client and server should be minimal.
We had a paid student over the summer working on the problem and he found out a lot of good info on the subject.
we will not simply make it so that you have to "wait" to die. All these issues are the primary reason that it is NOT in 3.0, because we will not do it unless it is done right.
the first part of this is ensuring that the shot paths and tank paths can be matched on the client and server. current research is showing that shots can be done this way. Once we are sure that everything is in sync, the disputes between client and server should be minimal.
We had a paid student over the summer working on the problem and he found out a lot of good info on the subject.
we will not simply make it so that you have to "wait" to die. All these issues are the primary reason that it is NOT in 3.0, because we will not do it unless it is done right.
JeffM
For all you lazy Mac users ():
Source:
http://home.comcast.net/~devin_d/bzflag ... ce.tar.bz2
MAC 10.5 Binary:
http://home.comcast.net/~devin_d/bzflag ... c-10.5.dmg
MAC 10.4 Binary:
http://home.comcast.net/~devin_d/bzflag ... c-10.4.dmg
All binaries are PPC. The 10.5 binary was configured with --enable-debug. The 10.4 binary was configured with --enable-optimized. I don't know if the 10.4 binary will actually work on 10.4. I configured with:
The 10.4 build works on my 10.5 OS, but I'll leave both there, since one is a debug build.
Source:
http://home.comcast.net/~devin_d/bzflag ... ce.tar.bz2
MAC 10.5 Binary:
http://home.comcast.net/~devin_d/bzflag ... c-10.5.dmg
MAC 10.4 Binary:
http://home.comcast.net/~devin_d/bzflag ... c-10.4.dmg
All binaries are PPC. The 10.5 binary was configured with --enable-debug. The 10.4 binary was configured with --enable-optimized. I don't know if the 10.4 binary will actually work on 10.4. I configured with:
Code: Select all
export SDK=/Developer/SDKs/MacOSX10.4u.sdk
./configure --enable-optimized CXXFLAGS="-mmacosx-version-min=10.4 -isysroot $SDK" --enable-plugins CFLAGS="-mmacosx-version-min=10.4 -isysroot $SDK" LDFLAGS="-isysroot $SDK -Wl,-syslibroot,$SDK"
Last edited by Enigma on Sun Sep 07, 2008 2:11 am, edited 1 time in total.
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
I think there is a problem with the new radar mesh rendering algorithm. The idea that treating a mesh as a single object and using the mesh Z position and height to scale the alpha channel does not work for a mesh that is the terrain of the entire map; there is no definition of the landscape. If a mesh object is something like a tank or boulder or a small building, the current method works well. I think that a mesh terrain needs to be alpha scaled for each individual face height. Perhaps a new BZW option could be used to distinguish between a mesh that is used as the terrain and a mesh that is a smaller monolithic object. This option would be placed in the mesh definition if needed. The current radar rendering code would still have the same rendering speed for monolithic mesh objects. This option would be used to mark the terrain mesh for a face by face alpha scaling. Each face Z position and height needs to be taken into account for the alpha scaling referenced to the tank Z. That way the mesh landscape will have some definition.
Also the use of static display lists defeats the alpha scaling changing with the tanks altitude. It's decided when the player joins before spawning and the tank is at zero altitude. That alpha scaling is fixed at the altitude of zero units.
Also the use of static display lists defeats the alpha scaling changing with the tanks altitude. It's decided when the player joins before spawning and the tank is at zero altitude. That alpha scaling is fixed at the altitude of zero units.
Last edited by anomaly on Sun Sep 07, 2008 6:14 pm, edited 1 time in total.