Did you ever though about this idea ? The engine of minecraft could help for this I guess.
Quote from: rex4 on July 18, 2011, 06:03:37 AM
Did you ever though about this idea ? The engine of minecraft could help for this I guess.
yes, no, the minecraft engine is designed to play minecraft (a sort of FPS game), CW is nothing like that
yes, yes a lot of people have thought about this, however, when you notice that we still only have two different 2d views, it may tell you that we do not yet have the processing capabilities to support such a thing. And while it may be possible to make a creeper simulation with the minecraft engine, Considering how laggy the minecraft engine is already, I imagine it would not work.
Roccologic tried to make a 3D Map (http://knucklecracker.com/creeperworld/mapcomments.php?id=1927&page=) :)
I was thinking about this too
the minecraft engine (srry if im wrong just played demo) looks like it could work but first it would need lots of changes to fix lag, the view on map.
but that will most likely not happen.
another idea I had is combine cw 1 and 2 together like... you see the world as a cube and you get attacked by creeper on the surface and from under the ground
The problem with a 3D CW is not that it would be impossible, but that the sheer amount of computation that would be needed to simulate so many cells of creeper makes it technologically infeasible for the time being. Imagine it as simulating a large number of CW2 screens that have been "stacked," and increasing the amount of computation for each one by 50%. Just one screen cause cause lag on some computers. Dozens of them will bring the greatest computers of the age to their knees, so to speak.
omg my poor pc cant take that
omg and I cant take not playing the latest cw
so I would die so keep it 2d
Not only that, but it would have to calculate for creeper flowing between these extra "screens" so it'd be way too much.. Right now. We need future computers for cw3d... But for now, what if the graphics quality were decreased?
Quote from: Ebon_Heart on July 18, 2011, 12:56:39 PM
Not only that, but it would have to calculate for creeper flowing between these extra "screens"
Already mentioned in my post... :P
Quote from: mthw2vc on July 18, 2011, 10:40:58 AM
and increasing the amount of computation for each one by 50%
Meh. What if graphic quality were decreased, along with some other changes to make it more computer friendly??
Believe me, graphics are the least of your worries if you're thinking about CW3D, and even those could be problematic. It's a bit hard to show where a subterranean cavity with creeper in it is in 3D... A moveable camera and semitransparent terrain and creeper would all be needed, as well as 3D unit models and textures...
Every time the creeper array updated, it would mean an absolute minimum of a million or so calculations. The CPU load would be insane. I imagine that much of the work that would need to be put into it would simply be optimizations on that process.
Let's just leave it at: It's a mess.
It would be indeed... and don't forget to mention controls. How do you define where you want a unit to go when dealing with a third coordinate?? The best way I could think of would be having to type in the x,y, and z coordinate for each movement.
I saw Harry Potter and the Deathly Hollows in 3D.
3D makes things bad.
No to 3D CW. Any related ideas should be taboo.
Quote from: Kamron3 on July 18, 2011, 07:08:39 PM
I saw Harry Potter and the Deathly Hollows in 3D.
3D makes things bad.
No to 3D CW. Any related ideas should be taboo.
I totally agree...
I always thought if the first Creeper World was remade with 2.5 D graphics. The game would still be in a top down view but the terrain would have more depth, while the in game objects would be three dimensional models instead of sprites.
The creeper would be more "rounded" instead of squared cells. You would be able to see it flow over and bury your structures and weapons and watch them crumble.
As for a 3D creeper world, the idea of seeing an unstoppable wall of creeper blot out the sunlight as it devours your structures would be cool, but we do not have the technology to run something like that.
Quote from: TonyP2000 on July 19, 2011, 05:07:55 PM
I always thought if the first Creeper World was remade with 2.5 D graphics. The game would still be in a top down view but the terrain would have more depth, while the in game objects would be three dimensional models instead of sprites.
The creeper would be more "rounded" instead of squared cells. You would be able to see it flow over and bury your structures and weapons and watch them crumble.
As for a 3D creeper world, the idea of seeing an unstoppable wall of creeper blot out the sunlight as it devours your structures would be cool, but we do not have the technology to run something like that.
Yet... So for now, we have to use our imaginations.
how about CW3 is 4D!
I read a few people who suggest CW3D and i see people for and against. The main reason that comes up is
if you make it 3D you lose one aspect that makes CW so great, the ease of it to play.
As for it not being posible/comps would die etc. That is not the concern, comps can quite easily handel it
its just finding a programmer who got the time as it is quite complex to program such to work efficently.
The calculations for the creeper flow would actualy be very very similar to how it is currently in CW, making
it 3D dont change that. The render of the creeper is where it is dependent on how much it would take/complexity.
Ok, now the techy computer jargen bit to explain.......
The creeper would simply be a 2 demensional array of a struct holding the height/volume within each area of terrain.
Like CW you could split each terrain further down which on a terrain 60-60 which i belive is similar sized grid
for CW you could split that by 5 and would only be looking at 90,000 crepper structs to deal with.
Ok that sounds like a lot, but if you say a model for a building is 1k+ polys, that only like 90 units on screen/across
the map in an RTS, and with animations etc the calculations are quite a lot more. Also the creeper would not need to
spread each frame, so sepearating update of each area could be split across frames which would be the case anyway
to slow the creeper down.
As for the drawing of the creeper, the bulk/central areas would be easy enough done altering the alpha lvl of the
texture in comparison to its depth. The edges is where it a little trickyer. You could use simple squred cells in same
way CW manages it, or could calculate averages along edge to give a more round feel. Other alternative which is
way i would do it is if the particle is on the outside of the creeper place a simple particle effect moving outwards. This
would hide the edges in a nice effect which if done right would make it look like it was pushing forward violently.
......... ok people who made it this far well done :P I try to keep it as simple as I can.
Hope this clears up some misconseptions.
Grun
Guess my tech speek scared everyone off :P
Well I probably put a little too much thought into it that I should, but curiosity and the challenge beat me so.......
http://www.youtube.com/watch?v=Ns8g9r69hkw&feature=youtube_gdata
It not great but a start and shows what is posible. It based on an old framework I made in openGL and simple model loader for the emmiters. Apart from that it all what i tryed to explain in previous post. There a few bugs in the way is spreads etc.
One thing to note which isnt very clear on the video is the average FPS counter stays around 50 FPS. I could get that a lot higher through optomising the code etc, and the video was taken with the compiler it was written in open, Fraps, Photoshop, 3dsMax, Milkshape, about 100 web pages :P and most importantly CW2 running in background, so think you get the idea.
In relation to my amazing super awseome video editing skills, not need to discuss such, I know how good such is :P
Grun
That just looks like you made a 3d model for the emitter, and made a plane onto which you spawn the creeper, which still seems 2d/flat. 3d creeper should add up to form like a wave or hills of fluid ;)
Can make another vid when back on my other comp which I use to make such, the creeper has height, camera angle it set at is what i use for other fps games i worked on. Yes the emmiter is a simple model i put together in like 2 min :P The terrain is not actualy a plain it a triangle strip which maps from a height map. Not included hills etc as this was more a deomnstration to show it is posible etc. and not done calcs for change in terrain etc.
The idea that it a wave etc, well way it works is the emmitter keeps adding at there posistion and as that position grows in height, and yes that height is shown in 3d, it compares to the surronding area and increases height around while reducing itself for equal ammount.
As I say, there was not intention to do such apart from the amount of people saying it couldnt be done.
Grun
Quote from: Grun on July 23, 2011, 04:35:49 PM
Can make another vid when back on my other comp which I use to make such, the creeper has height, camera angle it set at is what i use for other fps games i worked on. Yes the emmiter is a simple model i put together in like 2 min :P The terrain is not actualy a plain it a triangle strip which maps from a height map. Not included hills etc as this was more a deomnstration to show it is posible etc. and not done calcs for change in terrain etc.
The idea that it a wave etc, well way it works is the emmitter keeps adding at there posistion and as that position grows in height, and yes that height is shown in 3d, it compares to the surronding area and increases height around while reducing itself for equal ammount.
As I say, there was not intention to do such apart from the amount of people saying it couldnt be done.
Grun
Holy crap Grun!!! That's amazing!
I still say no to a 3D CW.
I'm getting convinced, that looks awesome!
(http://i1214.photobucket.com/albums/cc497/Grunalin/showingheight.jpg)
Sry for delay, been little busy over weekend, but screenshot taken from lower camera angle showing that the creeper actualy has and displays the height in 3d enviroment. Also I dropped the Emitter on the right side down to the surface hoping to show the transparancy but it not that clear in pic as creeper quite dense by time i ajusted the camera. Guess a pause/speed option would be nice :P
Since making a lot of this have thought of better way to render it, which should look better and improve performance. If I get chance will have a look at changing such. Also another problem with it in its current state is the creeper seems to act more like sand rather than a liquid :P so it piles up rather than spreads.
Grun
well, how you do that depends on how you store your camera angle (X,Y,Z is much easier to code than Xtilt, Ytilt, Ztilt (though both are possible (seperately or simultaneously)))
although, the flow algorithim could be a little easier
The posistion and tilt for the carmera are all stored within a Matrix. The Matrix is the manipulated and altered currently with the position altered by moving the mouse to the edge of the screen and number pad to zoom in and out (would change to mouse wheel).
Grun
For the interested, this is a quick explanantion of how such works, again very boring to some.
The camera is made up of multiple classes which all inherite of a single base class. The base class holds the matrix and a virtual update function. Each class handels a diffrent calculation to be made to the camera Matrix, this way the code for zoom, X/Y (well X Z it happens to be but everyone thinks in terms of X Y) and any tilt can all be done seperatly. Then once all calculations done the Matrix is then passed to the main class to be passed to and openGL camera which is how its all displayed. Reason I done in such way is the camera can be switched to be used in other games/programs, such the zoom can be used in an FPS for scope site etc.
Now there's still the matter of calculating for large chunks of the creeper being destroyed by blasters and launchers and the likes... as well as the issue of unit controls in a 3d environment.
This may be helpful in determining how to simulate the creeper better
http://knucklecracker.com/forums/index.php?topic=304.0
that makes this pretty obvious
Cells:
ABC
DEF
GHI
Cell E creeper = (B+D+F+H)/4
OMG ty Ranak, that is great help, that one big thing i spent ages trying to get sorted. Will read through adn do some calculations and make chages here and there. Have decided that im going to change the render method from making each cell a cube which set its height from such calculations to a group of triangles which durve around to such heights to smooth things out. Will make all the changes in 1 go i guess.
Ebon as for weapon dmg. It is actualy a lot easyer than most things are. It simply determin what creeper in range and then select which to target, so nearest for blaster, highest density/height for mortor. Then after whatever animation/projectile you want hits reduce the height of the creeper cell by a set amount or reduce to nothing.
Now unit placement, this could be done simply by doing a thing called a ray trace. This basicly means firing and invisiable line from the mouse pointer into the screen and finding what position on the terrain it hits. As the terrain i use is based on a height map this could return the nearest point of the triangle strip, so could work very similar to the way CW works where you build in set positions based on a grid. Think to make easyer with such being on a 3D basis would have to have option to show a semi transparent outline of the grid to make easyer.
Guess if Virgil ever did make a 3D version of CW, I hope this topic may help a little about some of the methods posible to do somethings.
Any more problems people can think off, as im sure any programmer will tell you, this is the enjoyment of proggraming, it not the actual coding of such, it working out how to do it. That what 99% of prgramming is, problem solving :P (well that and syntax checking/run time errors and logic errors probably take up about 30% so say 69% problem solving :) )
Grun
thhhhrrreeeeee-dddddeeeee! :D
Pretty cool simulation if you ask me.
Ground = G
Creeper = C
Emitter = E
BEB
BBBBBBB
GGGGGGGG
Like MY simulation? :P
What you have shown thus far demonstrates nothing I consider infeasible. You are only doing calculations based on depth. In effect, it is a fancy 3D rendering of CW1 using a language that can handle a 3D display in an efficient manner. (Realize that under normal conditions, about three fourths of CW1's processor load comes from rendering it.) What then about underground creeper, or creeper floating in midair? To do that, you need to further your cellular automata based on density at each cell in a 3D lattice for numerous layers, vastly increasing the amount of computation that goes into running the creeper itself. Then, how do you deal with displaying subterranean chambers? How do you allow the user control of midair weapons in a practical fashion?
ok I asked for that Mthw2vc, I should sit in a croner now :P
lets see, for underground creeper I would not be able to use a height map for the reson the main limitation of using such it is unable to creater caverns, caves or over hangs, you would be looking at modeling the entire scene. But as it is, im basing on the current mechanics of CW1. As for how to sort the creeper for underground if the terrain wasnt a limiting factor you would be looking at a particle engine along with some rearly rearly mad phsics engine which as a solo programmer I am is a little out of the question.
So the last point, midair weapons, if you mean such as selecting a unit which has taken off to be moved, again through a simple ray trace, for placement of a flying unit which reamins in the air which is not in CW, for it to be done in and RTS fashion you would still place such a unit based on a XY baisis but display a unit on an increased Z axis for placement. I think I would show a simple shadow or selection indicator on the ground to show where the unit would be in relation to the rest of the scene.
One thing from your post though I had not thought of was the selection of units as they act in CW1, that being a unit that is in mid air, which would have been a big oversite.
I will keep at this, as one it testing me which is always great, there seems interest, and i soon got a lot of time off work, getting married, hunny moon then 2 weeks after off work also :) so dont think I can do on first half of work break, but latter half I may have quite a bit off free time.
Grun
ya'know, I really like your simulations, even though it's probably just a fantasy :(
3D does sound pretty cool, though. It would be fun to try. ;)
ok quick update, introduced terrain changes which the creeper works around. But still trying to get the creeper to spread right, spent about 3 hours writing code to realise i had done nothing :( In link Ranak gave it mentions other posts which talks abour the calculation of the spread, would ask Virgil but dont want to stop him working on next update for CW2 :P so anyone remeber anymore about the calculations for the creeper. I looked a lot into heat transfer physics etc but my physics a little rusty :P
Thanks
Grun
ohhh also nearly forgot, just finished putting together a quick model for what a blaster may look like in 3d, will try and get that includeded aswell once i sort spread problem out
also.....
Rex4, sry for hijacking your topic for such although i guess it is sort of relevent, thought i should add this even though Rex4 has only this one post he may still read a lot up on CW forums
Quote from: Grun on July 28, 2011, 07:43:59 PM
Rex4, sry for hijacking your topic for such although i guess it is sort of relevent, thought i should add this even though Rex4 has only this one post he may still read a lot up on CW forums
It's not hijacking, it's totally about the topic.
Wow Grun, I really liked your simulations... and your still working? COOL. :D
Well yes, im like a dog with a bone :P just ready to through pc out of window with the calcs for spread of creeper :P
Think i got it, depending on how drunk i get tommorow on my stag do :P may try and get an update done on Sunday showing the new creeper render, no squares this time :P and also added a height map showing changes in terrain. oh also the spread should be sorted, and if you very very lucky and I may introduce a blaster to the mix :P
or..... I get very very drunk and make muself ill all day Sunday :P
Grun
also nearly forgot, got FPS up to above 200 on my system rather than the 50ish i belive it was in last vid.
IMO it would be better to first simulate 2d creeper, just displaying it in 3d (height and terrain height) which on it's own would be quite an achievement. Then, After that is done try to figure out a way to simulate an actual 3d creeper and then display it in 3d.
You would think Ranak, but the display side is easy enough and already written yo work out such.
The calcs are the same for both 2d and 3d there after.
same as it would be for 2d or 3d, i know height of each area, and can get surrounding areas, it just from that to know how much to pass to each cell.
Tryed a few ways and slowly getting there. If only i had the source code of CW......... :P
Grun
sry guys for lack up update on this, been very very busy planning for wedding, only 5 days to go till the big day :)
But coz of that, I finish work today so got a couple of free days all going well. Been working on a few small areas and now putting the lot together.
Have now introduced code for height maps, ignore the texture for it but here we go...
(http://i1214.photobucket.com/albums/cc497/Grunalin/OpenGl_Framework2011-08-0912-53-49-862.jpg)
A very basic lay out for terrain I know, but it works well for testing the way the creeper spreads in like a canyon. And as you can see wtill keeping the fps pretty high, again you dont want to know how many things running in the background when ss was taken :P
Worked out the probs I was having with creeper, just need to ajust timers etc so will introduce that to the terrain, and the final part is I have put together a simple blaster model which is able to attack the creeper, well sort of no animation/graphic to show the projectile just yet.
Hopefully upload a vid showing all this tommorow if I come across no probs.
Grun
ok just the screenshot of the heightmap is pretty dull I know, so.......
http://www.youtube.com/watch?v=COsIDNSrRjI
what you guys think?
Few points as noted on video description...
Terrain texture needs replacing, easy job to sort just being lazy and current texture is clear to see what creeper doing.
The emmiter is causing weird spike whenever it adds more creeper
Some clipping on terrain when creeper making its way over the edge of cliff.
Well after them small bugs I guess the blaster has to be next :)
Grun
Holy crap Grun! I can't wait to see this with weapons attacking the creeper. How long did all this take you?? (btw, 2nd Creeper World 3d demp? lol.) It's a small detail, sure, but it still made me laugh. :P
EDIT: congratz on the upcoming wedding. (just read your first post) You know you can wait to do this until after the big day. I'm sure the videogame world can wait a while.
Quote from: Grun on August 09, 2011, 10:25:13 AM
what you guys think?
Nice! Looks promising....
Looking forward to see more later on, but please enjoy your wedding first!
Wow...Amazing. This would be fun to try, if it actually was a game, instead of an awesome simulation! :D
PS: Enjoy wedding!
ty guys for support for wedding, looking forward to it :)
Ebon as for speeling error :P will change, although....... yeah should change it
As for how long its taken, it hard to say. Actualy sat in front of a comp, the current creeper flow code took about 2-3 hrs programming, but it is the th or 5th time i written to get it to what it is. The camera/terrain/model loader I already had written from a prev project but needed a little bit of cleaning up, it was very very old code i wrote and was full of bugs/memory leaks. The largest amount of time spent on it is thinking about how to go about it, normaly when im driving to work, it funny sometimes on way to work I suddenly think ahhh this could work, I get to work and write it all down to try when I get home.
Anyone whoever programs will know what its like, you come across a prob or somthing not working you can spend days thinking about it and suddenly an idea pops in your head and it sorted. I never seem to work out the probs, well logic probs, while sat at my comp.
Grun
ohhh also, as for getting a blaster in, I got a lot of time befor wedding, me and misses are very organised and got everything in place, so hopefully can get something done and recorded.
I'm no expert here, obviously, but shouldn't you, you know, be spending time with your wife-to-be or something? lol. Or maybe planning a bachelor party? :P
stag doo :) or bacholor party was other weekend, if you look back was planning to get todays update out then, but beer got in the way :P as for misses, we been together 6 years and she busy getting spray tan/nails done/other girly stuffs :P so I got a little time :)
I have already got a model almost done, so only about 4-5 hrs worth to get it working, and about 20 min for creating vid/uploading (my vid skills are very very basic as you guys already know :P )
Grun
Very neat work Grun... I wish I could force myself to be consistently working on the same project for longer; the results are that much better.
In the unlikely event that you have time to spare, and in the case you like a mix of programming and mathematics, be sure to check out http://projecteuler.net (http://projecteuler.net). It provides exactly that.
Lastly, congrats on your wedding. Good to see that at least some of us have a life :)
I used to have a life, but I sold it to buy creeper world. (epic quote from mthw2vc)
Quote from: Grun on August 09, 2011, 10:25:13 AM
ok just the screenshot of the heightmap is pretty dull I know, so.......
http://www.youtube.com/watch?v=COsIDNSrRjI
what you guys think?
Few points as noted on video description...
Terrain texture needs replacing, easy job to sort just being lazy and current texture is clear to see what creeper doing.
The emmiter is causing weird spike whenever it adds more creeper
Some clipping on terrain when creeper making its way over the edge of cliff.
Well after them small bugs I guess the blaster has to be next :)
Grun
(ripped from my youtube comment on it)
The weird spike is in the game BTW Basically, If you were to open CW1, and hover your cursor over the Emitter, you would see the spike each time it pulsed, so If I did not see that spike, I would know you made a mistake somehow. I do however agree that it doesn't look that good, but I don't know how to *fix* it, unless you were to render the height there differently from how you do elsewhere. (possible use the average height++ of nearby cells?
Quote from: Lord_Farin on August 09, 2011, 06:36:34 PM
In the unlikely event that you have time to spare, and in the case you like a mix of programming and mathematics, be sure to check out http://projecteuler.net (http://projecteuler.net). It provides exactly that.
I used to work on that, But I only got to I think problem 50 before I got stuck. Maybe my skills have increased to the point I can continue. who knows...
You know Grun, You could probably make a new thread to discuss this specifically... Although the rest of the thread seem like it would be dead otherwise, So I am not sure...
Lord checked out the site you given, it is a very very good site for anyone who wants to get into programming, i have covered a lot of such already but always good to look at chalanges i may have missed/got rusty on, as for setting up a seperate thread, yes I could but think this thread is still relevent, think if i ever got carried away enough to implement a UI etc I would :)
Rank in relation to the spike/emmiter, i agree, it good to see that the emmiter haveing an effect, i think the options would be slow the pulse speed but that would mean increasing the spike height, or to add a model/animation to the emiiter which I think would be best way, similar to the way first vid it was a constant stream from the emmiter, although looking back at first vid, dam that looked rearly bad :P
Grun
Quote from: Ebon Heart on August 09, 2011, 10:58:08 AM
I'm sure the videogame world can wait a while.
since when do gamers have patience?
Quote from: crazyone76 on August 10, 2011, 09:07:46 AM
Quote from: Ebon Heart on August 09, 2011, 10:58:08 AM
I'm sure the videogame world can wait a while.
since when do gamers have patience?
Maybe we don't... bug computers do. :P How else do you explain loading bars?
Off-topic alert. Get this back on track or it gets locked.
Alright, back on topic... If the simulation were allowed to continue indefinately, would the creeper ever be able to rise above that spike? I presume I works like cw1 did, right?
Quote from: Grauniad on August 10, 2011, 01:07:00 PM
Off-topic alert. Get this back on track or it gets locked.
Quote from: Grun on August 09, 2011, 09:11:07 PM
as for setting up a seperate thread, yes I could but think this thread is still relevent, think if i ever got carried away enough to implement a UI etc I would :)
maybe split the thread ?
Quote from: Ebon Heart on August 10, 2011, 01:25:54 PM
Alright, back on topic... If the simulation were allowed to continue indefinately, would the creeper ever be able to rise above that spike? I presume I works like cw1 did, right?
I'm assuming that intensity = height of emitter
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.
Quote from: Ebon Heart on August 10, 2011, 01:31:15 PM
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.
(http://i1214.photobucket.com/albums/cc497/Grunalin/showingheight.jpg)
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......
(http://i1214.photobucket.com/albums/cc497/Grunalin/blasterpic.jpg)
im no artist :P
Grun
Quote from: Grun on August 10, 2011, 05:23:03 PM
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)
Next you should add styglek interference. :P
Quote from: Grun on August 10, 2011, 05:23:03 PM
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.
Quote from: Grun on August 10, 2011, 05:23:03 PM
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.
Quote from: Grun on August 10, 2011, 05:23:03 PM
As for a blaster, model complete although just used a simple texture so dont look to good......
im no artist :P
Grun
Nicely done!
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.
Quote from: Grauniad on August 10, 2011, 05:56:01 PM
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).
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
Quote from: Grun on August 11, 2011, 04:04:24 AM
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... ;)
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
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
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.
Quote from: Ranakastrasz on August 23, 2011, 11:29:37 AM
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 :)
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