Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Scrolling Sprite Guidance

Author
Message
VG Teacher
13
Years of Service
User Offline
Joined: 27th Oct 2011
Location:
Posted: 9th Dec 2011 13:34
Greetings!

I am looking for a TINY hint in the right direction. I have a scrolling game where my sprite stays in one place, and the background consists of tiles that scroll as controlled by the keyboard, so my sprite appears to be moving.

I do not want my sprite to collide with certain parts of the background. I was hoping that someone could suggest an avenue for me. Here is what I have thought about:

1) Check the color of the tile in the background, and have the sprite react based on that color.
2) Make some transparent sprites that move with the background, so I can detect a collision that way (with the forseeable problem that it would be difficult to change my layout wihtout creating and placing a new sprite).
3) Some great idea that I haven't thought of....
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 9th Dec 2011 15:23
Quote: "3) Some great idea that I haven't thought of.... "


Like not using tiles? Lol, just kidding, each to their own
Although life is a lot easier when using one basic backdrop and having "entities" (rocks, trees, etc) on it (like tiles but fewer of them). The scrolling will be smoother, collision can be detected against each smaller entity (Rock(n).img, Tree(n).img, etc) and placing your objects on your map is simpler. People often forget that you can apply 3D principles to 2D. People often associate 2D and tiles (Could it have anything to do with NES and SNES? Nah, impossible!). It also means less sprites on-screen. On today's mid-range systems you can get away with sprites that exceed your screen size without slowdowns.

I can't give you more info unless you tell me:

1. This is a top-down scrolling game right (I'm assuming so)?
2. How many directions can the player move in?
3. How large is the playing area?
4. How precise do your collisions need to be?

In response to the other two questions:

1. I would advise against it. 2D Vectore collision works better. I haven't ever tried colour-pixel based collision but theoretically it would be very CPU-intensive.
2. If you use my abovementioned method for your background, you don't need to use transparent sprites. HOWEVER, don't discard the idea completely. It can be useful as a bounding box for your player if your player has an irregular shape.

My recommendations for collision are:
Check if a regular sprite collision occurred between entities. If you want acurracy at the cost of CPU, run a 2D vector check with your player's bounding box VS the colliding entity. If you don't need accuracy, simply check for collisions between your bounding box and the enemy but make your bounding box smaller than your player (Technique was used for early games that often produced a "I got hit but not according to the computer" effect. In cases of bad coding, it was the other way round, coining such phrases among children as "the computer's cheating!").

Well, hope that info is at least a clue.

VG Teacher
13
Years of Service
User Offline
Joined: 27th Oct 2011
Location:
Posted: 9th Dec 2011 16:09
Thank you, non-zero. My game is a very basic scroller, I am trying to move through a maze, I am writing the game to teach myself the elements of the software.

1) This is a top-down scrolling game.
2) The player can move up, down, left, right.
3) My playing area is 2000 pixels by 1200 pixels. At any given time, I can view 800 by 600 pixels.
4) My collisions do not need to be very precise.

Thank you for your time. I think that I have enough to play around and do something.

I really appreciate your points!
MrValentine
AGK Backer
13
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 10th Dec 2011 02:29 Edited at: 10th Dec 2011 02:33
Urm... how about ray casting? Or is that what you meant zero?

Perhaps create a grid of objects in the backgroung and use a ray casting system in the z axis...

Just a thought...

EDIT

or urm y axis?

EDIT

Was just reading this http://forum.thegamecreators.com/?m=forum_view&t=192195&b=38

and found that the secret ODE engine inside DBPro houses an internal ray cast function... hope this helped...

zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 10th Dec 2011 13:29 Edited at: 10th Dec 2011 14:16
If you already have a tile map, then why not use that structure for your collision? That's one of the main ideas of having a tiled world (beyond the memory savings vs. single large images). The collision is built-in to the map itself, and is flexible (non-dependent on any specific tile).

What you would do is have layers by utilizing a 3-dimensional-rray. Think of that 3rd element/dimension as height, if it helps. So a simple outline for how the layers could be used...


