TROGDOR

That's a good idea for the sword control, Philsan. If you wanted to move in the opposite direction, say from left to right, you'd have to rotate the joystick through all the rotation positions for the movement to register. So left, then up-left, then up, then up-right, then right. This would happen in a fraction of a second, so it wouldn't be a distraction to the player, but it would make for more challenging play than just pressing in the other direction. It better represents the swinging of the sword. The implementation I chose for Labyrinth requires some training, but it's more lifelike. If you use a real sword in a swordfight, you'll find it's a challenge to coordinate your leg movement with movement of the sword. Novice swordfighters have a habit of standing in one place while fighting, when they should be moving. The intent in the game is the player will spend most of their time moving, and occasional fractional seconds adjusting the position of the sword. It does allow for some advantages over the other control method. If you get backed into a corner, you can fight with your back against a wall without having to move toward the opponent to rotate your sword. Also, you can back away from an opponent while keeping your sword pointing toward him (another tactic that is essential in real swordfighting.) I did some searching for a manual scan for S&S, and couldn't find anything. I'm surprised the manuals haven't been scanned and saved for posterity. I'm guessing it's a copyright issue, but it's unfortunate.

My ears are burning. My intention for Labyrinth was a mix of S&S, Dragon's Lair, and Gateway to Apshai. The sword battles are very similar to S&S. If you download the bin, you'll see that the Goblin AI is also very similar to the S&S AI. Labyrinth has a control system that could allow full functionality of the original S&S: - Pushing the joystick in any direction moves your player in that direction. - Holding down the button allows you to rotate the sword. Pressing right is clockwise, left is counter-clockwise. - Holding down the button while pushing up allows you to select a different item in your inventory. - Holding down the button while pushing down activates the selected inventory item, casting it in the direction you're currently facing. I haven't implemented inventory items yet. My current development efforts are focused on Stellar Fortress. I've owned the original Intellivision S&S since around 1986. It was always a fascinating game, but not very playable unless you had another person around to play the wizard. The gameplay is repetitious for the knight. The wizard could only stun enemies with his default spell, which had unlimited casts. The warrior had to kill them. The wizard did have access to a fireball spell when he found the scroll, but it only allowed 3 casts, if I remember correctly. Espire8, I'm really impressed with your 8-bit graphics artistry. That dragon looks great considering the resolution. Unfortunately, given the limitations of the 2600, I don't think the mock up you've made can be implemented without a lot of flicker or skipped scanlines. I think only supercat could pull it off. He's done some very nice kernels. One thing to keep in mind is that P0 and M0 must be the same color. Your current mock up would require the M0 to appear on a different frame than the P0 for the player. Also, a horizontal scrolling background is next to impossible on the Atari without using a ton of memory and cycles. Your best bet would be to use a multi-screen approach similar to Adventure, or limit scrolling to vertical, which is much easier to implement. Still, the mock ups look great.

It could be done on one joystick. When the button is not pressed, the joystick moves the player around on the platforms (forward/backward, left/right). When the button is pressed down, the target crosshairs move (up/down, left/right). When the button is released, a disc is fired. Granted, this would require the user to stand still while aiming, but that would still work with the game play. It just means you have to aim quickly.

It does neither look faster, nor smaller than the bit-shifting code. Add in the need for boundry checks and you'll realize that with this approach you actually don't even know where you're going Details. Details. I was having so much fun optimizing the look-up code, I didn't go back and byte/cycle count the bit-shifting code. You burst my bubble. Bit shifting is definitely the way to go. But without the 2s complement, it's not nearly as sexy.

Here's what Michael's routine would look like in assembly: LDA SWCHA LSR LSR LSR LSR TAY ; Store for later use. LSR LSR ; A now holds D7 and D6 from SWCHA in bits 1 and 0. TAX LDA JoyDeltaTable,X CLC ADC Xloc STA Xloc TYA AND #%00000011 TAX LDA JoyDeltaTable,X EOR #$FF SEC ; 2s Compliment from the above EOR. ADC Yloc STA Yloc JoyDeltaTable .byte #0 .byte #1 .byte #255 .byte #0 Note that by adding two more LSRs in the X delta check, and using a 2s compliment on the Y delta, you can reduce the 32 byte ROM table down to just 4 bytes. I haven't tested this code, but it looks like it should work.

