Jump to content

Photo

Indenture


39 replies to this topic

#1 edyensid OFFLINE  

edyensid

    Combat Commando

  • 4 posts

Posted Tue Aug 4, 2009 11:46 AM

Is anyone out there still playing with Indenture? I recently started playing it again, using DosBox on XP, so I could finish my maps I started making about 9 or so years ago. :)
I made my maps after seeing the cool map graphic of the original game that Warren Robinett had on his website, made by Maurice Molyneaux. Then there was someone else (dont remember the name) around 2002 timeframe that made the Indenture Mapping Project and dumproom program, that would dump all the rooms for v1.5 into a text file. This site also had some GIF files of some large areas mapped out. Anyways, these made me want to map it out as well, so I thank them for that! I also made a little VB app that can read the v1.5 and v1.7 .COM files and show a graphical view of the rooms and their connecting rooms.

Anyway, if anyone is still a fan of this awesome Adventure remake by Craig Pell, I would be more than happy to share my maps and talk about this old classic. For some reason I still love this game and just cannot get it out of my head.

Ed

#2 edyensid OFFLINE  

edyensid

    Combat Commando

  • Topic Starter
  • 4 posts

Posted Tue Aug 4, 2009 12:32 PM

Here are my maps btw, no reason to wait for someone to ask for them. :)

Ed

Attached Thumbnails

  • 001_original_rooms.png
  • 002_vgr_north.png
  • 003_vgr_south.png
  • 004_vgr_flashy_castle.png


#3 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Tue Aug 4, 2009 1:44 PM

Here are my maps btw, no reason to wait for someone to ask for them. :)

Ed

Thank you! I already have the text file with all the rooms printed out, but a real map is better! :)

Michael

#4 Godzilla OFFLINE  

Godzilla

    Quadrunner

  • 6,794 posts
  • Location:Jacksonville, Fl

Posted Tue Aug 4, 2009 4:12 PM

I want this for the 2600 :)

#5 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Tue Aug 4, 2009 5:52 PM

Some screens, particularly the swiss cheese mazes, would be a real challenge to do faithfully. You'd have to use a kernel capable of asymmetrical display. And even then there might be a few stumbling blocks. As such, Adventure's original kernel (and the modified one I did) are inadequate.

#6 Godzilla OFFLINE  

Godzilla

    Quadrunner

  • 6,794 posts
  • Location:Jacksonville, Fl

Posted Tue Aug 4, 2009 6:11 PM

yea, I could tell that :) But, I do think the 'ol 2600 could do Indenture in its entirety using modern 2600 homebrewery & a healthy rom size :) the graphics aren't terribly complex at that, maybe one of those batari/assembly combinations might pull it off...

#7 accousticguitar OFFLINE  

accousticguitar

    Quadrunner

  • 6,666 posts
  • Sherlock made it to 15 before he left us.
  • Location:Idaho

Posted Tue Aug 4, 2009 6:21 PM

Some screens, particularly the swiss cheese mazes, would be a real challenge to do faithfully. You'd have to use a kernel capable of asymmetrical display. And even then there might be a few stumbling blocks. As such, Adventure's original kernel (and the modified one I did) are inadequate.

How about the new kernel you made for Earthquake? He was doing some amazing stuff with that one. Wouldn't it still be too many rooms though? I thought it was limited to 256 rooms and if I remember right Indenture has about 300 rooms.

Edited by accousticguitar, Tue Aug 4, 2009 6:47 PM.


#8 tjb OFFLINE  

tjb

    Stargunner

  • 1,030 posts
  • Let's play soccer
  • Location:San Antonio, Texas

Posted Tue Aug 4, 2009 6:23 PM

It would be nice to have a version for the Atari 8-bit and/or 5200. I know there's Adventure II and it's great but I was thinking of a game that would have the same low-res graphics as the original Adventure (as Indenture does) to save memory and therefore be able to have a large number of screens to explore. Galahad and the Holy Grail did this.

Has this already been done?

tjb

#9 Pitfall Harry OFFLINE  

Pitfall Harry

    Stargunner

  • 1,993 posts
  • Location:Glendora, CA

Posted Tue Aug 4, 2009 6:39 PM

My grand pappy used to love to take his in-dentures out every night and play with them. I'm not sure that is relevant, tho.

#10 Godzilla OFFLINE  

Godzilla

    Quadrunner

  • 6,794 posts
  • Location:Jacksonville, Fl

Posted Tue Aug 4, 2009 6:44 PM

LOL :)

#11 accousticguitar OFFLINE  

accousticguitar

    Quadrunner

  • 6,666 posts
  • Sherlock made it to 15 before he left us.
  • Location:Idaho

Posted Tue Aug 4, 2009 6:46 PM

My dad used to rattle them around in his mouth somehow.

#12 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Tue Aug 4, 2009 7:43 PM