layer0 (Base Layer) - This layer is drawn first and is below everything else including your character. These Tiles are generally walkable.

layer1 (Fringe Layer) - This layer is drawn on top of the base layer and is mainly used to transition tiles from one type to another. It makes for smoother transistions by use of fringes. For example blending grass to a stone path. It takes the blockyness out of the world.

layer2 *** (Object/Item/NPC's/Collision layer) - This layer is a combination visual & logic layer. This layer is drawn on top of layers 0 & 1, and is on the same plane/height as the character. Any tiles drawn here are non-walkable or cause a collision. There are also items here that the player interacts with. This layer is responsible for handling logic. *Ill explain more about this later at the end

layer3+ (Bridges, Environmentals) - This layer or layers is/are drawn above all other layers including the layer your character resides. The character can walk underneath these tiles. Some examples would be a bridge the character can walk under, or environmental effects like clouds.
==========

Okay, some important things to note. A value of 0 for any given layer means no tile has to be drawn. Some layers,, especially layer 3+ will have very little data (depending on level design) and probably contain a lot of 0's.

Layer 2 is unique and important. Values for layer 2 can represent a few different things (not just an index to a specific tile). Many of the values are logical values rather than "Only" representing an image. For instance...
- A value of 0 for layer 2 could mean; Don't draw a tile (for this layer), but the space is walkable (no collision occurs here).
- A value of 1 (or any value higher than 0) could mean; Don't draw a tile (for this layer) but the space, [regardless of whatever other layers are drawing here] are not-walkable tiles. A collision occurs here.

By using some form of this method; a layer (here layer2) becomes your collision mask for the level. It controls what tiles are walkable and which one's aren't. This is a powerful concept, as you can use it to set up hidden/secreat areas very simply. Say for instance ocean tiles are generally not-walkable. If you have a value of 0 in layer 2 however, you can make certain ocean tiles walkable.


Now a very simple 3-dimensional map using this method. These values would be stored in a 3 dimensial array, ie WorldArray(10,10,3) <ignoring the 0 index of arrays to avoid confusion>.

Let's say I have 3 tiles.
4 = Grass
8 = Ocean.
I have small Grass island surrounded by Ocean. You can generally only walk on the Grass, and you Collide with Ocean tiles. But there is a secret path over the Ocean in the logic of layer2. Layer 2 controls our logic.
I will not draw anything in the fringe layer - layer1- so it will all be 0's. I'm leaving out higher layers above 2. My island map will be 10 x 10

Here is what the layers would look like:



=======
Some other things to Note:

I provided a "fairly easy" layout for using the layers. You are not beholdent to utilize them exactly in that way. It just makes more logical sense to me.

Sometimes I use 5-7+ layers.
Not all of them are visibly drawn layers. So roughly...
layer 0 = (visual)base layer
layer 1 = (visual)fringe/transistion layer
layer 2 = (visual)Main Character/Items/NPC's/Environmental Effects below player
layer 3 = (Logical/sometimes Special Visual Elements)Logical Collision layer
layer 4 = (logical)Triggers/Events (special animated tile logic) layer. This layer can set off NPC events, open paths liked locked doors or previously blocked paths. It can also be the trigger for quests, and resolve/complete quests.
layer 5 = (visual)First layer above character. Used for things the player can walk under... ie bridges, limbs from trees, overhangs etc..
layer 6 = (visual)Environmental effects obove player. Weather, clouds, rain, birds, some magical fx etc...

~ZENassem
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 10th Dec 2011 18:04
I whipped up something in a hurry (So it prolly isn't coded in the best way possible) but maybe it'll give you a visual clue. I think at 2000x1200 pixels, it becomes a question of both your specs and your target-user's specs. My laptop can handle it with up to 150 entities before dropping a single frame below 60fps, but that's my machine and not your audience's. Also, Zenassem's method with the tiles may be a little more user-friendly in terms of logic (Square used a similar methodology in FF4 and FF5 and then a complicated version in FF6 on SNES. I dunno abt the NES ones, I and II look like 2 layers, III is hard to tell because of some clever effects but I'd say at least 4.)



Anyways, tiled, or not tiled, I'm sure you can draw something useful from this. Btw, if your collisions don't need to be accurate, then just use DBPro's sprite collision command. It's not half bad actually.

@MrValentine:
Quote: "Urm... how about ray casting? Or is that what you meant zero?"


I meant 2D vector collision. Brief summary: If a sprite collision is detected, check if either of the four corners (depending what side of the vector line they're on) of the sprite is between a set of 2D vector lines (which are technically fake as they're in pixels), return a a positive value for collision. Different boundaries can be set for different enemies to accomodate the player's bounding box and larger player characters can have more collision points. Usually no more than 3 down each side is needed. It's hard to explain in words, but it worked quite well in the last 2D shooter I made.

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 19th Dec 2011 20:17
This is all quite interesting. I'm glad I popped my head in to see what's going on. I really like the idea of multiple tile layers (if not using lots of separate sprites).

I wonder this though:
Say I have an image file for a background of a maze,
Couldn't I take that image in GIMP or Photoshop and delete the parts I want to be walk-able and save that file as a PNG with alpha
Then I could load the PNG with alpha channel into a memblock then
reference the player's location with the location of the alpha pixels and handle collision that way?

Maybe it would be even less intensive to make a 3 dimensional array storing coordinates and 0s and 1s based on where the transparent pixels exist then release the image from memory. That way random access to locations would be a bit easier to the logic.

I don't really much like the idea of tiles myself and this seems like a way to take any image, manipulate it in a photo editor and make the walk-able areas transparent.

Thoughts on this process?

Oh also could I see an example of a Fringe Layer. I think I know what Zen is talking about, but I'm not sure.

PS- sorry to hijack this thread, VG Teacher, I'm assuming your questions has been answered. If not feel free to throw things at me.

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 20th Dec 2011 08:30
Quote: "If not feel free to throw things at me."


*Activates banana cannon* heheheheh....

I think the idea with the png is interesting but remember pngs don't store data in a true bitmap form. You'd prolly be better off using aa uncompressed bitmap (bmp) and chooseing a specific colour to paint over it with and then using that colour. Remember pngs (Portable Network Graphics) are compressed. Perhaps write a "The block trapped in a maze" program and do some benchmarking.

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 20th Dec 2011 15:58
*catches bananas* mmmm thanks!

Good point, I hadn't thought about that and probably would have noticed the issue when trying to actually read data from a BMP.
I'll try to give this a shot soon. Seems like it would be a neat way to do collision mapping.

Chris Tate
DBPro Master
16
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 21st Dec 2011 01:04
Quote: "Couldn't I take that image in GIMP or Photoshop and delete the parts I want to be walk-able and save that file as a PNG with alpha
Then I could load the PNG with alpha channel into a memblock then
reference the player's location with the location of the alpha pixels and handle collision that way?"


You could. You would not need to compare an exact pixel colour or alpha value; it could be a range. For example, any colour range below 10 or above 245. In PNG format, anything with an alpha value above 127 could be treated as solid.

Tiles are more reuseable and less memory intensive. If you want something easy to draw and interpret into logic, reading a pixel map and turning pixels into tile array elements would be efficient. Based on Zenassem's concept, each pixel could determine the class of each tile. You also have the option to use more than one image layer in GIMP to represent each layer in his idea.

Naphier
14
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 21st Dec 2011 05:14
Great idea, Chris. I like where this has turned.
I'll try it with a couple of different methods for reading the file.
I'm sort of thinking to load an image to a bitmap and the read the pixels from there. I may try making tiles for collision objects or may write my own collision function.
The options seem a bit limitless so I hope I don't bog myself down with trying to include too much.

I'm going to try to write something over the next couple of weeks while I work on my rail shooter.

I love it when ideas sprout!

Login to post a reply

Server time is: 2024-11-22 06:57:04
Your offset time is: 2024-11-22 06:57:04