Davioware's Forum Posts

  • Scenario mode.. kind of like the event matches in Smash Bros? Their is a minor plot however, If you mean story mode. But there isn't any saving of progress.

  • Underwater.

    <img src="http://dl.dropbox.com/u/1010927/Forumpics/Tcwater2.png">

  • So say your mean is 10, and the sigma is 10 you will get any random number between 10-10, and 10+10....

    Kind of, but sigma is just the width of the bell curve. Specifying 10 doesn't actually mean it will give you a number that's either ten greater or ten less. Here, I made this .cap. A sigma of 4 gives you around about a 32 number deviation from the mean with normally distributed probabilities. Any number is actually possible, but the chance is really small. You should clamp the value if you want it to stay within a certain range.

    Link: http://dl.dropbox.com/u/1010927/Forumpics/normalRandomTest.cap

  • Why do you need loading text exactly?

  • NormalRandom(mean, sigma)

    Generates a random number according to a normal distribution.

    <img src="http://3.bp.blogspot.com/_BoiGN8E7WGw/TLdmU21-oVI/AAAAAAAAAFk/ac1TVK0RdQM/s400/Normal_distribution_and_scales.gif">

    Mean is the number, sigma is the width of the curve/standard deviation.

  • Set the animation frame to 1+random(number of frames in animation), every X milliseconds or ticks.

  • Nice one! But for fog of war an opaque layer (and maybe a PS 0.0 blend mode) with erase objects is probably less gpu hungry. This effect is awesome for lighting effects though, great job.

  • Looks like irbis has yet to learn a fundamental lesson in gamedev: your creativity is held back by system limitations. Sure, who wouldn't like to have huge images not impact performance? It's not that people don't want it. It's that Construct can't do it. It's hardware accelerated. The engine you used in the past, RPVX or whatever it's called, could not do what Construct can, not even close. Construct is very high performance, but you can't use images of any size; that's the price you pay. Get creative and figure out a way around it. All of these old games that you speak of, they weren't created by spoiled developers who had infinite resources like we (practically) do today. If you were to see the things they had to devise and come up with to get around system limitations, you would leave gamedev forever, as it's a pure technical/mathematical/boring nightmare. Consider yourself spoiled that you can waste resources like crazy and get away with it. So what, you can't use a big image for a space scene. Make some starfield textures, rotate them, overlay them, slap on an additive blend mode, adjust the color filter for infinite color variation, and do the same thing with galaxies; you'll have a starfield which is just as nice, or even nicer than a painted one, at a fraction of the resources use, AND you can animate it, change it, do anything to it with events. More work than drawing? Yes, but that's the price you have to pay to make a game. Anyone who makes games does this. Your not going to get your big image support, it's not something that can just be added. If you want to use Construct, then learn to work around it's limitations, which quite frankly, are few and far between.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Construct is not worst right? i am here not to point that Construct is worst then something. I am just saying that if others can why not to make Construct too be able to handle such features?

    I mean, Construct developers are quite a birght minds right? find a way then, you can do it. You are not worst then them right?

    It's a different engine, and was made from scratch to accommodate large images. It has different ways of loading them into memory, and the game is structured around loading these images. Construct is an all purpose 2d engine which is hardware accelerated. It doesn't support large images well. And this notion of slicing that you keep bringing up; it only matters if the large image isn't a square power of two. if you have a 2048x2048 image, then no amount of slicing is going to make it use any less resources. it only matters if you have an image which is let's say, 128x2048, in which case the gpu will treat the slices as 16 128x128 images, instead of one large 2048x2048 image. Construct isn't IE. If you want to use large images then section your levels into layouts and load the textures on layout start up, it might work. But in general, you shouldn't design your game around large texture backgrounds, it's not efficient.

  • Playing around with a radiosity shader I made. I might include this effect as a setting for people with faster graphics cards. It's quite subtle in the screenshots, but it looks great in motion. Purple berries cast a soft purple glow on stone, lava illuminates anything near it, and the man's skin reflects light as he's climbing, making the walls look somewhat reflective.

    <img src="http://dl.dropbox.com/u/1010927/Forumpics/TCradshad.png">

  • Is custom movement more efficient in terms of processor overhead? Is that what makes it a better choice than Physics? Just curious.

    Yes.

    One last question (I hope ): Now that I'm no longer using the bullet behavior, what is the best way to set a range for the bullets? My guess would be some version of destroying it over TimeDelta? Also, should I be using TimeDelta to regulate the bullet speed (so it will run the same on different computers)?

    Using timedelta in your movement calculations makes the game run at the same relative speed regardless of the frame rate. For example, when the frame rate drops due to lag, objects will perform large steps of movement, which may result in missed collision or other unwanted things. You can also set a special setting for timedelta which remedies the aforementioned problem; it modifies the timedelta if the value gets to low, so that the game goes from "skip frame" lag, to "slowdown lag" if passes a certain threshold. Timedelta is not mandatory however. You can use a fixed frame rate for when you want to program to run with frame based logic, instead of time based logic. Without timedelta however, if you select V-synced framerate, then your game will run at different speeds depending on the monitor's refresh rate. If you need pixel perfect collisions, reliability and consistancy (ie. low res platformer), then use a fixed frame rate. If you want to be able to slowdown time in your game, then you need to incorporate timedelta (there are ways around that but I won't get into that).

  • An MMO is pretty infeasible. Not just because of Construct's limitations, but because it is an enormous amount of work for one person.

  • You have to set them up manually with events, and it all depends on the design of your game. It could get complicated depending on what you want. Something like "fence hop", for example, would require a variable which increments, for a sort of timeline. First, it would freeze the player movement, then it would detach the animation sprite, play the animation and possibly move it over the fence (timed with the animation), then snap the hitbox back to the animation sprite. Like I said, it's really specific and depends on the design of the game. Something like I just described would give a prince of persia (not the 3d one, the old one) type of feel. Maybe you just want the animation to play when the player actually just walks over the fence. In that case you would just set the animation when the hitbox is over the fence. Think about what you want, and try to implement it.

  • use custom movement and "set speed toward position", and choose accelerate as the type. It functions the exact same way as physics. Like I said, if you want vector based movement (ie. Inertia physics, without the collisions) then use custom movement.

  • Why do you want your bullets to use physics behavior specifically? Will they need to collide and bounce around physically? If not then physics behavior shouldn't be used. The only time you should use it is if you want physics based interaction between objects. Using it solely for the purpose of vector based movement/inertia is inefficient; for that you should use custom movement behavior. In general you shouldn't combine two movement behaviors unless you're manually toggling between them for a certain reason. Physics behavior hijacks the x,y, and angle of an object, so adding a bullet behavior on top will just apply angle based movement to the object after its movement has already been physically solved and applied by physics behavior. Bullet behavior is dead simple, and is equivalent to the "move at angle" action, minus the time-delta adjustment.