Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Advantage with tile map over LARGE bitmap, etc...

This thread is locked; no one can reply to it. rss feed Print
 1   2 
Advantage with tile map over LARGE bitmap, etc...
SonShadowCat
Member #1,548
September 2001
avatar

o.O O.o
I have no idea what you guys are talking about -.-

I am in the process of making a "maze" type level using my new found tile map skills :) pixel perfect collision and all ^^

23yrold3yrold
Member #1,134
March 2001
avatar

So you got it working? Cool 8-) Toldja it was easy ;)

Quote:

Then you must be stuck in a routine world of samey games.

So games like Solar Jetman, Super Mario 3, Final Fantasy VI, Chrono Trigger, Symphony of the Night, Skullmonkeys, Yoshi's Island, Startropics, MegaMan X4, Battletoads, Zelda III .... these are all the same? :P

Here's one for you; my game objects have a variable called footing, which is a pointer to terrain of some kind, be it a tilemap, moving platform or whathaveyou. I can make a few seperate tilemaps for a whole level and have them move independantly of each other, say bobbing in the ocean or something. Or use callbacks for scripting things like extending walkways or blocking doors. Dynamic, and I'm not stuck "snapping to grid" like I might if I did RLE tilemaps. Maybe we use 1980 algorithms because they just plain got it right in 1980. ;D

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Thomas Harte
Member #33
April 2000
avatar

Quote:

No, he's got a valid point. What does it bring to the game besides graphics

You see no change to gameplay from being able to do things like dynamically rotate and deform parts of the world? Or being able to procedurally define vertices? Even in a static world, you think it would be just as easy to define a rolling hill top by drawing all the different tiles as it would be just to put down a patch with bezier edges and flag it as being grass? What if you wanted a game that procedurally generated hilltops?

You see no benefit to being able to work in a mathematically valid way with normals? Games such as Sonic which do 'real physics' on tilemaps have restrictions on tile shapes and require a programmer or a tile creation system to additionally create a second lookup of angles at every edge pixel.

Quote:

So games like Solar Jetman, Super Mario 3, Final Fantasy VI, Chrono Trigger, Symphony of the Night, Skullmonkeys, Yoshi's Island, Startropics, MegaMan X4, Battletoads, Zelda III .... these are all the same?

That isn't a far comparison. If the hardware can only do tilemaps, then you are forced to adapt your ideas to working on a tilemap, and to come up with increasingly clever ways of working around the tile map. If you're on a system that does not inherently use a tilemap, such as the PC, there is no such need to limit or reduce your ideas.

