Adventure: Would you use this program?

[EarthQuake]

Actually, I am having a problem. The new code I added checks if an object is the surround before recoloring it. However, since the surround has an object number of $00, it affects the title screen since it is also $00. The ChangeColor routine is used by both, for recoloring the screen and objects to use the color cycling effect you see on the chalice.

 

How can I differentiate between a room and an object? Is there a simple way of doing it, or am I going to have to use some bitwise trick to check it?

 

EDIT: Actually, something more sinister is going on here. Room $00's colors seems to take on colors from room $01, making it a solid color using the playfield color from that room. Setting the darkness bit on room $00 makes it so the background is visible, but the colors are inversed. After hitting the game reset button and after visiting a dark room, the colors are more normal, but are still incorrect (using another room's colors). I'm not quite sure what's going on...

 

Perhaps it has to do with the initial location of the surround when the game starts.

 

EDIT 2: Fixed part of it (I was checking the Surround's room instead of the Player's room in the ChangeColor routine). Room $00 now behaves more normally, but it's still a solid color (at least the colors are correct and it's not gathering information from other rooms.

Edited October 17, 2008 by EarthQuake

[+Random Terrain]

[Nukey Shay]

Easy. Give the surround a specific color value in the Object table (where the Store7 tag is). For example, $FF. Then you can add just 5 lines of code to the routine (and a new color table)...

 

;Change color if necessary.
ChangeColor:
;new lines...
   CMP #$FF;Check if it's specifically the surround
   BEQ ChangeColor_4;branch if so
;existing lines...
   LSR;If bit 0 of the color is set
   BCC ChangeColor_2;then the room is to flash.
   LDA LoCnt;Use frame counter for color.
ChangeColor_2:
   LDY HiCnt;Get the input counter.
   BPL ChangeColor_3;If console/stick moved recently then branch
   EOR HiCnt;Merge the high counter with the color wanted
   AND #$FB;Keep this color bug merge down the luminance
ChangeColor_3:
   ASL;And restore original color if necessary
   RTS

;new stuff...
ChangeColor_4:
   LDY PlayerRoom;Get the current room
   LDA SurroundColorTable,Y;read from a seperate table
   RTS

SurroundColorTable:
;add .byte color values

 

The table should be as long as the highest room number that features the surround (i.e. ones with ball priority set).

[EarthQuake]

I've pretty much got everything sorted out. The only problem is that room $00 is using the wrong playfield color. Everything else works like a charm. Although I think you might have already solved the problem... where does the $FF value in your code come from?

 

Oh, here is the routines I used. Keep in mind efficiency wasn't really my goal. I just wanted to get it to work and clean it up later. I used the Temp variable to restore A to it's original value after I was done changing the color of the surround. Any reason this code might affect room $00?

 

ChangeColor:
   STA	Temp
   LDA	CurrentObject
   CMP	#SurroundNumber
   BEQ	Testies
   LDA	Temp
   
   LSR					  ;If bit 0 of the color is set								 ;2
   BCC	ChangeColor_2	 ;	  then the room is to flash.							 ;2
   LDA	LoCnt			 ;Use frame counter for color.								 ;3

ChangeColor_2:
   LDY	HiCnt			 ;Get the input counter.									;3
   BPL	ChangeColor_3	 ;If console/stick moved recently then branch				  ;2
   EOR	HiCnt			 ;Merge the high counter with the color wanted.				;3
   AND	#$FB			  ;Keep this color bug merge down the luminance.				;2

ChangeColor_3:
   ASL					  ;And restore original color if necessary.					 ;2
ChangeColor_4:
   RTS																					  ;6
   
Testies:
   LDA	PlayerRoom
   JSR	RoomNumToAddress
   LDY	#$03
   LDA	(CurrentObject),Y
   JMP	ChangeColor_4

 

The code does work. It just has the side effect of changing room $00's playfield color somehow.

Edited October 17, 2008 by EarthQuake

[Nukey Shay]

Noplace. It's just a value I picked out of a hat. The value you want to use in the CMP# should be the same "color" you give to the Store7 tag. It can be anything, but you should avoid even-numbered values (to keep the program flexible and allow users to choose any color from the 128 supported)...to keep the surround code from interfering with other things.

[EarthQuake]

Oh so I should check it's color as well as it's number, and use some arbitrary, yet obscure color value to compare with (since I won't be using the surround's color value for anything else).

 

I'll try it and see what happens. I really am hoping I was correct in assuming it was changing room $00 because it has the same number as the surround.

[Nukey Shay]

The code does work. It just has the side effect of changing room $00's playfield color somehow.

 

That's because the surround object IS object number zero. So is room zero (remember, this subroutine is also used for playfield color). Thus, when new room data is gathered, the program jumps to this subroutine to set the color...and mistakes the value in CurrentObject (which was the current room, in that case) as being the surround. The CurrentObject variable is reused for both. It's generic.

 

CurrentObject = surround = 0

CurrentObject = room number = 0

[Nukey Shay]

I really am hoping I was correct in assuming it was changing room $00 because it has the same number as the surround.

 

Correct

 

It's easier to avoid this mess by assigning a specific color value - which redirects the code elsewhere. That way, there is never any confusion by a generic routine like this.

[EarthQuake]

Got 'er!

 

Yeah, it was just as I suspected, but checking for some obscure color value was the perfect plan, Nukey.

The user can't choose any odd numbers to begin with, so if they want the room/object to flash, they can just click on a checkbox, which in turn assigns the value $CB to the room/object. So if I reserve, say $CD, for the surround color, everything will be good later down the road.

 

Thanks Nukey, despite the confusing post war we just had.

[Lauren Tyler]

I know it's been awhile since you posted, but best of luck to you!

[nonner242]

[Byte Knight]

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

 

I just ran across this thread... I would love to be one of those newbies making a bad hack! How is this project coming?

[EarthQuake]

Ack! Yeah, so...

 

I've been away from AtariAge for a little while busy with some other things, but in several weeks I'll be returning to finish up my Adventure hack. After that, I'll be putting my time into writing Ceuta. I've been sort of challenging my programming skills lately, so hopefully I'll be a bit more prepared for this when I get back. It's a rather ambitious project.

 

Getting the Odyssey engine to work flawlessly is my main priority, as Ceuta will use the source code as a base for everything you can do with it. You won't be able to compile a 4K ROM with it, but you'll be able to accurately reproduce the original Adventure as an 8K ROM.

Edited April 13, 2009 by EarthQuake

[Impaler_26]

I would love to be one of those newbies making a bad hack!

If you wanna make a hack of Adventure try Create Your Own Adventure.

[Byte Knight]

I would love to be one of those newbies making a bad hack!

If you wanna make a hack of Adventure try Create Your Own Adventure.

 

Yeah, I've tried CYOA - great program but it doesn't let you change enough things... That's one of the reasons that I made my game from scratch.