Jump to content


Photo

Destructible Terrain


  • This topic is locked This topic is locked
79 replies to this topic

#1 Sinaz

Sinaz

    MCP Killer

  • Retired Staff
  • 2751 posts
  • Version:GM8

Posted 16 April 2008 - 04:13 PM

Original topic can be found here:
Destructible Terrain
originally posted by Alezunde


We've all seen them, from the classics Scorched Earth, Dig Dug, and Sopwith, to modern marvels like Worms and Red Faction. Destructible Terrain (DT)! This is not something so readily available to the GM user. DTs break down the clean and memory-neat concepts of tiled backgrounds and holds every pixel or polygon accountable for it's own life on the screen.

The nature of destructible terrains makes it a complicated feature to overcome. Giving every element of the image it's own presence tends to bog down processors and require enormous amounts of memory... that is... if you try and do it the most obvious way. First attempts at GM DTs tend to try to place an instance per pixel or sometimes, per small square sprite (basically a large pixel.) But these systems fail because suddenly you have hundreds of thousands of objects running collision routines to build up terrain in the smallest of playable areas.

Obviously, DTs need a more clever approach to function properly in GM. The tools that have been used to further GMs DT technology include parameterization of objects (subdividing big objects into little ones when needed), ds_grids and other datastructures (to manage pixel perfect collision and hole-punching routines with the set_disk functions), and surfaces (to easily edit the on screen information.) Some GMCers have even stepped into the 3D realm using data structures to manage the vertices of ground planes.

DTs require more engineering than simply blasting away the background. Consideration has to be given as to how objects will collide with the transforming terrain. One might also want the ability to paint terrain back into the environment, or convert dynamic objects into destructible terrain. Will suspended terrain cascade to the nearest floor? How can you tunnel in 3D? Some of the concepts for destructible terrain may be beyond the capacity for GM's runner. But that doesn't mean we can't try.


Here are some online references to programming Destructible Terrains:

YoYoGames Wiki Page on DTs

Existing Examples:
  • KXDTE Kaietnap's impressive extension shows just how possible Destructible Terrains can be in GM. Though Kaietnap hasn't released the source, this is a good place for GMCers to go who don't have the time or ability to create a system from scratch.
  • Post 2 on this page By Icuurd
  • Post 3 on this page By Indecom
  • (This list will grow with posting of new examples - or old ones with merit. If you have an example, submit it!)

Because this topic is starting anew, some older concepts will be welcomed back into the fray. So don't be afraid to post. Seeing some games in the past several months that have done some clever things to simulate destructible terrain has really expanded the expectations for such a system!

PS - for those who followed my examples in the old thread, I have lost a lot of the original source files, but I plan on recreating the project with the things I've since learned in the near future. The Destructible Terrain examples were some of my favorite experiments! The source for my latest released example is still available in my signature.
  • 1

#2 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • Retired Staff
  • 15715 posts
  • Version:GM:Studio

Posted 16 April 2008 - 10:27 PM

This example has the popular "slip object into little square" techinque

and my own "punch hole into sprite technique".

How it works is every instance of the crate has it's own personal sprite, cloned from the original. When a bullet hits it, I use surfaces to punch a hole in the image and reset the sprite to the new image.

bottom 4 crates are my technique.
http://host-a.net/ic...2b42/crates.gmk
  • 0

#3 Indecom4000

Indecom4000

    GMC Member

  • GMC Member
  • 1482 posts
  • Version:GM:Studio

Posted 21 April 2008 - 02:13 AM

I actually created an effect for gm6 similar to Icuurd's sprite and srface based effect, however i felt that it really needed an extra graphical boost, so i created a rendering system that bevels the edges of the sprite where its been damaged so there is a nice shading effect to the edge creating a more realistic effect in general.
Here is a screenshot where you can notice that the parts where its been blown apart are more realistic and not just spheres, and you can see the shading on it as well, though its not super noticable in this current shot.
Posted Image
Here is the download: FIXED!!
http://h1.ripway.com...destruction.gm6

I fyou have problems running this, try removing some blocks from the room, leave in line 2 or 3 at the most, and try again.

Edited by Indecom4000, 26 April 2008 - 06:34 AM.

  • 0

