How to walk pixel by pixel instead of tile by tile?

[sheamkennedy]

I was wondering if there is a tutorial out that shows me how to override the Up, Down, Left, Right so that instead of making them move my hero the normal tile-by-tile, I can instead code the hero to move pixel-by-pixel. I was trying to find stuff like this on my own but really didn't know what to search.

Also is this where we post this kind of stuff now?

[Bob the Hamster]

Yep, this is the place for this kind of question! :)

Pixel-by-pixel movement is something I would love to someday support natively in the editor, but for now, yes, it can definitely be scripted.

You will be using the "read pass block" command to read the wallmap in each of the four corners of your hero walkabout, and you will be handling x and y movement yourself (probably with globals) Most hero map movement commands will become useless, but you can script your own equivalent commands.

I think the best place to start is one of the many example sidescroller scripts. http://rpg.hamsterrepublic.com/ohrrpgce ... ling_games

Pixel-movement in the OHRRPGCE is exactly the same a sidescroller movement, without any gravity or jumping.

[Urkelbot666]

Great! I was hoping to implement something like this at some point to give The Fly a more authentic Atari Joystick feel

[kylekrack]

Stand is a sidescroller without any gravity or jumping. I don't remember if I included a script file with that game. I should have.

It still may not be much help though. I'm looking back at it and I've come to discover I don't even know anymore myself how this game works.... I, uh, think I might need to spend some time refamiliarizing myself with my own game.

[Taco Bot]

I'm actually working on something similar. I was wondering, is there a version of the "read pass block" function that uses pixel values instead of tiles?

[Gizmog]

I'm actually working on something similar. I was wondering, is there a version of the "read pass block" function that uses pixel values instead of tiles?

Well, you could always divide the pixel value of whatever tile you're askin about by 20 and pass that number onto ReadPassBlock.

[Spoonweaver]

Even though it's unlikely that anyone will ever actually use a tech demo's script, my game somekindaninja has a script for walking around in a pixel based way and is open to you if you'd like to look at it or edit it in any way shape or form.

somekindaninja LINK:
http://www.slimesalad.com/forum/viewgame.php?t=1882

[Taco Bot]

Well, you could always divide the pixel value of whatever tile you're askin about by 20 and pass that number onto ReadPassBlock.

I am currently doing this, but since I'm using it with walktall, it's a little bit... iffy.
The down/right collisions work fine, but up has a few problems and left is straight up broken.

Here's the scripts, in case you want to see them:

Code: Select all

global variable (1,playerx)
global variable (2,playery)

plotscript, newgame, begin
	#Nothing, as of yet.
end

plotscript, mapautorun, begin
	write global (1, (hero x (0) * 20))
	write global (2, (hero y (0) * 20))
	suspend player
	embiggen heroes
	while (0 == 0) do (
		put hero (0, playerx, playery)
		wait (1)
		
		if (key is pressed (key:Up)) then (
			if (read pass block (playerx / 20, playery / 20 -- 1) == 0) then (
				playery -= 1
				set hero direction (0, up)
			)
		)
		
		if (key is pressed (key:Down)) then (
			if (read pass block (playerx / 20, playery /20 + 1) == 0) then (
				playery += 1
				set hero direction (0, down)
			)
		)
		
		if (key is pressed (key:Left)) then (
			if (read pass block (playerx / 20 -- 1, playery / 20) == 0) then (
				playerx -= 1
				set hero direction (0, left)
			)
		)
		
		if (key is pressed (key:Right)) then (
			if (read pass block (playerx / 20 + 1, playery / 20) == 0) then (
				playerx += 1
				set hero direction (0, right)
			)
		)
		
		if (key is pressed (44)) then (
			if (hero frame (0) == 1) then (
				set hero frame (0, 0)
			)
			else (
				set hero frame (0, 1)
			)
		)
	)
end

script, embiggen heroes, begin
	variable (hero, sl)
		for (hero, 0, 3) do (
			if (hero by rank (hero) >= 0) then (
			sl := get hero slice (hero)
			embiggen walkabout slice (sl)
			)
		)
end

script, embiggen walkabout slice, sl, begin
	variable(pic sl, pic num) if(sl) then(
		pic sl := lookup slice(sl:walkabout sprite component, sl)
		pic num := get sprite set number(pic sl)
		replace hero sprite(pic sl, pic num)
	)
end 

[Spoonweaver]

It had nothing to do with the fact that you're using walktall.
In order to avoid letting the player walk into walls you have to check each corner of the hit box for wall collisions.
playerx & playery actually point to the upper left corner of the hero sprite hit box. So anything other than the upper left pixel of the hit box will slip right into walls because you're not checking for that.

