Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,537

Highs & Lows

Sign in to follow this  
Guest

329 views

The Highs:Juston has finished the label for Hunchy 2 and it looks amazing (see below). My first Atari cart release looks set to happen real soon, and I can't wait to see the finished product. The 2005 minigame multicart is also coming along nicely, and will contain some of my minigames (Hunchy, Jetman & Nightrider). The deadline for the minigame competition is also nearly here and I hope my games will do well, though the competition is tough.The Lows:I have booked my flights and accomodation from the UK to attend the vgXpo (formerly PhillyClassic), but it seems they have now turned it into some kind of family entertainment event. The classic arcades museum won't be there, and it looks like AA might be pulling out as well. This is a major pain as it will probably be my only chance to attend a large US classic gaming show, at least for a few more years. I will probably still be going as it is too late to cancel, but it isn't what I was expecting. I am also still stuck on the PoP falling tiles problem. I implemented the solution outlined last time, using the ball sprite to show the tile briefly falling, but there was an obvious flaw in the plan that I don't spot until it was done. The floor tiles are 16 pixels wide, but the ball can only be stretched to 8 pixels, meaning that the falling tiles were too small! I can't use the missile sprites (stretched double) as this will affect the player and object sprites also, so this just leaves the playfield (PF). The problem here is that the wall tiles are 32 pixels wide (8 PF pixels), so there may be an overlap between a wall segment and a falling tile, even though the falling tile will not actually overlap the wall (if this makes sense!). What this means is that I would need to define each wall tile twice: once as normal, and a second time to show the falling tile. The second one could then be substituted briefly for the first to show the tile falling. However, this will require a lot of memory (12 tiles * 27 bytes * 2 = 648 bytes!). I could reduce the wall tiles to 16 pixels wide (4 PF pixels), but then the screen data would require a lot more space, and the kernel would become more complex. Neither of these solutions sounds appealing. Therefore, I am steering towards one of the following:

  1. Just make the tiles disappear (as in the current version).
  2. 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: ----___
  3. Don't attempt to draw the falling tile in the wall area, just flash the floor tiles on/off in the floor rows underneath.

The third one sounds the best compromise, so I will try this out in the next release unless anyone has any more suggestions? In the meantime I think I am going to switch off the computer and have a well-deserved break from it all!EDIT: The following mockup shows what option 2b would look like:Chris

Sign in to follow this  


9 Comments


Recommended Comments

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 :x)

 

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? :sad:

 

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

 

Greetings,

Manuel

Share this comment


Link to comment

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

 

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.

Share this comment


Link to comment
Uihjah... at least the highs seem to outweigh the lows :x

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? :sad:

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

Share this comment


Link to comment
Holy smokes, I just read the thread about vgxpo - like watching a train wreck.  Yikes.  :sad:

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

Share this comment


Link to comment
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.

Share this comment


Link to comment
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

Share this comment


Link to comment
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. :sad:

Share this comment


Link to comment
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.  :sad:

 

I figured that might be the best way :x 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

Share this comment


Link to comment
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.

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...