#4 schmidtbag

schmidtbag

    GMC Member

  • New Member
  • 542 posts

Posted 29 April 2008 - 04:56 PM

In my game Turret Defense 3D, I created my own 3D destructible terrain. Its a little slow but it works. The greater your bullet's mass, the more you damage the land. This game is turn based so the slowness of my destructible terrain doesn't greatly affect game play. Keep in mind that I never completed this game, and the reason it is poorly rated is due to an installer, which is required for functional reasons.

How I did this was somewhat simple. During the game, I have the heightmap visible. Every time the bullet hits the ground, its coordinates are mapped to the heightmap and 5 pixel sprites in a + shape and with an alpha value (depending on the bullet's mass) is drawn on the heightmap. The heightmap is saved as a temporary bitmap and the sprite objects are removed. Then, the game replaces the current heightmap with the temporary, and the 3D map is re-drawn. Then, the objects' z axises are realigned.

This is the most efficient heightmap technique I could think of, but for regular 3D designing, there are much faster ways, nothing I know how to do though.
  • 0

#5 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3525 posts
  • Version:GM:Studio

Posted 19 May 2008 - 08:48 PM

This is the engine im using for my own worms game, its an extraction from the game engine and it has almost no modifications.
the concept is very basic, it uses sprites and surfaces, but not just one, it uses many small different sprites to make the whole map, the explosion checks wich sprite it should destroy (they might be many) and it makes the changes to destroy the land using the surfaces method. Realize that the sprites are saved as a binary array, hat ses he posiion of the suface in the room (fe: [0,0] is he first, [1,0] is the second, etc...)

TOPIC LINK
  • 0

#6 aaaaa3000

aaaaa3000

    GMC Member

  • GMC Member
  • 663 posts

Posted 01 June 2008 - 08:19 PM

i began making a game with destructable land, a while ago. the land was made of large blocks, and if it was hit, the large block would divide into 4 and if the divided object was hit it would divide into 4 and eventualy the last object would destroy, here is a link to the game
http://host-a.net/aa...troy_landex.gmk
  • 0

#7 Sinaz

Sinaz

    MCP Killer

  • Retired Staff
  • 2751 posts
  • Version:GM8

Posted 26 June 2008 - 05:31 PM

I've been deleting a lot of posts of people just dumping their engines here. If you've posted an engine prior to the date of this post and it's not visible, then it's been deleted from the thread. I didn't delete it to be spiteful, but because I need you guys to talk about your process in your post. Just posting the engine and making us reverse engineer it is counter-productive. Since you already know how it works, take the time to discuss your implementation and theory.

Those who already had their engine post approved, please evaluate it and think about adding more information about your process and theory.

  • 1

#8 SerMSYS

SerMSYS

    GMC Member

  • New Member
  • 180 posts

Posted 26 June 2008 - 06:53 PM

Well, I've been working on a falling destructible terrain (DT) method for quite some time. So, I've come with an idea for a Pocket Tanks-style DT that supports tunnels and colorfull terrain. It uses 3 data grids: one for indicating whether a pixel is empty or not, second for color, and another for pixel-type (tunnel, bouncy, glue, etc. just like in pocket tanks). The grids can be filled from GML, custom image file, or previously saved landscape. The terrain is then checked for any strips in the grid column that are isolated from the ground. These are put onto separate surface strips and progressed each step downwards until they hit solid ground. The main terrain and floating strips are drawn separetely each step. Once they hit ground, they are merged with the main terrain sprite.

Here's an example:
Download Example
  • 0

#9 brett14

brett14

    GMC Member

  • GMC Member
  • 1151 posts
  • Version:GM8

Posted 07 September 2008 - 05:35 AM

In my game Turret Defense 3D, I created my own 3D destructible terrain. Its a little slow but it works. The greater your bullet's mass, the more you damage the land. This game is turn based so the slowness of my destructible terrain doesn't greatly affect game play. Keep in mind that I never completed this game, and the reason it is poorly rated is due to an installer, which is required for functional reasons.

How I did this was somewhat simple. During the game, I have the heightmap visible. Every time the bullet hits the ground, its coordinates are mapped to the heightmap and 5 pixel sprites in a + shape and with an alpha value (depending on the bullet's mass) is drawn on the heightmap. The heightmap is saved as a temporary bitmap and the sprite objects are removed. Then, the game replaces the current heightmap with the temporary, and the 3D map is re-drawn. Then, the objects' z axises are realigned.

This is the most efficient heightmap technique I could think of, but for regular 3D designing, there are much faster ways, nothing I know how to do though.

There is a much easier and much more efficient way to do this (with NO limitations in height) - heightmaps can have only 240 height variations, and it is also easier - Here's how to do it!


Start out just like you did, by loading the default terrain from a heightmap and storing all of its positions in a grid and creating the terrain model, but now when you want to destroy the terrain instead of drawing on the heightmap and reloading it, use ds_grid_add_disk() - of course you'll have to make the destroyed X and Y values synced together (on the grid and on the terrain) then you re-create the terrain model using the grid. This saves you from having to reload the heightmap (which is REALLY slow).

I am not very good at explaining things (So if you did not understand the above), I have made an example (open source DUH) which can be found HERE - TOPIC LINK - OR - The Direct Download which can be found HERE - DIRECT DOWNLOAD -- Please note that this has no comments, so you'll need to know the GML to understand how this works (Tells you what it does and it's arguments), BUT this is the experts topic so...
  • 0

#10 Supertramp

Supertramp

    GMC Member

  • GMC Member
  • 353 posts

Posted 09 January 2009 - 05:27 PM

Well, I've been working on a ...Pocket Tanks-style DT

yes, i have pocket tanks and when i saw the old topic i thought of it.
i then decided to make a game like it (because i never habe good ideas)
Posted Image
here is my engine

it uses lots of strips of two pixel think horisontally next to each other that when clicked on, calculate two new strips at the correct positions.

it is similar to the square that breaks into 4 more but smaller, but it works out exact values of the sizes so it only breaks once. i can't really explain it better than that. the strips move down untill they reach either the ground or another bit of land, where they either stop or join onto the bit of ground below by adding their height to the heigt of the ground they anded on and then destroying

i am woring on a newer version where you can add ground but it is a bit difficult

Edited by Supertramp, 09 January 2009 - 05:28 PM.

  • 1

#11 blue_chu_jelly

blue_chu_jelly

    Shut your FMaj7

  • GMC Member
  • 228 posts

Posted 12 January 2009 - 06:05 AM

That works rather nicely supertramp, good job. I set the room speed up to 1000 and managed to get about 325fps with nothing happening at the beginning.
Explosions hardly slowed it down, although it dropped to about 100fps after using the tunnel numerous times and at the time I had about 1000 instances in the room.
  • 0

#12 bearSoft

bearSoft

    GMC Member

  • New Member
  • 1002 posts

Posted 12 January 2009 - 09:58 AM

yes, 'strips' ot rather culumns of 'ground' can be a solution. the downside is the graphical presentation.
I have not figured out how to make the terrain look 'pretty' in DT..
What we get from most DT is a somewhat clinical 'cross-section' of a cartoonish word..
In selebrated games like worms and OF CAUSE Lemmings (drewl..) they have a lovely graphic presentation
Lemmings was not just a DT platformer ..it was a beatyfull DT-P :)
The isue here is 'texturing' the visible 'egde' of the destructable items..
(remember how the diggers could 'scrape' through a convinsing looking wooden stock or grassland amo?)
..it almost make one wonder if all was build in a huge pixel-matrix
neee.. silly thought
..so perhaps 'we' has the subject for a competiton:
"recreate the classic Lemmings" :)
  • 0

