Latest revision bugs

Post by **Zefz** » Tue Nov 03, 2009 2:04 pm

I am almost finished with the next Imprisoned One module. There are a couple of bugs that need to be looked at:

- Particles spawn in the wrong Z direction
- Particle size increase is wrong
- Fix particle transparency for particles that change size
- Fix squares under particle reflections
- Some funky physics effects when hitting and killing stuff

The top two is most important imo, as they are most annoying to see in-game. We still havent updated Egoboo and who knows how many months behind the release schedule we are

Post by **bgbirdsey** » Tue Nov 03, 2009 4:12 pm

- Arrows need to stick into objects and continue to do damage. The particle attachment is not working properly. I had this working for a while, but I'm sure it caused some other bug...

Some quirky code has caused a lot of odd things.

I would really like it if particles could bounce off of columns just as they do walls. That would be great! But if you try to implement bouncing off of scenery objects then the crates in th wizard starter with the gonne powder won't explode because the particles bounce off the crates, too...
There are lots of other issues with attaching bump particles, too, like the fact that books will burn up even if the fire particles that try to attach to them do no damage... But this means that bump particle attachment basically has been turned off forever, and turning it back on causes problems...

sigh...

- Some funky physics effects when hitting and killing stuff

I think this is because the damage particles are not being poofed properly when they hit. So, they are doing lots more damage and pushing more than intended.

---------------------------------

Yeah.... weren't you pushing for a Christmas release last year?

As soon as I can get EgoMap up and running again I will work hard to kill bugs!

Cimeries · Post by **Cimeries** » Fri Nov 06, 2009 6:32 pm

Hmm, everything seems to be sinking into the floor a little. Something with Z detection, I assume.

Post by **Zefz** » Fri Nov 06, 2009 7:39 pm

Yeah I reported that a bit earlier... Birdsey removed that every object was floating 20 points above ground, but that seemed to be a bit much.

Post by **bgbirdsey** » Fri Nov 06, 2009 8:14 pm

that is on the to-do list, along with fixing the particles!

Post by **bgbirdsey** » Thu Nov 12, 2009 3:18 am

there is a pretty serious problem with the number of particles being generated by the varguiles and the protectors in the imprisoned1 module.

I upped the number of particles to 8192, and by update 75, the particles had overrun the entire 6200 normal particle slots. I don't know what the particle limit would have to be to not have a problem.

There are lots of problems with running out of particle slots. In principle particles like weapon damage are supposed to be marked with "force" so they can use the 1/4 of the slots that are reserved for necessary particles, but I don't think all of them are. For instance, I was having a problem making the gonne work properly.

Also, there are some list-management issues. Not really a problem in the non-debug mode, but in debug there is some code that makes sure that the same particle is not being freed twice. That gets pretty sloppy when the particles are almost all used up.

Post by **Zefz** » Thu Nov 12, 2009 3:24 pm

I added a fix a few revisions ago that reduced the number of particles spawned by Protectors, Braziers and Vargouilles by 2/3. They should not use more than 5-15 particle slots each or so. I think one of the reasons of this problem is caused by particles not despawning.
- I see many weather particles that hit the ground and stay there.
- When I catch on fire and the attached particles end, they still stay in the air forever. Still dealing damage if you touch them.
- There seems to be a problem with the spawning rate. Particles spawn faster than before (particles that spawn other particles over time). This is really apparent in particle trails such as the missile spell or the confusion ray of the Brain Scramblers.

The fast spawning particle bug was not here before. Maybe it got introduced when I merged various for loops in update_all_particles()?

Post by **bgbirdsey** » Thu Nov 12, 2009 5:56 pm

The fast spawning particle bug was not here before. Maybe it got introduced when I merged various for loops in update_all_particles()?

This could be. It seems that some of the particles were going bonkers in the "imprisoned one" , including the fire and smoke from the braziers.

Here it the problem

Code: Select all

// the following functions should not be done the first time through the update loop
if( 0 == clock_wld ) return;

this is inside the loop. There line was in the original code because the functions below it were not supposed to happen the 1st time through the game loop.

Post by **Zefz** » Fri Nov 13, 2009 12:59 am

I have confirmed that merging the 4 or so loops was the cause of this bug. Reverting to particle.c from revision 909 seemed to fix the problem. I am trying to track down the exact cause of this bug now...

Code: Select all

// the following functions should not be done the first time through the update loop
if( 0 == clock_wld ) return;

