Sauerbraten - Bug reports

by Gilt on 11/28/2004 19:49, 574 messages, last message: 06/30/2007 22:00, 520638 views, last view: 09/30/2024 00:35

So yeah, since I don't feel like doing a whole lot of testing anymore, I may as well leverage my resources, and shove that responsibility to all of you. Hopefully, this will allow for more updates, and a less buggy engine.

The Format:
-----------
What: A *short* description of the bug / problem.

How: point form of relevant steps to reproduce the bug.

When: revision of exe. OS, video card... yeah I don't know, anything that might be relevant. keep it short.

Detail: any other stuff that might be relevant. like pics. http://www.imageshack.us/ if needed.
-----------

new releases here:
http://cvs.sourceforge.net/viewcvs.py/sauerbraten/sauerbraten/sauerbraten/bin/sauerbraten.exe?view=log

for each new version, I will list fixed bugs. you are then responsible to make sure that it really is fixed, and then confirming it in this thread.

!!! NOTE !!!: this thread is not for feature requests, design discussion, bitching, moaning, yadda yadda, etc. there are other threads for that. plus, a forum thread already does not afford great organization. please no garbage.

Keep reports short. I have a habit of skimming large blocks of text.

Focus on the WHAT, not the WHY. There is a tendancy in people to want to be too helpful. They try to diagnose the problem instead of very clearly describing what is wrong. at the very least, keep theories in the detail section.

some examples are below:

   Board Index   

#273: Other strange subdivision errors...

by enigma_0Z on 07/16/2005 06:36

I too have recently had a strange subdivision error...

I had a vertical bar five cubes high of a gridsize of 2x (eg, not the smallest, but the second smallest). Each side was "pushed" in three times. I had several of these bars pasted side by side in front of a window. I went to texture the sill and selected it with a smaller gridsize (1x, to be specific).

The bars just happened to be in the selection. I changed the texture, and the side of all the bars (just one side) got these weird cross thingies on them. They were big X-shaped flat spike thingies... It seems that the smaller gridsize of the selection caused the vertices in the center of the selection (It was two cubes wide) to be correct, but all the corners were reset. I'll get a screenie up soon, anyway, it seemed to be a simple subdivision gone haywire.

I also did some experiments and it seems that simpler shapes (cylinders to be specific) and subdivision error didn't afflict them. It seems that if the cubes are modified on more than one axis/plane then subdivision gets a little flakey...

anyway.

reply to this message

#274: Re: Hmm...

by Andrew Brault on 07/16/2005 18:15, refers to #274

I just recompiled the latest sources from CVS and fiddled with things for 10-15 minutes with no new problems (not even on ksauer1). The above mentioned subdivision bug is still there of course. However there is now some serious z-fighting or something going on when in edit mode (only) that was not there in the prior CVS version.

reply to this message

#275: Re: Hmm...

by enigma_0Z on 07/16/2005 18:24, refers to #274

You're a gentoo user too? So am I! I'm on an AMD thunderbird though... 1000 MHz

reply to this message

#276: Buggy cubes

by Andrew Brault on 07/16/2005 19:46

Here are some interesting degenerate/buggy cubes I was able to
produce. Quite a large variety is possible. Most of these were
derived from the small cube obtained by pushing in all 4 "walls" of a
big cube by 3 or 4 clicks then pushing the "ceiling" down 7 clicks.
Many of these buggy cubes appear to be numerical errors solving the
intersection-of-planes equation, or possibly the result of having
edgespan values of 9..15.

Here is the "parent cube" and the small pushed-in version:

http://unsignedint.com/images/sauerbug/cube1.jpg

Other buggy cubes; the selected cube shows the actual size:

http://unsignedint.com/images/sauerbug/cube2.jpg

http://unsignedint.com/images/sauerbug/cube3.jpg

http://unsignedint.com/images/sauerbug/cube4.jpg

http://unsignedint.com/images/sauerbug/cube5.jpg

Here is the map file (may lock up/crash):

http://unsignedint.com/files/misc/cubetorture.ogz

reply to this message

#277: Re: Buggy cubes

by kurtis84 on 07/16/2005 19:54, refers to #276

If you think about what you're asking the engine to do with those shapes, I think you would realise why thats happening. It cannot determine what is needed to do with some cubes surrounding what you attempt. It might try to divide to a size that will not fit on a grid at all...then you get these mistakes.

If you want to build stuff shaped like those screenies ( why I do not know ) then use a small grid to start off with...don't start with gridpower 8 when you intend to make something thats gridpower 2 size, because you simply cannot shape one cube into 20 different directions...but you could shape a pile of small cubes into that ;)

reply to this message

#278: Re: Buggy cubes

by Andrew Brault on 07/16/2005 20:23, refers to #277

The cubes pictured were produced by manipulating individual cubes, no subdivision involved...

reply to this message

#279: Re: Buggy cubes

by Andrew Brault on 07/16/2005 21:11, refers to #278

Using a debugger I pulled out the "edges" array for some of these weird cubes (12 hexadecimal bytes each):

- 101010006054888000888854

- 006080200088005010558284

- 101010100080851087005480

- 100010108054885080000084

- 106010100088005000558284

These appear to be normal in the sense that all nybbles are between 0 and 8 and high nybble >= low nybble. So the rendering problems must be caused not by corrupt edgespans but by the conversion of edgespans into vertex positions.

reply to this message

#280: Re: CVS Sauer on x86_64 hangs in intermission

by Aardappel_ on 07/16/2005 22:30, refers to #270

to solve the 64bit issues we will have to wait until we have a programmer that uses such a system, and thus can just find the bugs.

reply to this message

#281: Re: Buggy cubes

