EarthQuake

Assuming you keep most of your screens the same, you'll have some major savings despite the extra scanline count byte.

Use Nukey's new kernal, you can have variable vertical resolutions. In terms of the original adventure, it could cut some of the rooms down to 12 bytes. Plus, if you didn't need double the resolution, but more than 7 rows of pixels, you could save bytes there too. Here are the sizes of all the rooms I have so far: Page 1 - 64, 72, 68, 52 Page 2 - 64, 64, 40, 44, 44 Page 3 - 40, 52, 24, 52, 36, 28 Page 4 - 32, 36, 28, 48, 32 And I have more than 7 pages of data left, plus I can squeeze many more bytes onto the above pages. These are also some of my more detailed areas. If my calculations are correct, I should have room to make 50-some screens total. I also have several pages in the second bank I could use... And if you decided to go for 16k, you could probably detail each and every room to it's full potential and come out with like 75-100 rooms. Also, why the need for 100+ rooms? It makes the game easier by allowing the bat and dragons to roam in more places so you encounter them less often. Let's say the original Adventure had 33 rooms with 3 dragons. That's one dragon per 11 rooms. If you had five dragons, wouldn't it make since to limit yourself to 55-60 rooms? There might be other factors taken into account like what if all dragons were roaming around at the same time, or what if 4 of the dragons were locked up in castles, so my assumptions might be off a bit in practice. Also, the speed of the dragons is a large factor. The faster they move, the more area they cover in less time.

Now using this tech, make the fabled Doom 2600. I could probably gather a rather large fanbase if you did so.

o_O "Turning Adventure into a 16k game..."

88 bytes saved between all the screens I had done so far. I only have about 11 screens or so completed, so that's about 1/5th of the total I had planned. Add up those savings, and I was I correct, probably going to have an entire page of ROM that I can use to make stuff even more detailed.

Ah! Thank you so much, I will definitely swap the CTRLPF and scanline count. It makes more sense that way anyhow. The only thing I will not be able to do on a line per line basis is change the ball width (because it needs the upper nybble), but I never planned on doing that in the first place. I had a lot of places in my room bitmaps where I would need to use multiple identical lines to fill up the screen. I can probably free up to an entire page of space or more with those changes! The bitmap you see in the screenshots above are 52 bytes. With the new code, they are 40. A 24 byte savings between just two bitmaps. Oh, you probably haven't seen anything yet. I took into account the massive ROM usage when I implemented Nukey's new (new new) kernal. So I had enough room for about 4-6 screens per page and still make my 55 room goal. Now with the extra byte savings, I can make some rooms more detailed than planned.

I found a small glitch, Nukey. It's pretty insignificant, but if you set the playfield priority above the missiles, then missile0 overlaps the playfield by one scanline. It might be something that was present in the original adventure, or it might be a result of your improved kernal. Just set the playfield priority of any screen with missile 0 enabled. In my attached example, I set the priority about halfway down the screen and onwards. Missile 1 is pixel-perfect in the right image. If you can't reproduce the problem in your sources, then it's probably something I did. I was repositioning the missiles and I modified their width. Like I said, it's nothing major though, or at least I hope not.

68-byte preview. Oh and stuff can be hidden behind the trees.