#13 ditdingiscool

ditdingiscool

    GMC Member

  • New Member
  • 335 posts

Posted 12 January 2009 - 06:14 PM

the easiest and fastest way is to use a surface for the visuals, and a ds_grid for collisions...
will edit with example...

EDIT:
yay! here it is:
download linky(click me!)
contains:one destructable terain example, gmk format
haven't actualy tested the speed, but because my pc doesn't lag when using(my pc is reeeeaaaaly slow),
the only thing that slows it down are the actual objects editing the surface and ds grid...

Edited by ditdingiscool, 12 January 2009 - 07:04 PM.

  • 0

#14 xDanielx

xDanielx

    GMC Member

  • GMC Member
  • 1002 posts
  • Version:Unknown

Posted 13 January 2009 - 01:45 AM

I finally had a stab at a raster-based terrain engine; see the topic here.

Internally, the engine works as follows. The terrain object (obj_terrain) maintains a surface as well as a sprite to represent the terrain. To add to the terrain, an instance draws onto the surface and informs the terrain object that an update is required for the sprite. To subtract from the terrain, an instance draws onto the surface using bm_subtract and likewise informs the terrain object that an update is required. Any drawing functions can be used for these purposes, so arbitrary shapes and/or images can be used for construction and destruction.


EDIT: The latest version splits up the terrain into small pieces, making the computational cost pretty negligible (unless there's simultaneous construction/destruction on many different areas of the map).

Edited by xDanielx, 13 January 2009 - 03:59 AM.

  • 0

#15 Marchal_Mig12

Marchal_Mig12

    The Rhouan

  • GMC Member
  • 1180 posts
  • Version:GM:Studio

Posted 13 January 2009 - 05:41 AM

I finally had a stab at a raster-based terrain engine; see the topic here.


When I took a look at the memory used by your engine, it grew up each time I pressed left button. The thing is that you create new sprite every time we press left button. But you do not destroy old and unused ones. Here's a better example showing how you can use it easily in any games. It keeps a low memory usage and a high fps. The principle used is pretty much the same as yours though. I made it couple months ago though so there may have better way to do it.

Actually, blending is not the solution. I think that the best solution is to use small sprites as terrain and whenever these sprite are colliding with an explosion, you use surface to create the same sprite but with a hole (or whatever the shape you want) over it (using the same transparent color as the old sprite). Then make it transparent, and here you go.

Never forget to destroy unused sprite though.

Mig
  • 0

#16 xDanielx

xDanielx

    GMC Member

  • GMC Member
  • 1002 posts
  • Version:Unknown

Posted 13 January 2009 - 06:46 AM

Thanks for pointing that out. I actually put in a sprite_delete command (see obj_terrain end step), but commented it out while hunting a bug and then forgot about it. The bug is gone and I've uncommented the sprite_delete.

Actually, blending is not the solution. I think that the best solution is to use small sprites as terrain and whenever these sprite are colliding with an explosion, you use surface to create the same sprite but with a hole (or whatever the shape you want) over it (using the same transparent color as the old sprite). Then make it transparent, and here you go.

It should work either way.

Edited by xDanielx, 13 January 2009 - 06:47 AM.

  • 0

#17 Supertramp

Supertramp

    GMC Member

  • GMC Member
  • 353 posts

Posted 18 January 2009 - 04:17 PM

i had an idea:
you could use something like my strip DTE, and use the strips to create an alpha psrite, which is then applied to the background sprite, or a background picture. the trouble is, it would lag seriously, creating new sprites every step.

you could use draw_sprite_part, whre the whole background is split up and drawn by the sprites.
the pros of this: hopefully it would be fast. i ahev never used sprite_part, so i can't say for definite
the cons of this: the background would not be distorted, it would get drawn as if the strips were alpha-ing the background, not changing it. i'll try it and you tell me what you think
  • 0

#18 griffi

griffi

    GMC Member

  • New Member
  • 243 posts

Posted 05 February 2009 - 05:25 PM

If i knew how to make DTs, i'd have a better post, but here's my suggestion on realistic DT:

1) Not destructible terrain, it's more realistic to have displacable terrain, because as you all know, mass cannot be created or destroyed, so it should be shifted or thrown into the air.