by Andrew Brault on 07/17/2005 03:42, refers to #279

After reading the code some I think the problems with cube rendering stem from a confusion in the code of what the edgespans really mean. To me, the edgespans define 6 heightfields in the 6 axis directions where each heightfield has a flat square "base" and a jagged "top" which should always be a convex mountain shape (or flat). The ultimate cube shape should be the CSG intersection of these 6 heightfields. However the rendering code treats the edgespans as defining 6 flat planes (even if the planes are not flat) that when intersected always result in a 8 vertex polyhedron.

This seems wrong and inconsistent to me but maybe I have an wrong understanding of the idea behind the edgespans. Any ideas?

reply to this message

#282: Re: Buggy cubes

by Andrew Brault on 07/17/2005 03:52, refers to #282

I don't think so ... from what I can tell the buggy cubes have perfectly legal structure but the conversion to poly vertices is going wrong, sometimes even producing vertices outside the cube volume.

reply to this message

#283: the nothing crash

by shadow.516 on 07/20/2005 00:52

In the lates CVS, if you remove all the cubes from the map (so that all that is left is the skybox), the game crashes.

reply to this message

#284: Re: the nothing crash

by shadow.516 on 07/20/2005 00:56, refers to #283

in addition, it doesn't matter if there are other materials left on the map - as long as there are no solids, a crash is inevitable.

I came across this bug while trying to make a map entirely out of glass.

reply to this message

#285: gun vanish

by da(5)id on 07/23/2005 07:18

i've noticed that when i go up stairs the gun flickers in and out of exsistance.
this doesn't happen with the character model in the thirdperson mode. weird huh?

reply to this message

#286: Re: CVS Sauer bugs on x86_64 -- out of world ents

by kurtis84 on 07/23/2005 15:07, refers to #285

just for the record, there are no ents outside of ksauer1. I do have a clue why you're getting that message though. There are several cubes I pulled back 1 or 2 units, then I set ents in that pulled back space...is it not properly calculating those small spaces like that?

I cannot help but wonder Morgaine2, have you done anything to find the source of this 64bit problem, or are you just posting everything you see wrong with it on a 64bit system? AFAIK, nobody working on Sauer has a 64bit system, so I would think these problems aren't going to be fixed unless you, or someone with a 64bit system does it themselves ;)

reply to this message

#287: Re: CVS Sauer bugs on x86_64 -- out of world ents

by shadow.516 on 07/24/2005 03:54, refers to #287

Actually, there are out of map coordinates for 32-bit. But for some reason the code doesn't hang.

Here's what I get with ksauer1:

init: video: mode
init: video: misc
init: gl
Using GL_ARB_vertex_buffer_object extensions
init: world
game mode is ffa/default
init: basetex
init: sound
init: cfg
unknown command: and
init: localconnect
init: mainloop
read map packages\base\aard3.ogz (3893 milliseconds)

game mode is ffa/default
warning: ent outside of world: enttype[11] index 14
warning: ent outside of world: enttype[11] index 15
warning: ent outside of world: enttype[3] index 16
warning: ent outside of world: enttype[3] index 17
warning: ent outside of world: enttype[3] index 18
warning: ent outside of world: enttype[5] index 19
warning: ent outside of world: enttype[8] index 20
warning: ent outside of world: enttype[9] index 22
warning: ent outside of world: enttype[11] index 25
warning: ent outside of world: enttype[4] index 28
warning: ent outside of world: enttype[10] index 34
warning: ent outside of world: enttype[5] index 60
warning: ent outside of world: enttype[4] index 61
warning: ent outside of world: enttype[6] index 64
read map packages\base\ksauer1.ogz (4062 milliseconds)
3Dimentia_1
game mode is ffa/default

reply to this message

#288: Re: CVS Sauer bugs on x86_64 -- out of world ents

by kurtis84 on 07/24/2005 19:02, refers to #288

So, let me get this straight. Is there something wrong with my map thats causing this, or is it in the method the engine is loading the map?

If it's something wrong with my map, I would like to hear someone say exactly what it is about ksauer1 thats causing this...does anyone know yet?

reply to this message

#289: Re: CVS Sauer bugs on x86_64 -- out of world ents

by Aardappel_ on 07/25/2005 23:06, refers to #289

that's because it doesn't solve the problem, only hides it. Other maps have entities outside the world which are legal, such as sunlights.

Some coordinates of some entities are clearly corrupted, they show up as big numbers or NaN even on win32 (so this is not a 64bit portability issue, it just crashes harder on 64bit linux).

I can easily "fix" this map, but I would rather first know how they got corrupted in the first place. You can't really tamper or corrupt a .ogz externally, as it would show up as a zlib crc error. So somehow, some version of sauer must have corrupted this itself.

reply to this message

#290: hmm

by Pxtl on 07/26/2005 14:55

It does seem that it should at least make a warning about such violations, at least where appropriate (as Aard mentioned, some entities should be outside).

reply to this message

#291: Re: CVS Sauer bugs on x86_64 -- out of world ents

by >driAn<. on 07/26/2005 20:19, refers to #290

Morgaine2, no it doesn't solve the problem. A bug must be fixed on the root of the problem, else its a cheap hack.

reply to this message

#292: Re: CVS Sauer bugs on x86_64 -- out of world ents

by kurtis84 on 07/27/2005 00:13, refers to #292

ksauer1 was built before we had a working "dropent" command. I did use the dropent on the map after it was implemented, but I think I remember there being some issues with that command.

Could this have caused these troubles?

At any rate, I think if theres any evidence that the newer versions of sauer do not create these "corrupted ents", I would like to fix the map and forget about this....it makes me nervous knowing theres a bug in my map :)

reply to this message

   Board Index