Be careful when reading SWCHA. It's generally better to load SWCHA into a register or a temp variable at the start of your joystick routine. Don't do multiple checks directly against SWCHA in one frame. The danger is that the user will happen to press the joystick in the middle of the joystick checking routine, which would cause SWCHA to change state in the middle of the logic. This caused a nasty transitional logic bug in Master of Arcturus. I generally use a technique similar to Supercat, except I store the register in a temp var so I don't have to worry about preservation. However, I really like Michael's lookup technique. It's very elegant, definitely faster, and may even be less ROM. I may try this out in Stellar Fortress.

Great game! I'd suggest an occasional bonus bomb that the player can pick up. They can then use the fire button to detonate the bomb, which will destroy all blocks in a 3 block radius of the player. The virus theme is good. Something like Fantastic Voyage. Your microscopic ship has been implanted into the President's brain to destroy a dangerous growth, which is impeding his ability to make competent decisions.

The targeting computer for the Plasma Cannon is now online: Now witness the firepower of this fully armed and operational battle station. sf21.zip New Features: sf21.asm 1/15/08 - Added support for all four quadrants, so the Plasma Cannon can now fire in all 64 directions. - Implemented targeting computer for the Plasma Cannon. The cannon tracks the player's ship and will shoot at it with reasonable accuracy. - Implemented delayed cannon rotation. The cannon now rotates toward the player one direction increment per frame. Current rotation speed is maximum, but this will be slower when easier levels are implemented. - Fixed bug in plasma ball height. Ballend is defined before Ball movement is calculated. This was causing the ball to be 2 scanlines too short on frames with a Y delta. - Compressed the Vectortable to use one byte per vector, rather than two. Greatly simplifies the code, and uses less ROM. Now uses single Vectortable for both X and Y deltas for more ROM saving. To Do: - Rewrite the kernel to squeeze out more cycles and allow for some extra features. - Improve the Plasma Cannon graphics. Currently only 8 directions are implemented. This will be expanded to 16, as was done with the player's ship. - Design the Stellar Fortress destruction animation. - Title screen and title music. - Targeting computer for missiles. - Add starting level selection and gradual difficulty increase per level. Known Issues: - There are many issues right now, too many to list. I'll formally list them when I have more time.

Adds "sithcart" to project list.

It's a 2600 question. What you're describing is difficult to visualize without a screenshot. The best answer is likely a mix of both methods. That was certainly the case for me, when working on Stellar Fortress. Originally I only used coordinate constraints, which meant the player ship couldn't move in the center of the screen at all (where the fortress is.) When I used a mixed solution, I only had to check for collisions when the collision register was flagged, and then the coordinate constraints were used to determine which side I had collided with. This helped determine which direction the ship should ricochet away from the fortress.

I missed this when it was first posted. This is a beauty of a kernel. Can you post commented source? This has forced me to go back and review the illegal opcodes. There's some wacky stuff in there.

Check out this review from IGN. It covers most of the strengths and weaknesses of the game. I played the game myself a few years ago. The only problem I had with it was the boss fights. You will die hundreds of times on some of the boss scenes, and get very frustrated. However, I was able to get through the entire game. The frustration must have been worth it, because I still have fond memories of the game. As mentioned in the review, the PC version is the best, because it uses the mouse. I've never played the game on a console system, but for 3D games I've always considered a mouse essential to get a truly immersive feel. Also, I think there is a patch out there somewhere for the PC version which fixes most of the bugs mentioned in the review. This game is about nostalgia. They did a great job capturing the look and feel of the original game, and that alone makes it worth the purchase. The game is arguably not worth $40 US, but at only $5, it's a no brainer. I think I paid $20 for it back in 2003 or 2004.

As a classic gamer, I of course appreciate the C64 version of Dragon's Lair. But, I have to disagree with this statement: The best game in the series, and the most playable, is Dragon's Lair 3D: Return to the Lair. If you follow that link, you'll find lots of screen shots and videos. If you've never played it, I highly recommend it. It came out in 2002 for PC and several consoles. You can find it on Ebay for 5 bucks.

1. Empire (capture cities to produce tanks, infantry, and ships.) 2. Utopia an Intellivision game. I've always wanted to do both of these games. They could be implemented in a somewhat reduced capacity as SuperCharger games.

