Adventure: Playfield Manipulation Midscreen...?

[Nukey Shay]

How?

[accousticguitar]

I've been playing around with the original 8k assembly and I managed to get the double screen resolution to work. At 42 bytes per room only 6 rooms will fit per 256 bytes which is 24 rooms per kilobyte. If it has 3k of free space that makes 72 rooms. I am assuming I can combine the original 31 rooms into space for another 15 rooms for a grand total of 87 rooms. That is slightly below my goal of 90 to 100 rooms, but close enough to make do. Having played Missadventure a lot, I think it is slightly on the large side which is how I came up with the 90 to 100 figure. I can see why Warren Robinett went with 21 byte rooms in his 4k rom!

[EarthQuake]

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.

Edited November 16, 2008 by EarthQuake

[EarthQuake]

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

Edited November 16, 2008 by EarthQuake

[accousticguitar]

You should know by now that I am technically challenged.

 

I am beginning to grow comfortable with the old assembly. It took a long time to figure out what little I know about it. I don't think I'm ready to move on to a new kernal just yet.

 

As far as the number of rooms is concerned, I was going by my experience with Missadventure. It has 112 rooms, and like I said, it seems a bit large at times. I think a larger kingdom is more challenging in the regard that it takes longer to find a needed item. The thrill of the hunt, you might say. I think that makes up somewhat for the lesser density of dragons. It's going to be an opinion that varies from person to person and you need to find a balance somehow. I don't think I would want to go any higher than 100 rooms; 90 might be closer to ideal. Adventure Country has 91 rooms, but with the grid layout it's hard to compare the two versions.

 

I don't think I would have significant savings of space because I would want to make most of the rooms more detailed anyway. Bare corridors just don't cut it as far as I'm concerned. I was trying to play Secret Quest last night and can't stand all the identical rooms. How are you supposed to know where you are at in that game? Even with 112 rooms Missadventure does a great job of letting you know where you are at at all times (except in the forest, of course). I wonder what Yorgle could do with a high-rez bitmap.

[Nukey Shay]

I just eliminated another table. By renumbering the origin to begin at $1000 instead of $D000, it leaves the upper 3 bits free in the MSB table (RoomDataTable1). The old CTRLPF table (RoomDataTable3) had already been cut down to 3 bits, so I merged those two tables.

 

In addition, the line just before PF data is read has only 58 cycles used...so it's possible to enable/disable additional things (like having panels turned on or off mid-screen...or altering colors multiple times).

 

I agree about using too many screens, that is what killed off the old Advent hack. On the plus side, the game allows 256 game objects, so you can use leftover space to decorate screens with static objects.

 

Current:

Edited February 4, 2009 by Nukey Shay

[EarthQuake]

That's a really nice future addition... modifying the missiles and playfield colors midscreen. Imagine what beautiful room graphics one could come up with. However, I much prefer the room data table in it's original form. It was pretty difficult to connect rooms and such as it was. Separating the tables makes this a nightmare, or in my opinion at least. I might employ this new technique in the Adventure creator program, since the program itself is what will generate the tables. It would actually be favorable in that case, since it can just dump the arrays of room connections and such without having to format them. The user won't have to deal with editing the source code tables manually, so I see no reason not to separate them in that version.

[EarthQuake]

Nukey, I also have some questions for you. I was going to start work on a new screen bitmap editor to account for the variable vertical resolutions and new playfield control mechanism. What sort of things should I work into the editor for future additions? I don't want to have to keep rewriting the damned thing every time you update the kernal.

 

This thing would make screen bitmap generation a breeze. Right now I'm using two outdated editors to create my room bitmaps, and it's a pain in the ass, especially since I can't see the final result without throwing it into the binary.

[Nukey Shay]

Right now, it appears that the format will remain unchanged. The display code leaves 12 cycles free when leading into the playfield reads (but no registers are free), and exactly 76 cycles afterward. It would be good if I could find the time to throw the 2 missile enable bits into the low nybble of PF0 as well...but there is zero free time to implement it (unless Supercat elaborates on what he meant by 2 vectors to save time). Even if I could save 3 cycles, it would make it possible to enable one of the side walls (7 more would be required to enable the other one).

 

