Creeper world 3D

[thepenguin]

I think think the intensity is more related to the height of the spike... It seems like all the emitters with his simulations are automatically the same height.

[Grun]

Well I think ss thepenguin put shows that the actual Emmiter model has no effect, it just visual :) I would add the code to the emmiter class to tell the creeper what to do. The way its working is it adds a set value to the creeper at the point and set time intivals, so say every 0.1 seconds, had to do on time as the frame rate is not constant. I think a solution to the weird spike would be to add every frame but calculate the ammount based on time, so rather than add 1 every second, divide that by current frame rate and add each frame, will smoth things out nicly, will just have to check the hit in performance.

As for letting the sim run indeffently, it would continue to grow indefently but I have put cap on max height based on the max height the terrain is. What happens if the sim runs for a period is the whole terrain is flooded and the creeper becomes a flat surface not moving at all. Currently it takes about 3-4 min for the whole area I made to get flooded of a single emmiter.

As for a blaster, model complete although just used a simple texture so dont look to good......



im no artist :P

Grun

[UpperKEES]

As for a blaster, model complete although just used a simple texture so dont look to good......

Wow! More than good enough for now....

Keep going!  8)

[Ebon Heart]

Next you should add styglek interference. :P

[Ranakastrasz]

Well I think ss thepenguin put shows that the actual Emmiter model has no effect, it just visual :) I would add the code to the emmiter class to tell the creeper what to do. The way its working is it adds a set value to the creeper at the point and set time intivals, so say every 0.1 seconds, had to do on time as the frame rate is not constant. I think a solution to the weird spike would be to add every frame but calculate the ammount based on time, so rather than add 1 every second, divide that by current frame rate and add each frame, will smoth things out nicly, will just have to check the hit in performance.

I suggest however that you make emmiters at that same height.
Also, you have a error in your mechanics, the creeper is supposed to be set to the intensity of the emmiter, not added, unless you are simulating cw2, which it looks like cw1 currently. And while you could fix it based on making it emmit every frame, it would not be using the same mechanics as cw1 or 2 does.

As for letting the sim run indeffently, it would continue to grow indefently but I have put cap on max height based on the max height the terrain is. What happens if the sim runs for a period is the whole terrain is flooded and the creeper becomes a flat surface not moving at all. Currently it takes about 3-4 min for the whole area I made to get flooded of a single emmiter.

Yep, definitely does not work like cw1, It should cap out at the highest Height+magnitude of an emmiter.

As for a blaster, model complete although just used a simple texture so dont look to good......

im no artist :P

Grun

Nicely done!

[Grauniad]

Bear in mind that frame-based actions are kinder to people on slower computers. Time-based actions can have varying results on different powered computers. The Creeper World maps (as well as many other games) are frame-based. So if the calculations in a frame is to omuch to handle, the game slows down, but everyone gets the same end result.

[Ranakastrasz]

Bear in mind that frame-based actions are kinder to people on slower computers. Time-based actions can have varying results on different powered computers. The Creeper World maps (as well as many other games) are frame-based. So if the calculations in a frame is to omuch to handle, the game slows down, but everyone gets the same end result.

Too true. I think frame-based actions are always required for everything that is not local (in multiplayer, but similar to singleplayer nonetheless) (graphics and sounds are local, creeper spread is not).

[Grun]

In order to do the calculations you need to consider both time and frame rate. All calculations done are based on time between frames. As the frame rate is not constant unliike CW is (30 fps i belive) I am unable to say do something every x no. of frames as the speed of the comp would effect the speed of the program. The way it works currently is a variable which adds the amount of time since the last frame, then each frame it checks if it above a certain threshold, if it is it recues the variable by that threshold and fires of the code to update the creeper/emmiter. This way if I say update every 10th of a sec it will do at same real time intivals if FPS is at 10 or 100, it would only be an issue if less than 10 but with way I manage each aspect currently it would run on low end machines at 50+ fps, tested it on a duel core laptop which is about 8 years old.

As for the emmiter adding rather than set intensity, it a little bit of a work around as such by just adding but the amount it actualy adds is higher than the current max height so it works such as intensity would. Advantage of adding is it easy computations when looking at blaster/mortor damage at the location of the creeper. Think I will alter it slightly for the emmiter to constantly try and maintain at set height every frame which will keep the same apperance but without the spike flashing/bouncing as much.

Made a few changes in relation to how it works with the emmiters aswell, the model of the emmiter has further code added to it such that I can set the intensity/delay (bettween updates and for start) which automaticly calcs where it is in relation to the creeper field. Dont add anything in realation to performance or visualy, just tidyer way of programming so I can say I want an Emmiter at loc x,y with strength z and rest is done.