Heh. I just got stuck in the same mode while writing a reply post. After a minute of screeching hysterically, I calmed down, went to the Web Site Comments forum, and found this post. Life is good again.

Definitely static screen. Think Adventure with a helicopter. Should be very doable. Is intelliflicker ™ vdub_bobby 2008? "Your flicker is our flicker. Intelliflicker."

a 2LK means you update something every-other-line instead of every line. The Atari will automatically repeat the data from one scanline to the next. If the playfield has different data on each side of the screen then you must update the playfield as a 1LK, but you can still update the sprites, missiles and ball as a 2LK. My understanding of 2LK vs 1LK is that it depends on the structure of your kernel loop rather than what you're updating. A 2LK processes two scanlines per loop, whereas a 1LK processes 1 scanline per loop. The unwrapping of the loop in the 2LK generally allows for more processing time. The Battle of Midway uses a 2LK, but still provides full vertical resolution for all 5 movable objects. I might be wrong on this. I've never seen a formal definition of a 1LK/2LK. Does anyone know when the term was first used, probably on [stella]?

Can you clarify what you mean by visible jitter artifacts? I'm guessing you're referring to the case where the object moves right on one frame, then down on the next frame, rather than diagonally on a single frame. If that's what you mean, I agree that is a risk. However, with the method I've described, the programmer has full control over the exact path that will be taken for each of the angles, in terms of both time and location, so this problem can be avoided. While I was researching the general problem of defining 8-bit vectors, I did some study on Bresenham's line algorithm. One of my earlier implementations attempted to use this algorithm, but it wouldn't work for diagonals because the algorithm assumes that there is always motion on one of the coordinate axis. I needed to slow down the diagonals to provide realistic motion (proper trigonometric ratios) which means constant motion cannot be assumed and it breaks the algorithm. However, I did pick up something useful from that research. All the vectors that I define must follow the path of a proper Bresenham's line. This will prevent jittering. I haven't checked the vectors yet, but I will walk through them and iron out any poorly traversed diagonals. It may require me to individually define the X and Y deltas in ROM, but the extra 16 bytes is worth it to solve the problem. As for the pause of travel on some frames, that is unavoidable, regardless of the implementation. Unless an object is moving at exactly 1 pixel per frame, there will be some degree of jerkiness to the motion. That's just the nature of the low-resolution beast.

