EarthQuake

Two things with the above code: You checked for PlayerY instead of PlayerX, and the sprite flipping is backward. I dunno how to fix the latter, using BPL instead of BMI misses something and causes crashes when I have a lot of dragons on screen. EDIT: Oh duh, just flip the dragon bitmaps.

I've thought about the same thing in the past, but I just came to accept the current behavior. Nukey Shay recently packed the kernal a bit tighter, so it might actually be possible now, but there is still the problem of positioning the dragon when it bites the player when it's being flipped. It's a really good idea though, just don't know how feasible this would be.

Another option would be to make their biting delays different.

Here's a few Adventure challenges for someone: 1. Some speed runs on level 3 (the randomization would play a huge part in the times). 2. A speedrun on level 1 or 2 with all items returned to the yellow castle. 3. A speedrun on level 3 with all dragons killed. I've attempted several speedruns on level 1, but my best time was about 31 seconds.

Hello. I ran into a similar problem when testing Odyssey. A good solution for breaking them up is making them fear each other or having just one fear the other. This reduces the chances of having several dragons of the same speed grouping together as one, making it easy on the player.

Not I, but the very last part involving the portcullis was a really nice trick. Good way to shave off a second or two during speedruns. The guy did sort of mess up a few times (like coming back into the corridors below the gold castle), setting his time back several seconds, but a good run nonetheless.

I absolutely cannot get enough of this game. It is probably my favorite 2600 game next to Adventure. I had some questions though regarding the game from a development perspective. Is the 32KB size due to the inefficiency of Batari Basic? Not trying to be negative towards bB, but I understand it is relatively limited in comparison to programming from the start in assembly. It seems the game is pretty simple for a 32KB ROM, although I do understand the calculations required to perform all the game functions are probably pretty extensive. Also, do you have any plans on sequels or expansions? Perhaps even source code optimizations (on the assembly-level) to allow newer features or more quests and mazes? If not, do you plan to release the source code?

I'd like to say this is one of my new favorites. I was always sort of attracted to DC/RPG styled game. I've played Dragonstomper, but was pretty disappointed in it's complexity and there really aren't any other games out there for the 2600 like this. You've done a wonderful job of making this a very simple, yet replayable game. A dungeon-crawl game with a joystick and a button. It doesn't get better than that. I wanted to point out one peeve with the whole game, and trust me, this is absolutely not personal at all and I don't know how to not be blunt about it... I really don't admire the title music at all. It seems really flat, off-key, and cheesy-sounding. I think something else would be more suitable, if not silence. Something dark and dreary would fit the atmosphere a bit better.

Actually this concept has some huge potential. It really needs dynamic music (something similar to Lead), I can't stress that enough, but I'm sure you already have it planned. Also, this could use some visual sprucing up. Flashing colors, special effects. Basically whatever you can wrap your brain around that could 'sync' with the gameplay. Also, have you considered giving some slack based on how many consecutive "notes" you hit? Like say I miss two notes early on, and I get a good 30+ combo going, I should probably get some X's erased. Think of like in Guitar Hero or DDR (iirc) where you're allowed to miss so many notes before your 'meter' drops. Perhaps the difficulty could become ramped up by spacing the 4 boxes closer together, adjusting the speed at which they travel, or both. You could explore quite a few gameplay enhancements to keep this a very enjoyable game. I look forward to future versions.

I'm definitely not passing this one up. I'll happily dish out $50 for something like this. I just hope it sees itself through and proves to be solid.

If I don't get my sorry ass out of the house tonight (I live in a college party town, so there's lots going on), then I've got plans for Haunted Adventure.

The game is a bit frustrating at first, but it's a good concept. I like the bubbles on the fish, I just think the gap needs to be a bit wider (literally). Oh, and I did you a seahorse sprite. It's a bit smaller but it still looks like a seahorse.

Finally got the bloody thing. Thank you Rybags for the suggestion.

Heh, never seen that before. I'm sure whoever wrote it was more talented and experienced than I am. I've only been programming in VB for several years. It's not really the programming itself that stumps me, it's the logical thinking of it all. Doesn't really matter what language I work in, it's just a bit difficult for me to do some things in an easy yet efficient manner. I think I almost got this though. I got the array to fill with the proper values, but I'm still having problems getting the input to work. Should have it figured out in a couple hours. Actually, it looks like that playfield editor uses something like a spreadsheet control. I went the GDI route and did all the drawing by hand. The form only has a picture box on it so far. The rest is code. Lol.

So basically, say I have the row height array hold: 16, 32, 32, 32, 32, 32, and 16 And just fill another array with: 16, 48, 80, 112, 144, 176 And check where the Y coordinate falls between? Edit: OH! You mean fill an array with 192 values that each represent a value that corresponds to an index in the row height array. Haha, okay, yeah, that should work out okay. If it's a byte array, it would only use up like 1/4th of a KB, so it would not be too memory-draining.