As an aside, speaking as someone who has never had a NES (they didn't do great business in Europe - they were easily outsold by the Master System, and most people bought computers instead anyway), what is Solar Jetman like? If you've played Jetman and Jetpac, is it as good as them?

SonShadowCat
Member #1,548
September 2001
avatar

o.O!!

Edit: My program is screwing me over, instead of moving the player in a straight line it goes in diagonals ><

I want to try to figure this out before I post it here, maybe ill be smart for 10 minutes and find out whats wrong -.-

edit2: With only 1 hour to go before I am forced out of my house I ask that you all help me ^^

here is the code for a little program that I made that lets you walk underground through "tunnels" till you reach the ultimate bottom. The whole area is visible( this will be changed)

this is the code for my main source file

#SelectExpand
1#include "allegro.h" 2#include "Player.hpp" 3#define TILE_W 32 4#define TILE_H 32 5 6int main() 7{ 8 allegro_init(); // Initialize allegro 9 install_keyboard(); // Install the keyboard routines 10 install_timer(); // Install the timer routines 11 12 set_color_depth(8); // Set the color depth to 8 13 set_gfx_mode( GFX_AUTODETECT, 800, 600, 0, 0); // Set the screen size to 800x600 14 15 DATAFILE *Images=load_datafile( "c:/C++/Allegro/Tilemap/Tiles.dat"); // Load the data 16 // File containing the tiles 17 18 int trans; 19 20 BITMAP *Tiles[4]; // Create an array of bitmaps to hold the tiles 21 for( int a=0; a<4; a++) // Load all the tiles into the array 22 { 23 Tiles[a] = create_bitmap(TILE_W, TILE_H); // Create bitmaps to blit the tiles to 24 blit( (BITMAP*)Images[a].dat, Tiles[a], 0, 0, 0, 0, TILE_W, TILE_H); // blit the tiles into 25 // The correct space 26 } 27 28 int Map[18][25]={ {0, 0, 0, 2, 2, 0, 0, 2, 0, 0, 0, 0, 0, 2, 2, 2, 0, 0, 0, 2, 0, 0, 0, 0, 0}, 29 {0, 0, 2, 2, 2, 2, 0, 0, 0, 0, 2, 2, 0, 0, 2, 2, 2, 0, 0, 0, 2, 0, 2, 2, 0}, 30 {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 31 {1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1}, 32 {1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1}, 33 {1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1}, 34 {1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1}, 35 {1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1}, 36 {1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1}, 37 {1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1}, 38 {1, 1, 1, 1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1, 1, 1, 1, 1, 1, 1}, 39 {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 3, 3, 3, 1, 1, 1, 1, 1, 1}, 40 {1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 3, 3, 1, 1, 1, 3, 3, 3, 3, 3, 1, 1, 1, 1, 1}, 41 {1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1, 3, 1, 1, 1, 1, 1, 1, 1}, 42 {1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1}, 43 {1, 1, 3, 3, 3, 3, 3, 3, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1}, 44 {1, 1, 1, 1, 1, 1, 1, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 1}, 45 {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}}; 46 // Create the map 47 48 BITMAP *buffer=create_bitmap( 800, 600); // Create a buffer that is 800x600 49 clear_bitmap( buffer); // Clear the bitmap 50 51 BITMAP *background=create_bitmap( 800, 600); // Create a background buffer that is 800x600 52 clear_bitmap( background); // Clear the bitmap 53 54 BITMAP *foreground=create_bitmap( 800, 600); // Create a foreground buffer that is 800x600 55 clear_bitmap( foreground); // Clear the bitmap 56 57 for( int y=0; y<18; y++) // Go down each set of tiles on the y-axis 58 { 59 for( int x=0; x<25; x++) // Go right each set of tiles on the x-axis 60 { 61 blit( Tiles[Map[y][x]], foreground, 0, 0, x * TILE_W, y * TILE_H, TILE_W, TILE_H); // Blit the tilemap 62 // To the buffer 63 } 64 } 65 66 for( int y=0; y<18; y++) // Go down each set of tiles on the y-axis 67 { 68 for( int x=0; x<25; x++) // Go right each set of tiles on the x-axis 69 { 70 blit( Tiles[0], background, 0, 0, x * TILE_W, y * TILE_H, TILE_W, TILE_H); // Blit the tilemap 71 // To the buffer 72 } 73 } 74 75 int mask_color = bitmap_mask_color(foreground); // Find the translucent color 76 int white = makecol(255,255,255); // Color to change 77 78 for(int i=0; i<foreground->h; i++) // Go through enture height of bitmap 79 { 80 for(int j=0; j<foreground->w; j++) // Go through entire width of bitmap 81 { 82 if(trans=getpixel(foreground, j, i) == white) // If white is found 83 { 84 putpixel(foreground, j, i, mask_color); // Change the translucent color 85 } 86 } 87 } 88 89 blit( background, buffer, 0, 0, 0, 0, 800, 600); // Blit the buffer to the screen 90 masked_blit( foreground, buffer, 0, 0, 0, 0, 800, 600); // Blit foreground to buffer and skip 91 // Translucent pixels 92 blit( buffer, screen, 0, 0, 0, 0, 800, 600); // Blit the buffer to the screen 93 94 cPlayer *Player=new cPlayer; 95 96 while( !key[KEY_ESC]) 97 { 98 Player->Draw_Player( foreground); // Draw the player 99 Player->Move( foreground); // Move the player and check for collision detection 100 101 masked_blit( foreground, buffer, 0, 0, 0, 0, 800, 600); // Blit the foreground to the buffer 102 vsync(); 103 masked_blit( buffer, screen, 0, 0, 0, 0, 800, 600); // blit the buffer to the screen 104 } 105 106 return 1; 107} 108END_OF_MAIN();

now here is the code for my player header file

#SelectExpand
1class cPlayer // This is the player class 2{ 3 public: // The following code is public 4 5 cPlayer(); // The constructor 6 7 void Move(BITMAP *foreground); // The function that moves the player 8 9 bool Collision_Detection(BITMAP *foreground, int direction); // The collision detection routine 10 11 void Draw_Player(BITMAP *foreground); // The function that constantly draws the player 12 13 private: // The following code is private 14 15 short unsigned loc_x; // The x coordinate of the player 16 short unsigned loc_y; // The y coordinate of the player 17 short unsigned old_loc_y; // The last y coordinate of the player 18 19 short unsigned jump_limit; // How high the player can jump 20 short unsigned jump; // How much the user has jumped 21 22 BITMAP *Player; // The bitmap that holds the player 23}; 24 25cPlayer::cPlayer() // The constructor 26{ 27 loc_x=SCREEN_W/2; // The player starts off in the center of the x axis 28 loc_y=0; // The player starts off at the top of the screen 29 old_loc_y=loc_y; // The old y coordinate is the same as the current one 30 31 jump_limit=10; // The player can jump 10 pixels 32 jump=0; // The player hasnt jumped yet 33 34 Player=create_bitmap( 10, 10); // Create a bitmap that is 10x10 35 clear_bitmap( Player); // Clear the bitmap 36 circlefill( Player, 4, 4, 4, makecol( 255, 0, 0)); // Make a red circle the player 37} 38 39void cPlayer::Move(BITMAP *foreground) // the function that moves the player 40{ 41 42 bool move; // To check if we can move or not 43 44 if( key[KEY_RIGHT]) // If the user presses the right arrow key 45 { 46 if( move=Collision_Detection( foreground, 1) == false) // If there is no collision detection 47 { 48 loc_x+=3; // Move to the right 3 pixels 49 } 50 } 51 52 if( key[KEY_LEFT]) // If the user presses the left arrow key 53 { 54 if( move=Collision_Detection( foreground, 0) == false) // If there is no collision detection 55 { 56 loc_x-=3; // Move to the right 3 pixels 57 } 58 } 59 60 if( key[KEY_UP]) // If the user presses the up arrow key 61 { 62 if( move=Collision_Detection( foreground, 2) == false) // If there is no collision detection 63 { 64 if( jump<11) // If the user hasnt reached the jump limit 65 { 66 loc_y--; // Increase the y coordinate 67 jump++; // Increase the height that has been jumped 68 } 69 70 if( jump>9) // If the player has reached the limit 71 { 72 loc_y++; // Decrease the y coordinate 73 jump--; // Decrease the height that has been jumped 74 } 75 } 76 } 77 78 if( move=Collision_Detection( foreground, 3) == true) // If there is no ground 79 { 80 loc_y++; // Increase the y coordinate 81 } 82} 83 84bool cPlayer::Collision_Detection(BITMAP* foreground, int direction) // The collision detection routine 85{ 86 int trans; // This will check the color 87 88 if( direction==0) // If the direction is left 89 { 90 if( trans=getpixel( foreground, loc_x-1, loc_y)!=0) 91 { 92 return true; 93 } 94 } 95 96 if( direction==1) // If the direction is right 97 { 98 if( trans=getpixel( foreground, loc_x+1, loc_y)!=0) 99 { 100 return true; 101 } 102 } 103 104 if( direction==2) // If the direction is up 105 { 106 if( trans=getpixel( foreground, loc_x, loc_y-1)!=0) 107 { 108 return true; 109 } 110 } 111 112 if( direction==3) // If the direction is down 113 { 114 if( trans=getpixel( foreground, loc_x, loc_y+1)!=0) 115 { 116 return true; 117 } 118 } 119} 120 121void cPlayer::Draw_Player(BITMAP *foreground) // Draw the player 122{ 123 blit( Player, foreground, 0, 0, loc_x, loc_y, 10, 10); // Blit the player to the foreground 124}

23yrold3yrold
Member #1,134
March 2001
avatar

You'll have to be a bit more specific about the error. He moves diagonally ... so if you push right, he moves up and right? Also remember you should be checking two tiles; at any time there's a 31 in 32 chance the player has one foot on one tile and the other foot on another tile. Check both before you fall. It also might be wise to make your array of tiles a simple struct:
<code>
struct CTile
{
BITMAP* image;
bool walkable;
};
<code>
Now you can check the walkable value of any tile you hit; if it's false, you can pass through it; if it's true, you stop.

BTW, how much of your engine works?

Quote:

You see no change to gameplay from being able to do things like dynamically rotate and deform parts of the world?

For your examples, I'd still use a tilemap for the majority of the level, and make a game object (class CPlatform or something) for the more dynamic parts. No biggie ;) Also, levels on the SNES could rotate too (Contra III, Castlevania 4, the intro to Super Metroid ....)

Quote:

what is Solar Jetman like?

Well, the gameplay mechanics are like Asteroids, but with gravity and huge planetary levels to explore. You have to run around them and collect artifacts, resources, parts, money and haul them back to your mother ship with a tracktor beam. You can upgrade your Jetpod, or run around without it when it blows up ;) It's a very cool game.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Thomas Harte
Member #33
April 2000
avatar

