The Southsider

Hi there!

 

Uihjah... at least the highs seem to outweigh the lows

 

vgxpo will still be a very worthwhile event I'm sure.

 

And there's allways some hit-or-miss experiments going on while developing a complexer game. (There's dozens of Star Fire dead-ends in the [stella] archives. There's binaries with different crosshairs, different starfields, different lasers, even intermission levels with meteor storms... all for nothing, just gained me a handful of experinece points )

 

I'm not sure if I understood "3." fully. You mean that you'll only have a falling tile, when there's free space underneath for it to really fall? That'd be just realistic then, no?

 

Other than that, 2.b sounds best to me.

 

Greetings,

Manuel

Holy smokes, I just read the thread about vgxpo - like watching a train wreck. Yikes.

 

I think the flicker idea (2.a?) sounds best. The tiles will be falling somewhat rapidly, so the flicker won't be very noticeable. If you can get the falling animation in somehow it will be much better IMO.

Uihjah... at least the highs seem to outweigh the lows

vgxpo will still be a very worthwhile event I'm sure.

 

Thanks - that is what I am hoping. It will be a shame if AA doesn't make it though, as I was hoping to meet Al, etc for the first time.

 

I'm not sure if I understood "3." fully. You mean that you'll only have a falling tile, when there's free space underneath for it to really fall? That'd be just realistic then, no?

Other than that, 2.b sounds best to me.

 

Possibly - the idea with 3 is not to draw the tile actually falling, but to switch the floor tiles on/off in the path that the tile would fall in sequence until a point where it wouldn't be possible for the tile to fall anymore. It is a bit difficult to explain, but this seems like a good solution to me, as I would have to check the path of the falling tile in any case. Hopefully this should be a bit clearer when I get a chance to implement it. I may combine this with 2 if it doesn't work out.

 

Chris

Holy smokes, I just read the thread about vgxpo - like watching a train wreck.  Yikes. 

I think the flicker idea (2.a?) sounds best.  The tiles will be falling somewhat rapidly, so the flicker won't be very noticeable.  If you can get the falling animation in somehow it will be much better IMO.

 

Yes, people seem to be dropping out of the show like flies - I am going to work out how much it will cost to cancel/change my flights tomorrow. I am going to try a range of different tile falling options and see which one looks best, starting with 3 which I think will be the easiest to implement.

 

Chris

Draw the falling tile using the 8-pixel ball sprite, but flicker the left/right sides on alternate frames, or draw the tile in two halves like this: ----___

 

Hey, the fact that the tiles are crooked when they fall is a "feature". In reality, do you think the tiles would always fall perfectly straight?

 

IMHO, having the tiles skewed like that is definitely the way to go. It should look reasonable, and would fit perfectly with what your kernel is already doing for the sword. I don't know if you're still using the trick I mentioned earlier of just loading HMBL once at the start of screen, hitting HMOVE every two lines, and setting the starting position of the sword to compensate, but if you are all you'd have to do would be to change the initial-position logic and store a $80 in HMBL and you'll be all set.

IMHO, having the tiles skewed like that is definitely the way to go.  It should look reasonable, and would fit perfectly with what your kernel is already doing for the sword.  I don't know if you're still using the trick I mentioned earlier of just loading HMBL once at the start of screen, hitting HMOVE every two lines, and setting the starting position of the sword to compensate, but if you are all you'd have to do would be to change the initial-position logic and store a $80 in HMBL and you'll be all set.

 

I haven't implemented that trick yet, but it is on my to-do list. It is still necessary to switch on/off the ball on the appropriate scanlines, but it should save some space in the kernel. The biggest difficulty is figuring out the starting position for the ball at the top of the screen.

 

Chris

IMHO, having the tiles skewed like that is definitely the way to go.  It should look reasonable, and would fit perfectly with what your kernel is already doing for the sword.  I don't know if you're still using the trick I mentioned earlier of just loading HMBL once at the start of screen, hitting HMOVE every two lines, and setting the starting position of the sword to compensate, but if you are all you'd have to do would be to change the initial-position logic and store a $80 in HMBL and you'll be all set.

 

I haven't implemented that trick yet, but it is on my to-do list. It is still necessary to switch on/off the ball on the appropriate scanlines, but it should save some space in the kernel. The biggest difficulty is figuring out the starting position for the ball at the top of the screen.

 

Chris

Thomas and I used that technique extensively in our old PoP demos - I found that the easiest way to figure the correct starting position was by...trial and error! I would do a little rough calculating to get close and then plug in values until it was perfect.

 

Dirty, but effective.

Thomas and I used that technique extensively in our old PoP demos - I found that the easiest way to figure the correct starting position was by...trial and error!  I would do a little rough calculating to get close and then plug in values until it was perfect. 

Dirty, but effective. 

 

I figured that might be the best way It would be very difficult to figure out the correct value when the sprite wraps from one side of the screen to the other. Did you have any neat way of turning the sprite on/off in your old kernel, or do you just use switchdraw for this?

 

Chris

Thomas and I used that technique extensively in our old PoP demos - I found that the easiest way to figure the correct starting position was by...trial and error!  I would do a little rough calculating to get close and then plug in values until it was perfect. 

Dirty, but effective. 

 

I figured that might be the best way It would be very difficult to figure out the correct value when the sprite wraps from one side of the screen to the other. Did you have any neat way of turning the sprite on/off in your old kernel, or do you just use switchdraw for this?

 

Chris

Well...wrapping the screen isn't too hard.

 

I'd just do something like this:

   lda TargetXValue
  clc
  adc Offset
  cmp #160
  bcc EverythingAOkay
  sec
  sbc #160
EverythingAOkay
  sta InitialPosition

And by sprite you mean the ball, right? What did I do?...have to go look.

[...]

Heh, I used a routine I came up with a while ago. In this case it is one cycle faster than SwitchDraw.

   lda BallHeight
  dcp BallYPosition
  sbc BallAdjuster
  sta ENABL          ;+14    40

For a tile two lines high you could use this variation:

   lda #2
  dcp BallYPosition
  sbc #0
  sta ENABL          ;+12

If you want to look at the source for my last PoP demo, let me know and I'll PM it to ya.