Jump to content

Robert M

Members
  • Content Count

    1,533
  • Joined

  • Last visited

Posts posted by Robert M


  1. Hooray! A game I own and like.

     

    8100 for my first high score

     

    TIPS:

     

    In the soldier section there are 2 key tactics.

    1. Line the enemies up vertically with your player and slightly to the right so you can hit them, but they miss you.

    2. Wait for the enemy coming down to get his gun level in line with a tree, but with his head or feet sticking out. Hit the end sticking out of the trees.

     

    In the tank sections, the shots come from the center and not the right side of the sprites so you need to change tactics.

    1. When a tank first enters the screen you have about 2 seconds of safety when the tank can't shoot. So plow ahead at full speed and pop the enemy tanks off as they enter on the top.

    2. Let the tanks come to you, they have to enter your field of fire to shoot at you. Set up your shot so it crosses the path of the approaching tank, and time your shot so it gets there when the enemy tank arrives to meet it.

     

    Cheers!


  2. put in Nintendo Entertainment System and Atari 7800 and see what you get.

    894914[/snapback]

     

    Atari 7800 kicks butt in that matchup.

    894964[/snapback]

     

    I got quite the opposite... what is this thing?

    894994[/snapback]

     

    Well I put the names in quotes like this: "Nintendo Entertainment System" vs "Atari 7800" That way the page must contain those words in that order and position relative to each other to be counted.


  3. How could that be accomplished though?  The anaglyphs would converge as they appear to get closer to the viewer, which means overlapping images whose individual pixels would have to AND as they merge.  That in and of itself is probably beyond the 2600's capabilities, let alone doing it for multiple objects.

     

    Not that it wouldn't be cool.  :-)

    892767[/snapback]

     

    If they were going to use Red/Blue glasses I suspect that the program would alternate drawing Red and Blue frames.


  4. Hello,

     

    Since Wolfenstein is finally shipping (thanks Packrat VG!), I have decided its time to provide a hint on finding the secret level mentioned in the rule book. If you don't want a hint then don't read. I have encoded the hint into a poem. Here is the first hint I am giving for finding the secret level:

     

    Bold soldier, if your quest is to

    enter the ninth level.

    take heed of my words, and you

    will soon be there.

    entrances hidden, and

    exits all closed.

    now that the game is

    Won, you can be told.

    as you dwell on your victory,

    nearby lies the

    door, rise and

    Enter if you dare.

     

    Let me know if you can find it.

     

    If you don't go for this cryptic riddle stuff. Complete the game, and send me a PM that tells me the text shown on the screen when you complete the game. I will provide you with detailed instructions for reaching the hidden level.

     

    Cheers!


  5. Hello,

     

    Without understanding the relationship of the loopa and loopb labels to the flow of the kernel code its hard to recommend an optimization. Can you post the complete loop? Also is the BlockChange table stored in RAM or ROM?

     

    Cheers!


  6. So, Jarett put me to work in his sweatshop today, to help him catch up on several orders for the first run of Wolfenstein.

     

     

    Thanks for all the hard work you guys. I am really glad this game is getting out the door. Three cheers for Packrat VG! :)


  7. Okay, I spoke to Jarett on the phone today. He says that he will definitely ship the first run this week. I really hope he does. If he still can't seem to get it out the door, then Scott and I will talk with Al about making it available through AA.

     

    If we do a run with AA, should we change the maps so as to differentiate the 2 releases?

     

    Cheers!


  8. I do not know what the ongoing delay is about. The last thing I heard from Jarett was that the 1st run was assembled and ready to ship. That was 12 days ago. I have not heard anything or received my copy yet. I plan to call Jarett within the next week and ask him what is going on. I will share my findings.

     

    Thanks to all for their patience. |icon_innocent.gif


  9. -1- It feeds sprites' position counters an extra 0-15 counts during the horizontal blanking period.  In the absense of part 2, this would have the effect of moving the sprites 0-15 pixels to the right.

     

    -2- It disables counting (and video) for the first eight pixels of a scan line.  This has the effect of moving all five sprites eight pixels to the right (offset by whatever amount they were moved in -1-).

    882005[/snapback]

    I have read that you can move sprites and avoid the black lines by calling HMOVE 2 cycles early, but the effect is that it moves 0-15 pixels instead of -7 to 8. I imagine this has something to do with the above :?

    882203[/snapback]

     

     

    That is true. There is a very well done analysis on the Stella mailing list. I can't find it right now. :( The author hit the HMOVE function on each clock cycle and measured what happened for all possible movement values. IIRC hitting HMOVE on cycle 74 or 75 will move the object from 0 to 15 pixels to the right from its current position without drawing the comb. So with some planning you can get rid of the comb. The biggest trick would be placing a sprite on the left most side of the screen. Doing so becomes a special case if you can't HMOVE to the left. You would have to rough position on the right side and shift off the right side onto the left.

     

    There is another HMOVE trick that was first used in Cosmic Ark and I believe again in Rabbit Transit. The star field in Cosmic Ark is made by hitting HMOVE normally at the start of the first line, then writting one of a few special values to the target object's HMxx register on cycle 18 (IIRC). The result is the HMOVE function gets stuck turned on, and the object moves 15 pixels to the left (I think) every scanline until HMOVE is hit again. That is how the star field is generated in Cosmic Ark. Its the ball object smeared over the whole screen with an color wave on top to make it extra nice.

     

    Cheers!


  10. What you are seeing is sometimes called the comb or comb effect. It is produced by the video chip in the 2600 called the TIA on every scanline where the software has requested the TIA to horizontally reposition an object on the screen using the HMOVE feature of the TIA. Activision eliminated the comb, by requiring all games to hit HMOVE every scanline thereby producing a solid black band on the left edge which makes the game image appear off center.

     

    Many people consider the comb to be a bug, because it can look ugly. I wonder if the designers might have put the comb in on purpose as a means to scroll sprites off and on the edges of the screen. Without the comb, a sprite off one edge will appear sticking out on the other side unless you do some nifty tricks in software. the comb is the same width as a standard sprite (8 pixels). So a programmer can use the comb as a sort of virtual backstage curtain to move sprites in and out as if entering or leaving a stage.

     

    Cheers!


  11. I think a main block to programmers picking up ideas from other people to implement is they have no shortage of their own ideas that they want to try themselves first. There have been lots of great ideas proposed by non programmers, Prince Of Persia for instance. I love the idea of POP for VCS, as did many other programmers. Thomas and vdub_bobby demostrated the kernel can handle display of the necessary game element. Now the hard part of making the game remains. Hundreds of hours of work in truth to make it polished. I know its very tempting for many, but that time commitment very big.

     

    I think would be VCS game designers should seek to emulate what Scott Dayton (neotokeo2001) did and does to promote his design ideas. For Wolfenstein, he put forth a graphic hack of Venture, and listed some ideas for making it even better. I saw what he had done, and could see clearly that his ideas were very doable. Then the nostalga forWolfenstein on C64 and Apple II kicked in and I couldn't resist his proposal, because I could see how it could be done.

     

    What I am saying, is I think a lot of people with ideas don't present a well rounded proposal for a new game that a programmer can feel really comfortable picking up and bringing to fruition. Presenting a well rounded idea (example hacks for instance) just to demostrate the feel or a particular idea from your design, can really spark the imagination and desire of a programmer to make it a reality.

     

    Writing the software for a game takes several hundred hours. If you show as a designer that you have put 20 or 30 hours into your design, prototyping and expressing your concepts through hacks, mockups, and text descriptions analyzing game mechanics you will greatly improve the chances of making a programmer fall in love with your ideas.

     

    In the end, even if a programmer doesn't pick up your design immediately it doesn't mean they never will. Keep your design in the public eye on a website. Some really famous books were rejected by publishers for years before being printed. Design because you are enjoying it and want to share your ideas. Ask programmers to critique your work, listen and adapt your design to what you hear. Show dedication and have fun!

     

    Cheers!


  12. If the timer chip isn't getting enough power, it's underclocked, and if it's underclocked, the crystal isn't running at its proper speed, and the timer slows down.

    The 2600 has no timer chips.

    868180[/snapback]

     

     

    More importantly, if you did under or overclock an Atari 2600, the TV signal would go out of spec and could not be displayed. I believe the margin for the clock tolerance before the image would go bad is < +-2%


  13. he means the limewire icon in my dock..

     

    i dont use it to steal music (i got all my bought CD's to prove it..)   that limewire is there when I just want to get *ahem* other stuff ;)

    860609[/snapback]

    Doesn't OSX readily spport screenshots of just the current window?

     

    It's little stuff like that that make me hesitate before taking the plunge from PC-land.

    860780[/snapback]

     

     

    Yes, it does. If the program does not support it itself, then there is the Grab utility which allows screenshots of the whole screen, a single window, or any rectangle of the screen you wish to grab.


  14. The kernel for this game is going to be quite difficult.  There are a couple of problems with the design at present:

    Hello, glad to see some interest in this baby. Not problems! Challenges! That's what makes this hobby fun. ;)

     

    1) There are 40 PF pixels across the screen (the design assumes 20 pixels). 

     

    The design shows 20 PF pixels being used because that is the minimum number needed to get 5 game board spaces across. You can just leave 10 pixels unused on each side, which frees up CPU time. Or if you can make a kernel that displays more than 5 spaces then that is even better.

     

    2) There are too many colours per scanline if you are using PF graphics.  You can change the foreground or background, but not both, between squares. 

    The code below is a sketch of a kernel which would draw the board using PF squares that are 6 pixels wide.  The timings are not entirely correct, but you should get the basic idea.  This kernel could probably be made to work by reducing the size of the squares and ignoring PF0, or  using self-modifying code.  However, I think it is going to be better to use sprites instead ...

     

    You are on the right track here. I think self modifying code is your best bet. You can change the PF color for each space in a row using a self modifying routine in RAM. That leaves the sprites free to draw icons and the player. Note that the spaces are 4 PF pixels wide for the reason that the spaces are then 16 color clocks on center which allows us to use the hardware sprite replication to get 3 identical icons per row. So making them 6 PF pixels wide will block that feature.

     

    The timing is a bit touchy with 16 color clocks per space since 16 does not divide evenly by 3 to stay in sync with the CPU. That's the fun part!

     

    Consider though that you do not need to change the PF registers at all during the display, only the COLUPF register. :ponder:

     

    Cheers!


  15. Hey Neo,

     

    You should post the NES rom you got the core idea for this game from. Playing that ROM clarified alot for me about the flow of the gameplay and showed me how fun it could be. It might help to drum up more programmer talent.

     

    Cheers!


  16. I am rather busy at the moment moving from Illinois to New York. Once I am settled I would be able to help some more on this project.

     

    I would be willing to write the display kernel(s) and a "fill in the blanks" program/state-machine shell. Are there any (possibly newbie?) programmers who would be interested in taking a working kernel and putting the game code in? It could be a great learning experience :ponder:

     

    Cheers!

×
×
  • Create New...