Adventure w/multicolor sprites

[+Gemintronic]

How about procedural Adventure? Use a PRNG to select between 256 worlds - each generated based off of a seed

[edweird13]

Have you thought of taking the original game having it level 3 only with a variation selection so you can chose the adventure you like. Even the ones where the keys are locked in the castles.

[Nukey Shay]

You can do this already in Stella with the original unhacked game. Set a trap at LF413 (type trap $f413 in the debugger window) - the start of the randomization subroutine. When the debugger appears as you press select to get to level 3, alter ram address $E5 to any seed you want. Just click on the value shown and type a new one. Exit the debugger with the ~ key and press f2 (game reset) to see what that seed generates.

[+Gemintronic]

You can do this already in Stella with the original unhacked game. Set a trap at LF413 (type trap $f413 in the debugger window) - the start of the randomization subroutine. When the debugger appears as you press select to get to level 3, alter ram address $E5 to any seed you want. Just click on the value shown and type a new one. Exit the debugger with the ~ key and press f2 (game reset) to see what that seed generates.

 

I appreciate the how-to on that! It's kind of dumb but it'd probably be easier for me to make my own than learn Stellas debugging features. It's not Stellas fault - I can't learn VCR interfaces either

[Nukey Shay]

That was how I mapped the first 64 seeds. Worried that an altered rom might skew the result, I just used the debugger instead....with traps set at the start and end of the subroutine. Typing each seed value whenever the first trap hit. When the second trap was hit, I jotted down the room numbers given to all the randomized objects (the X/Y location and movement direction are left unchanged from game #2's values - only the room number changes).

 

Room # variable for each object:

$a4 = red dragon

$a9 = yellow dragon

$ae = green dragon

$b3 = magnet

$b6 = sword

$b9 = chalise

$bc = bridge

$bf = yellow key

$c2 = white key

$c5 = black key

$cb = bat

[+Gemintronic]

Have you attempted to manually filter unbeatable games or does Warren already take care of that?

[Nukey Shay]

His program obviously didn't do it since the unwinnable games are still there - all due to hitting game select from #2 to #3 at the wrong times. You could use a lookup table to invalidate bad seed values (of course the remaining 192 seeds would need mapping...I only did the first 64), but there are better ways of keeping conflicts in check for a hack. The main problem is that the program does not look to see if at least one of the three keys is out of a castle (and worse, the yellow key's boundries allow it to be given any room # - even it's own castle's interior). Grouping castle rooms to be at the start and end of the map seems to work well enough.

[Nukey Shay]

New version:

Running out of space in the main program's bank would be an issue if a lot of rooms and decorative objects are added (especially when recoloring scanlines!), so I moved the object caching routine and all object tables to a different bank. Only 1 table needs an untagged duplicate in the program bank (Object_Data_LSB -> Object_Data_LSB2).

 

Also, the map portal routine is quite a departure from Adventure (and you may not have a use for it), so this can be turned off in the assembly options. You'll save 3 bytes of ram reserved for the portal sprite when the map is not enabled.

Adventure(16-32).asm

[SoundGammon]

Hi Nukey! I had an idea along time ago that Adventure needed a bat cave, where the bat lives, but he left because something from cave is gone and he is searching the kingdom for it! He finds the Chalice and brings it to his cave and guards it until the player finds the item the bat was looking for and brings it to him for a trade! I just can't think of an item to put in the game to please the bat. Any ideas?

[Nukey Shay]

Robin The Boy Wonder? A female bat? I dunno.

[Nukey Shay]

BTW you could create a version where the bat won't swap objects unless a more-desired object is present very easily...just ignore or remove the "fed-up" timer and branch, and it will always be on the lookout for his precious.

 

Solving the previous issue with randomization can also be done. This was suggested long ago (I forget who), but I shrugged it off because romspace is so limited for the program. Not so much now, you can devote an entire bank for the setup routine if you needed. Instead of using a boundry table to declare where objects CAN be placed, use an "ignore" table for each object to specify rooms that they should NOT be placed.

[Nukey Shay]

Here's that fix. Two data tables have been added to the randomization routine (in the Titlescreen kernel): Invalid_Room_Tbl - which holds all of the special case rooms w/delimiters for multiple exceptions, and Invalid_Room_Index - which holds the pointer to that table for objects that require it (value 0 if not). Upper bounds/lower bounds tables are still present...to invalidate an entire range of rooms.

 

I also split these other kernels off from the main assembly to make editing a bit easier to manage.

Adventure(16-32).zip

Edited August 23, 2014 by Nukey Shay

[Nukey Shay]

Current developments:

 

New build w/Superchip ram enabled. All movable object data moved there...which frees up most of the native ram (for possible reduced flicker or asymmetrical screens). There appears to be a nasty glitch that shows up in Stella, tho - entering a screen containing the bridge will usually warp you into the belly of the yellow dragon for some reason. I can't replicate the bug in Z26, so tracing the problem is going to take some time.

 

BTW use F6SC in Stella, or -g6 in Z26.

SARAdventure.zip

[accousticguitar]

Those new data tables will sure come in handy for excluding keys from their own castle. I wish I had that capability when I was working on Missadventure!

[Nukey Shay]

Found the glitch...one of the writes to SC was being done to its read address when dealing with the bridge Almost done revising the program...it won't let you recolor playfield lines (not that this was very well supported anyway), or cross pages for room gfx (no big deal), BUT all sprite bitmaps will be able to exist on any banks like the room bitmaps. Handy since recoloring sprite lines really consumes memory fast if it's confined to a single bank.

[+Gemintronic]

Man, you can almost pull this off in batari BASIC. RevEngs modified kernel doesn't need SuperChip RAM but loses the missiles.

http://atariage.com/forums/topic/218357-vertical-scrolling-no-blank-lines-playercolors-demo/

[Nukey Shay]

Updated...now you can put sprite and room bitmaps wherever you want. Executing a short routine (41 bytes) in ram handles the necessary banking to each bitmap during the display kernel. It may be possible to squeeze in a little extra stuff (like page-crossing)...there's some time left over on scanlines where the playfield or playfield cache are not being updated - 39 cycles in the No_Playfield tag.

 

I got rid of the |BANK tags, too (you don't need to declare where you are putting bitmaps and the other kernels...jut paste 'em in any bank other than the last one). Glitch with the bridge is fixed. The dragons have hit points, and the large bat revives them (both of these options and many others are selectable in the assembly file).

 

The map is still unchanged, tho...aside from the 5 extra castles.

SARAdventure.zip

[Nukey Shay]

Page crossing/color changing code added to the main assembly. The rom display code becomes 45 bytes longer by using this, so it's a selectable option for those who never intend to use it (the display code still fits in a single page either way, however). If a page break is hit before playfield caching of the next 4 bytes takes place, it will automatically bump to the start of the next page...skipping the remaining 1-3 bytes in the process. You could use those bytes for color-changing before playfield caching takes place, if you wanted to. A page break is automatically checked when changing the color.

 

Color changing:

This works the same way as in the old 16-32 assembly: if the next byte following a data line has the high bit set ($80 or higher), the value is shifted left 1 bit and used as a new color for the playfield *with the current playfield data it's using*. As before, you can recolor a displayed playfield as many times as you want...but the cache routine *must* be allowed to run when the scanline counter is due to run out on the next pass (if your display block is 8 dbl.scanlines high, you can recolor it only 7 times maximum).

SARAdventure.asm

Edited September 17, 2014 by Nukey Shay