[Taco Bot]

It had nothing to do with the fact that you're using walktall.
In order to avoid letting the player walk into walls you have to check each corner of the hit box for wall collisions.
playerx & playery actually point to the upper left corner of the hero sprite hit box. So anything other than the upper left pixel of the hit box will slip right into walls because you're not checking for that.

So, you're saying that I need to do something like this?:

Code: Select all

if (read pass block (playerx / 20, playery / 20 -- 1) == 0) then (
     if (read pass block ((playerx + 32) / 20, playery / 20 -- 1) == 0) then (
          if (read pass block (playerx / 20, (playery + 40) / 20 -- 1) == 0) then (
               if (read pass block ((playerx +32) / 20, (playery + 40) / 20 --1) == 0) then (

Edit: Tried that. It only screwed up my game further... ;(

[Spoonweaver]

as far as I know, playerx still points to the upper left pixel of the hero box, not the sprite, while walktall is active.
*This might not be true.

However, in any case, it would only need to check 2 of the corners in each direction, as it would be impossible for a left based pixel to go through a wall while only going right.

Code: Select all

if (key is pressed (key:Up)) then (
        
if (read pass block (playerx / 20, playery / 20 -- 1) == 0) then (
     if (read pass block ((playerx + 20) / 20, playery / 20 -- 1) == 0) then ( 
            playery -= 1
            set hero direction (0, up)
         ) )
      ) 

if (read pass block (playerx / 20, playery / 20 -- 1) == 0) then (
if (read pass block ((playerx + 32) / 20, playery / 20 -- 1) == 0) then (

[TMC]

It's crazy that there are so many sidescrollers made with the OHR, but few examples of RPGs with pixel-based movement, even though that would make vastly more sense to do. I guess the reason for it is that we have the Sidescrollers 101 scripts, but I can hardly name any games that even had pixel-based movement, let alone releasing scripts. I think we really ought to have a SS101 equivalent. And also I'd love to see the engine support it directly, of course.

Heh... I completely forgot that I wrote a bunch of scripts for pixel based movement for Eldardeen back in 2007 (not in the download). These scripts are awfully complex, containing all kinds of bells and whistles like collisions with edge-on walls, primitive pathfinding, and 4-frame walk animations. I think it would be better to start over though anyone who wants can have them. I seem to recall that Mogri had really nice support for diagonal walls in something.

Code: Select all

   write global (1, (hero x (0) * 20))
   write global (2, (hero y (0) * 20)) 

Don't do that (there's several thing in bad taste here). Write "playerx := hero pixel x (0)", etc.

Also, to check the topright corner for collisions, you should use x = (playerx + 19) / 20 rather than (playerx + 20) / 20, otherwise you'll find it's impossible to walk through a 1 tile wide gap. But you should not use 1-tile wide gaps at all unless you automatically get realigned with the grid when you nick the corner of a wall. Which is easy to do, but looks bad unless you spread large realignments over several frames,

[Spoonweaver]

I think you're over valuing ss101. I might have been the only one to use it and I altered it greatly. I think the reason for more platformers than pixel based movement is because when you make a platformer you're ok with doing away with all the rpg aspects of the ohr. With pixel based movement you're breaking doors and npcs in your rpg. The idea of rewriting a bunch of stuff for an rpg in an engine that already makes rpg's is likely a turn off.

As for reducing the size of the hitbox to +19 instead of +20, I agree but ideally you wouldn't stop there. It would be best to make the hitbox centered around just the feet. Meaning something like:

Code: Select all

playerx+4,playery+15
playerx+4,playery+20
playerx+16,playery+15
playerx+16,playery+20

[Taco Bot]

Oosh. At this point, it seems I've already messed up quite a lot of the code. Perhaps I'll just start from scratch, and thy to make it a bit neater this time.

[TMC]

I think you're over valuing ss101. I might have been the only one to use it and I altered it greatly.

I was going to link to the list on the wiki to prove my point, but it only lists games based on SS101 by you and me. It is 5 years out of date, but I can't remember what's been released in that time.

I also found this: Zelda-style games, which is a very sad article. (Can anyone name any others?)

I think your observation about platformers vs pixel-based movement probably is most of the reason. A lot of trouble for little payoff.

As for reducing the size of the hitbox to +19 instead of +20, I agree but ideally you wouldn't stop there. It would be best to make the hitbox centered around just the feet.

You're quite right, although one has to make sure to design the maps/tilesets so that overlapping a wall by several pixels horizontally doesn't look bad.