How about the new kernel you made for Earthquake? He was doing some amazing stuff with that one.

Not flexible enough. The mixture of reflected/reversed patterns helps get a little closer (as does isloated placement of panels on those lines)...but too many rooms use patterns there's no good solution for.


Wouldn't it still be too many rooms though? I thought it was limited to 256 rooms and if I remember right Indenture has about 300 rooms.

The original game was limited to 32 rooms. The hack is limited to 128 rooms (or 256...if no level differences are present). This is only a limitation because that is the maximum amount of values that can be held in a single byte. We beat that restriction all the time in most games where you score points ;) Multiple variables to handle the problem. Another way (without wasting resources) would be to use redundant bankswitching to handle all rooms of a particular type in one bank, etc...for example, all "light" rooms in one, all "dark" rooms in another. Or all "inside" rooms vs. "outside" rooms...whatever. This makes for some clever coding tricks, because enemies could "see" more than a single room at one time (helping with the common problem of having too much ground for opponents to cover to provide any challenge). Object placement would need a bit of work (to prevent a key from showing up when you dropped it on a companion screen, etc), but nothing that would turn into a nightmare to code. Lookup tables are good at that sort of thing...and keeping dropped items' coordinates confined to even values gives you two extra bits to implement per object. That brings the total up to 1024 unique screens that any object can exist at using no advanced tricks.

The kernel is the main problem. If reproductions of such unsophisticated screens can't be 100% faithful, there's not much point. Bugfixing the game is also a problem...you get to know the mazes a bit -too- well for it to be any fun.

#13 accousticguitar OFFLINE  

accousticguitar

    Quadrunner

  • 6,666 posts
  • Sherlock made it to 15 before he left us.
  • Location:Idaho

Posted Tue Aug 4, 2009 8:12 PM

The kernel is the main problem. If reproductions of such unsophisticated screens can't be 100% faithful, there's not much point. Bugfixing the game is also a problem...you get to know the mazes a bit -too- well for it to be any fun.

I suppose so. I remember Steve DeFrisco talking about Secret Quest saying that there could be a lot of rooms but they would all look the same. It seems like he could have followed Warren Robinett's pattern and made a better looking game than he did. After all, he had a lot more rom space to play with.

#14 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,666 posts
  • begin 644 contest

Posted Wed Aug 5, 2009 12:34 AM

The kernel is the main problem. If reproductions of such unsophisticated screens can't be 100% faithful, there's not much point.

It may be possible to do a 40-wide asymmertic playfield with two 2-line, single color sprites and the ball - assuming P1 and the ball are VDEL'ed. I haven't tried it, but with a 2-line kernel, assuming 48 cycles per line for the PF, there are 56 cycles left in which to draw the two players and the ball and any loop maintenance, which is a little tight but with skip/flip/switchdraw or similar techniques, it might barely work.

You would need 6 bytes for the extra pointers, so RAM may be an issue.

#15 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Wed Aug 5, 2009 6:13 AM

You have to add in the problem that the playfield lines need a line counter just for that row of pixels (otherwise, there is extreme waste for empty rooms and such). That adds up to 3 skipdraws, 6 playfield indirect loads and stores using it's own Y, a counter update for the band height (AND'ed from PF0 data), and a total screen line counter.

(13+5)*3+(10*6+6)+12+8

Getting the playfield stores in time might be difficult. CTRLPF isn't needed, and neither are independant panels...so a little bit of savings there. I count about 12 cycles left out of 2 scanlines tops (assuming no WSYNCs are used). Save a few more if PF0 datas are shared in upper/lower nybbles.

#16 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,666 posts
  • begin 644 contest

Posted Wed Aug 5, 2009 10:59 AM

You have to add in the problem that the playfield lines need a line counter just for that row of pixels (otherwise, there is extreme waste for empty rooms and such). That adds up to 3 skipdraws, 6 playfield indirect loads and stores using it's own Y, a counter update for the band height (AND'ed from PF0 data), and a total screen line counter.

(13+5)*3+(10*6+6)+12+8

Getting the playfield stores in time might be difficult. CTRLPF isn't needed, and neither are independant panels...so a little bit of savings there. I count about 12 cycles left out of 2 scanlines tops (assuming no WSYNCs are used). Save a few more if PF0 datas are shared in upper/lower nybbles.

Just redo all rooms at 16 lines each row. It will use some extra space but one could put the graphics in a separate bank (or multiple banks with multiple kernel copies.) A separate Y can simply be ANDed off from a ZP value that holds the line counter.

It might work. I don't know how the Adventure kernel works but the above may require some setup or modification of pointers and graphics in order to work, but probably that's easier than adapting a kernel to Adventure's current kernel setup.

Now does someone want to try it?

EDIT: Here is a more detailed analysis with psuedocode. Line counter is in X.

