Jump to content

azure

Members
  • Content Count

    106
  • Joined

  • Last visited

Community Reputation

82 Excellent

1 Follower

About azure

  • Rank
    Chopper Commander

Profile Information

  • Custom Status
    Busy.
  • Gender
    Male
  • Location
    Seattle, WA
  • Interests
    Atari 2600, Commodore 64, SNES, N64, Sega Genesis
  • Currently Playing
    Millipede, Moon Patrol, Crystal Castles, River Raid, Ms Pac-Man, Pole Position

Recent Profile Visitors

5,773 profile views
  1. Just a question, because I'm not familiar with how Twitch works. Will Twitch store all 12 hours of the stream or do you plan to store a full recorded copy locally and upload to Youtube? I may end up missing parts of the stream due to work. It'd be great to be able to catch up on missed parts after the event.
  2. Very nice. This game is going to be fascinating to watch develop.
  3. I don't actually. I'm currently using 100% of RAM. However, it's not at 100% usage all the time. The rendering of the top status bar on the betting screen consumes a bunch of stack space. I was looking into rewriting a few routines for it and flattening the call depth. I have a couple RAM variables that I could do without or pack together. The card dealing and discarded card search has been the most difficult part of the project, because I'm finding it difficult to minimize or eliminate modulo bias without entering into a costly loop. If I spread it across frames, then there could be inconsistent delays, which may give the impression the game is lagging. I think I have a solution, but it's going to require changing the bit packing format for cards, which is going to affect a number of routines. I've already rewritten two discard routines, but I'm having some issues because it's CPU intensive. I get screen bounce when dealing cards above ~65% deck penetration. I'm trying to work out a way to spread more of the logic across video frames, but that requires splitting the search into smaller work tasks, which is not going to be simple, because the algorithm doesn't know in advance where in the search it will begin. I have an out-of-band mechanism for task work, but this particular algorithm is going be more work to divide into smaller tasks, because state needs to be maintained between frames and that requires more RAM, which I don't have at the moment. I could take the easy way out on this and just go with a top down search, but I don't find that appealing. It would bias the deal in favor of Aces, Twos, Threes, etc. A bottom up search would bias in favor Kings, Queens, Jacks, etc.
  4. I knew from the start a card game wouldn't be winning popularity contests. 🤓 I chose Blackjack because I was sorting through some recently purchased 2600 games and found the original Blackjack Atari game. I was extremely underwhelmed, because I knew something much better could have been accomplished even with 4KB and 128 bytes of RAM. I was also watching STNG and had just watched "The Royale" (S2E12). I thought a card game would be a gentle introduction into the 6502 instruction set and Atari 2600 hardware, because I didn't have to deal with 3 or more moving sprites. I was always intending to work on an action game once I understood the hardware better. I didn't want to get discouraged by taking on something too big or too complex as a first game. My first attempt was actually in 2008, but I got sidetracked with a new programming job that took a lot energy out of me, so I didn't have the endurance to spend every waking hour of my day coding. I had been keeping tabs on the site periodically from 2008 to 2018. I recently found my old files for that game, but I don't think it wasn't a very good idea, so I won't be finishing it. You're right about card games being a difficult genre when all the attention goes to the hot action games, but I found enjoyment from thinking about the algorithms and solving problems unique to the 2600. Many of those problems are already solved by others, but going through the process is what's fun. Puzzle fans still love solving puzzles even if they've been solved by others. (See Rubik's Cube.) Arenafoot was also a big motivator. He's given some valuable suggestions and found bugs I wasn't finding. I was struggling to figure out if there should be an ending to the game. I had given it some thought last year and then sort of forgot about it without coming up with anything. I like your suggestion about following along with the plot of the STNG episode and escaping by breaking the bank. I have room in the 4th bank for something like that. It would tie up the loose end of why in the world would a card game be based on a Star Trek episode. 😄 There are the other parts of 2600 game programming I'm itching to work on because they are "unsolved" to me whereas the Blackjack game is in my "solved" file. I will continue working on two simultaneous projects, because I have to take occasional breaks from each project in order to maintain interest. I'm aware of the grandiose promises this community has seen from those who haven't delivered, so I've been holding back on my other plans. Atari 2600 programming is Hard Work, so I can hear the audible sighs when there's more talk than action. However, I think my mistake was not beginning Proton sooner, because I got burned out a little bit back in December and January. I've picked up work on Proton again. I'm trying to figure out this new kernel, so it's interesting. I'm planning for Proton to have Xevious style game play, but with much faster action and some real-time strategy. How that's going to work I'm not so sure yet. I'll probably solicit some ideas once I've got the kernel worked out. My other plan is for a platform shooter I've tentatively titled Cop Justice. It's a Martin Riggs and John McClane inspired character cleaning out the baddies in a building loaded with baddies. Once Blackjack is done I'll be working on both of those. For now I'm working on Blackjack and Proton.
  5. I can see it working as 16 bit sprites. P0 and P1 set adjacent to make a larger sprite. It just needs to keep them in separate layers.
  6. I might steal that. The method I've used with my one and only 2600 game is I have a few sections: Persistent globals: game state that persists between game rounds; reset when powered on or pressing Game Reset Game globals: game state exists only for a single round; reset in a loop Temporary variables: these overlap with the stack Stack: subroutines and some special purpose uses My game global section is reset with a loop: ldx #0 ldy #(MemBlockEnd - MemBlockStart) .Memset stx MemBlockStart,y dey bpl .Memset I make sure to check my subroutine call depth before using some of the temporary variables or before nesting another subroutine call. I've had to refactor a few subroutines, because my call depth was getting a bit too much. My game is not CPU intensive, so I have the luxury using lots of subroutine calls and pushing data onto the stack for a few special cases. I'll probably use the stack more in the future. I like using it.
  7. Just an update on current progress, because its been 2+ months since my last posting. I'm not posting a binary, because it's not ready. Development work really slowed down for a couple months, because of life events and a new job. Now that most of those things are settled, I've been finding more time to finish up my game. I have a few more features completed: Dealer stand or hit on soft 17 (left difficulty switch) Late and early surrender (right difficulty switch) New random number generator using a LFSR (simpler than it sounds) I also worked on a number of internal changes that won't be seen by the player. Reorganizing files, reducing ROM foot print, and reducing CPU cycles. Moved the betting screen to its own kernel Reduced the number of CPU heavy subroutine calls Found modulo bias in my card dealing routine Finding more ROM space in bank 3. In progress: Selecting 1, 2, or 4 decks (game select button). 3 decks might be too difficult or messy to bother with (for reasons). Fixing a bad bug in the card discard logic. Duplicate cards were being dealt. Fixing the bias in my card dealing routine. I may not fully fix it because CPU reasons. My current solution is a compromise. Fixing screen bounce on real hardware Fixing bugs: card dealing, discard, and some edge case bugs Player chips representing actual chip amount A few more animations. I'm deciding on what else I should do with it. I'm hitting the 80/20 part of development. There's lots more I could do, but I also want to wrap it up in the next few months and get to my other game ideas: Battle for Proton (River Raid + Xevious) or a police action game (Lethal Weapon movie + Elevator Action). For this Black Jack game, I'm going to end it with the current feature set. I thought about implementing 6 and 8 decks, statistics, casino loans, and a 2nd player, but I'm shelving those ideas for now. I don't want this to be a multi-year project. One year is enough. I can see myself revisiting the game in the future for a 2nd version or maybe rework it for a different card game. I've also got my Commodore 64 set up with a LCD monitor (4:3), and plan to spend some time learning C64 development and playing some C64 games. I'm somewhat split between my 2600 and C64 interests. I also play SNES and Genesis games, so there's that too.
  8. Can the Harmony or UNO carts create and delete files on the SD card? I'm wondering if a message passing system could be constructed using a Wi-Fi enabled SD card. Messages would be passed as files on the SD card. If the ARM CPU could do message passing to a server, it might be able to relay those messages to a running game on the 2600 by updating RAM variables. The server and ARM CPU would have to periodically poll for message files. The game would periodically read/write RAM variables. If any of that's possible, then I'm thinking a game could do a few things: Trigger a bankswitch that loads a bank with server supplied ROM data to produce longer games. Use server generated content on the fly for playfields, sprites, and game maps. Load the next chapter of a game while maintaining game state variables. Upload high scores and game state to a server. Personalized graphics. How feasible is this with a Harmony or UNO card?
  9. Noticed something in the graphic. That should be 12PM-12AM PT. 12PM is noon and 12AM is midnight. It would be noon to midnight.
  10. This would have made a nice game for the Top Gun movie. Is Danger Zone is referring to the Top Gun song?
  11. I use this and don't get any warnings: IFCONST AFP_TARGET IF AFP_TARGET != 1 lda #%00000010 sta VBLANK ENDIF ENDIF Then tried adding a new reference I know doesn't exist: IFCONST TEST_0987654321 ECHO "defined" ENDIF Still no warnings. Are you sure it's not caused by something else? Dasm version: DASM 2.20.11 20171206
  12. The motion physics on the dropping cubes is incredible.
  13. Has anyone suggested using bankswitching as memory? If you had 8 banks, that would provide 3 bits of state. Each bank would have mostly duplicate code, but coded with an identifier between 0 and 7. Storing the value of 5 would be done by jumping to bank 5.
  14. Making this game is going to be a lot of hard work.
  15. Ahh, so it's accurate game play. Fine details like this really make this port even more impressive.
×
×
  • Create New...