Sauerbraten - Bug reports

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

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   

#264: Re: Gilt: cube subdivision doesn't work for complicated cas

by Aardappel_ on 07/15/2005 02:58, refers to #257

I am sorry, there is nothing wrong with that screenshot per se. There isn't always a perfect way to subdivide. Sure maybe it can be done better, but it is not a bug at least. There used to be a bug with completely random gaps being generated in unrelated spots, that has been fixed.

reply to this message

#265: Re: Gilt: cube subdivision doesn't work for complicated cas

by enigma_0Z on 07/15/2005 03:33, refers to #264

Oh yeah, I remember that one! That was funny... heh.

reply to this message

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

by Aardappel_ on 07/15/2005 03:55, refers to #256

I just fixed the spawning code somewhat, and now no monsters spawn up in the air anymore.

DMSP requires roomy spawnpoints for the larger monsters, and ksauer1 has only few spawnpoints, most in narrow spots. This is where sauer's emergency spawning routine kicks in, randomly trying to find a spot close by. It does a better job now :)

Looking at the code for lightreaching(), I can't see how part of ray can be NaN. it just computes the distance between a light entity, and a monster in this case. That should be valid even if the monster is way above the level. Eihrul?

reply to this message

#267: Re: Gilt: cube subdivision doesn't work for complicated cas

by kurtis84 on 07/15/2005 04:37, refers to #264

Ok, this latest fix seems to do it fine! I can not only retexture a large slope with a small grid, I can use the small grid to make a small slope right on a large slope! sweet :)

reply to this message

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

by Gilt on 07/15/2005 04:37, refers to #256

there is no ceiling, you're just standing on a solid cube with the skybox texture. you can even try editing it if you want while you're up there!

reply to this message

#269: Hmm...

by Pxtl on 07/15/2005 05:12

I realise it would double the polycount of maps, but would it be more effective to double-subdivide, at least as an option? That is, on each quad, you add a vertex in the middle located at the mean point of the 4 corners and then just split the surface into 4 tris, each try being one edge connected to the center vertex at its ends... that is:

*-*
|X|
*-*

As I said, it would double the polycount, but allow the rendering of such surfaces to be at least consistent, instead of each card deciding on it's own where to put the diagonal in the quad. At least as an option for users with power to spare.

reply to this message

#270: Re: Hmm...

by kurtis84 on 07/16/2005 01:54, refers to #269

I think the problem with subdivision, is theres always going to be that certain combination of shapes that will not work at a smaller size...there would have to be subdivision across the joints between certain cubes to allow EVERY shape. I was experimenting last night to see why I cannot do certain things, and now I can see why. Subedivision isn't always needed to reduce a cube...sometimes it needs to split a cube, then ADD something to a surrounding cube, in order to keep it all smooth every time..and I don't think thats possible for these guys to program.

I'll not mention this...quirk? of sauerbraten anymore...it's just something to deal with, no biggie. If I need those complex shapes, I'll simply subdivide that area myself at a smaller grid.

reply to this message

#271: Re: Hmm...

by Andrew Brault on 07/16/2005 02:05, refers to #270

If you load up the blah.ogz map, turn right about 30' and go inside the "castle" there is a small triangular piece on the floor. Put gridpower down to 2 and tweak the piece and it will be subdivided strangely, kind of "backwards" looking. It is possible to get it to subdivide into a piece with a vertically striped texture (coincident texcoords); if you try to tweak this piece (the pointed-at piece in crash.jpg) sauerbraten will lock up.

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

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

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

reply to this message

#272: Re: Hmm...

by Andrew Brault on 07/16/2005 02:11, refers to #271

BTW, this is with the latest CVS sources (self compiled), x86_64 Fedora Core 3 linux, crappy GeForce card.

reply to this message

#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

   Board Index