It's difficult designing playfields using this. I'm tempted to write a new playfield editor (as if I haven't already written enough of them ), but I haven't a strong direction about how to do the variable row heights with the most flexibility possible without cluttering up the interface. I'll probably do things by hand until I get fed up enough to work on a new editor. I'm anxious myself to see what I can come up with.

Got 'er. It was indeed something I forgot. I didn't update the return code for the second bank. Now to see what neat little things I can come up with. >~

Hmm, I merged the new kernal with my source code, but I have several problems. First, the objects are flickering obsessively. Not only that, but upon closer examination of each frame, the playfield seems to be changing priority continuously because one frame, a dragon would appear in front of the playfield, and on another frame it would appear behind it. Also, dragons have a difficult time biting, probably due to the bad flickering. They also seem to be cycling through states at times. I worked on this at my parent's house and there were quite a few distractions, so I'm going to give this another try and see if I get the same results. It might have had to do with where I made changes so that it was compatible with the indirect Y loading that my source uses. And what does this mean? Is it applicable to me, or should I just remove it? ;do not use these lines if RoomLo/Hi is not shared... The room display works perfectly. It's just the objects that are having the problem. I'll post back here if I figure out what it was. Oh hah, by the way, one of my bitmaps is 80 bytes, with a total of four bitmaps on the entire page filling it up exactly. Thankfully I have about 11 more pages reserved for screen bitmaps, and those four bitmaps are the most detailed of the bunch. I'm not going to have any problems filling up my entire 8k.

I'm still contemplating adding the flipping behavior to Odyssey. Although it is a definite improvement, it does look quite out of place for Adventure. I'll have to dwell on it some more and play around with your binary, acousticguitar. From a player's perspective, would this seem like an idea that strays from the classic feel of Adventure? Odyssey is going to be overwhelming enough with all the new playfield-related enhancements and the new dragons, castles, and difficulty levels. What do you think? Cram as much shit in there as possible? What about a seperate build with the flipping enabled?

Wow! I wasn't expecting another kernal from you! I never thought about adding another byte to each row in the bitmap to hold the playfield control. This has very huge implications. I can't find an immediate use for all the new things that are possible, but hopefully someone in the future may take advantage of it in it's entirety. The real groundbreaking thing here is being able to modify the playfield mirroring on-the-fly, allowing some really neat new worlds to be created. I'm definitely going to give this a try. The added byte per room is a killer though, especially when you got rooms that are 36, 45, 51, 63 bytes et cetera... but I think the new possibilities far outweigh the disadvantages. Some quick questions: because each row of playfield data contains the playfield control, does this make the byte in the room data table redundant or anything? Afaik, the engine still uses it for determining if a room is dark and if the missiles should display. Also, in my source, it checks the byte if the room is set as dark and establishes and recolors the surround object. The only thing that is redundant is the mirroring bit, correct? Will this interfere at all?

So I was working on my Adventure hack a bit, overwhelmed with the new possibilities given Nukey's new kernal. Basically, each line of the playfield data has it's own value (stored in the lower nybble of the byte sent to PF0), which allows not only higher vertical resolution in bitmaps, but screen bitmaps where each playfield row can be of variable height, so you can increase the vertical resolution only where you need it. But, anyways, I was wondering about something and it might just be possible. IIRC, the bit in the playfield control register that controls the mirroring, could theoretically be switched on and off as the screen bitmap is drawn to achieve a playfield layout that is somewhat non-symmetrical. The engine could look for a certain bit set in the screen bitmap's PF0 byte and XOR the bit sent to the playfield register, effectively toggling it each time the condition is met. I know I'm always going on about how Adventure could extremely benefit from asymmetrical playfields, but this idea could be a great compromise. Would this even be possible? It's a long shot, but I can see amazing things resulting from this. Here's a textual result of a room that would take advantage of such an addition: .byte $F0,$FF,$0F;XXXXXXXXXXXXXXXX RRRRRRRRRRRRRRRR .byte $30,$00,$00;XX RR .byte $30,$00,$00;XX RR .byte $F0,$C0,$FC;XXXXXX XXXXXXRRRRRR RRRRRR .byte $30,$00,$00;XX MM <- * .byte $30,$00,$00;XX MM .byte $F0,$FF,$FF;XXXXXXXXXXXXXXXXXXXXMMMMMMMMMMMMMMMMMMMM * Playfield register updated on noted line. The value specified in the room data table could perhaps just be used as the initial value of the mirroring behavior.

No kidding. I don't know if I want one, two, or more! I'd love to have at least two, one as a backup, but despite the promises of "saturating the market", who knows how many will exist a couple years or how much it would be worth. I'd probably buy more if I could afford it. Might be an easy way of getting a couple hundred bucks if things got rough. Plus, an extra one I'm willing to part with, means that someone else who doesn't have one could still get their hands on it. Still, I really look forward to the final thing. I have just now started dabbling in assembly, and I would die for the opportunity to be able to test stuff on actual hardware.

Okay after looking at it, it basically just crashes. I just got a black screen. I really don't think this has anything to do with the new sprite flipping code. Instead, I think it's related to the main loop where it checks if the winning condition has been met. You didn't reorder any of the code in the first part of the main game loop did you?

Not quite sure I've ever experienced anything like that before. I'm pretty sure the above code wouldn't cause the playfield or background to exhibit any such things, at least. Can you describe in detail what's going on? What things' colors are being changed? How do they change over time? Is the screen rumbling or are the colors just changing? Is it possible to take screenshots? Are you just getting random output or is the game still in a semi-working state? Does the select button fix everything?

Oops, delete me.

I guess one way of getting around that, is to check if the dragon's current state is the "moving" state, and then flip the sprite if that is the case. It would prevent the sprites from flipping if you're eaten, they are dead, or they are biting (preventing the need to reposition the dragon when it's flipped). And yes, I agree, the dragons look mighty strange when flipped.

Hmm, it should be working, although when I tried it with my source code, the "two existing lines" were actually three: ResizeObject: LDA Store8,X ; Get size of Object1. ;4 ORA #$10 ; And set to larger size if necessary. ;2 STA NUSIZ0 ; (Used by bridge and invisible surround. ;3 I put the LDY #$00 before it, and the rest of the code after this block of instructions, and the same for object2 in the ResizeObject2 routine. After defining REFP1 and REFP0, adding $80 to the width of the dragons, and flipping the bitmaps of the dragons, everything worked perfectly. Oh and make sure it uses PlayerX instead of PlayerY.

Add $80 to the byte that controls the size. Or just simply make it $80, since most objects have a size of $00 to begin with. Oops, someone beat me to it.