100 replies to this topic

[Nukey Shay]

Yeah, because it's impossible to do in 7 bits AFAIK. You could cheat and expand the gfx to use all 8...

X X  X X
XXXXXXXX
X X  X X
XXXXXXXX
X X  X X
XXXXXXXX
X X  X X
XXXXXXXX
X X  X X
XXXXXXXX
X X  X X

[accousticguitar]

That works like a charm! Doggone it though, that's going to bug me now that almost every version out there has it off center.

[EarthQuake]

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.

[accousticguitar]

I tried Nukey's suggestion and made it 1 bit wider. Works great! I even built an image into it like I've seen somewhere before on another hack.

[EarthQuake]

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?

[EarthQuake]

Got bored.

Attached Files

•  Badventure.zip   4.52K   79 downloads

[Impaler_26]

EarthQuake, on Sun Nov 23, 2008 6:13 PM, said:

Got bored.

Cute!

[lemoncurry]

This stuff is neat. I really hope to get a chance to get into this stuff someday if I can find the time. Assembly language is fun, and looks like doing it in the context of a limited piece of hardware like the 2600 is quite a challenge.

Meanwhile, here's all I have in the way of a contribution :

kernel
(Note: NOT "kernal").
1. The essential part of Unix or other operating systems, responsible for resource allocation, low-level hardware interfaces, security etc. See also microkernel.
2. An essential subset of a programming language, in terms of which other constructs are (or could be) defined. Also known as a core language.
(1996-06-07)
The Free On-line Dictionary of Computing, © 1993-2007 Denis Howe

[supercat]

Would it be practical to adapt the Adventure game engine to use a different kernel? I have a kernel I wrote which uses a bit more RAM that would be ideal, and would really only be suitable for an 8K or bigger cartridge, but it allows two 2lk objects, colored per line pair along with the Ball; the background is 25 rows (8 lines each) by 40 pixels wide, with even and odd scan lines separately drawn and colored. Each screen has 25 bytes that serve as indexes into a master row list; all screens in a bank must together use 256 or fewer rows total. The kernel uses about 32-40 bytes.

[Nukey Shay]

The original game is not practical or efficient.
Knock yourself out

[mos6507]

Better yet, an Adventure game with a Raiders style inventory, kind of like Swordquest with real playability.

[atwwong]

Must not touch assembly files... must stay away... argh!!!

[EarthQuake]

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!

Edited by EarthQuake, Fri Nov 28, 2008 7:29 AM.

[EarthQuake]

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.

Attached Files

•  osc1.zip   18.37K   67 downloads

[accousticguitar]

This is so cool!

[EarthQuake]

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.

Attached Files

•  osc1_source.zip   11.28K   53 downloads

Edited by EarthQuake, Fri Nov 28, 2008 6:15 PM.

[EarthQuake]

GAH

[EarthQuake]

Seriously, what the hell is wrong with AtariAge?

[EarthQuake]

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.

[EarthQuake]

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.

Attached Thumbnails

• 

Attached Files

•  plan_b.zip   9.81K   54 downloads

[gambler172]

Hi EarthQuake
Good work.
greetings Walter

[atwwong]

EarthQuake, on Fri Nov 28, 2008 3:34 PM, said:

Seriously, what the hell is wrong with AtariAge?

Did you mean Plan A didn't work???

Thanks for sharing!

[EarthQuake]

Haha, no, was angry about this.

So atwwong, do we get to see any more Adventure hacks?
It was a neat experience working on Odyssey alongside Haunted Adventure way back in the day. Good memories.

[atwwong]

EarthQuake, on Mon Dec 1, 2008 5:54 AM, said:

Haha, no, was angry about this.

So atwwong, do we get to see any more Adventure hacks?
It was a neat experience working on Odyssey alongside Haunted Adventure way back in the day. Good memories.

Interesting traceroute problem. Right now my Real-Life ™ work is keeping me busy so no assemblies worth reporting on for now.

Yikes, if back in the day is around 3 or so years ago, what about pre-1980's days...

[EarthQuake]

Ahh, I'm a youngin compared to most people around these woods. I don't remember those days.