After a lot of experimentation, I've finally come up with a high resolution vector system for missiles. Here's what the code looks like: LDA #%00000001 ; Using every other frame for plasma ball to slow it down. AND Frame BEQ UpdateMissle1 LDA #%00001110 ; Because we're using every other frame. AND Frame LSR TAX LDA FrameBitMask,X STA Temp1 ; Temp1 holds the mask. LDX PlasmaBallDir LDA Vector,X AND Temp1 BEQ NoPlasmaXMove INC BallX NoPlasmaXMove LDA PlasmaBallDir EOR #%00001111 TAX INX ; Add 1 because the X map is slightly offset from Y. LDA Vector,X AND Temp1 BEQ NoPlasmaYMove INC BallY NoPlasmaYMove ; Associated data tables FrameBitMask .byte #%10000000 .byte #%01000000 .byte #%00100000 .byte #%00010000 .byte #%00001000 .byte #%00000100 .byte #%00000010 .byte #%00000001 ; This table shows the destinations for the 16 angles after 8 frames have passed. ; The +'s are main angles (4 per quadrant). The origin is in the bottom left. ;012345678 ;+ooo.....8 ;...+oo...7 ;.....o+..6 ;......oo.5 ;.......o.4 ;.......+o3 ;........o2 ;........o1 ;o........0 Vector .byte #%00000000 ; shot 0 .byte #%00000001 .byte #%00010001 .byte #%00100101 .byte #%00100101 ; shot 1 .byte #%01010101 .byte #%11011010 .byte #%11011010 .byte #%11101110 ; shot 2 .byte #%11101110 .byte #%11111110 .byte #%11111110 .byte #%11111110 ; shot 3 .byte #%11111111 .byte #%11111111 .byte #%11111111 .byte #%11111111 This was written for Stellar Fortress, but it can be used in any game that requires a large number of angles for missile vectors. The above model supports 16 directions per quadrant, with 4 quadrants, for a total of 64 directions. Its main purpose is to save RAM. Common high-resolution motion systems require 5 bytes of RAM: XHi XLo YHi YLo MissileDir By encoding the motion deltas into ROM, you can save 2 bytes of RAM by using 8 bit values for position instead of 16, but still provide the appearance of high-resolution motion. X Y Missile Dir Another important factor is applying trigonometric constraints. This means slowing the missile down on diagonal motion. When the missile is traveling horizontally or vertically, it moves one pixel per frame. But if it is traveling at a 45 degree angle, it should move (square root of 2) / 2 pixels per frame, which is less than one. The motion is achieved by encoding a series of 8 deltas into a lookup byte. Each bit of the byte represents one frame. So, if the missile is traveling horizontally, it would use #%11111111, to represent that the missile should move one pixel to the right on every frame. If the missile is traveling at 45 degrees, it uses #%11101110. This is 6 pixels for every 8 frames. 3/4 is approximately (square root of 2) / 2 = 0.707 Another feature is the fact that the trig tables are almost symmetrical. To get the Y table, I just EOR the index and add 1, then reuse the X table, so only 16 bytes of ROM are needed to define the table. The above code only supports one quadrant. I'm now working on enhancing it to support all 4 quadrants. The result will be in the next Stellar Fortress WIP release. This code is similar to version 0.20 of Stellar Fortress. But in that version, I was using 16 bits for each angle to define 16 frames, then switching the lookup byte on every other frame. This required a larger ROM table and resulted in some ugly code, so I compressed it down to 1 byte per angle, but it still supports the same 16 directions per quadrant. As a side note, 64 directions may seem excessive for an Atari 2600 game, but there are instances where it is necessary. For this particular game, I need all these angles to ensure that the cannon can hit the player ship at any location on the screen. With only 16 directions, I found there were safe zones where the player could park his ship and the cannon would never be able to hit it. I'm guessing the programmer for the original Star Castle may have run into the same safe zone problem. This is probably where the idea for the expanding cannon attack came from.

Looks nice Hornpipe. Keep up the good work. Thanks! I'm not much of an artist so this was the best I could do... Yeah, they flicker at 30hz. I turned on "Use Phosphor" with amount 77 in Stella to capture this image. TROGDOR smacks himself in the head with his big beefy arm. I've been using Stella for over a year now, and I didn't even know that feature existed. No more hand editing screen shots for me!

Dammit. I knew I shouldn't have taken off the shrink wrap / radiation shielding. I probably just hosed the resale value.

Thanks Nathan. Brick+ #1 arrived last week in the mail. He wasn't joking. $173 for shipping. But it's worth it. The case is made from spent uranium cores. The only downside is a few teeth have fallen out, and I've noticed substantial hair loss since I've started playing the game. Is that covered by the warranty?

Welcome back David. We were concerned about who was going to pay for the Heavy Industries superfund cleanup, but now that you're back, that won't be an issue.

Check out this blog entry. It does a 24 character display with a 26 byte RAM buffer and 512 bytes of ROM. The source code is included. (There is a bug in the code that's addressed in the blog comments.)

Here's the seed I use at power up: ;Initialize the random number generator. LDA #$D6 STA Rand1 STA Rand2 STA Rand3 STA Rand4 Any seed can be used, as long as it's not all zeros. As supercat mentioned, all zeros will lock up the generator, producing infinite zeros. Technically, I'm not reseeding the number generator. But since the state of the random number generator is constantly changing, the time that the game is started will affect the set of random numbers generated. Another possible technique is to grab the frame byte (most games have a byte that keeps track of the frame count), and drop that value into one of the bytes of the random number generator. As long as the number is not zero. The X in my routine is the number of bits desired. If you want a byte (i.e. 8 bits), you have to set X to 8. With each pass in RandomBits, (where X is used for looping,) a new "random" bit is generated and shifted into the random number buffer. So 8 passes will shift in 8 new bits. This is slow, but it is also genuinely random. If you only set X to 1 and then try to use the result in A as an entire byte, you'll be reusing 7 bits from the previous random number, which really isn't random. Supercat, how do you handle this problem in your algorithm?