EarthQuake

Thanks for the suggestion. I did as you instructed and these were the results. The first trace is during one of the epidsodes. These are in sequential order, I assume? If that's the case, it's definitely not on my end. What does this mean in terms of solving the problem? Tracing route to atariage.com [216.40.231.66] over a maximum of 30 hops: 1 50 ms 48 ms 48 ms 10.34.37.1 2 50 ms 48 ms 48 ms so-0-3-3-0.CORE-RTR1.CHI01.verizon-gni.net [130.81.36.180] 3 52 ms 51 ms 50 ms so-7-2-0-0.BB-RTR1.CHI01.verizon-gni.net [130.81.20.56] 4 51 ms 51 ms 48 ms so-6-0-0-0.PEER-RTR1.CHI80.verizon-gni.net [130.81.16.11] 5 49 ms 48 ms 48 ms 130.81.15.166 6 101 ms 102 ms 102 ms hagg-03-ge-0-0-0-540.hsto.twtelecom.net [66.192.246.206] 7 80 ms 78 ms 77 ms et3-3.ibr01.hstntx1.theplanet.com [70.87.253.153] 8 79 ms 78 ms 80 ms po1.car01.hstntx1.theplanet.com [207.218.223.2] 9 * * * Request timed out. 10 78 ms 77 ms 80 ms stella.atariage.net [216.40.231.66] Trace complete. Tracing route to atariage.com [216.40.231.66] over a maximum of 30 hops: 1 50 ms 48 ms 51 ms 10.34.37.1 2 48 ms 48 ms 48 ms so-0-3-3-0.CORE-RTR1.CHI01.verizon-gni.net [130.81.36.180] 3 52 ms 51 ms 51 ms so-7-2-0-0.BB-RTR1.CHI01.verizon-gni.net [130.81.20.56] 4 50 ms 50 ms 48 ms so-6-0-0-0.PEER-RTR1.CHI80.verizon-gni.net [130.81.16.11] 5 48 ms 48 ms 48 ms 130.81.15.166 6 103 ms 107 ms 103 ms hagg-03-ge-0-0-0-540.hsto.twtelecom.net [66.192.246.206] 7 76 ms 78 ms 78 ms et3-3.ibr01.hstntx1.theplanet.com [70.87.253.153] 8 79 ms 78 ms 79 ms po1.car01.hstntx1.theplanet.com [207.218.223.2] 9 78 ms 77 ms 79 ms stella.atariage.net [216.40.231.66] Trace complete.

This is really getting to be a pain... I tried a few more things and the problem still persists. I connected directly to my router as opposed to using my wireless, and there was no change. I also try pinging the server during several episodes, and it reported a 25% packet loss each time. One time I was loading a page and it didn't fetch the stylesheet, confirming the packet loss. Not sure exactly what's going on, but from my end, it seems like something is blocking or interfering with my connection. It could be a firewall, or possibly even my ISP. I've been able to view other forums using the same software without any problems whatsoever. It's solely AtariAge which is giving me problems... I really don't know what to do aside from calling my ISP and seeing what's up...

Simple tool I wrote to aid with screen connections and world layouts. Instructions are on the program window. Here's a preview. It took me longer to make the screenshot, than write the program. plan_b.zip

Simple tool I wrote to aid with screen connections and world layouts. Instructions are on the program window. Here's a preview. It took me longer to make the screenshot, than write the program.

Yeah, I can only test from this laptop at the moment, but I haven't changed any of my network configuration and it only seems to be doing this on AtariAge. I'll go to make a forum post or just visit the main page and it hangs like my internet went out. After it displays the error page, I can immediately reconnect fine, and everything is okay for a minute or so and it happens all over again. I've been browsing the internet like crazy, and I haven't experienced any problems elsewhere.

Seriously, what the hell is wrong with AtariAge?

GAH

Here's the source code to the editor, in case I decide to disappear one day and someone wants to update the editor. I stopped optimizing and commenting it at one point, so some of it uses some rather ugly hacks, but again.. it works. osc1_source.zip

I've been having one hell of a time staying connected to AA. I keep getting network timeout errors and posting in the forums is painfully excruciating. This started happening only recently and I have no other problems with other websites. Something going on with the servers or is it just me?

Alright, here it is. I skimped on some features, but it should output assembly compatible with Nukey's new kernal. Accousticguitar, when you get the chance to read this, let me know the format you're currently working with and I'll add support for it. I assume you're working with the original kernal with 7 rows of data per map, no scanline count, and no playfield control? Also, the editor's map format is unlikely to change, so if you want to use this editor now, you can always save your work and load it with future versions. osc1.zip

So I just had an epiphany and figured out how to fix my program's routine... I just wish I would have thought about it sooner. Instead of putting the scanline count on the end of each line, I put it on the previous line, skip the first line, and add a value of "96" to the end of the last line. I tried doing this before, but the idea this time around was to move around the line break to the beginning of the line, leaving the end of the line open (without a line break), and appending the scanline count on the next iteration and then adding the linebreak and printing the next line of data. Rinse. Repeat. This of course requires that I check to see if the current line is the first, and skip printing the scanline count and line break. Another result of doing this is that the last line doesn't have a scanline count, but by adding the 96, I solve this problem and also ensures the room bitmap will fill the screen when pasted into the assembly. That's mostly a precaution because I don't think it's possible for the program to miscount the row data's scanline count, but oh well. That probably doesn't make sense, but hey at least it works!

Got bored. Badventure.zip

Okay, I'm sorry, but I am not going anywhere with this... I need help. I'm stuck on the routine in my program that generates the source code. It grabs the information from the pixel array and converts it perfectly, the only problem is getting the correct scanline count to display on the end of each row's data written to the output box. Basically, this is how my code is structured: Initialize stuff. Count = 2 Previous_Row = Whatever (see note 1) Loop Y (iterates 48 times) Loop X (iterates 20 times) Get map data from array and store in variables. End Loop X Convert map data into assembly-compatible values. Current_Row = Value based on data retrieved from array. (see note 2) If Current_Row = Previous_Row Then Increment Count by 2. Else Write converted map data to output box with Count variable. Reset Count to 2. End If Previous_Row = Current_Row End Loop Y What happens is when a change in map row data occurs, it prints to the output box. Otherwise, the Count is increased. (Note 1:) It is obvious that during the first iteration of the Y loop, that the Previous_Row variable is going to be 2. On subsequent iterations, it prints the data after the change in rows is detected. This means, the scanline count is going to be off by one row, with the first row of data having a scanline count of 2. (Note 2:) The code stores a value based on the data extracted and converted from the pixel array. This is used to compare different rows. Is there a way I can restructure this to account for these issues?

I first noticed it like three years ago with revision 9 or 10 of Odyssey. I recently tried to fix it, but couldn't get something that looked good enough. Just accept it as part of the game and it won't drive you nuts.

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

"Yeah, Adventure can do that."

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.

Any hex editor will work and I'm certain there are hex editors for a Mac. Just google around.

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:

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

Dragonstomper covers pretty much all aspects of it, but Dungeon really hits the spot as a simple and extremely fun RPG-styled game. It is probably more appropriate to call it a dungeon crawl or roguelike game, but then again, a full-fledged RPG is a difficult task for the 2600, so this game is a great middle ground. It is probably my favorite game next to Adventure.

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

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.