So you got it working? Cool Toldja it was easy

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?

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.

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

now here is the code for my player header file

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

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?

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?

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 :

line

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

From which two conclusions flow :

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.

and the post counts keep getting higher!

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

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

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

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.

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...

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

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