Kernel_loop:
txa/tay (4 cycles)
switchdraw P0/P1 (30 cycles)
txa/and #$0f/tay (6 cycles)
Playfield (48 cycles)
skipdraw ball (only needs X - Y is preserved) (13 cycles)
Playfield (48 cycles)
dex/bne (6 cycles)

3 cycles to spare. It will require a copied PF for timing. I'm not sure how flexible the copied PF timing is, so this may require moving stuff around a little.

Edited by batari, Wed Aug 5, 2009 11:36 AM.


#17 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Wed Aug 5, 2009 11:17 AM

Might take a stab at it later...kind of busy now. But I really don't believe that it needs all of that waste. Should at least be possible by adding in a little bit of redundancy within the engine. Worst-case, set up 3 vectors that have been precalculated to call specific short kernel sections in order without needing skipdraw.

#18 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Thu Aug 6, 2009 12:08 AM

Here are my maps btw, no reason to wait for someone to ask for them. :)


Thank you for posting these! I was seriously addicted to that game when it came out. I was so bummed that I never got a T-shirt!

--Will

#19 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Sun Aug 23, 2009 7:00 AM

Without wasting ANY additional ram or relying on illegal opcodes, an asymmetrical playfield is possible (with panels and variable line counts) by blanking every other line. About the only drawback would be that objects cannot be hidden behind walls. Here's a pic of the latest binary I'm editing.

Attached Thumbnails

  • Asymmetrical.jpg


#20 accousticguitar OFFLINE  

accousticguitar

    Quadrunner

  • 6,666 posts
  • Sherlock made it to 15 before he left us.
  • Location:Idaho

Posted Sun Aug 23, 2009 8:50 AM

Wow, imagine what Earthquake could do with that! I wonder when he's going to finish that Odyssey hack.

#21 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Sun Aug 23, 2009 11:05 AM

Without wasting ANY additional ram or relying on illegal opcodes, an asymmetrical playfield is possible (with panels and variable line counts) by blanking every other line. About the only drawback would be that objects cannot be hidden behind walls. Here's a pic of the latest binary I'm editing.


Looks nice! Another option would be to switch to a 3-line kernel; the playfield could be solid, and identical to the original if you change the frequency of playfield updates, although the player sprites would be stretched vertically.

--Will

Attached Thumbnails

  • 3LKcastle2.png

Edited by e1will, Sun Aug 23, 2009 11:07 AM.


#22 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Sun Aug 23, 2009 11:26 AM

IMO an even better solution is to use 2 kernels (since both of them occupy less than a page of memory)...and have a flag decide on which to use. Asymmetrical data is very memory-consuming...and even Indenture doesn't need the capability for 3/4 of it's screens or so. I'm trying to keep the resources claimed by both identical. Leftover ram is better allocated to added objects, rather than the unchanging screen.

This is an example of how bloated lookup tables for such screens become:

;NOTE: Room definition data format is PF0,PF1,PF2,PF2,PF1,PF0
;      Lower nybble of 7th byte description:
;      Bit 0 (+$01) true if (R)eversed playfield
;      Bit 1 (+$02) true if left panel wanted
;      Bit 2 (+$04) true if playfield has priority over sprites (dark rooms, hide sprites)
;      Bit 3 (+$08) true if right panel wanted
;Scanline counts can be from 1 to 15...defined on the PREVIOUS line (the first line's count is
; fetched from the very first byte).
Room0F: ;White Castle (outside)
Room10: ;Black Castle (outside)
Room11: ;Yellow Castle (outside)
       .byte $F9,$FD,$0A,$0A,$FD,$FF;XXXXXXXXXX X X X        X X X XXXXXXXXXX - 9 2lk scanlines
       .byte $31,$07,$0F,$0F,$07,$3F;XX       XXXXXXX        XXXXXXX       XX - 15
       .byte $30,$07,$FF,$FF,$07,$32;XX       XXXXXXXXXXXXXXXXXXXXXX       XX - 15
       .byte $30,$01,$FF,$FF,$01,$32;XX         XXXXXXXXXXXXXXXXXX         XX - 2
       .byte $30,$00,$00,$00,$00,$32;XX                                    XX - 2
       .byte $30,$06,$12,$B2,$1C,$32;XX       XX  X  X   X XX  X   XXX     XX - 2
       .byte $30,$08,$B5,$AA,$04,$32;XX      X   X X XX XX X X X   X       XX - 2
       .byte $30,$04,$55,$AA,$0C,$32;XX       X  X X X X X X X X   XX      XX - 2
       .byte $30,$02,$17,$B2,$04,$32;XX        X XXX X   X XX  X   X       XX - 2
       .byte $30,$0C,$15,$A3,$1D,$32;XX      XX  X X X   X X   XXX XXX     XX - 2
       .byte $30,$00,$00,$00,$00,$32;XX                                    XX - 2
       .byte $30,$01,$FF,$FF,$01,$3F;XX         XXXXXXXXXXXXXXXXXX         XX - 2
       .byte $30,$01,$3F,$3F,$01,$3F;XX         XXXXXXX    XXXXXXX         XX - 15
       .byte $30,$00,$00,$00,$00,$39;XX                                    XX - 15
       .byte $F0,$FF,$0F,$0F,$FF,$F0;XXXXXXXXXXXXXXXX        XXXXXXXXXXXXXXXX - 9


