Jump to content
Posted Tue Aug 4, 2009 11:46 AM
Posted Tue Aug 4, 2009 12:32 PM
Posted Tue Aug 4, 2009 1:44 PM
Thank you! I already have the text file with all the rooms printed out, but a real map is better!
Here are my maps btw, no reason to wait for someone to ask for them.
Posted Tue Aug 4, 2009 4:12 PM
Posted Tue Aug 4, 2009 5:52 PM
Posted Tue Aug 4, 2009 6:11 PM
Posted Tue Aug 4, 2009 6:21 PM
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.
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.
Edited by accousticguitar, Tue Aug 4, 2009 6:47 PM.
Posted Tue Aug 4, 2009 6:23 PM
Posted Tue Aug 4, 2009 6:39 PM
Posted Tue Aug 4, 2009 6:44 PM
Posted Tue Aug 4, 2009 6:46 PM
Posted Tue Aug 4, 2009 7:43 PM
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.
How about the new kernel you made for Earthquake? He was doing some amazing stuff with that one.
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.
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.
Posted Tue Aug 4, 2009 8:12 PM
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.
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.
Posted Wed Aug 5, 2009 12:34 AM
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.
The kernel is the main problem. If reproductions of such unsophisticated screens can't be 100% faithful, there's not much point.
Posted Wed Aug 5, 2009 6:13 AM
Posted Wed Aug 5, 2009 10:59 AM
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.
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.
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.
Edited by batari, Wed Aug 5, 2009 11:36 AM.
Posted Wed Aug 5, 2009 11:17 AM
Posted Thu Aug 6, 2009 12:08 AM
Here are my maps btw, no reason to wait for someone to ask for them.
Posted Sun Aug 23, 2009 7:00 AM
Posted Sun Aug 23, 2009 8:50 AM
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.
Edited by e1will, Sun Aug 23, 2009 11:07 AM.
Posted Sun Aug 23, 2009 11:26 AM
;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
Posted Sun Aug 23, 2009 5:01 PM
Using two kernels is an excellent idea.
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.
Posted Sun Aug 23, 2009 8:31 PM
That makes one of us
Now, it's hard to be critical of such an ambitious project, especially since I know you have the talent to see it through.
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.
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.
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.
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 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).
I also don't understand why you consider using undocumented opcodes is "resorting."
Posted Tue Sep 8, 2009 11:02 PM
0 members, 0 guests, 0 anonymous users