Adventure: Would you use this program?

[EarthQuake]

Through the course of creating my own Adventure hacks, I programmed several tools to help me. They are sort of similar to the CYOA application that Atarius Maximus wrote. However, CYOA only allows you to modify the game to a certain extent. The tool I just rewrote recently only aids in screen and sprite bitmap creation (it generates the source code to paste into your Adventure source file) and has an object positioner, but I was thinking about expanding it to deal with room connections and such.

 

The program I had in mind would take a modified 8K source file with extra features (like dragons, portcullis', etc) and would let the user have the option of enabling or disabling them. Not to mention the user would be able to draw screen and sprite bitmaps, connect screens using those bitmaps together, add a larger number of rooms, and change pretty much every other "moddable" thing in Adventure.

 

Of course, the thing would be very professionally made and user-friendly. Compared to CYAO (and I'm not trying to compete with it, really), it would be about 10 times smaller (probably less than a MB), execute faster, and use a lot less memory. Plus, in the tool I programmed, you can literally draw on the bitmaps and not have to click each pixel.

 

My question is, would it be worth my time to create such a program? Or would only a handful of people use it?

The only argument against it that I can see, would be that there might be a flood of new(bie) adventure hacks (hey, but at least they're not just graphic hacks, right? )

 

It's a rather complicated program, so before I start on it, I'd like opinions, "go aheads", and suggestions. If there isn't a high enough demand for it, there's not much point in doing it.

 

Thanks!

Edited October 12, 2008 by EarthQuake

[accousticguitar]

The only argument against it that I can see, would be that there might be a flood of new(bie) adventure hacks (hey, but at least they're not just graphic hacks, right? )

That sounds like an argument for it to me. I say bring it on. I could never get CYOA to work on my computer because it took too much memory. I'm used to doing all my graphics on paper though, it might be a hard habit to break.

[Nukey Shay]

If you build it, they will come. It's always unknown how many. Some ideas start out great (like AHD), but then peter out.

 

Pretty much the only reason to do anything 2600-related is for your own sense of accomplishment. This applies to tools, hacks, and even homebrews. CYOA was used a lot...there's probably quite a number of users interested in a version that has more features and creates 8k binaries

[EarthQuake]

I decided to go ahead with the project, just to see how far I could go with it.

 

I have a question somewhat related to the program. In the room data table, the control byte has several unused bits:

 

; Offset 3: The properties of the room:
;   Bit 0 (+$01): The room is displayed "reversed", as opposed to "mirrored".
;   Bit 1 (+$02): Not used.
;   Bit 2 (+$04): The room is a "dark" room, with the invisible surround.
;   Bit 3 (+$08): Not used.
;   Bit 4 (+$10): Not used.
;   Bit 5 (+$20): The room is a room... (All rooms have this set.)
;   Bit 6 (+$40): The room has a thin right panel.
;   Bit 7 (+$80): The room has a thin left panel.

 

My question is, are the unused bits actually used for something or are they literally not used? I'm asking because I would like to let users select those bits if they so wished, but I don't want to do that if it will mess anything up. Also, is there any situation where a room with bit 5 NOT set would be useful? What's the purpose of this bit?

 

Oh, and a teaser of the fully working screen properties dialog:

Edited October 14, 2008 by EarthQuake

[accousticguitar]

Correct me if I'm wrong, but I believe that a "dark" room means that objects will disappear behind barriers. The surround is controlled by the color of the room. I found that none of the rooms in Adventure used the number "20" which means the right half of the playfield is the same as the left and objects don't disappear behind barriers.

 

Edit: I guess that doesn't apply when using surround. I just tried it and it made the barriers invisible. When using surround the room needs to be dark or you can't see the barriers.

Edited October 14, 2008 by accousticguitar

[EarthQuake]

I haven't figured out yet how to actually get dark rooms to work with the new screen-dependent background colors... In Adventure, the surround was the same color as the playfield color of dark rooms, which leads me to believe that I will have to make changes so it actually uses the playfield color.

 

Still though, I haven't gotten it to work at all yet...

Edited October 14, 2008 by EarthQuake

[gambler172]

Hi Earthquake

An Adventure creator would be cool.

greetings Walter

[Nukey Shay]

I haven't figured out yet how to actually get dark rooms to work with the new screen-dependent background colors... In Adventure, the surround was the same color as the playfield color of dark rooms, which leads me to believe that I will have to make changes so it actually uses the playfield color.

 

Still though, I haven't gotten it to work at all yet...

Use a different bit of the CTRLPF values. You can AND away ones that cause conflicts if you want to reuse the bits pertaining to the ball size...but bit 3 (value = $08) is unused. You even save a couple of bytes by not having to reset A following the check

 

Old:

;Deal with Invisible Surround Moving.
Surround:
   LDA	PlayerRoom;Get the Current Room
   JSR	RoomNumToAddress;Convert it to an Address
   LDY	#$02;set read pointer to the color value
   LDA	(CurrentObject),Y;Get the Room's Color
   CMP	#$08;Is it Invisible?
   BEQ	Surround_2;If So Branch
   LDA	#$00;If not, signal the
   STA	SurroundR+2;Invisible surround not wanted
   RTS;

 

 

This should work OK:

;Deal with Invisible Surround Moving.
Surround:
   LDA	PlayerRoom;Get the Current Room
   JSR	RoomNumToAddress;Convert it to an Address
   LDY	#$03;set read pointer to the CTRL value
   LDA	(CurrentObject),Y;Get the Room's CTRLPF
   AND	#$08;Is it Invisible?
   BNE	Surround_2;If So Branch
   STA	SurroundR+2;disable Surround
   RTS;

 

Any room you want the surround present in, set bit 3. You can couple this with the framecounter if you want a flicker-type effect.

 

Of course, sprite priorities are also implemented in the kernal. So an optimal change would be just to check bit 2...

 

;Deal with Invisible Surround Moving.
Surround:
   LDA	PlayerRoom;Get the Current Room
   JSR	RoomNumToAddress;Convert it to an Address
   LDY	#$03;set read pointer to the CTRL value
   LDA	(CurrentObject),Y;Get the Room's CTRLPF
   AND	#$04;Is ball priority set?
   BNE	Surround_2;If So Branch
   STA	SurroundR+2;disable Surround
   RTS;

 

That still leaves bit 3 free for something else

Edited October 15, 2008 by Nukey Shay

[Nukey Shay]

..

Edited October 15, 2008 by Nukey Shay

[Nukey Shay]

; Offset 3: The properties of the room:
;   Bit 0 (+$01): The room is displayed "reversed", as opposed to "mirrored".
;   Bit 1 (+$02): Not used.
;   Bit 2 (+$04): The room is a "dark" room, with the invisible surround.
;   Bit 3 (+$08): Not used.
;   Bit 4 (+$10): Not used.
;   Bit 5 (+$20): The room is a room... (All rooms have this set.)
;   Bit 6 (+$40): The room has a thin right panel.
;   Bit 7 (+$80): The room has a thin left panel.

 

The CTRL value is passed as-is to CTRLPF. Bit 1 isn't actually "not used"...neither is bit 4.

 

If bit 1 is set, CTRLPF sets the display to "score mode"...that is that following scanlines will gather playfield color from the sprites - sprite0's color for the left half, and sprite1's color for the right. This made it easy for programmers to display playfield scores in the same color as the players.

 

Bit 4 and 5 are used to set the size of the ball...

00 = single pixel

01 = 2 pixels

10 = 4 pixels

11 = 8 pixels

 

Bit 2 doesn't select a "dark" room...it just sets the register so that the surround object (which is an 8-bit sprite) falls behind the ball sprite.

 

 

 

 

As far as the CTRLPF register is concerned, bits 3, 6, and 7 are not applicable. Adventure just uses bits 6 and 7 to set whether side panels are wanted.

 

Here is a full description of the hardware's use of CTRLPF:

  Bit  Expl.
 0	Playfield Reflection	 (0=Normal, 1=Mirror right half)
 1	Playfield Color		  (0=Normal, 1=Score Mode, only if Bit2=0)
 2	Playfield/Ball Priority  (0=Normal, 1=Above Players/Missiles)
 3	Not used
 4-5  Ball size				(0..3 = 1,2,4,8 pixels width)
 6-7  Not used

 

If you want bits 1, 2, 4, and 5 to control something else, you'll need to adjust it with AND's and OR's before it's sent to the register. Otherwise (for example), you'd have shifting modes, priorities, or ball sizes between screens.

Edited October 15, 2008 by Nukey Shay

[Nukey Shay]

BTW if you want to reassign some of the bits used by CTRLPF, you'd need to change one area of the display kernal in SetupRoomPrint...

 

;Playfield Control.
   LDY	#$03;CTRL value pointer
   LDA	(CurrentObject),Y;Get the playfield control value
   STA	CTRLPF;And put in the playfield control register

 

You could do something like this, for example...

;Playfield Control.
   LDY	#$03;CTRL value pointer
   LDA	(CurrentObject),Y;Get the playfield control value
   TAY;save for later
   AND	#$05;keep only mirror and priority bits
   ORA	#$20;set ball width = 4 pixels
   STA	CTRLPF;And put in the playfield control register
   TYA;get back original value

 

That leaves 6 bits free. 4 bits free if you still want the option to utilize missile panels in the value. The original code just LSR's bits 6 and 7 to the enable position (bit1 = missile on). How about this...

 

;Playfield Control.
   LDY	#$03;CTRL value pointer
   LDA	(CurrentObject),Y;Get the playfield control value
   TAY;save for later
   AND	#$05;keep only mirror and priority bits of the value
   ORA	#$20;set ball width = 4 pixels on every screen
   STA	CTRLPF;And put in the playfield control register
   TYA;get back original value
   STA	ENAM1;enable right wall (bit 1)
   LSR;move down 2 bits
   LSR
   STA	ENAM0;enable left wall (bit 3 shifted to 1)

 

That only takes 2 more bytes of code than the original routine used (18 vs. 16)...and leaves the entire upper nybble of the table values free to be used as something else. Plenty of time to set other things of your choosing, that will not affect register CTRLPF in any way.

Edited October 15, 2008 by Nukey Shay

[EarthQuake]

Thanks for the detailed elaboration Nukey.

 

I was not aware it directly sent the control byte to playfield register. I guess that clears up a lot of things. Although I don't have much use for the four extra bits at the moment in my own hack, I incorporated your idea into the new base source code for any expansion later down the road. Before I read your replies I had already made it so bit 5 was always set (so that you didn't need to set it for every room), but your method was more thorough.

 

Although the new changes make it much easier to configure the dark rooms, I still need to change the surround's color on the fly so it uses the background color for the room it's in, and I also need to change the background itself to use the playfield color when the "dark bit" is set. Now that I know exactly what's going on with the playfield, I should be able to do these easily. It will be pretty straightforward for the program user. Although, would there be any practical reason why I should not automatically set up the colors for the dark rooms? The user would be able to set which two colors to use. The playfield color would be the color of the "darkness" and the background color would control the surround's color. Any reason why I shouldn't do this?

 

Thanks again.

Edited October 16, 2008 by EarthQuake

[Nukey Shay]

I suppose that one drawback is that a CYOA program would force the designer to enter values for all dark rooms...but I suppose that annoyance could be remedied by allowing the user to set dark room foreground/background color globally (or use a default value). The same might be said of ball width...you never know if somebody would want to create an Adventure game where the player changes size (sort of like small on an "outside" world, and larger when entering buildings, etc). If that sounds like a good addition, preserve bits 4 and 5 too (get rid of the ORA #$20) before it's sent to CTRLPF. You still have bits 6 and 7 free for quick BIT tests to be done for any added future options.

 

NOTE about the above:

Setting a smaller or larger width of the ball does not change the height. To do that, you'd need to alter the PrintPlayer00_1 routine. Where it mentions getting a depth of 8...that AND's instruction would need to be changed for each specific screen. I'll work out something for that if you want.

 

Regarding the surround object's color, there is already an "exception" in place for recoloring objects (if bit 0 is set, use the framecounter). You could add in lines to check if a given object is the surround sprite...in which case, pull the color from someplace else. You could either add in a seperate table to handle this, or add a byte to RoomDataTable (note: RoomNumToAddress would need alteration if you add or remove data from each room in that table).

[Nukey Shay]

BTW if the surround color was the same as the background, it would be invisible. Priority given to the ball also gives playfield priority over the players/missiles. A totally seperate color (via an independant table) might be a better approach.

[EarthQuake]

The idea though, is to allow each dark room to have it's own set of colors (which it gathers from the room data table -- so there wouldn't be any need to add bytes to this table or create a completely independent table). It's just a matter of swapping colors around depending on if the "dark bit" is set for a room. After examining the code, it might be tricky without using code that is too redundant, but I think it should be possible.

 

EDIT: Oh I see what you meant. Having a global darkness set of colors in case the user does not want to specify them in the actual room properties. Still, seems like a feature no one would really want to use. I mean, how many dark rooms is someone going to have in their mod? If it's only several, and you get the option to select the colors used, I think it would be better just handling it based on playfield and background colors.

 

EDIT 2: Added code to set the background to the playfield color. Now I gotta make the surround use the background color from the room data table and this should be complete. Quick question though: transfer instructions (TAY, TAX, TYA, etc.) copy the value from one register to another, leaving the former value intact, right?

 

EDIT 3: Haha, the first several tests didn't go so well when changing the color of the surround. It works, but all my other objects are shades of pinks and purples. It's kind of neat, but I'll have to work on it some more.

Edited October 17, 2008 by EarthQuake

[Nukey Shay]

TAX, TAY, TXA, TYA, TXS, and TSX leave the original register (the middle letter) uncorrupted. It just copies the value to the register indicated by the last letter. This sets A and Y to zero, for example...

 

LDA 0

TAY

 

NOTE: careful about using the Stack pointer. If the stack currently isn't being utilized by a routine (i.e. no JSR return addresses are being kept track of, etc)., you are free to use it. Reset it to value #$FF once you are done with it (i.e. before any stack usage is going to be done) via LDX #$FF / TXS.

[+Random Terrain]

I don't know what the CYOA application that Atarius Maximus wrote is, but the thing you're talking about sounds like fun.

[Nukey Shay]

I dunno if that was sarcasm or not. A search for CYOA points almost directly at his thread.

http://www.atariage.com/forums/index.php?showtopic=47441

[+Random Terrain]

I dunno if that was sarcasm or not. A search for CYOA points almost directly at his thread.

http://www.atariage.com/forums/index.php?showtopic=47441

Thanks. Nope, never heard of it and I was too lazy to search for it. If this is program is supposed to be better, I figured it would be a waste of time to search for CYOA.

[EarthQuake]

...but the thing you're talking about sounds like fun.

Oh it will be!

 

CYOA (Create Your Own Adventure) was a program that basically just replaced things in the original Adventure and spit out a binary. You couldn't add stuff and you were limited by the restrictions of the original game. What I'm aiming for here is an application that uses a flexible modified source code to let you create something a little more adventuring.

 

Right now the features look something like this:

• Easily modify any of the graphics including rooms.
  
• Up to 128 rooms should be possible (although 64 is more practical).
  
• Connect those rooms however you like.
  
• Establish room connections dependent on difficulty level.
  
• Ability to choose background colors for rooms.
  
• Up to five dragons are supported.
  
• Modify dragon movement and biting speeds.
  
• Additional portcullises are planned.
  
• Enable or disable any object in the game.
  
• Easily position any object's locations and what rooms they can appear in.
  
• Up to four difficulty levels which are somewhat configurable.
  
• Specify starting and winning rooms for each difficulty level.
  
• Option to enable new sound effects.
  

This is a pretty big and ambitious list (and incomplete), so I can't guarantee anything. I will have to do things one at a time, starting with the more important stuff. Getting the room connections to work will be the largest task, and difficulty room differences to work will probably be the hardest task.

 

Before I can really work on the program in it's entirety, I need to finish the source code and make it so the program can easily modify it (using IF/ELSE directives and moving all variables to a general location so they can be switched on or off).

 

Right now I'm trying to get the source code in a state where dark rooms are automatically set up for the user, but I'm still having trouble with changing the surround (without changing the other items). I'll start working on the program more and more as I get more things working in the source code. There are a lot of details I need to plan out before I jump in head-first.

Edited October 17, 2008 by EarthQuake

[+Random Terrain]

Sounds great. I hope you finish it. I'd also like to see this kind of thing made for other games too in the future.

 

Will this program only allow the user to create a static world, or will there be an option to include controlled randomness?

[EarthQuake]

Well, I've figured out how to control which difficulty levels can be randomized, but that only covers object placement. I might be able to modify the seed for the random number generation, which will allow you to have several binaries each with their own possibilities.

 

I'm not sure how else I could make the game more random other than that. But if I think of something, I'll make an effort to include it!

Edited October 17, 2008 by EarthQuake

[accousticguitar]

How's Adventure Odyssey coming along?

[EarthQuake]

Well considering the source code for this program is based off the Odyssey source, it's still coming along.

[EarthQuake]

Woot!

 

I finally got the surround recoloring working! There is still an issue with room $00, but it might have to do with some of my constants being set incorrectly. Time to get bustin on this program now.

 

In the picture below, the playfield and background both use the playfield color from the room data table. The surround is actually white, but it is changed to use the background color from the room data table. Took me enough tries, but I got it.