Example:

	   TXA					   ;2 Get PF0 definition back
;enable one of the walls (3 cycles)
   STA	ENAM1			  ;3 Enable right hand panel
   AND	#$0D			   ;2 (skip bit 1...score mode)
   ORA	#$20			   ;2 merge in the ball size
   STA	CTRLPF			 ;3 Store to playfield control
;enable the other one (7 cycles)
   LSR					   ;2 shift bit 3 down...
   LSR					   ;2 ...to enable position
   STA	ENAM0			  ;3 Enable left hand panel

 

Then bits 1 and 3 could be set in the PF0/ctrl data to enable the panels on a per-band basis. The right panel is enabled quick enough so that it's lined up correctly...but the left panel would be misaligned by 1 scanline (I dunno a way around that).

 

Neither of these changes are possible with the existing routine. No cycles are free to do it. I'm looking into keeping all the branches on the sprite scanlines using the same number of cycles...so that the ending WSYNC can be deleted (that would be the 3 cycles needed for one panel).

[Nukey Shay]

2 cycles short for both walls! Still working...

[Nukey Shay]

I've got it. The remaining 2 cycles have been picked up by eliminating the CLC (because using 2 LSR's for the CTRL store automatically clears carry status due to bit 1 not being kept in the AND). There is only a very slight chance of sprite shearing when it's on the far right of the screen (because it's written before the scanline begins)...but it looks passable. In addition, the problem of the left panel being off by 1 scanline is no longer an issue

 

Here's a pick that shows an example of isolated panel placement...you could use small panels to block individual passageways (because the playfield is defined on the same lines that the panels are). In the lower nybble of PF0, use bit 1 to turn on the left panels, and bit3 to turn on the right panels. A "dark" room is still set by turning on bit5 of the room MSB (RoomDataTable1)...bits 6 and 7 are still unused there if you keep RORG's in the display bank set at $1000-$1FFF.

Edited November 16, 2008 by Nukey Shay

[Nukey Shay]

Better picture...note the glitched key gfx here.

 

BTW the existing locations of the panels allow you to use the bridge to bypass them. You can eliminate this by resetting the panels closer to the edges (like $04 and $9E instead of $0D and $96 in the startup routine).

Edited November 16, 2008 by Nukey Shay

[Nukey Shay]

Sprite glitch fixed

 

NOTE: because the bridge is allowed to overlap the screen border on the right side, it still may be possible to get past right panels. Increase surrounding wall height to 30 scanlines to kill this ability (just as in the original game, the magnet can be used to drag the bridge anywhere, however...bypassing any panels you may have placed).

 

The assembly currently has a minimum of 7 free cycles before a playfield update occurs. I listed free cycles.

Edited February 4, 2009 by Nukey Shay

[EarthQuake]

Great news! I'll be sure to implement this in the bitmap editor. I take it 7 cycles doesn't leave much time to load different playfield colors per band, does it?

 

Regardless, this is a great feature. I wonder if anything could be done to reposition them horizontally... There are quite a few bits free in the old playfield control byte, but again, probably not enough time to do anything, and 7 bits don't really give much freedom in positioning them.

 

I still look forward to any new developments.

[mos6507]

Better picture...note the glitched key gfx here.

 

BTW the existing locations of the panels allow you to use the bridge to bypass them. You can eliminate this by resetting the panels closer to the edges (like $04 and $9E instead of $0D and $96 in the startup routine).

 

Any way to repurpose the castle gates so you could have keys to gates elsewhere?

[Nukey Shay]

I take it 7 cycles doesn't leave much time to load different playfield colors per band, does it?

Directly, no...but remember that you also have 14 free cycles (or 17, by taking out the WSYNC) when the sprites are updated without the playfield, and a whoppin' 46 cycles following that WSYNC. So you could do some calculations to update a ram location, and then read and store it to a register using those 7 cycles.

 

The bad news...

These 7 free cycles end on cycle 65 of the current scanline (just before updating the room gfx)...so updating a color may leave some artifacts on the very edge of the screen.

 

 

Regardless, this is a great feature. I wonder if anything could be done to reposition them horizontally

