Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Robert M

Members
 View Profile  See their activity

  • Content Count

    1,533

  • Joined

  • Last visited

Posts posted by Robert M

  1. Posted

    Hi Robert!

     

    Look at Dolphin for proof of concept.   How did the programmer generate the Dolphin, Octopus, and Sea Weed without flicker?

     

    You are fooled by Activision magic. The dolphin and the octopus are only one single sprite each. Take a careful look again. It's just clever shifting and double/quadruple sized pixels. :)

     

    The only two possible Karateka approaches are either doing exact that (-> Double Dragon) or flicker (-> Fu Kung!)

     

    Greetings,

    Manuel

     

    Manuel, I don't understand what you are saying here. I believe I made it clear that I plan to use "just clever shifting and double/quadruple sized pixels.". Also, I don't see any of that technique being used in Double Dragon, but then the only access I have to that title is the screen shots on this website.

     

    Fu Kung is an awesome concept, but its not what I am looking for. I need the backgrounds to really capture the feel of the original game. Andrew's mega sprite technique requires a black background.

     

    Cheers!

  3. Posted

    I'm not sure how well that method would work for a game.  I used similar tricks for the Marble Craze title screen and character pictures in the Homestar Runner demo, but it would be really complicated for animated moving characters.  And that's a lot of register writes in one line.  Asymetric playfield (usually 6 writes), NUSIZ0&1, GRP0&1, HMP0&1.  Assuming 7 cycles per load/write (LDA addr,x STA addr), that's 84 cycles, and you still have to do an HMOVE and handle looping.

     

    Your numbers are correct, so that leaves 3 options:

     

    1. Reduce the horizontal resolution. (Reflected asymetrical playfield with PF0 never used saves 14 cycles per line.)

    2. Reduce the vertical resolution (2 line kernal)

    3. Hardware acceleration [ Work in progress ;) ]

     

    Cheers!

  4. Posted

    I don't see how you would display the two fighters (without flicker).

     

    Paul, that's a fair question. I am doing something kinda new here, but I was inspired by the game Dolphin. The character images are a combination of playfield (orange) and a single sprite (white).

     

    This technique requires a relaxation of the idea that a sprite needs to have the same resolution and horizontal position or each visible scanline. There is no such requirement on the 2600 since each scanline is rendered largely independently from the previous line (as allowed by HMOVE -7 to +8 color clocks).

     

    So when you look at the sprites in the mockups the question for each scanline is: can I shift the sprite via HMOVE from the previous line position to the leftmost visible pixel (usually but could possibly overshoot to allow further movement for next scanline) and what is the width of each sprite pixel 1, 2, 4 or 8 clocks. For example in the second mockup the player sprite is 1 color clock wide for the hair, 2 color clocks wide for the torso and lower leg, and 4 color clocks wide where the leg is kicking out.

     

    I am restrained by the use of playfield graphics for skin, as I stated in thte first post. This would restrict players to 40 horizontal positions on the screen. which may or may not work for this game. Investigation is required. I may be able to share the Ball between the players to generate (with some flicker) skin between the rigid playfield resolution.

     

    As stated earlier I think I will need to include RAM (256 or 512 bytes) in the cart to buffer a frame for display because to get the image above the players cast shadows and such would require to much calculation to do in frame.

     

    I need to come up with a Java utility for editing these sprites with variant width and position. That will make the concept easier to see and implement.

     

    Look at Dolphin for proof of concept. How did the programmer generate the Dolphin, Octopus, and Sea Weed without flicker?

     

    Cheers!

  5. Posted

    That second one is more like what the 2600 version would look like.  

     

    Tempest

     

    What part of the first image (besides the mountain which is too wide, but fixable) don't you believe. There may be a couple pixel level errors in the updated mockup for screen one but nothing critical. Notice that there are only 3 colors per line at the top which is doable because the playfield is blue and orange/black alternating with sprites and missles for all the white and some of the black details.

     

    The bottom half has only black/orange (playfield) and white (sprites/missles) All of the pixel widths are valid (I think). Take a look at the sprites in Dolphin and then come look at these again. The display is nicely banded into horizontal strips of detail. The players never leave the ground so in the upper screen space the sprites are free to draw other things.

  6. Posted

     That mock up you made is way beyond the 2600's limitations.

     

    Tempest

     

    Actually its not that demanding of an image. It uses a technique similar to the one used in Dolphin to create the Dolphin and Octopus images to make the characters. The Arch is sprites at the top, and missles and playfield in the columns. The mountain will need to be retouched, but will most likely be a 48 pixel sprite, which is known technology.

     

    The characters are demanding, I am expecting I would need to include 512 bytes of RAM on the cart to make it possible by buffering the character images in RAM for each frame.

     

    Cheers!

  7. Posted

    Here's another one. (minus mountain, the mountain is just a 48 pixel sprite always in the same place, so I am assuming its a done deal and leaving out of the images for now). I converted the water to land/desert because its the easiest to be monochrome. It might be possible to put the water in as a sprite if the enemy never appears on the screen at the same time. Which would preclude the joy of being pushed off the cliff :wink:

     

    This image is important because it stretches the TIA to its limits to draw the player. The player sprite is moving horizontally and varying in pixel width from 1 to 4 color clocks every scanline. The image is such that it could be drawn in reverse for the enemy sprite as well.

     

    Enjoy

    post-2784-1061901834_thumb.jpg

    post-2784-1061901835_thumb.jpg

  8. Posted

    Hi,

     

    I have always loved the game Karateka, and so I hve been dabbling with the possibility of a 2600 version. Below is my first attempt at a mockup of a 2600 screen. I am 99% confident I could get that screen on an actual 2600. I know the Mountain looks like crap, but I was getting tired. I will improve it in later mockups. To get the screen below to work on thte 2600, I had to raise the height of the arch and remove the middle cross beam. I also had to restrict the faces, hands, and feet to playfield graphic positions. It remains to be seen if that last restriction is fatal to the whole concept of a 2600 port with this graphic quality. I will update this thread as I complete more mockups. Comments/critcism is welcome.

    I am attaching screenshots from the C64 version for comparison.

     

    (edit) Whoops! I can see I forgot to put orange stripes inside the mountain, as I would have to do because of the 2 color per line restriction for playfield graphics. I told you I was tired :P (/edit)

     

    (edit2) Image updated to be more correct. (/edit2)

     

    Cheers!

    post-2784-1061881859_thumb.jpg

    post-2784-1061881860_thumb.jpg

  12. Posted

    I just received a copy of Stun Runner. Wow. What an excellent port of the arcade game. It really captures the feel of the arcade. I can't imagine it being done any better. I always enjoyed Stun Runner in the Arcade. Does anyone know if Stun Runner was ported to any other home consoles?

     

    Cheers!

  15. Posted

    I haven't cleaned the console because I don't know how could that be the problem? I have the original t.v. hook-ups and I have a semi-newer T.V. but I use the RF attachment for the atari.

     

    As was stated before, make sure you are connecting to either the CABLE-TV input Jack or and EXT-ANT(enna) jack on the TV. You can not connect directly to an S-Video Jack on the TV. The output wire from the Atari will fit the S-Video Jack, but it won't work! You need to either get an adapter to convert to F-Type connector which fits the CABLE-IN and EXT-ANT jacks of newer TVs, or if your External ANT is 2-screws, then you need to use the old style switch box.

     

    Please provide the part-number/name of the adapter you are using, and the label on the jack on the TV you are connecting it to.

     

    Look at the channel switch on the back of the Atari. It will be switched to channel 2 or 3. Match that channel on your TV, and set your Signal Source in the TV controls to match the JAck you connected to. If you see nothing (static) when you flip on power, then either the power supply is bad, the Atari unit is bad, or the connections are not correectly configured. If you get anything other than static when you switch power on, then you have a dirty cartridge/system. Clean both. You can use rubbing alcohol and q-Tips to clean the contacts inside the cartridge.

     

    Also make sure you have power to the outlet you are plugging the AC adapter into. Many modern homes connect half or all of the outlets in a socket to a wall switch. Plug in a normal lamp to prove the outlet has power.

     

    Good-luck!

  18. Posted

    I'm probably going to get flamed for this, but Entombed was a big let down for me. I thought you would get to explore the catacombs and hunt down zombies. When it turned out it was more of a dodge the obstacles race game I was disappointed. :(

  20. Posted

    Hi All,

     

    I have been studying the graphics techniques used in Activision's Dolphin. Its pretty incredible when you look at the game and see that there is no flicker. Anyway I see a potential to exploit the technique used to make the octopus and Dolphin in that game to create a better DK graphic.

     

    The trick used is the sprite is double wide, but each line is offset by 0 or 1 pixel from the previous line. This trick allows "smoother" contours to be made. Since DK is immobile I also assume it would be easy to put some Playfield graphics into place behind the sprite there by coloring the eyes, teeth, chest and hands. I have attached a mockup of what this technique could accomplish. NOTE: this would take a serious code rewrite and nota simple hack to implement in DK.

     

    Cheers!

    post-2784-1056140141.gif

  21. Posted

    Hi,

     

    I recently bought a copy of Omega Race (cart only). Is there any way to play this game with a regular controller. The manual mentions a special Turbo Booster controller. Is there any way to build my own custom controller?

     

    Thanks,

  24. Posted

    The controls as planned right now will be:

     

    Fire = Shoot

    Up = Thrust forward

    Left = Rotate counterclockwise

    Right = Rotate clockwise

    Down = Activate Gravity generator

     

    If you are carrying the ball, then Fire will shoot the ball instead of a shot. The current plan is to have the ball shoot out the rear of the ship so that the carrier will have to move towards the goal and then turn around to get the shot off. That will give the opponent some more time to react.

     

    I am also juggling the idea that if a shot hits the Gravity ball, then the ball inverts its field for a couple seconds pushing everything away rather than pulling it in.

     

    Cheers!

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...