Grun

ohhh almost forgot, Ebon made the most important update, It no longer a demp :P

[mthw2vc]

In order to do the calculations you need to consider both time and frame rate. All calculations done are based on time between frames. As the frame rate is not constant unliike CW is (36 fps i belive) I am unable to say do something every x no. of frames as the speed of the comp would effect the speed of the program.

Yes, but without making it frame-based, the speed of the computer will affect the output of the simulation... The solution to this dilemma is making the in-game timer based on frames and not actual time while capping the framerate at a certain value on any computer that can handle running the simulation that quickly. Oh wait... ;)

[Grun]

Dont think I explained myself too well, basicly as long as the frame rate is faster than the shortest update intaval, say every 10th of a sec then it not an issue. Then again a comp which couldnt handle it current at 10fps wouldnt be ablet to run very much and would strugle with even the most basic of programs. To give you idea of how im doing such but obviusly would change here is sort of like a little of the code...

void Creeper::update(float time) //where time is time since last frame so 0.1 if 10fps or 0.01 if 100 fps etc
{
       timer += time; //add the time since last frame to timer
       if (timer < updateTime) //if not been long enough
              break; //dosnt update anything
       timer -= updateTime //if very very small time intivals can change to make = 0
       
      //update creeper code here
}

so as you see it wont matter on what the fps is as long as it faster than the time intervals between events, say how often the creeper spreads which i think at moment is about 20 times a second, or the fire rate of a blaster, the code is pretty much the same. This function is in each aspect of the program, so the creeper, the blaster even the camera. For anyone who knows a little programing can probably guess each class inherits of a base class which has a virtual update function (and render function if it to be rendered) so to update everything it just iterates through a vector of componenents each frame. It a very easy structure to work with.
The other option I could use would be rather than have it update a set intervals would be to use the time value as a scaler for all other values to be passed..(more code for people who didnt tl;dr :P )

void Creeper::update(float time)
{
      float creeperAdd; //amount of creeper to be added per sec
      creeper.add(creeperAdd*time, posX, poY); //call a 2nd funtion which adds creeper and position x/y
}

This also would work the same on all comps and would not matter if even 1 fps, but problem with doing this way is the update is done everyframe adding a large performance hit lowering overall fps.

Although this has not been biggest problem, I underestimated the range of blasters and now needing to think of a method to do the vast calculations for such, been able to get it working but the range is about 1/2 what needed and increasing the range will increase calcs deom 13 to 61 per blaster per frame, again could put delays so only checks based on frame or time but that introduces other probs. Sure I will work out and will try and post a vid even if unfinished befor I go away on honeymoon :)

ohhh almost forgot as for capping framerate for high end pcs, there little need for unless the speed between frames was very very small to the extent I would need to change my float values to doubles for added accuracy, but that would be insane FPS. Another advantage of doing such is for assuring if background prgrams running the program would not take up all resources but at moment it only runs on 1 core so high end quad cores would not have this prob either.

ty for support guys, amazed of how much of a challange this is and real test of efficent programming.

Grun
       

[Grun]

Well been a nice break and im back from honeymoon, was great.

But anyways update of what i been able to do....

got the blaster model now targeting creeper and ajusting and the turrent altering position to show such. Created a blast model effect and just in process of rendering such in correct position at correct timings etc.

Will get another vid once all sorted although the calculations are quite complex for all this lot to keep the fps to an acceptable level and with all the new CW2 maps Im getting easily distracted :)

Grun

[Ranakastrasz]

I'm pretty sure that Floats are slower than doubles, but doubles use more memory, because Floats are converted into doubles when doing any math, and then converted back to floats to be stored. However, doubles are larger. I don't know if this applies to anything other than C++ tho, so I am unsure if it would apply.

[Lord_Farin]

I'm pretty sure that Floats are slower than doubles, but doubles use more memory, because Floats are converted into doubles when doing any math, and then converted back to floats to be stored. However, doubles are larger. I don't know if this applies to anything other than C++ tho, so I am unsure if it would apply.

If it would apply, then doubles would be the way, as I think the bottleneck for fps will not be available memory  :)

[Grun]

Ranak you are sort of right, it depends on which lib's you use to do your maths. I guess you talking about using std:maths which I belive deals in doubles for all non int values but been a while I used such with the exception of for trig which I do use doubles. I use a maths lib that I had about for quite a while which aslong as you tell the function that you dealing with 2 floats it wont convert so using less memory and quicker processing. The reason I use custom lib's rather than std stuffs etc is to make it easy to port to other platforms although still use quite a lot of windows lib's which I slowly need to rewrite/get others etc.

Grun