Quote:

> . . . dynamically rotate and deform parts of
> the world?

For your examples, I'd still use a tilemap for the majority of the level, and make a game object (class CPlatform or something) for the more dynamic parts. No biggie

So, it is fair to claim that a tilemap is not sufficient for your needs.

Quote:

Also, levels on the SNES could rotate too (Contra III, Castlevania 4, the intro to Super Metroid ....)

The SNES can rotate an entire tilemap layer, or none of a tilemap layer. It cannot rotate part of a tilemap layer. But that is besides the point - this isn't a conversation about the limiting effects of the SNES hardware, but one about how I feel a lot of people select the tilemap as the representation for their game by default, even though it is not the best representation for them.

What if I wanted a room with that old cliché, walls that move in? A tilemap would not be sufficient, and I'd have to use sprites, which would require either I code that room as a special case, or much improved collision routines over those that would suffice for the normal platform interations with enemies.

What about something more interesting - say two rooms, connected by a piece of string over a pulley? I'd have to use different layers for each room, and either bodge a piece of string together with sprites, or write some non-tilemap code. So again, purely a tilemap is not sufficient.

How about if I wanted a cavernous cave complex, where new passageways could be instantly blasted in the walls? Well, if it were a tilemap, I'd have to severely limit the possibilities for new passageway shapes.