2) the reaction from the terrain should work with these equations:

Speed of bullet = mass x velocity
Density of terrain = mass x volume

Distance that terrain is moved relies on velocity and mass of bullet, density of the terrain and amount of terrain that surrounds the area of impact.

Sorry, i'm only doing GCSE physics, so i'm not going to be able to recite it all.

Also, i'd suggest taking a look at "Pocket Tanks" or Worms - they're really the only 2 types of DT that exist.
  • 0

#19 RobertOK

RobertOK

    GMC Member

  • New Member
  • 186 posts
  • Version:GM8

Posted 05 February 2009 - 07:08 PM

A couple of points stick out at me straight away, griffi.

Firstly, the formula for density is mass/volume.

Secondly, in the strictest sense, mass can be destroyed, but that's way beyond GCSE (anti-matter annihilation, reaction in a hydrogen bomb, etc).

That said, this is an interesting idea. My only worry would be is that you are going to have the same problems with lag, as with the 'block method' mentioned above. Technology at the moment is not so as to allow us to have hundreds of 2x2 blocks which each behave according to several laws, we simply do not have the processing power.

A very simple way, that isn't really that advanced, but I feel should be brought up none-the-less, is to have various sprites for each image. Based on where the 'bullet' hits the terrain, it changes to a different sprite. This could work very well for platformers with tiled floors. You simply delete some of the tiles, and change others to standard angled tiles that are in most sprite sheets. It's a bit simplistic, but it's an easy method for novices to begin integrating destructible terrain into their games.
  • 0

