AuthorTopic: Sprite vs Background, ongoing battle  (Read 9486 times)

Offline Stwelin

  • 0011
  • **
  • Posts: 567
  • Karma: +0/-0
    • View Profile

Re: Sprite vs Background, ongoing battle

Reply #20 on: January 18, 2007, 03:16:35 pm
Thanks fawel. I coded my own engine, and i've always done so. I've been a programmer for a much longer time than a pixel artist. I did think about doing an autotiler, but there are some kinks that i need to work out. For example, the edit you did doesn't include the little 'diagonal' tiles that are on the 4 corners of the second set in my tiles, if you had a ledge like this:

   |
   |____
  x

Where the "x" is would be a blank tile, and the ones to the right of it and above it would end abrubtly.

I am thinking of giving the "block" or "platform" instance a variable that will change depending on how it's positioned and what surrounds it. Then, a block that is where the "x" is could check the variables of the blocks around it, and then it would know to become a cornerstone, persay.

Thanks for the example. i really appreciate the ideas.

(oh, btw, i am using the hspeed function in gamemaker to move the character, but i have not worked out ramps/slopes yet, not sure if it's entirely possible if you use anything but X displacement, however, i like the mario-esque smoothness and friction you get from using horizontal speed.)

Offline fawel

  • 0001
  • *
  • Posts: 62
  • Karma: +0/-0
    • View Profile

Re: Sprite vs Background, ongoing battle

Reply #21 on: January 19, 2007, 12:30:49 am
Do not use hspeed, use jump to position(x+3 for keypress right, etc0 , theres a dnd function for it.  That way when you do slopes, you can code " x+3, y+1 "  It's kind of complicated, but I really recommend you look at the foxengine to get a better idea of how it works.

Foxengine

(I know this isn't pixel-related, just trying to help)

Offline Stwelin

  • 0011
  • **
  • Posts: 567
  • Karma: +0/-0
    • View Profile

Re: Sprite vs Background, ongoing battle

Reply #22 on: January 19, 2007, 02:42:07 am
That's the thing, i think that when you do x displacement it makes the game look really tacky. i like having friction and it gives the player better feel for control.  I hate the fact that going up slopes using X displacement also makes you go like 2 times as fast as on flat ground.

on a more 'on-topic' note, here are some screenshots with updates:



You'll notice i've taken out the highlights on the tiles to make the style match the character more. That also gives an example of the circular menu system which i've implemented. you carry 6 items at a time. as i said before it's an adventure/puzzle/exploration game.

Offline Xion

  • 0100
  • ***
  • Posts: 1551
  • Karma: +0/-0
    • View Profile
    • FourbitFriday

Re: Sprite vs Background, ongoing battle

Reply #23 on: January 19, 2007, 02:55:55 am
I used GM for a hot second forever ago, and it prob'ly changed alot since then, but can you make it so that...

If you're on a slope and pressing the movement button, your maximum horizontal speed lowers, but the y + 1 or something? Or maybe make it so that if you're in contact with a slope, something like "slope = true," the character behaves differently with the movement button presses...? Like, if slope = 0, move like normal, but if slope = 1 & key pressed, horizontal movement = relative speed + 1 & vertical movement = horizontal speed/2...?
So that way, when he's going up the slope with acceleration, his horizontal speed won't exceed the actual angle of the slope.

Well, if that can't be done, I apologize for injecting this problem with my stupidity.

Oh, by the way, those screenshots look freaking delicious...and did you ever fix the sprite+bg problem?

Offline Stwelin

  • 0011
  • **
  • Posts: 567
  • Karma: +0/-0
    • View Profile

Re: Sprite vs Background, ongoing battle

Reply #24 on: January 19, 2007, 03:55:43 am
To be honest GM is really pretty buggy when it comes to using its built in functions such as 'hspeed' and all those things. The code should work in theory, but it's a bitch to actually get GM to do it correctly. (pardon my language) I know how to do it if you use a simple code like:

Code: [Select]
if left_pressed = true
{
x -= 1
}

because the charcter's 'hspeed' is always 0 when you use that method, eliminating the possibility that he will clip into the wall, which is basically what happens when you use hspeed, and it's only correctable when dealing with non-slope obstacles. I try to get away from the drag+drop feature so i have control over the scripting. i mainly use it because i am too lazy to learn a better dev. language. I am thinking of trying out pygame, but the level design would be a nightmare. (GM gives a nice little implement to put together levels and rooms.)

But let's get away from the coding, i'll deal without slopes for the time being. I did fix the sprite and background problem for the most part. the character actaually has an alpha-fade shadow now, although it's sort of countering the pixelart, but nothing too noticeable. (just enough to keep the character in the foreground) plus with the idle animations and all that, it should be no problem.