First off, I apologize if this thread isn't suited for this forum, but I didn't see anywhere I could put it. I've been working on a playfield bitmap editor for a 2600 game. What's special about this editor is that each row can be of a different height because the game it's been created for supports playfields of variable resolution where some rows of pixels may be taller than other rows. The way I have it set up so far, an array is filled with the height value of each row and the program displays each row at a time adjusting the height of the row. Displaywise, everything is perfect. Now, since this is an bitmap editor, you gotta have input right? I can get the X and Y coordinates of where the mouse pointer is, but I have been bashing my head against the desk trying to figure out how I get the Y coordinate to "line up" with the values in row height array. The X and Y coordinates are in pixels (0 to 319 for X, and 0 to 191 for Y). Only the Y coordinates are relevant to this problem, by the way. If each row was the same height, I could just divide Y by however many rows there are. So if I had a playfield with 24 rows, I just divide by 8 (because 8 x 24 = 192) and everything is fine. In this case, the height array holds 24 values which are all 8. I could just hard code the damned thing, but that defeats the purpose of the editor. The only other option I can think of is looping through the row height array and comparing the Y mouse coordinate, but that would slow the program down when drawing. I really don't know what sort of a solution I am looking for... I am using Visual Basic 5 (just FYI). If you need additional information, just ask. Thanks. Edit: Attached is an example of one of the variable-height playfields I have in mind.

Aha. So that's why if a flashing object is in the winning screen, it flashes at a faster pace until the select screen is invoked again. Seriously, there is so much stuff going on in Adventure, one could write a book about it.

Not exactly sure what you meant by the wrong selection number being displayed, but by setting the game to inactive, do the dragons and bat still move around? This is a pretty important step to making the game a bit more random by allowing things to move around while you are still on the game select screen. It doesn't really need fixed, at least on randomized levels, as it would make the limited variations more predictable. For the slow-mo winning sound, couldn't you just play a sound that overrides the sound? If you played it at volume 0, it would still take priority (as long as it's on the same channel) and cut off the sound?

Great. Now come up with something to do with all that RAM.

Thanks for the suggestion ClassicGMR. I just received one of those. My old switchbox was starting to fall apart and was giving a really fuzzy picture. You should have seen all the electrical tape holding that thing together.

It should be fine as it is. This is another one of those things I wanted to implement for the Adventure creator program. I probably won't use it in Odyssey at all. Someone mentioned it in another thread a couple years ago, and I always thought it was a good idea.

Haha thanks, this is nice. Not only are there less cycles used, but it solves my next challenge of having the difficulty switches affect their speed as well. I dunno where you come up with these sorts of things Nukey.

Can anyone think of a more efficient way of doing this per dragon? ;Move Dragon #1 MoveDragon1: LDA Level ; Get difficulty level. LSR ; Divide by two. TAY LDA Dragon1Speed,Y; Load speed for this difficulty. TAY LDA #<Dragon1Matrix; Get attraction table. LDX #Dragon1Number; Select this dragon. BNE MoveDragon ; Move this dragon. ;Test speed values for each dragon... Dragon1Speed: .byte $01,$02,$03,$04; (Level 1, Level 2, Level 3, Level 4) Dragon2Speed: .byte $01,$02,$03,$04; (Level 1, Level 2, Level 3, Level 4) Dragon3Speed: .byte $01,$02,$03,$04; (Level 1, Level 2, Level 3, Level 4) Dragon4Speed: .byte $01,$02,$03,$04; (Level 1, Level 2, Level 3, Level 4) Dragon5Speed: .byte $01,$02,$03,$04; (Level 1, Level 2, Level 3, Level 4) I thought about just loading an offset value into Y so that when it's passed to MoveDragon, it would load the appropriate speed from a table given the difficulty level. But I don't really know how to load a value from a table given two different offsets. I assume some addition or multiplication would be required, but if I can't find a way of doing it in 11 cycles or less, I might as well keep this as it is. Any ideas?

Hmm... You might want to pick a different title. There are already a dozen "Optimizing the Adventure Souce Code" threads. Actually, if you're serious about renaming it for the sake of making it easier for someone looking for specific information, then I wouldn't bother. I was thinking about doing a forum search and collecting links to all the different Adventure-related threads. My argument is that Adventure is one of the most hacked 2600 games, and a stickied thread with all the information pertaining to modifying it, would be really useful to people. Just think, four years ago I was using bithacker on Adventure. Now I can write my own assembly! There have been quite a number of developments over the past 5 years or so, and I'm sure people would like to add dragons/castles and other miscellaneous features without having to understand every little thing about Adventure. Nukey did several tutorials on adding all sorts of things to Adventure, and they seem to have been forgotten in time. Don't want that stuff to go to waste. And not only that, but it could get more people into hacking the source code and ultimately get them into assembly like it did for me!