Jump to content

azure

Members
  • Content Count

    158
  • Joined

  • Last visited

Community Reputation

140 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,658 profile views
  1. 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.
  2. I've uploaded my Proton code to Github. I'll be probably be uploading my Blackjack code after some more reorganizing.
  3. 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.bin
  4. 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.
  5. 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.
  6. 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.
  7. Stella's debug output was solid 262 the entire time. I just tested the breakif on the older versions. It didn't trigger.
  8. 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.
  9. 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.
  10. 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.)
  11. 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.
  12. azure

    Need game ideas

    Sky Jinks might be good. He can control the speed.
  13. Love seeing original code. We don't often get to see the programmer's original comments and variable naming.
  14. azure

    Chess

    It's still interesting to see original source code even if it's off topic. The labels and game variable names are so cryptic. I recall seeing coding style like that when I was interning for a company doing work on a VAX.
  15. A few things that helped my video. I wrapped the video cable around a ferret core a few times and tucked it inside the 2600 case. I moved the Atari and CRT further away from my flat screen TV. The CRT itself was putting out some interference, so moving the Atari and cable around helped. I've noticed some of my light bulbs were RF noisy. Try turning off nearby lamps. Turn off any fans. Some of your electronics might be putting out radio noise.
×
×
  • Create New...