Because a tilemap is nothing more than a bitmap with reduced redundancy (and greatly increased draw costs when talking about adding arbitrary graphics) for repetitive graphics, it is true that any game can be produced using a tilemap. However, most people can come up with various games where just drawing to a bitmap is a better plan. There is a reason that people said Elite on the NES, or that sand level of Earthworm Jim 2 couldn't be done with tilemaps - they simply aren't the best kind of structure for that sort of work, and getting the hardware to work around them was non-trivial.

Finally, most people read a little more into the term 'tilemap', and associate them with limited collision detection routines that don't solve for when collisions happen, but for when the did and you missed it already, with a combination of the tile level map itself and endless hacks for player/world collision detection & usually with very dodgy physics that just about make gravity appear correct, but no more. This is just something to take into account before you all try and recommend a 'tilemap' for everything 2d.

On the Jetman issue, I'm old enough to have read the Jetman comic strip in Crash! magazine, so I have a continuing fond spot for the guy. I'll probably try and seek Solar Jetman through emulation in the next few days, is it purely a NES thing, or is there some Megadrive or SNES version with halfway decent graphics?

23yrold3yrold
Member #1,134
March 2001
avatar

Quote:

The SNES can rotate an entire tilemap layer, or none of a tilemap layer. It cannot rotate part of a tilemap layer. But that is besides the point - this isn't a conversation about the limiting effects of the SNES hardware, but one about how I feel a lot of people select the tilemap as the representation for their game by default, even though it is not the best representation for them.

For most of the examples you give, a tilemap is just fine "for a game" until you find you need something more flexible "for a small piece of a level", while a tilemap is just fine for the other 90% of the game ;). For your blowing holes in walls example, a tilemap or big bitmap would do well, depending on how you came at it. Can't speak for the Earthworm Jim 2 sand level; I have never had opportunity to play it. But I'll assume the rest of the game was tilemaps, if the first was any indication ;)

BTW, Solar Jetman is NES only AFAIK. There could be some Jap-only Super Famicon release I don't know about, but I doubt it.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Thomas Harte
Member #33
April 2000
avatar

Quote:

For most of the examples you give, a tilemap is just fine "for a game" until you find you need something more flexible "for a small piece of a level",

And what if my imagination for level design is not myoptic and I need something more flexible for all my "small pieces of levels"? What if I just want a camera that zooms inward and outward?

It seems to me that you are willing to admit that there are things that cannot be accomplished with a tilemap, but since you personally can't offhand think of any games that would do them quite frequently you write them off. You do realise that not everybody thinks the same?

Quote:

For your blowing holes in walls example, a tilemap or big bitmap would do well, depending on how you came at it.