#23 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,666 posts
  • begin 644 contest

Posted Sun Aug 23, 2009 5:01 PM

IMO an even better solution is to use 2 kernels (since both of them occupy less than a page of memory)...and have a flag decide on which to use. Asymmetrical data is very memory-consuming...and even Indenture doesn't need the capability for 3/4 of it's screens or so. I'm trying to keep the resources claimed by both identical. Leftover ram is better allocated to added objects, rather than the unchanging screen.

Using two kernels is an excellent idea.

Now, it's hard to be critical of such an ambitious project, especially since I know you have the talent to see it through.

But, I don't like your second kernel very much. While what you have done might be slightly easier to adapt to the existing code base, I think that using an interlaced display is not a very good compromise. Also, I don't think it will save space - in fact if you must encode a height for each row, it will probably use more data, not less. The extra screens all appear to use fixed vertical sizes for the pixels, so a kernel using fixed sizes would be better anyway, and could be written such that it does not need interlacing.

I also don't understand why you consider using undocumented opcodes is "resorting." Back in the day, programmers did have a discussion about using them and decided not to in case future revisions of the 2600 broke their code, but now we know that never happened (except for a handful of the more obscure opcodes on the FB2, which should not be much of a consideration, IMO.) Not using them today is purely academic.

#24 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

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

Posted Sun Aug 23, 2009 8:31 PM

Now, it's hard to be critical of such an ambitious project, especially since I know you have the talent to see it through.

That makes one of us ;)


But, I don't like your second kernel very much. While what you have done might be slightly easier to adapt to the existing code base, I think that using an interlaced display is not a very good compromise.

I don't care for it much either...but there's no other way that I can find...currently. Ram must be saved at all cost, since Indenture's added objects demand so much. From what I can gather, I just -barely- have enough now to make it work pretty faithful to the original. The screen may not be as pretty, but it works. And that is job #1.


Also, I don't think it will save space - in fact if you must encode a height for each row, it will probably use more data, not less. The extra screens all appear to use fixed vertical sizes for the pixels, so a kernel using fixed sizes would be better anyway, and could be written such that it does not need interlacing.

That's a good point, but I'm not sure if all of the "multiple box" rooms can be done with mixtures of reflect & mirror yet (and those are 1/2 the resolution of the swiss cheese screens). As far as saving space goes, you only see this drop in rom savings wherever asymmetrical screens are concerned (the other kernel that does R&M saves a ton of rom)...throwing all of those screens into their own bank(s) is still a probability. No matter, since I'm not really concerned with saving rom at this point...I can add banks if I need 'em. The variable that does the counting is a shared one, so no loss of ram there...and as far as I can tell, it's operating at a 4-cycle difference between comparing a static value (the way the original game did) and one stored to temp ram. 1 cycle for the difference between immediate and zp addressing, and 3 more when storing the new value. Even taking all of that into account, I'd be seriously out of time trying to store the playfield data to temp ram (and since the existing stack only uses 4 bytes, there's an additional 2 bytes that I don't have to spare). Using static line counts for the asymmetrical kernel might be unavoidable, tho...if I can't scrape up the 4 (or possibly 2) cycles needed to kill the use of zero as the gfx delimiter.


I also don't understand why you consider using undocumented opcodes is "resorting."

I don't, really...but I still try never to use them if I can help it, or if the program routine in question isn't particularly demanding and a workaround is easily accomplished. I have a difficult enough time getting BIT instructions to read the way they are supposed to. Anything to avoid throwing in stuff that I don't fully comprehend. In the case of the latter, what I don't comprehend is why the instructions FAIL...and getting so hopelessly lost if/when they do that the hack is abandoned completely (I've done that a number of times).



Anyway...here's the current build of the kernel. The castles are the only screens using the new one...as a test. Looks to be operating smoothly. I had an issue earlier of the player square shinking as it was moved vertical, so I had to throw in a SEC instruction before the comparison (the other kernel, nope...it doesn't need it. And I don't know why the program treats them differently yet).

Attached Files



#25 e1will OFFLINE  

e1will

    Moonsweeper

  • 347 posts

Posted Tue Sep 8, 2009 11:02 PM

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?

Attached Thumbnails

  • asymtest_wn.PNG

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users