Of course. The missiles are positioned right in the main program. So you could load in specific X values for each room if you wanted to and reposition them. It was my intention to only hack the kernal itself...leaving program changes entirely up to the user. Those changes would affect running time outside of the kernal, which is why I never did it.

 

 

 

There are quite a few bits free in the old playfield control byte, but again, probably not enough time to do anything, and 7 bits don't really give much freedom in positioning them.

*See above

After breaking up the RoomDataTable into seperate tables, as many specific room variables can be added as you want (or run out of space for). Load the room number into the X or Y register, and load a value. This could even be done if you are still using the old offset calculation routine...something that these assemblies have done away with.

 

 

 

Any way to repurpose the castle gates so you could have keys to gates elsewhere?

Do you mean have a single key open multiple gates? Or just more gates with corresponding keys?

[EarthQuake]

Took a while trying to figure out how I wanted to do this, but I think I settled on an idea I like.

 

Take some looksies:

[Nukey Shay]

Looks good

 

How about placing linecount (#), screen mode (R or M), and priority (on or off) fields in as well?

 

Also, horizontal lines are not really needed within a pixel row (because it's defined by the count on the far left). The right half doesn't need either, it's not part of the drawing field...tho it's probably better to leave the horizontal lines seperating each group, for a better visual reminder.

[EarthQuake]

Already did some of that.

 

That's a terrific mockup, but some things I can't do. For the scanline count, it's completely dependent upon the number of sequential unique rows. So you have to keep an eye of the number of rows, displayed at the bottom. When you export the map to assembly code, it automatically assigns these unique rows with the proper scanline count.

 

The various playfield control flags are displayed in the same area, but I expanded it to accommodate the missile panels. In the above screenshot, the two columns were for reflection and priority, respectively. In the below shot, the columns are as followed from left to right: playfield reflection, left panel, right panel, and playfield priority. Not obvious without playing around with it, but it's easily learned. Also from the screenshot, you can see the editing menu. There exists the ability to change entire columns en masse, switching the different bits of the playfield control for the entire map to on or off.

 

Since the room will always be 96 scanlines total, it's not necessary to display that information. Instead, just the number of rows of data and their total size is displayed.

 

About the grid... I can't really do much with it. The grid in the screenshot is in fact the background of that picturebox, and the border around each pixel is transparent, allowing you to see the grid. This was the most time-efficient way of drawing the display. I added some black lines over top, however, as a guide for the original screen format. The program has the option to export the map to the original format (by only saving the first seven unique rows). In fact, I should be able to export it to the previous map format for the old kernal (just in case someone still wants to use such). It's just a matter of rearranging values in the output.

 

You will also be able to save your work and load it at a later time. I'm still working on this though.

 

Oh, I should mention. The maximum resolution is cut by half (making all rows at least 2 scanlines high). This is more than enough and can easily be changed, but it's rather difficult to work with, because you have twice as many pixels to deal with. Plus, the playfield control area on the right is really squashed together and hard to edit. Plus, a room with 96 different rows of data would total 384 bytes, which is a page and a half of memory.

 

One last thing, you can draw on either side seamlessly.

Edited November 22, 2008 by EarthQuake

[EarthQuake]

"Yeah, Adventure can do that."

[accousticguitar]

[ginnidog]

I sure would love to learn all this stuff.. looks enjoyable

[accousticguitar]

I believe the latest assembly is in post #38. Download it and start hacking! (That's how I learned what little I know.)

[EarthQuake]

By the way, after I'm done with this utility (and get it cleaned up and optimized), I'm going to start working on another editor that takes the .room files this program outputs and creates a room data table. All of these little programs I'll be doing over the next several months will be combined into the Adventure creator program I was planning. I'm naming her Ceuta. I wonder if people could guess what it stands for.

 

Anyways, now starting on the file loading/saving and source code output. If I can find a good way of doing so, I'll have a missile wall preview for those rows that have either enabled (with maybe an optional adjustment to change its horizontal location).

[accousticguitar]

Cwantum Earthquakes Utility for Adventure?

 

Seriously, is there a reason the portcullises aren't centered?