Jump to content

Robert M

Members
  • Content Count

    1,533
  • Joined

  • Last visited

Everything posted by Robert M

  1. Now what I would usually do here is to give you some great routines for multiplying and then show you how you can divide by 23 by multiplying with the reciprocal. Then someone else would come along and ask exactly why you needed a divide by 23 and 18 and then it would be found out that there was a way to avoid them in the first place. So, we can just skip the fast multiply and divide routines for now and talk about why you need the divide routines. hehe, point taken... Okay, i will explain... In my current routine, i check every (displayed) brick for having contact with the ball. I take the coordinates out of a table, thus avoiding any multiplications or divisions. This worked very well after a few tweaks, but needless to say, it really eats up cycles like crazy. The obvious idea now would be to see where the ball is, and then check if there are any bricks having a collision with it. For that i need to divide the X position of the ball by 23, because i have 11 bricks, and my screen is (virtually) 256 pixels wide, and 256/11 is 23.11 period ... after doing the same with the Y position i can compare the new value with my playfield matrix in ramspace, that looks like this fcb 0,0,0,0,0,0,0,0,0,0,0 fcb 1,1,1,1,1,1,1,1,1,0,0 fcb 0,0,0,0,0,0,0,0,0,0,0 fcb 0,0,1,1,1,1,1,1,1,1,1 fcb 0,0,0,0,0,0,0,0,0,0,0 fcb 1,1,1,1,1,1,1,1,1,1,1 (for example) and voila, i see if i have a collision. If there are any ways to do this without a division, i would be glad to hear them.. Rather than use a table, you can simply track two separate x and y positions for the ball. One is its screen postion, and another is its brick positon. The screen position x and y are just as you have them now with single bytes 0 up to 256. The brick ball positions are 16-bit fixed point decimals. Each time you move the ball xScreen += 1 you do a mirror addition to the brick position xBrick += 27.273 (BTW, I get 256/11 = 23.273) Since the brick count is less than 17 in both directions you can use the 4 uppermost bits for the integer, and the lower 12 bits as the decimal. for every 1 you add to xScreen, you must add 372 to the the 16-bit xBrick. Subtract the same amount going in the other direction. The upper byte of xBrick shifted 4 right >> 4 yields the x index to the brick map. For each 1 added to yScreen, you would add 256 / 14 bricks = 18.285714 * 16 fixed point adjustment = 293 to the 16-bit yBrick. Divide the upper byte of yBrick by 16 to get the map position. Cheers!
  2. Head on over to www.lemon64.com. Go to the games section. Pick your favorite game genre and get a list of the top 100. Its a great database on par with the AtariAge database for Atari systems. Cheers!
  3. Targ is cute, but Tunnel Runner has to be crowned king in this poll or there is no justice.
  4. Sale of all items is pending. Thanks everyone for your interest. Rob
  5. Hello, I have been cleaning house lately, and I have come up with some of carts I don't need anymore. I have grouped them by manufacturer for sale. All the lots are priced based on $1.33 per cart including shipping within the U.S. You must buy the entire lot, I am not looking to sell individual carts. If you live outside the U.S. you must agree to pay shipping in addition to the price below. All carts are tested and working fine. Refer to the pictures for game titles and label condition. There are 4 lots: 30 Activision carts for $39.90 shipped 15 M-Network carts for $19.95 shipped 13 Parker Brothers carts for $17.29 shipped 9 Imagic carts for $11.97 shipped If you buy more than one lot of carts, then I will lower the price. Buy any 2 lots and take 10% off the total price. Buy 3 lots and take 15% off the total price. Buy all 4 for $70 shipped. Feel free to ask questions. Thanks for looking. Rob
  6. I wonder if anyone will ever clear January 18 (all toys, none featured)? Levels after that are a bit goofy. January 19th is pretty much a gimme. January 20 is harder than 18 (again all toys). January 21 is a gimme. January 22 features ducks. January 23 features cars (no Nigebs, planes, or ducks) January 24 features trucks (no tractors, cars, Nigebs, planes, or ducks) January 25 is a surprise. Wonder if anyone will ever reach it (without cheating). I'll be truly amazed, though, if anyone clears it. I got to January 16th once last week. It was too much for me to handle. I think part of someone getting through to the end of the game will depend on getting just the right random combinations of toys. Sometimes on the later levels you have 3 toys on each conveyor, and the same color toys seem to be spread out as far as possible. Other times they are all lined up nicely. I think I would need a big dose of the latter to ever get past Jan 16th. Cheers!
  7. 59,441 January 14th. Excellent game design and execution! Good work guys! So does the gray paint do anything special?
  8. Robert M

    qix

    There is a precedence for using a block sprite for Qix in place of the Qix composed of lines: http://www.klov.com/game_detail.php?letter=&game_id=9933 and: http://www.klov.com/game_detail.php?letter...p;game_id=10236
  9. I never really cared for any of the ones I tried. I much prefer a RPG game like Pool of Radiance. Although, I did enjoy Times of Lore a lot when it came out, and it is very Zelda like. Maybe I just can't get into role playing as a girly looking elf dude. Barbarians with large axes are much more fun! Cheers!
  10. Robert M

    qix

    Hi, I am doing alright. I have just been very busy this past year. I visit AA and lurk about nearly every day though, and I have all my projects progressing in slow motion in the background. Cheers!
  11. Robert M

    qix

    Alright, I did some thinking on this problem a year or so ago. I was going to replace Qix with Blocko, as drawn wonderfully for me by Saldsadt. Anywho, I did some rough planning and I think it might work. I will try to descibe my ideas with words. The player is restricted to moving on a grid 4 pixels wide (1 PF pixel) and 8 scanlines high. Only the middle 32 PF pixels are used. The player moves on the lines between these larger pixel blocks. If we assign 160 scanlines for vertical playfield space, we get a rough grid of 32 by 20 squares, or 640 squares total. 640 squares needs 640 bits to store, 640 / 8 = 80 bytes. If we want to have 2 fill colors per pixel we need 2 bits, or 160 bytes, which means a SARA chip is required. OR, we can reduce the play area by removing 8x8 blocks of gameboard pixels to make non-rectanglar play areas. If we remove 4 such blocks of 64 pixels we get 640 - (4*64) = 384 pixels / 8 = 48 bytes * 2 = 96 bytes + a few overhead bytes to indicate which 8x8 blocks are solid, and we fit into 128 bytes with a 4 color PF. The 4 colors are made by mixing 2 PF colors on alternate lines. For example: Black background, plus alternating yellow and blue yields (Black+Black) = Black; Black + Blue = Blue, Black + Yellow = Yellow; Yellow + Blue = Green. The enemies are Blocko and 2 sparx. Blocko is P1 + Ball flickered at 30Hz for the eyes. The sparx are M1 flickered at 30 Hz. The player is P0 and P1. The player and sparx travel on the lines "between" the larger playfield pixels. Say 2 pixels wide with 1 pixel overlapping a PF pixel on each side. The drawing by the player does not make continuous lines, but only leaves marks at the corners where the player changes direction. P0 and M0 can be used to draw little "L" shapes to mark the corners. They are repositioned in the middle of the 8 scanline blocks to get multiple instances in a frame. Flickering is used when more than 2 "L" shapes share a horizontal line. Most likely a SARA chip would be needed to make the game doable and enjoyable. Cheers!
  12. Great work! Its nice to see the problem with RESBL is fixed. Thanks!
  13. 1. You are failing to seperate the design from the implementation. Take the game Monopoly for example. It exists both in the board game form and on video game consoles. The game Monopoly is the set of rules, the board, the cards and the pieces. The game design is independent of the implementation: paper or video. I have yet to see a single idea peddler present even an instruction manual for their game.] 2. As an idea peddler you want a programmer to invest hundreds of hours in your idea for minimal compensation. So you really need to be flexible, and communicate your ideas effectively. Yes, a number of the items I suggested may involve some effort, but if you do the early leg work for the programmer it makes it more likely your idea will be picked up. Programmers are not mind readers. You must effectively communicate the images and ideas in your imagination in a form that a programmer can use. You may have the most awesome game idea ever concieved inside your mind, but if you can't communicate it to others then it is stuck inside your head. In the real world, you would pay a programmer money and the programmer would sit down with you and through a series of meetings work out the kinds of things I listed and present them to you in forms you can understand. In the hobby world, you need to do some more of the work. Yes, it may all be for "nothing". Its a hobby though, and if you don't enjoy it why are you doing it? In the end you have your design and the enjoyment you got from creating and sharing it with the community. 3. I am not the almighty arbiter of good game design. I am merely making suggestions for effective communication. You could come on the boards an say you have an awesome game design: "Orange Ball". That's it, just a name, and maybe you will inspire a programmer. The more effort you put in, the more likely a positive result will occur. 4. The Fade Out project happened because Salsadt (sp?) is a professional digital artist. His sprites are very inspiring to look at. As a programmer, you want to bring them to life. Also he cleary has worked with programmers before. He speaks the jargon, and that makes communication much easier; especially through forums and emails as we do here. 5. I think the programmers have shown that they are willing to look at ideas and make constructive comments on them. What I rarely see is a designer taking that constructive critcism and updating their design. I would expect an ongoing conversation taking several weeks or months of back and forth communciation to generate a good game design. Again, the designer would need to show the flexibilty and persistance that the programmer would need to show to get the project done. Look at how the PPOP thread got programmers exploring what the VCS could do. That was another great designer/programmer session. Did it result in a final game? Not yet, but the interaction and the learning the exchange inspired is a great addition to the record of achievements in this community. Cheers!
  14. LOL! That's one of the better awesome game designs I have read. I have followed up with a few would be designers via PM, and they always rapidly trail off into extremely vague descriptions just like your joke post. If someone posted a TRUE game design with lots and lots of detailed design information and the design was good, then I think they could get a programmer's attention. What's in a good game design: - Backstories are nice and help to sell your idea, but they are all fluff. The game is the objects on the screen, how they move and interact. So write a backstory if you have one you like, but the story is not the game. - Many highly detailed screen mockups. A mockup showing every major event or situation in the game. (Don't worry about eye candy, that's fluff to be added later as possible. What are the visual elements that are integral to the game design?) - List all game objects: Name, attributes, states/classes-of-behavior, purpose ... - Detailed timing to showing how the game runs. How fast does everything move. In what ways do things move. You know the resolution of the screen and the size of the game objects and their speeds. Can the player jump the pit? Can the player/monster fit through the door? Can the player accomplish all the required tasks to win in the amount of time your design allocates? - Detailed control explanations. Responsiveness, timing, if the character jumps how does gravity look/work. e.g. Can the player jump off a ladder? You should try to enumerate all game playfield element to player combinations that are relevant to control. For example in Pitfall when the player is standing still and then the player pushes left or right the game will wait for 1 frame to see if the joystick is actually traveling to a diagonal position to request a jump. Without that control design the game would not play as well because the player standing on the edge of a cliff trying to jump will fall off instead. - Collision Detection/Results: What object collisions need to be monitored. List all possible object collisions. What happens in each collision case? Does collision detection need to be pixel perfect, or by overlapping mathematical zones. (For example: In arcade Pac-Man the player can touch the ghosts at maze corners and not die. In VCS Pac-Man, collision is pixel perfect. It makes a big difference in the gameplay.) - Scenarios and sequence diagrams as appropriate to explain game mechanics in detail. - How will difficulty be ramped. What timing and movement parameters will change? Did you do any math to support your position/design choices? (i.e. Does the player have enough fire power? Too much fire power? Your design says how fast and strong the enemies are, so can the player win? Can the player lose?) - What game elements are essential, and which ones are optional. If items can not be done on the VCS, they will need to be cut from your design. Is your design flexible enough to handle changes? Are you flexible enough to handle changes? Cheers!
  15. Many older chips have a minimum speed for reliable operation. Even today, some chips (most notably nearly all forms of DRAM) have such restrictions. I would guess that if one could probably slow a 2600's clock by at least a thousandfold without disrupting things (the display would be useless until the clock was resumed, of course); it might even be possible to go as high as a million. If things could be pushed out to a million, that might be almost as good as a pause in most cases. My datasheet for the 650X puts the minimum clock frequency at 25000 Hertz.
  16. http://www.mediacasesinc.com/Merchant2/mer..._Code=SPE\ The the cartridge stay put inside the box, or does it rattle around? Thanks!
  17. The device should monitor the address lines for for a write to VSYNC with a 1 in bit 1 of the data bus indicating the program is beginning vertical sync. All VCS programs must activate vertical sync this way. If the pause button is being pressed, then the pause device swaps out the cartridge ROM. The next instruction fetch is forced to zero (BRK), and then on the second instruction fetch after the write to VSYNC, the pause ROM is the source for all opcode fetches. This assumes that their are 4 bytes available on the stack. BRK_HANDLER: PHA ;save A to stack consuming 4th byte. 3 bytes are used by the BRK vector TXA TSX ; TODOs: Save the X register copy in A to the stack overwriting the status register copy in the BRK frame. ; - Adjust the return vector for the BRK to return to the correct address in the cartridge ROM also change it to use RTS instead of RTI. ; - Use A and X and no RAM for all pause ROM code. ; - When pause is released, the pause software goes to the write to VSYNC, restores A and X from the stack and jumps to an RTS instruction ; that also triggers the pause hardware to swap out in place of the catridge ROM. NOTE: If you put a SARA chip in the Pause hardware you can save a copy of the zp RAM thus opening the possibilty of a VCS game genie. pause the game. Save its state to the SARA ram. Restart play. If you die, pause and restore the game from the Sara RAM. It might not work for bankswitched games, and definitely not for games with extra RAM. You could edit the saved RAM image while paused to produce game genie effects. Or save the whole game state to a flash device to restore later. The pause hardware could insert a blank frame every other frame. Producing a flickering slow motion feature. There are other possibilities. A big challenge is the mechanical issue of producing a pass through cart. It would need to fit all the different consoles, yet it would be nice to have it latch onto the case of the console for more support. Cheers!
  18. I have received many PMs and I will answer them in the order received until the system is bought by someone. Patience please.
  19. Supposedly, if you have a dial-up service provider. It can do email and browse websites in text only mode. Probably would be tough today with so many graphics heavy websites.
  20. Hi, I'm doing alright. That company I was working for in Honoeye Falls closed its doors. I'm working for Harris RF on the east side now. How are you doing? Rob
  21. Hello, I am offering a Tiger Game.com collection for sale. I believe the collection of game titles is missing only 3 games: Batman & Robin, Wheel of Fortune, and Henry. All the games are CIB, some come in cardboard boxes, some come in plastic clamshells (see picture). The Game.com unit is the original larger silver variety. I also include the AC power adapter, and the rare Internet connectivity package. The internet stuff is M.I.B. Here is the list of games: - Monopoly - Very well done. - Centipede - Scrabble - Another great board game translation utilizing the touch screen. - Jeopardy! - Williams Arcade Classics (has: Robotron, Joust, Defender, Defender II, and Sinistar) - Resident Evil 2 - This is the MUST HAVE title for this system. Aside from a couple glitchy doorways, this game rocks! - Duke Nuke'm 3D - Indy 500 - Mortal Kombat Trilogy - Fighters Megamix - Sonic Jam - Surprisingly, having the screen blur on this system as it does with lots of motion looks rather good for Sonic games. - Tiger Casino - The Lost World: Jurassic Park. - Solitaire is built in. - Lights Out! is the pack in game cartridge. If you have ever been curious about this system, here is your chance to get your hands on most of what it has to offer. There is a store here in Rochester that has Wheel of Fortune and Henry new in box for $10 each. Henry goes for $15 on eBay. I will add either of those games for $10 each, just let me know. This system has given my many hours of entertainment. Now its your turn to have fun with it. I am asking $40 + shipping. The box weighs 4 pounds 8oz. and it is shipping from zip code 14534. Feel free to make a counter offer. Cheers! Rob
×
×
  • Create New...