Jump to content

Photo

Indenture


39 replies to this topic

#26 Zoyx OFFLINE  

Zoyx

    Stargunner

  • 1,538 posts
  • Prominent Internet User
  • Location:Anchorage, AK

Posted Wed Sep 9, 2009 7:47 AM

Older version by Nukey

#27 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,582 posts
  • Location:The land of Gorch

Posted Wed Sep 9, 2009 11:14 AM

I really like the idea of Indenture on the 2600... Sounds like the idea of a using a 3-line kernel for it was a non-starter, so I took the liberty of trying a 2-line kernel that might work without having to interlace.

It's actually a hybrid 4-line/2-line kernel: P1/P0/ball updates each 2 lines + PF updates each 4 lines (of course, 6 PF writes each line since it's asymmetrical.)

The pros are it works, and there are actually 20+ cycles free each loop for additional logic. And it's not TOO much of a RAM hog (doesn't require a PF index, for one thing.)

The cons are it requires a page per graphic image, which is a huge waste of ROM. On the upside, those 20+ cycles might be used to re-work it so it doesn't have to do that.

Thoughts?

The real downside is that it burns 7 bytes of temp ram above the original game. I'm currently trying to figure out a way to save ram among objects. Merging delta with state is one way (which saves 1 byte for each AI object).

Saving romspace is not important. Saving ram is essential. Otherwise, there's little chance of putting in all of Indenture's objects without adding ram to the cart.

#28 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Wed Sep 9, 2009 11:37 AM

The real downside is that it burns 7 bytes of temp ram above the original game. I'm currently trying to figure out a way to save ram among objects. Merging delta with state is one way (which saves 1 byte for each AI object).

Saving romspace is not important. Saving ram is essential. Otherwise, there's little chance of putting in all of Indenture's objects without adding ram to the cart.


Seems like there are probably still some opportunities for combining RAM bytes, at the expense of some outside-the-kernel cycles to manipulate them. For example, all 5 gate states could probably be combined into two bytes, freeing up 3:

BYTE 1
bit 7 = yellow gate open
bit 6 = white gate open
bit 5 = black gate open
bit 4 = green gate open
bit 3 = flashing gate open
bits 0-2 = which gate is currently being opened or closed (000 = none, 001 = yellow... 101 = flashing)

BYTE 2
bits 0-2 = state for currently opening/closing gate (8 positions)
bits 3-7 = free

You could then use bits 3-7 of the second byte to store CarriedObj, since there are (I think) less than 32 objects that can be carried.

Or maybe you've made some of these optimizations already... I'm just going off the Adventure(asymmetrical).asm.

--Will

#29 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Wed Sep 9, 2009 1:00 PM

Also, there might be just enough free cycles in that kernel to combine PF0_L and PF0_R, and/or combine PF_BANK with something.

The best bet for merging PF_BANK would probably be to structure the PF data so that each playfield definition starts aligned with its bank number. For example, data in bank 0 would start at $Fxx0 or $Fxx8, data in bank 1 would start at $Fxx1 or $Fxx9, so you could just AND #$07 the PF_PTR to get the bank # for bankswitching.

So that's another 2 RAM bytes saved (assuming PF0_L and PF0_R could be combined without using all the extra cycles; I have tried that yet.)

And since bits 5-7 of the high bytes of OBJ0_GR_PTR, OBJ1_GR_PTR, PF_PTR and ENABL_PTR are insignificant, you could store a byte and a half in there, prior to entering the kernel, and that wouldn't use any kernel cycles. For example, CarryX and CarryY might fit nicely in there, if you can confirm that bits 5-7 of those will always be the same. You could then use CarryX and CarryY as PF1_L and PF1_R, and then restore their original values from the PTRs after the kernel's done. That frees up another 2 bytes.

--Will

#30 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Wed Sep 9, 2009 1:38 PM

And you could use PlayerY as PF2_L, since PlayerY could be recalculated after the kernel is done by subtracting ENABL_PTR from ball_enable.

EDIT: Looks like combining PF0_L and PF0_R into PF0_LR and pulling the bank # from PF_PTR only used up 4 cycles, leaving 21 cycles free including the WSYNC.

--Will

Edited by e1will, Wed Sep 9, 2009 2:32 PM.


#31 Lord Thag OFFLINE  

Lord Thag

    River Patroller

  • 3,082 posts
  • We put our faith in Blast Hardcheese
  • Location:The Land that Time Forgot

Posted Fri Sep 11, 2009 12:51 AM

:love:

Damn.

I am SO there when this gets done!

#32 yorgle OFFLINE  

yorgle

    Dragonstomper

  • 585 posts

Posted Mon Sep 14, 2009 10:35 PM

Oooh. I've been away too long. This looks great, guys.

#33 Godzilla OFFLINE  

Godzilla

    Quadrunner

  • 6,794 posts
  • Location:Jacksonville, Fl

Posted Tue Sep 15, 2009 2:02 PM

woot! awesome, guys, awesome :)

#34 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Thu Feb 11, 2010 1:40 AM

I've been making some progress on a 2600 port of this. Some work-in-progress binaries posted here.

--Will

#35 NE146 OFFLINE  

NE146

    Dumbass Atari Fan

  • 14,596 posts
  • Location:Seattle, WA

Posted Tue May 13, 2014 2:24 PM

So... which one of you guys made this site?  Just curious. :)   

 

http://home.comcast....dent/Indent.htm

 

====================

 

On that note, anyone ever check out PIXA on ios? I'm debating whether it's worth the 99 cents.. hmmm

https://itunes.apple...d826977016?mt=8

 

 

screen568x568.jpeg


Edited by NE146, Tue May 13, 2014 2:26 PM.


#36 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,812 posts

Posted Tue May 13, 2014 2:29 PM

No idea.  All I can add to this topic is that I was given permission by the author of Indenture to make a port.  Haven't done much with it, though.



#37 bradhig OFFLINE  

bradhig

    Moonsweeper

  • 367 posts

Posted Tue May 13, 2014 4:17 PM

I would love to see it on an atari 2600 ,but the map might be too big for 4K.



#38 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Tue May 13, 2014 6:21 PM

I would love to see it on an atari 2600 ,but the map might be too big for 4K.

 

I don't think all of the mazes would be possible on the 2600, because some of them have too high of a horizontal resolution. Those screens would need to be redesigned for the 2600.



#39 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,812 posts

Posted Tue May 13, 2014 6:46 PM

I think there's no way I'd constrain myself to 4k.  The internal debate I've always had is to go procedural and retain the Indenture extras or go for strict authenticity.



#40 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,582 posts
  • Location:The land of Gorch

Posted Mon May 26, 2014 8:36 AM

All of the screens can be done on the 2600 AFAIK, there doesn't appear to be any that exceed 40 pixels horizontally. Movement collision would need to be handled slightly different than Adventure's code, tho...because you run into problems wherever there is only a 1-pixel playfield gap to move along (which is probably why W.R. made all of his passages at least 2 pixels wide).




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users