Jump to content

MrFish

+AtariAge Subscriber
  • Content Count

    7,395
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by MrFish

  1. Interesting read. Obviously a joke, as it's poking fun at him; and debunked by the author -- even though there is a kernel of truth in that his body of work was highly comprised of the form. I'm quite familiar with his concerti and appreciate their memorable themes and simplicity. Oddly, I don't like his most famous (the Four Seasons), except for a few movements within. Bach was highly influenced by him (and I venture Mozart was too), and pushed the form in his great compositions.
  2. I'm not taking issue with concerti being a form or framework; it's obviously so; but the statement I quoted makes it sound as if so little was different about each one composed by Vivaldi as to warrant labeling them as "one concerto" reproduced, which is far from the truth. Also, maybe a better analogy would "gun", and from there we have rifles, pistols, etc.
  3. Interesting for this subject to come up; I've been spending a lot of time with the compiler for my slot machine game over the last 6 months or so -- off and on. I've had some of the same problems, and some additional ones; but, interestingly, I've found a solution that seems to be working for a while now. Initially, I had (by way of loose programming) been operating in the 240+ range with the variable name table (supposedly expanded to 256 with TBXL). I had suspected it might be a problem, but only tested out the theory recently, because I'd found other temporary means of getting around it. I've found over the recent several months of compiling, that if I don't get above the 215 range in the variable name table, everything that works in the interpreter will work in the compiler. I haven't taken time to test this idea specifically enough to say this is what has fixed the problems I've been having; but experience has made it something that works so far. I'm hesitant to make any claims, in part too, because I'm also utilizing the basicParser, which could be pushing the compiler to do some additional things it doesn't like -- beyond what working with one-to-one source would do. Ultimately, not having more space available in the variable name table is going to result in moving everything over to Fast Basic, though. Porting will be pretty direct anyway -- aside from lack of multi-dimensional arrays; and of course they'll be a speed gain, and additional features available in Fast Basic. Since Fast Basic was designed with TBXL in mind, this will be a natural progression.
  4. Here's a preview. Everything is fully working. You can add and remove lines, adjust pull strength, view paycard and other infos using the joystick. I was thinking of releasing this as is; sort of a final release for this version of it. I also have some other themes that I've done and used in place of this one; and I have many more theme and machine graphics done. Some of these graphics are still preliminary.
  5. I'm not really relying on mechanical properties so much, other than by observation (youtube vids) and discussions I find on forums; although I'd eventually like to get into more specifics for those aspects. I do understand how the general mechanisms involved work together to provide payout for wins, spin the reels, and various other functions (although payouts can be handled more easily by a program). The main factors I'm focusing on are the reel strips, their matching payout/award cards, and the statistics that the two produce. I've done enough experimentation and testing with various random number use methods to see all the statistics produced on the player side of things. I have a fair number of various service and parts manuals in PDF form, although I haven't spent much time with them. I have seen that Mills book you linked. The Mills books I have are for a few specific machines. Yeah, quick google searches won't get you very far with slot machine theory. It's basically something the industry has no interest in making available; but you can get inside, with some effort. I actually plan for it to be both: a collection of slots machines within a full casino that has black jack, craps, roulette, and a few other games. The black jack game was started years ago, and it's just on hold at the moment. I actually used to work in casinos before, so I have a lot of experience to draw on from there too.
  6. I found out some months back that the above is actually incorrect. I had obtained a proper payout card for the machine I was emulating, but I wasn't aware, at the time, that there were different variations for the same model of machine. So, I ended up having a mismatch, which resulted in a 106.10% RTP, which is unrealistic for any casino machines (would be fine in your home, though). Some machines I've examined are slightly over 100%, of which it isn't bad for a casino to have one or two such on the floor; casinos don't post machine stats anyway. The difference is hard to tell in the short term -- and casinos rely on long-term stats. So, my original program here is a bit on the generous side -- which is fine for a simulation. Having played some casino video games -- like Vegas Stakes for the SNES -- I can say I'm quite sure it has an unrealistic RTP as well. The player tends to win quite easily on its slot machines (more so than with the one I created). I think it was just done in order to provide a means for a player to recoup money lost in the other sims; although I can't vouch how realistic the other sims are, as I haven't spent any considerable time with them. It's all fine for a video game, if that's the experience you want your player to have; it's fake money anyway. Anyway, everything I'm working on, going forward, is aiming for realism (as I originally intended), but the fun (since realism isn't always fun, in its pure form, for a video game) will be in the depth and variations available. For instance, in Vegas Stakes on the SNES, you have different-looking slot machines in each casino, and different denomination machines available for each casino; but they all use the same internal reel strips and payout cards. So, the slot portion of the game gets boring pretty quickly. I currently have a pool of about 20 machines that I'm working with, of which I'll probably cull the best 10 or less. Then I'll add about a handful of the IGT / Bally type machines that I mentioned above. I'm not sure how I'm gonna release all of these. The eventual goal is still to have a complete casino package; but I'm thinking to at least release a single machine, or a multi-machine version as a stand-alone. [Note: RTP is just percent "returned to player" of total money bet. If, during a play session, you are at even money, your RTP is 100%. So, casinos rely on an RTP below 100% -- among other factors -- to make their money.]
  7. I had a chance to examine some of the Bally and IGT machines that use spaces as stops. These machines have more jackpots and much higher payouts for them; so, this is just one method for balancing the stats. The old Mills, Jennings, Watling, etc. era of machines with 3 reels and 20 stops couldn't offer these kinds of jackpots. Another way to change the odds, of course, is to add more reels and require longer combinations. This was done on some machines by those manufacturers later on, adding 4 reels and some big payouts. The 3/20 setup gives you 8,000 possible combinations, while a 4/20 will give you 160,000 combinations. I like some of the IGT and Bally machines (with actual spinning reels), though, like Top Dollar, Wheel of Fortune, and some of these others that offer mini games after getting certain combinations, or free spins and other bonuses. Eventually I'd like to do a few of these types too, or at least create some variations of my own (since I'm not so fond of the "spaces are stops" method).
  8. As much as I like the idea of replicating the original 1090, I'd be more apt to purchase a smaller, more cost-conscious version; and I don't think a smaller version would be just another PBI device, when it would be modeled after a 1090, just in a smaller form factor. The only negative I can really see for a smaller version is that -- if both versions were made -- then you divide the project into two (probably small) camps, which might not be a good thing for a number of reasons.
  9. That's what I figured the case was. Not really a big deal, I can just convert to screen codes. The stuff I'm printing is no more than 8 characters per string anyway (and usually much less than that). It'll be plenty fast enough. The display I'm using is 18x Antic 4 + 8x Antic 2 (with 4 blanks inserted in between), which is just barely over.
  10. Is there an easy way to modify the vertical boundary used by PRINT and PRINT #6 commands in BASIC/TBXL to accept values greater than what the standard Graphics modes use? I'm working with display lists that have been modified for more vertical lines.
  11. Chopper Command and Pressure Cooker are two more good Activision titles.
  12. Wrong forum. This is the 5200 and 8-bit programming forum. You need to post on the 5200 general forum. Atari 5200 - General Forum
  13. Just for fun, I compiled it... runs at twice the speed, or faster. To run the compiled version, <BREAK> out of the uncompiled version once it's running. Then BRUN the "D:RUNTIME.EXE". Shuffle Deck.atr
  14. I don't see why not. The only catch is that the 7800 version uses all four POKEY voices for the music (with TIA doing the sound effects). So, sound effects on the 8-bit version would need to use some sort of multiplexing; probably best to multiplex with the percussion.
  15. Speaking of source code... source for the 7800 version is available. It's similar to the 8-bit version, in many ways (both developed by Sculptured), but also superior in a lot of ways. I'm not sure the 7800 version has as many levels as the 8-bit version, though. Commando (7800) - Source.zip
  16. Another note here... arrays are expensive in terms of memory. I used an array because this is just part of some preliminary coding for the project. Strings are a lot cheaper. All my values are going to be less than 255 too. So, it's quite simple to do with string memory offsets. I'd never really thought of it before, but values up to 65,535 are easily possible using strings too. Just store and retrieve your values using DPOKE and DPEEK, and offsets that increase and decrease by 2 instead of 1.
  17. I threw together a quick program to allow testing the method. The program lets you select a size, and choose whether you want to shuffle a freshly ordered array or reshuffle. One note on the code posted above (and the program attached here) is that the comparison can just be between the two indices if you're using unique elements (which both examples are). The reason I coded it like above, though, is in preparation for using a shoe of cards, which will have duplicate values. Therefore, it will potentially save a lot of swaps. With unique values, there's no necessity to compare the values (they're all different) and will save some small amount of processing if you eliminate it. The disk autoboots the program. Shuffle Deck.atr Thanks... it's growing; but I've no time for it right now.
  18. Here's the method I came up with (when I was working on my Black Jack program) to shuffle an array representing card values. It randomly selects an index value until there are none left to select, and swaps the value at that index position with the value in the current index position of the loop (if necessary). This takes about 2 seconds in the TBXL interpreter. The only variability is how many times it needs to make a swap, which will never exceed the number of elements -1. As for seeding... I haven't dealt with that part in the program yet, but user button presses from various title screens, or whatever, can be used to get random numbers for creating small timing loops to use in between card selections during the shuffle and/or to determine how many times the deck would get reshuffled; that coupled randomness of time it takes to play through a deck (or shoe, as it will eventually be) -- when the reshuffle happens during play -- would be sufficient in this case.
  19. Over-researched/over-presented a "who really cares that much?" subject (just like the overworked -- I need attention, like a girl -- hair-wad sticking out from the front of his hat). The video could have been over in less than 30 seconds. "So... like... in the game Pac-Man, the antagonists have mostly been known as Ghosts for all these years; but in reality, they were originally called Monsters by the creators".... "Oh, ok... interesting. They do look like ghosts, though; and ghosts are a type of monster, generally speaking". Finis. I watched about 4 minutes before hitting the "go away" button.
  20. The music always seems... better in these demos; but I've gotta say, I really like those break-dancing aliens.
  21. There are some other oddities with the sprites too. If you look at their rackets, they don't have the same shape, and sometimes appear square in the 800 version. Also, their extended arm should always look as seen in the 2600 screenshot above. I had a look into the ROM, and the sprite data looks to be correct. So, it has to be something with how they're being rendered.
  22. Something seems to be going on with their feet. In the 800 version they lose and regain their feet at various times. I don't see this happening in the 2600 version.
  23. Champ Games They do high-quality, modern homebrews for the 2600 -- with a focus on a lot of the arcade classics.
×
×
  • Create New...