#20 Supertramp

Supertramp

    GMC Member

  • GMC Member
  • 353 posts

Posted 13 February 2009 - 05:02 PM

you could just have a sprite that you play once like a movie that looks like a block breaking up, but it is only an animated sprite. the broken "pieces" would then fall off creen, when the sprite would be removed(not deleted because it would be needed again) .you could have several different sizes and "strengths" of explosion.

just a wierd semi-off topic question- what makes GM games slow down with a lot of instances but other games do not? obviously thay are complete different programs, i understand that, but is there a way to harness the same "power" that other games do so it does not lag?
would a .dll be of some help? or is that more complicated than it needs to be and just use surfaces/etc?

EDIT: i just had a crazy idea for a destuctible becaground, so long as it does not collide with anything. give me about 10mins and i'll have it up and explain it.

EDIT 2:OK here it is
Posted Image
it is bad, i know, but it is another idea. what happens is that instead of destroying the background, you draw on top of it, creating the illusion that it is being destroyed

Edited by Supertramp, 13 February 2009 - 05:22 PM.

  • 1

#21 sylvan

sylvan

    GMC Member

  • New Member
  • 99 posts

Posted 16 February 2009 - 05:11 AM

On the topic of displace-able terrain, I was working on a new game and came up with something that might be useful to achieve this affect.

http://www.mediafire.com/?lmwytttmmjm

The code in there is quite bad, this was made as a test file. I've never used surfaces before so a lot of it can be done better.

Looking at some of the previous posts, it seemed what I did is quite similar to the others. I used a surface to draw the sprite, then drew over the sprite with a transparent colour to erase the destroyed portion of the object (I used a really big triangle, but ideally this could be done with primitives or something). Then do the same for the other half. This cuts an object cleanly into two parts.

Of course, the more cuts that are made the more objects there are to handle. And I should point out that all object's sprite sizes are the same, e.g. 1 pixel of colour will be still on the 128x128 sprite. I didn't bother putting in a cropping system (could be done with bounding boxes.) I did say the code was bad =P

The advantage of this method is that the cut happens instantly (no bullet and travelling time), and it retains the mass of the object that is cut.

Edited by sylvan, 16 February 2009 - 05:11 AM.

  • 0

#22 RTsa

RTsa

    Ragdoll Matrix

  • New Member
  • 352 posts

Posted 19 February 2009 - 10:36 PM

I created a destructible polygon method for my game a while ago. Basically, the stuff that's destructible is defined with polygons and then you "subtract" another polygon from it. Performance problems occur with large objects (or rather, that combined with complex destructive polygons) but overall, with small destructive polygons it was fast enough to be used in a game. The advantage I found in this method is that it's possible to use moving, destructible, physics based polygons, which also react correctly when split into several objects. Don't know if that could be done with any sprite method. The problem came with drawing in the end as GM's primitives aren't too fast.

If people are interested in my method, I could probably upload an example that has the polygons and destroying them. (if I still have it somewhere..)
  • 0

#23 GeEom

GeEom

    GMC Member

  • GMC Member
  • 218 posts

Posted 23 February 2009 - 08:26 PM

I belive i have an efficient solution
im thinking this through as i type, so forgive me if i end up alt f4ing this page

recently i looked into creating 100% in game unit sprites, for an evolution sim, alowing perfect , or vauge, splicing of a pair of units, to create their mathmatical average as ofspring

