Jump to content
Sign in to follow this  
EarthQuake

Adventure: Playfield Manipulation Midscreen...?

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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. :lol:

 

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 by EarthQuake

Share this post


Link to post
Share on other sites

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

post-5734-1226804803_thumb.png

Edited by EarthQuake

Share this post


Link to post
Share on other sites

You should know by now that I am technically challenged. :lol:

 

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.

Share this post


Link to post
Share on other sites

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 by Nukey Shay

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :lol:

 

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

post-222-1226847492_thumb.jpg

Edited by Nukey Shay

Share this post


Link to post
Share on other sites

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).

post-222-1226848526_thumb.jpg

Edited by Nukey Shay

Share this post


Link to post
Share on other sites

Sprite glitch fixed 8)

 

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 by Nukey Shay

Share this post


Link to post
Share on other sites

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? :lol:

 

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. :)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
I take it 7 cycles doesn't leave much time to load different playfield colors per band, does it? :lol:
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?

Share this post


Link to post
Share on other sites

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:

post-5734-1227343557_thumb.png

Share this post


Link to post
Share on other sites

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.

post-222-1227356697_thumb.png

Share this post


Link to post
Share on other sites

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.

post-5734-1227360766_thumb.png

Edited by EarthQuake

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...