Jump to content

azure

Members
  • Content Count

    162
  • Joined

  • Last visited

Community Reputation

149 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
    Knight Rider (2600)
  • Playing Next
    Knight Rider II (2600)

Recent Profile Visitors

6,798 profile views
  1. I haven't posted in a while, so I uploaded the current WIP. I redesigned the title screen using a new kernel that allows for dynamic palette changes. Watch the blue text and wait 4 seconds to see what I mean. I'm working on changing the betting screen to allow for higher bets (5 or 6 digit amounts), but the change will touch a lot of code, so it's going to be a significant change. The 1K and x2 bets are not working yet. x2 will double the current bet. I have to reassess if I have the RAM. I don't believe I do at the moment. The new kernel is using a few more bytes RAM, so I'll find some other code to crunch. These are not big changes, but I've been working on them for the past several weeks. Next change after this is adding keypad support. I display the two controllers that will be supported on the title screen.
  2. I've been thinking the same thing. He's so slow at producing videos that I've stopped visiting his channel, because I've already seen his entire library. He clearly needs help with video production, because it's consuming way too much of his time. I got into his channel, because I love 8bit and 16bit classic machines. He showcased some cool hardware and software, and his Planet X3 game journal videos were super fascinating. He's got to stop doing everything and outsource the busy work. He is simply not producing content fast enough and this botched job shows it. Now he's consuming too much of his time on the new studio build, when he should be letting contractors handle it. I think he should devote half his time to game production and journaling his progress, because that's what he excelled at. He's a great game developer, so why not lean into that? And worse yet, he didn't have to begin hacking up this machine to generate filler content. He could have simply showcased the computer, ruminate on why it's not booting, and simply left it that. The solutions would have come in the comments for diagnosing the machine. There are so many interesting filler videos he could have done to keep the channel churning. Interviews, showcasing retro stores, the history of the Crash of '83, start a new DOS game, etc. ----- Update: Six hours after I commented it seems he posted a rundown of his new game. Neat.
  3. The nuclear destruction in Missile Command would count as a disaster game. Maybe Atlantis too.
  4. I've uploaded version 0.2. I have the top and bottom rows rendering buildings, so they don't pop in and out of existence. The top row also renders enemy fighters. Enemy fighters don't currently cross into the bottom row. This was kind of tricky, so I went through a few kernel versions before getting it to work. I also reduced RAM usage, because I had a few unnecessary arrays. I also added the full title name to the title screen. Enemies and buildings spawning is still stubbed. I'll be working on that next.
  5. I like the idea of healing/repairing the destroyed buildings. I'm adding more stuff to the HUD. A rudimentary radar, fuel, damage, and alarm gauges. There's no problem with showing stats on an intermission wave screen. This is a very early WIP, so there is no real alien or building logic. It's just stub code to test the kernel rendering. I'm working on an RNG for generating aliens and buildings procedurally. I will be rendering aliens and buildings in the top and bottom rows. I haven't got around to it yet. If you mean the green playfield shimmering, that's unavoidable at the moment, because it's doing work on a horizontal positioning line. Horizontal positioning while rendering playfield complicates matters. It's essentially violating horizontal separation. There are only 5 excess cycles available for extra work in the horizontal blank during horizontal positioning, so I may need to go with another special case positioning routine. The strange thing I discovered during testing is 1 blank line hidden among the backgound texture isn't noticeable, so I can fall back to that. If not, I'll chop some pixels off to avoid it entirely (like Activision games.) I like the wide screen format though. Wide screen is worth the effort, imo. Features I am considering at the moment: Ice, desert, mountain landscapes. Defend and chase modes. Defend mode is when the aliens attack buildings. Chase mode is when you go after flying aliens. Combat divided into waves. Reduced terrain detail at higher speeds. Too much detail at speed becomes a blur. I have a few more features in mind but I'm holding off mentioning them, because I'm not sure they're technically possible. I have to tighten up the kernel to free some cycles.
  6. I've uploaded my Proton code to Github. I'll be probably be uploading my Blackjack code after some more reorganizing.
  7. This is something I've been working on over the past couple weeks. It's very basic and very WIP, so there's no real game play yet. It's only a demo. I'm not that sure where I'm going with this one, but I have some ideas. It started with an experiment, but I scrapped everything I wrote and started over. I have only two goals with this game. Fast and greasy. The concept so far: The new human settlements on the recently discovered exoplanet are under attack. You're the best pilot in the colony, so it's up to you to defend the colony from the alien attackers. You're piloting the state of the art ship equipped with the best laser cannon in the fleet. I've uploaded the code to Github. I'm open to suggestions. proton-02.bin proton-01.bin
  8. I had tried it with a breakif, but it didn't trigger. I'll post an update when I can better understand the precise point in the code it was having a problem. I'm switching between 3rd shift to 1st shift at work and I'm very sleep deprived at the moment.
  9. I was still on 6.0.2. I installed 6.2.1 and tried it out on the known bad version of my game. "print _scanend" shows #262 for both screens.
  10. It was in 2 sections of code running in variable time inside the kernel. I didn't have them wrapped in a timer. My current hypothesis is I think they were probably cancelling each other out in the emulator. When the top row ran long the bottom row ran short (and vice versa), so the emulator saw a stable line count. They weren't cancelling on the hardware, so there must be a timing difference. Showing a working example is going to take a little bit of effort without a full upload of all my files and support scripts. It may be easier if I reproduce it by transplanting the offending code into a sample program.
  11. Stella's debug output was solid 262 the entire time. I just tested the breakif on the older versions. It didn't trigger.
  12. I've uploaded another version as a result of testing on real hardware. There were a number of problems with scanline counts. I also re-enabled the landing screen. I also fixed a bug with the split automatically hitting the split hand twice.
  13. I've uploaded another version: 0.91. However, it's not well tested. I'm not sure if I've broken anything on real hardware. I just need to get a version out regardless of the state it's in. What have I done with this one? It's not visibly apparent, but the card rendering is completely rewritten. I rewrote it to reduce two pointer arrays down to one array. I was using one array for the top half (rank) and the other for the bottom half (suit). The change saved 12 bytes, but at the cost of using 6 bytes of temporary stack space inside the kernel, so 6 bytes were freed globally. It was the most difficult part, because animating the gap space between the rank and suit while loading graphics pointers was kind of tricky for me. It does both by interlacing the work. I freed up a few more bytes here and there. I actually lost count how many. It's probably around 10 bytes total. I freed up more ROM space by redoing some dumb code and using more table lookups. I finally implemented the selectable options for early and late surrender, dealer hitting or standing on soft 17, and 1, 2, and 4 decks are fully working. I don't intend to implement any more options other than card colors. I'm looking into the card colors, which can be done if I turn off the background texture. I reworked the navigation help. I never liked it, because it looked bad. I moved the menu options to the middle of the screen to make them more obvious. I changed the joystick inputs to be more natural with the menu. The fire button now selects the current menu item. I fixed a few bugs: cards flickering, status display flickering, and yet another bug in the random card dealing. I expanded my task handling routine to support more than 15 tasks. For the next version, I will be working on keypad input, card colors, and game over animations. The split hand interface really needs attention. There's just something about it I don't like. The controller menu on the title screen is a non-functional graphic. The intro animation is temporarily disabled, but it will return soon. I don't expect to be doing too much beyond that other than minor touches, testing, and bug fixes.
  14. If the game was playable (with the manual) as so many keep saying, then it wouldn't have needed a hack to fix the broken bits. Since a hack was necessary to fix the broken bits to make the game playable (with the manual) then I argue the game wasn't playable (even with the manual.)
  15. If you're on Windows, you can try simultaneously pressing CTRL-ALT and an arrow key to rotate the desktop screen. The arrow direction determines which direction the top of the screen will rotate to, so you could press CTRL-ALT-LEFT to rotate left and then CTRL-ALT-UP to reset back to normal.
×
×
  • Create New...