Hmm. I see the problem where it breaks out of the loop and skips the rest of the particles on the first frame, but that should still not cause the out of control spawning and size change. Simply changing the code to:

Code: Select all

// the following functions should not be done the first time through the update loop
if( 0 == clock_wld ) continue;

should fix the problem you pointed out above.

Post by **Zefz** » Fri Nov 13, 2009 1:20 am

Lol! I found the error and fixed it. Try the new revision and check out if you still have any problems with The Imprisoned One.

[edit]Umm, okay I just saw your latest revision. I was working towards merging the unnecessary many loops and you work with splitting them up

Check out my version of particle.c. I myself find it much more organized and mainly because it is optimized. And now it works too![/edit]

Post by **bgbirdsey** » Fri Nov 13, 2009 2:27 am

OMG! Changing a loop control variable inside the loop???? Impossible to catch and very nasty...

--------------------------

The code is now not working properly, again.

There was a problem with particles with short lifetimes not being displayed properly. Since the update rate is faster than the frame rate, certain particles with a 1 update lifetime (like the charging particles for the missile spell) were creating a weird/annoying flickering.

To fix this, I created another state (a "limbo" state) for the particle where it would be drawn but would not interact with anything in the game or create any particles after it is supposed to already be dead.

The statement

Code: Select all

if ( !ACTIVE_PRT(particle) ) continue;

actually eliminates updates of the limbo particles and may even prevent them from being drawn since their onwhichfan variable is not being updated.

-------------------------------

Anyway, I wouldn't worry about collapsing loops like this unless the old way was too confusing. The added overhead for 4 loops instead of 2 is practically infinitesimal.

We can gain a lot more by iterating only over the used particles. I added some code to my last commit to actually keep track of what particles, characters, and enchants are still live every update. This could save a significant amount of time.

The macro that is defined at the moment is CHR_BEGIN_LOOP(IT,PTR), which is the beginning of a loop and the CHR_END_LOOP() macro is the end of the loop. The macro parameter IT is would be the variable that replaces cnt in the statement "for(cnt=0; cnt<MAX_CHR;cnt++)" and PTR would be the a valid pointer to the current object.

This whole system would be most useful if the number of used particles/characters/enchants is small. If 100% of the particles were used this system would actually take *more* time, LOL!

----------------------------

In any case, I think we need to worry much more about clarity of code over performance. Except in the graphics/rendering which is taking up the majority of the time.

Post by **Zefz** » Fri Nov 13, 2009 11:33 am

Great

Now that's working as well. Here is my current bug list so far:

- Particles spawn in the wrong Z direction (candles for example)
- Objects are often partly under the mesh now because they no longer float above it.
- Game crashes when using specific texture filter modes and billboards. (Linear and anisotropic works)
- Fix squares around particle reflections.
- Some funky physics effects when hitting and killing stuff.
- Changing max particles while in the game causes all current existing particles to disappear.

Post by **bgbirdsey** » Sat Nov 14, 2009 5:52 am

Particles spawn in the wrong Z direction
Particle size increase is wrong
Fix particle transparency for particles that change size
Fix squares under particle reflections
Some funky physics effects when hitting and killing stuff

I have no idea what is causing the inverted z in the particle spawning. It may just be a display problem.

The squares around the particles are due to the program alpha blending the "light" bitmap. This bitmap has black as the background color and is supposed to be added to the image.

Can you be more specific about "funky". If the attack is particularly powerful, the creature could be bumped quite hard. Is this the funkyness, or something else?

Post by **Zefz** » Sat Nov 14, 2009 8:01 am

It was in the Wizard Starter, where I attacked a Mephit with my staff and he flew all across the room bouncing several times around like a pinball and flying into the air as well.

This was a couple of revisions ago.

Post by **bgbirdsey** » Sat Nov 14, 2009 8:52 am

Yeah. that is less now. Brom can still knock a smack a grub bug around, though!

--------------------------

I found and fixed one of the particle bugs. The "black boxes" are around the reflected particles. They were generated because the particle mesh was writing into the depth buffer and that was messing the drawing.

I think I may have to go back and make sure that I set glDepthMask(GL_FALSE) for all transparent objects. Otherwise you get all kinds of graphics glitches.

It must've appeared after the order of some graphics functions was changed because it never did that when I was working on the particle reflection code.

You have to HATE unstable code!

--------------------------

I think I also fixed another minor problem with the particles. Large particles near the floor were having their floor_level altered so that the particle would rest on the floor. This was messing with the reflections so that both the reflection and the original particle were above the floor.