Jump to content

RevEng

Members
  • Content Count

    6,842
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. I'd recommend you keep the subroutines fairly shallow - there isn't a lot of stack memory free. Also bear in mind that there's some overhead for each sub call as well... actually a lot of overhead if you're calling subroutines from other banks.
  2. I agree the Wii is way too easy to hack from N's perspective, but OTOH they don't exactly lose revenue from each new console sale either. Did you see the new hardware-based USB Loader mod? I think Nintendo just permanently lost the battle against backups.
  3. I first want to say thanks, Longhorn Engineer. Last night I installed one of your preassembled video mods in my 4-switcher, and the difference between the before and after is night and day. Simply beautiful. I am now doubly excited about the possibilities while I wait for a Harmony cart. Also a tip to installers. If you don't have the recommended non-biting type of drill bits, run the drill in reverse for hole diameters greater than 1/8. This gently shaves the plastic away, and it doesn't take much longer than normal on the relatively thin plastic. This worked well for the standard bit I used for the 1/4 holes, and with this method I was even able to use a wood-boring bit for the 1/2 hole and it came out nice and clean!
  4. In an ideal world, yes. In a 6507 world, a multiplication (or a division) by a non-power-of-2 is horrendously costly in terms of time, and generally is avoided at all costs. Instead, 6507 coders use approximations, lookup tables, etc. Hence all the gymnastics in this thread trying to find the ideal way to do it. (Though mostly the gymnastics are for fun. Any one of the posted methods would be good enough in most cases)
  5. With the talk of distribution I was curious how the two methods would graph out for the case of a screen width of 160. The first chart is just the rand() function mod 160. It's there just to show that the rand() in the libc I used had provided reasonably evenly distributed numbers. The second chart is rand() mod 256 (to simulate picking a rand number from 0-255) mod 160. The third chart is my rand() mod 128 + rand() mod 32. Its kinda pyramidy, just like Michael predicted, though I think its still fairly useful for the purpose of picking a random screen co-ordinate. There's still the problem that bB uses a rand from 1-255. I'd personally just subtract the 1 from both rands and add one to the overall result, which would center the range on the screen. A couple pixels from the edges won't be missed.
  6. I have a WIP with Ari presently too. Tentatively, its titled "ari vs the mole king". I think it would be great to have a thread that was a repository of public domain artwork, sprites, characters, etc.
  7. I'll preface this by saying that I'm a 6502 noob. Hopefully someone more experienced can jump in with corrections. I think the reason what you're trying to do can't be done boils down to the fact that the opcodes that allow indirect/variable memory access have a base address hardcoded in the instruction and an 8-bit index, which only allows for access to 256 bytes. (Hence the limitation on array access in bB) You might see if "sread" can do what you need, or use if statements to test your level variable and use different blocks of code for different levels, or... You might be able to create a small ram-based value loader subroutine. Just change the instruction address in ram and jsr to the routine. [Patiently waits to be schooled by one of the 6502 gurus ]
  8. No problem! Glad your wheels are turning. [Edit - caught Michael's post after posting this... I suppose a lookup table is the only "perfect" way to go. Even then you run into some values being favoured by rounding errors. Perhaps someone else has a better/easier suggestion]
  9. The question isn't stupid at all! In a normal programming environment, you'd just do something like val=(rand*160)/255 Since multiplication or division by a non-power of 2 is insanely expensive on a 6507 you have to kludge it... 1. You can test if the result is greater than your max, and regen the random number. The problem with this is you are intoducing random delays into your code. 2. Add it together in parts that are powers of 2. Ie. For for a max value out of 160 use 128+32, temp1=rand/2, temp2=rand/8, val=temp1+temp2 3. Create a lookup table that converts the range from 0-255 to 0-159 or whatever. IMO this is a waste of ROM space, unless you're doing this conversion a heck of a lot.
  10. Nice trick! I've seen posts of several different round-about ways to share the sprite data, but that's definitely the best way to do it.
  11. The Wiimote does a lot more than just the motion sensing that Xavix has. The Wiimote has a digital camera sensor embedded in it to "see" the IR sensorbar too. But if you think the overall sports simulation is the key, I think Nintendo and Xavix both copied the company that came out with "LasaBirdie - Get In The Hole"
  12. IIRC it won't work with just bank4 set. Just go ahead and define them sequentially anyway. The don't actually need any code in them.
  13. Yeah, with bank switching you need to throw the sprite data in the last bank. Normally that's where bB places all the player0/player1 data anyway, no matter where you place it in your code. Because the shared-sprite technique uses a data: statement instead of player0:/player:, bB doesn't know it needs to do this for you. edit: dang! scooped by Michael!
  14. Check out the shared sprite data example in this thread: http://www.atariage.com/forums/topic/109288-code-snippets-samples-for-bb-beginners/
  15. I like it. I think I'll do the same, and add in a "by company" category.
  16. I bought a launch Wii because I owned an original xbox, gamecube, psx, ..., and the 360 and ps3 seemed more of the same as the last gen, only faster with higher resolution. I was tired of all of the third person shooters on the other platforms, and the Wii promised a different direction. A lot of games have delivered on that promise. I later bought a 360 after a price reduction, because I missed some of those classic gameplay games and wanted to play titles that wouldn't make it to the Wii. (Prince of Persia, Halo 3, Left 4 Dead, ...) The 360 and Wii really are complimentary consoles in that way. One has classic gameplay with updated graphics and a popular online environment, the other has a lot of experimental titles with non-traditional game mechanics. And the thing about the Wii "what the GameCube should have been in the first place" is a bit tired. First off the gamecube was smack in the middle of the last gen capabilitywise, with the ps2 being the weakest console. Being the weakest of the bunch didn't seem to hurt the ps2, so why should the gamecube have been more powerful? With the Wii Nintendo took a chance and invented a new way to control games. In contrast, I could easily see Left 4 Dead and many of the other big 360 titles being on the last generation, albeit with cutdown graphics.
  17. The multisprite kernel actually uses the real P1 to draw all of the virtual P1 through P5 sprites. So any of the following will cause *some* flicker... P1 P2 P2 P3 P3 P4 You are guaranteed to get no flicker in the following cases... P0 P1 P0 P3 P0 P4 In the example you gave... P1 P2 P3 P4 P5 P1 P2 P3 P4 P5 P1 P2 P3 P4 P5 ...you'd probably get a whole lot of flicker. If you're looking to recreate a Space Invaders pattern without flicker you need a custom kernel. This requires a deep understanding of assembly language and VCS internals. You might instead try grouping your ships more organically or staggered vertically, and you also may want to use one of the virtual sprites for your ship instead of P0, since the other sprites won't frequently sit in a horizontal line with your ship. (though that will complicate collision detection)
  18. It's the other way around. The multisprites flicker when they're all in a horizontal line. YYYY = lots of flicker Y Y Y Y = no flicker
  19. I'd like to use a paddle and my joystick with the Kate Beckinsale game. Oh wait, you were talking about the game controls. Nevermind.
  20. You'll sometimes find that a syntax error elsewhere will trigger this kind of odd error. Without the source code its hard to say more.
  21. I'll miss the show too, but I'll be happy if I can get a Harmony this year. You first lucky bastards need to share the unboxing. I'll gladly give up a rep point for the first person to post a review here at AA and urge others to join in a rep point bounty!
  22. The symmetric thing is only for playfield data. The multisprite kernel doesn't use the same variables for player1 that the regular kernel does. You're probably not using the right variables... From RT's online copy of the bB guide:
  23. Yes, its supposed to work with 27C32 and 2732. I'm still very happy with the purchase. The programmer does what its supposed to do, and it hasn't failed me once.
×
×
  • Create New...