now my method followed a vauge path,

firstly some inspecifics, scale (off a base size) etc, were determined, with v slight randomisation
then colour, i had a 100*100 surface, and drew a base colour block upon it, then, in a second colour, using a 100 point list, small shapes were, or were not , drawn, creating a 100*100 'skin' for my creatures

thats pretty much as far as i got, and the system i made had no output

however my next stage is crucial, to that and this

setting aside the skin:
i created a series of *body* sprites
these held two key colours, white and black (the only colours unatainable by my splicing system, therefore deemed safe
a body sprite had a black image of the creatures shape, as i would have liked it. all *unused* space was white, Bar the corner dot that determines transparency, this was black, these outlines, silouettes, are transparrent, a white *frame*

now
i reloaded the skin, (sprite saved from previous surface) at any scale, based on origional scale factor, creating a skinned square, then a scaled frame sprite (shape determined by avg again), so now i have a skin shape, white excess, and a skin dot in the far corner
a white dot is drawn upon the far corner.
a sprite is saved from surface, transparrent
a perfect, shaped, skinned, creature


that never got finnished, gr8 concept

now, the non imersed, and predictive among you, may have noticed that ive an effective way of transparasising an area of object

so, take a background image, and over it make your destructable terrain, as detailed as you like:
the destructable terrain is an object, or t'least a drawn sprite, pick 1 colour, pref a easy combo of the 3 255 values, and dont let it into this sprite.

now, not every step, but every terrain effecting event, draw the sprite to surface, and upon areas (so take worms example, you blast a nice circle in the ground, im using that example now because3 i cant keep talking out of context, hav headache) so you blow up a circle, use the reverse of my frames, this time, have the colour you set aside as the shape you want REMOVED, and draw it at apropriate impact point on sprite, then colour the lower corner pixel, and take a transparrent snapshot.
(a method that removes having to align the impact point to co-ords for the sprite, and also the un-reaserched area of whether transparents drawn to surface stay transparent, (pref use the set aside colour for ALL transparencys here people,) would be to merely take the screen as pick to surface, your objects, if caught, get redrawn, and background shows thru still any which way...)
then simply replace the sprite you used for ur destructable terrain with the one youve just created, hole and all


with further difficulty this could even be layered

im sorry ive no example, but im rli busy with non gm work, and even in spare time, my own projects prioritise

reluctant to release what i think of as a great breakthru into transparency manipulation

now thats all basicly theory, but should work, the actual event step will be drawing a pair of surfaces, but thats what the game dose every single frame, so should run at ooo... 60% of capable redraw rate, which means like, 30% norm speed, but without any object events, extremely unhindering






im rather pleased with myself, relitively new to GM, if any1 makes a working example of this, A credit to me, and B credit to them, well done

P.S.
no one needs to read this bit rli...
i qualify my reluctance to post : this is a great and extremely aplicable system, it will easily set many games aside, for instance destructable terrain, and 100% variational ability with an evo sim, will put games above others...
i fear a novice like me needs all he has to make his mark, and this is kinda my ace,
meh...
nvm, will probs be using in my top down: talon tank XP, barely begun, yet looking good,
ill be using a sub object system: each object degenerates into a lower form of rubble
now if i want to knock a block of a wall, i can either use sprite layering to achive 8 or nine "knock of points" and remove the nearest sprite, but thats lower quality than my desires, so now i can take a block out of the sprite at precisely the right place, scatter a few extra transparent pixels localy, and create realistic dammage :o

Edited by GeEom, 23 February 2009 - 08:36 PM.

  • 0

#24 WXKFA

WXKFA

    GMC Member

  • New Member
  • 42 posts

Posted 25 February 2009 - 09:10 PM

I don't see any reason why 2D DT can't be done using surfaces. Because a really big surface lags as hell, why we don't just split it to smaller pieces.
Let's say 80px x 80px. This way we would have total 48 objects in a place 640px x 480px. While there is too much objects I think it can be solved by deactivating and activating terrain objects. I know that all computers will not support surfaces, but at least it works on my crappy computer.
Rather simple code but I upload it anyway :whistle:. http://wxkfa.vndv.com/sm_wxkfa_eng.zip
~wxkfa

Edit: Btw. I use a DT like this in my game project; Custom Lemmings 95.

Edited by WXKFA, 25 February 2009 - 09:12 PM.

  • 0

#25 ditdingiscool

ditdingiscool

    GMC Member

  • New Member
  • 335 posts

Posted 26 February 2009 - 02:54 PM

I don't see any reason why 2D DT can't be done using surfaces. Because a really big surface lags as hell, why we don't just split it to smaller pieces.
Let's say 80px x 80px. This way we would have total 48 objects in a place 640px x 480px. While there is too much objects I think it can be solved by deactivating and activating terrain objects. I know that all computers will not support surfaces, but at least it works on my crappy computer.
Rather simple code but I upload it anyway :D. http://wxkfa.vndv.com/sm_wxkfa_eng.zip
~wxkfa

Edit: Btw. I use a DT like this in my game project; Custom Lemmings 95.

using one big surface doesn't lag at all, just don't use it for collision checking, you should use a surface forr the visuals, and when you draw onto the surface you can set some data in a ds-grid for the collision checking,
that should be lag-free...
  • 0

#26 GeEom

GeEom

    GMC Member

  • GMC Member
  • 218 posts

Posted 26 February 2009 - 05:36 PM

so weve fixed the DT problem, efficiently,
tea anyone?
someone should pick thru and make a tute/examp of it, personaly i think the aplication is v limited
  • 0

#27 ~Dannyboy~

~Dannyboy~

    ~hoqhuue(|~

  • GMC Member
  • 2144 posts
  • Version:GM8

Posted 26 February 2009 - 10:55 PM

using one big surface doesn't lag at all, just don't use it for collision checking, you should use a surface forr the visuals, and when you draw onto the surface you can set some data in a ds-grid for the collision checking,
that should be lag-free...

If you have a HUGE area, then one big surface will lag. If you bother to scan through the old topic, you'll find that this has already been discussed. Splitting the surface into 256 * 256 or 512 * 512 chunks and having an objects which draw only the surfaces which are in the view makes a noticeable difference. In fact if you have terrain bigger than 1024 * 1024 then many gfx cards won't cope. The discussion was only about a page, starting here

Edited by ~Dannyboy~, 26 February 2009 - 10:56 PM.

  • 0

#28 WXKFA

WXKFA

    GMC Member

  • New Member
  • 42 posts

Posted 27 February 2009 - 09:05 AM

using one big surface doesn't lag at all, just don't use it for collision checking, you should use a surface forr the visuals, and when you draw onto the surface you can set some data in a ds-grid for the collision checking,
that should be lag-free...

Yes, but why I need some ds-grid for collision checking if I create a sprite from a surface. It is fast even on my laggy laptop, because the sprite what game should create is only 80px wide and 80px high. Or was my example bad and laggy or something? If it was, I might rethink some other methods to solve this problem.
But I think that we should think some other methods too than using a surface... B)
  • 0

#29 ditdingiscool

ditdingiscool

    GMC Member

  • New Member
  • 335 posts

Posted 27 February 2009 - 12:23 PM

using one big surface doesn't lag at all, just don't use it for collision checking, you should use a surface forr the visuals, and when you draw onto the surface you can set some data in a ds-grid for the collision checking,
that should be lag-free...

Yes, but why I need some ds-grid for collision checking if I create a sprite from a surface. It is fast even on my laggy laptop, because the sprite what game should create is only 80px wide and 80px high. Or was my example bad and laggy or something? If it was, I might rethink some other methods to solve this problem.
But I think that we should think some other methods too than using a surface... B)

sorry for not reading the whole topic, but it's a bit huge ^_^
and yes using a sprite for collision checking is fast, forgot 'bout that method, i was thingking about using draw_getpixel (or whatever it is)
  • 0

#30 Got Rice

Got Rice

    GMC Member

  • New Member
  • 37 posts

Posted 28 February 2009 - 07:25 AM

Interesting stuff you all have here.

But I've seen a great example of destructible terrain here, the objects atop the terrain even fall when there is nothing below. Great collision checking too. Although it doesn't have the splitting of objects so if you cut an object in half the floating part won't fall...

http://gmc.yoyogames...howtopic=421754

PS: :lol:
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users