A bitmap is not a tilemap, so using one would demonstrate that a tilemap is not good enough. Therefore, if you feel a tilemap would be sufficient, tell me how, in the general case, I could support something as simple as permanently adding a line segment - i.e. an equivalent to the Allegro 'line' - to my tilemap, without it becoming a very inefficient data structure, with especial reference paid to the bounds of current hardware acceleration. To remind you :

Quote:

Can't speak for the Earthworm Jim 2 sand level; I have never had opportunity to play it. But I'll assume the rest of the game was tilemaps, if the first was any indication

The whole thing was tilemaps, it being yet another unimaginative platform game, sold like most commercial titles principly on hype and secondarily on gameplay.

23yrold3yrold
Member #1,134
March 2001
avatar

Quote:

It seems to me that you are willing to admit that there are things that cannot be accomplished with a tilemap, but since you personally can't offhand think of any games that would do them quite frequently you write them off. You do realise that not everybody thinks the same?

But of course. :) But most games take place in a 99% static environment. I can look over my fairly large collection of games, leaf through a few EGM's and see it everywhere. Sure there are games like (I think the name is) Red Faction, where you can blow holes in the 3D level, and the level "re-writes" itself to put a big hole where you just fired your rocket. IIRC, that was the game's big selling point, and recieved very lackluster reviews. It was a tech demo first and gameplay second (I can say that for more games than I'd like nowadays).

Quote:

tell me how, in the general case, I could support something as simple as permanently adding a line segment

Personally, I'd just add a CLine object to my list of game objects. 20 lines of code.

As for the first Earthworm Jim, I thought it was pretty imaginative. The lightless level, the bungie jumping, riding around on a hamster, For Pete's Sake, etc. Tilemaps don't really restrict one's imagination.

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Thomas Harte
Member #33
April 2000
avatar

Quote:

Personally, I'd just add a CLine object to my list of game objects. 20 lines of code.

From which two conclusions flow :

  • tilemaps are not sufficient

  • you are unwilling to be drawn into a genuine conversation
  • Quote:

    Tilemaps don't really restrict one's imagination.

    So you believe that if I go away and arbitrarily invent a 2d game, I will later discover that all my ideas are catered for by tilemaps? All your examples to date have been games that were forced to use tilemaps from the start and all ideas were conceived with that knowledge.

    23yrold3yrold
    Member #1,134
    March 2001
    avatar

    Quote:
    • tilemaps are not sufficient

    Odd line of reasoning. Tilemaps aren't suficient for bullets or enemies either. So? Just as with the line, I'll use something else.

    Quote:

    So you believe that if I go away and arbitrarily invent a 2d game, I will later discover that all my ideas are catered for by tilemaps?

    No, but so far, I have, and what small examples you've given aren't enough to convince me otherwise. Thanks for your input though ;)</li>

    --
    Software Development == Church Development
    Step 1. Build it.
    Step 2. Pray.

    SonShadowCat
    Member #1,548
    September 2001
    avatar

    and the post counts keep getting higher!

    23yrold3yrold
    Member #1,134
    March 2001
    avatar

    Not mine. I better stop posting before I bottom out ....

    --
    Software Development == Church Development
    Step 1. Build it.
    Step 2. Pray.

    Thomas Fjellstrom
    Member #476
    June 2000
    avatar

    No! you should keep going till you have -3000 posts ;)

    --
    Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
    "If you can't think of a better solution, don't try to make a better solution." -- weapon_S
    "The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

    23yrold3yrold
    Member #1,134
    March 2001
    avatar

    Quiet. You're supposed to be jumping a shark or something. ;)
    (actually, now that I think about it, that's rather sick .....)

    --
    Software Development == Church Development
    Step 1. Build it.
    Step 2. Pray.

    Thomas Fjellstrom
    Member #476
    June 2000
    avatar

    Well... That does sound more fun than talking about your post count ;) so OK, I suppose I can get an extra shark for you so you don't feel left out ;D

    --
    Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
    "If you can't think of a better solution, don't try to make a better solution." -- weapon_S
    "The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

    23yrold3yrold
    Member #1,134
    March 2001
    avatar

    No, no, that's quite all right. You go ahead without me; I'll stay behind and watch movies on your 110 foot TV.

    --
    Software Development == Church Development
    Step 1. Build it.
    Step 2. Pray.

    Thomas Fjellstrom
    Member #476
    June 2000
    avatar

    hehe... I'll tell you one thing, It wasn't Shaq's foot I used to measure the TV ;)

    --
    Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
    "If you can't think of a better solution, don't try to make a better solution." -- weapon_S
    "The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

    SonShadowCat
    Member #1,548
    September 2001
    avatar

    about my problem, im still stuck

    I dont get it, I wrote my code so that there WOULD be collision detection but there aint any ><

    the ball just goes straight down ><
    and the ball leaves a trail behind it, I tried clearing the buffer and foreground but the trail is still there

    (look at above code for reference) anyone got any ideas?

    Gabhonga
    Member #1,247
    February 2001
    avatar

    1. your jump code is pretty screwed up ;-)

          if( jump<11)  // If the user hasnt reached the jump limit 
          { 
            loc_y--;  // Increase the y coordinate 
            jump++;  // Increase the height that has been jumped 
          } 
     
          if( jump>9)  // If the player has reached the limit 
          { 
            loc_y++;  // Decrease the y coordinate 
            jump--;  // Decrease the height that has been jumped 
          }
    

    when looking at this a bit closely and thinking about it, you should see why your player is moving kind of strange...try having a variable to decide whether the player is jumping up or down, and check this before adjusting the players heighth...i.e.

    1static int jumping = 0; //indicates wether the player is thrusting up or just standing or falling
    2static int jump; //like your linear counter style jump...of course gravity would look better ;-)
    3//...
    4//later in code, when checking input...:
    5//...
    6//first we check wether the player is falling down...
    7//wich could also happen because he's just walked down an edge!
    8if(jumping==0) //is the player supposed to be standing on ground?
    9{ if(Collision_Detection( foreground, DOWN) == false ) //erm...so that there's no collision
    10 { jumping=2; } //player walked off edge and is now falling...
    11 else if( key[KEY_UP] )
    12 { jumping=1; //mark the player as jumping up!
    13 jump=11; //may jump up 11 pixels
    14 }
    15}
    16if(jumping==1)
    17{ if(Collision_Detection(foreground,UP)==true) //boinked head into wall??
    18 {jump=0; jumping=2;} //mark player as falling
    19 else if(jump) { locy--; jump--; } //else move the player up a little further...
    20}
    21if(jumping==2) //falling down...
    22{ if(Collision_Detection(foreground,DOWN)==true)
    23 { jumping=0; } //hit ground, now standing
    24 else loc_y++; //or fall a little deeper..
    25}

    try out this trick...better would of course be to implement velocities and a kind of gravity, that looks smoother.

    about the trail: are you clearing the buffer you blit all your stuff on every frame?

    well hope this fixes some of your problems...

    --------------------------------------------------------
    sigs suck

    SonShadowCat
    Member #1,548
    September 2001
    avatar

    ohhhh, pretty code, thx

    Yes, I am clearing the buffer every frame

    Gabhonga
    Member #1,247
    February 2001
    avatar

    duh...I've looked at your code again, and now see what you're doing wrong...
    in your main function you should change some little bits:

    1. clear your buffer thingie, i.e. by blitting background over it...

    2. masked_blit the foreground onto it (or, what would be better, have your tileset drawing routines here wich you've used to setup your foreground BITMAP)

    3. NOW draw the player onto the buffer, not onto foreground!

    4. sync and blit the buffer to screen.

    this should fix your trail problem :-)

    however, your collision detection also still seems a little improvised to me, and as this doubles up with your movement routines, there's still a little work to do to implement basic features...for example, like it's now you may run slopes down, but not up!!

    [eDiT] OoOps I made a mistake in the jumping code above!! like i've presented, the player would hover in mid-air when he finished floating up or hit a wall :D;D:D

    hmm, to correct this...

    //...change this...
    
    { if(Collision_Detection(foreground,UP)==true) //boinked head into wall?? 
    
    //into this!
    
    { if((Collision_Detection(foreground,UP)==true) || (jump==0))
    

    as silly as I am I forgot about that case when I wrote it up here :-b

    --------------------------------------------------------
    sigs suck

    SonShadowCat
    Member #1,548
    September 2001
    avatar

    ok there is no trail now, another problem popped uo from that

    since my circle doesnt cover the whole bitmap assigned to it I decided to masked_blit it to the buffer, but that causes the circle to now move... do I just keep it the way it was before?

    edit: Why the hell isnt my collision detection function working? I know its bad but shouldnt it still work?

     1   2 


    Go to: