Utilising Non-Tileset Backgrounds

[GrooveMan.exe]

This is probably one of those simple/straightforward problems that I'll feel silly for asking about; but hey, that just means it'll be replied to faster.

Ok, so for my project, I don't want my maps to be tile-based. Instead, I want to use backgrounds I've already drawn (large enough to fill up that particular map, obviously), and instead use invisible tiles for collision detection. I'm pretty sure this is possible (I swear I've seen it done before), but I'm really not sure how to go about it. Any suggestions/instructions?

 

[Brewmeister]

There is a solution using panoramas. Do a search. You need to install 1 small script to keep the panorama from moving slower than the map.
However, this prevents you from using panoramas.

The other option is to slice your drawn map up into 256 pixel wide (vertical) slices, and stack them into a tileset.
The nice thing about this is you can still set passability on the tileset while looking at your map parts.
You can also copy objects like trees, that you might want to walk behind to another section of the tileset.

Be Well

 

[GrooveMan.exe]

Ah, I understand. I'll have a play around with both methods.

Also out of curiosity, is the situation any different on RMVX?

Edit: Oh, and I would appreciate more detail on the script I'd need to utilise the panoramic functions. Assuming I won't need a panorama (under it's intended functions, anyway), I can use the panorama layer for the drawn background, and then use the other sprite layers for passable objects like trees and other crap, right? Because that would be perfect.

Actually, I've not used panoramas before either. Darn.

 

[Unka Josh]

BTW, don't forget that if you do the non-tile-based version, you won't be able to have anybody move behind trees or bushes without a chunk more work.

 

[GrooveMan.exe]

Work isn't necessarily a problem. I'm not expecting this thing to make itself, even if "IT'S ALMOST LIKE CHEATING!".

Upon trying the same thing in RMVX, I've noticed that you can have the parallax layer show on-screen, which is useful. And sprites on other layers still retain their depth-perception function, which is just peachy. (I hate the RTP sprite style, but that'll all be custom soon enough). I figure it'll be easier utilising the system in VX over XP then.

Now I just need to work out how to get the panorama to stand still when I walk from side to side, and we're cool; and I can worry about the other engine mechanics I'll have to pour over to get working. =D

 

[Brewmeister]

In XP, it's this section of Spriteset_Map

# Update panorama plane
@panorama.ox = $game_map.display_x / 8
@panorama.oy = $game_map.display_y / 8

If you look just above, the origin (ox,oy) is set to map.display_# / 4

This means the panorama is moving half as fast as the map.

change those 8's to 4's, and you're gold!

I assume VX is the same, but alas I have no VX

Be Well

 

[GrooveMan.exe]

Wow, this site is a greeat deal more helpful than it was half a year ago.

Looking in the VX version of Spriteset_Map, I can see two bits of code that pertain to panoramas.

  #--------------------------------------------------------------------------

  # * Create Parallax

  #--------------------------------------------------------------------------

  def create_parallax

    @parallax = Plane.new(@viewport1)

    @parallax.z = -100

  end

and

  #--------------------------------------------------------------------------

  # * Update Parallax

  #--------------------------------------------------------------------------

  def update_parallax

    if @parallax_name != $game_map.parallax_name

      @parallax_name = $game_map.parallax_name

      if @parallax.bitmap != nil

        @parallax.bitmap.dispose

        @parallax.bitmap = nil

      end

      if @parallax_name != ""

        @parallax.bitmap = Cache.parallax(@parallax_name)

      end

      Graphics.frame_reset

    end

    @parallax.ox = $game_map.calc_parallax_x(@parallax.bitmap)

    @parallax.oy = $game_map.calc_parallax_y(@parallax.bitmap)

  end

There's also a 'dispose of parallax' section, but we don't want that. Update Parallax seems to have the equivalent of what you're suggesting ("@parallax.ox = $game_map.calc_parallax_x(@parallax.bitmap)"), but it's relating the updating to a different variable. I assume it's telling the system to update the parallax location according to the new position of the game window; which is harder to change.

I'll try just copy/pasting the code you're aware of to replace those lines, and see what happens. Actually, since this is ruby-related, the help files might actually be useful this time.

Edit: Turns out that the code you suggested works just fine. It seems that in VX, setting that number to 4 will make the panorama scroll too quickly, and 8 is the appropriate number. Hell yes, things just got easier and interesting. Thanks a bunch.

 

[Brewmeister]

Ok, look at update_tilemap. IT's still

@tilemap.ox = $game_map.display_x / 8
@tilemap.oy = $game_map.display_y / 8

If you want all of your parallax positions to be the same as that, just set in update_parallax...

@parallax.ox = $game_map.display_x / 8
@parallax.oy = $game_map.display_y / 8

Otherwise, you'll have to go look at calc_parallax_x (and _y) in Game_Map

You're on your own here, because although I have the VX scripts, I don't have VX running so I don't know the parallax options.

Be Well

 

[GrooveMan.exe]

Oh no, don't worry - it's cool. The code you gave me beforehand works exactly as it needed to.

Oh dear, I've made you go out of your way. Sorry. :V

 

[Brewmeister]

Oh dear, I've made you go out of your way. Sorry. :V

That sounded a little sarcastic. I don't "go out of my way" (at least, not far). I enjoy solving problems & helping out.

I think I would still lean toward the Tileset solution. Just because it gives you more flexibility.

Be Well