Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

DZ-Jay

+AtariAge Subscriber
 View Profile  See their activity

  • Posts

    14,954

  • Joined

  • Last visited

  • Days Won

    21

 Content Type 

Blog Comments posted by DZ-Jay

    atari2600land

    Posted

    That has always been Nintendo's way. I remember, back in my younger days, even as far back as the PS2, all the Mario games required me to buy the play-guide book.

     

    I love Super Mario Sunshine and Super Mario Galaxy, they are phenomenal games, but I still needed to purchase the play-guide to complete them. I always assumed that their policy was "instruction manual sold separately." *shrug*

     

    -dZ.

    atari2600land

    Posted

    Hey, programming doesn't come easy to me either. When I try to help is because I struggled with something for so long that it actually stuck with me, and I can then pass it on. :)

     

    The LFSR (Linear Feedback Shift Register) pseudo-random number generator I posted in C was taken from Wikipedia. It should work.

    #include <stdint.h>
uint32_t lfsr = 1;

/* x^32 = x^15 + x^13 + x^12 + x^9 + x^8 + x^0 */
uint32_t rand(uint32_t bits)
{
   while (bits-- != 0)
       lfsr = (lfsr >> 1) ^ (lfsr & 1u ? 0x0000B301u : 0);

   return lfsr;
}

    You call that function with the number of bits you want to shift, typically the largest power of 2 that fits the range you wish. If you are looking for a random number between 0 and 255, then you call it with 8 bits:

       x = rand(;

    That's it. If it doesn't work, let us know why.

     

    Just to put your mind at ease, I didn't come up with that. I don't even understand most of the math behind it. I asked others for help and they helped me arrive at a good implementation and was recommended that something like that would work for my purposes. I translated that to Intellivision Assembly Language and then was helped a bit more to optimize it.

     

    In the end, it's mostly the work of others, and that's OK. It is now one more tool in my kit and I don't have to agonize over it ever again. :)

     

    -dZ.

    • Like 1
    DoctorSpuds

    Posted

     

     

    I'm glad you guys can find enjoyment in something I find so very meh. Perhaps I've been spoiled by other better games that came out at the time or later, but I can see how this game would have been pretty awesome back in the day.

     

    Like which ones? I don't recall any other Death Star Trench Battle game back then. The closest thing was the Star Wars arcade, but that was with vector graphics but it cost a quarter per play.

     

    To me, a suitable replacement did not come until Rogue Squadron II: Rogue Leader for the Game Cube finally made the trench battle a key part of the game. In fact, it started there.

     

    https://www.youtube.com/watch?v=6Xyge10USMU

     

    -dZ.

    atari2600land

    Posted

    I posted a fully working Galois implementation of PRNG on the Intellivision forums. It's in Assembly Language but it was based on this code:

     

     

     
#include <stdint.h>
uint32_t lfsr = 1;
unsigned period = 0;
 
do {
  /* taps: 32 31 29 1; feedback polynomial: x^32 + x^31 + x^29 + x + 1 */
  lfsr = (lfsr >> 1) ^ (-(lfsr & 1u) & 0xD0000001u);
  ++period;
} while(lfsr != 1u);
    atari2600land

    Posted

    You also perhaps need to come up with a good shuffling algorithm. A very good one is the Fisher-Yates Algorithm, also known as the Knuth Algorithm, or the Fisher-Yates-Knuth Algorithm.

     

    https://www.i-programmer.info/programming/theory/2744-how-not-to-shuffle-the-kunth-fisher-yates-algorithm.html

     

    It's as simple as:

     

     
for (int i = 0; i < data.Length; i++)
{
 swap(ref data[i], ref data[i+R.Next(data.Length-i)]);
}

     

    Where "data[]" is your card array and "R.Next(n)" is the next random number generator from 0 to n.

     

    -dZ.

    atari2600land

    Posted

    As for debugging and troubleshooting, I use what some call "Zen Debugging": a more intuitive approach, analysing the problem and building assumptions on it, rather than focusing on a direct solution.

     

    Check out this article and see if it aids in your approach. A few salient points to consider:

    • Right off the bat, start with the assumption that the problem is in your own code. Accept that or risk looking for the problem in the wrong place.
    • Assume that you can solve the problem. That the fact that you haven't yet, is merely temporary. You will find the solution.
    • Relax, look away, go for a walk, think, meditate, and stop staring at the code. Do not stress about the problem.
    • Focus on the problem, not the solution. Try to understand and recognize the conditions which could lead to the behaviour you are observing.

     

    To me, that last one is the key. Rather than trying to jump to solutions, patching the code here and there to see if the problem is fixed, concentrate on the problem itself. Try to understand the behaviour that you see, and what could cause it.

     

    In my own experience, this is the hardest thing to do, but the most conducive to a proper solution: Once I recognize what I see, I make assumptions of how it could happen. It doesn't matter how silly or stupid or improbably it is, the fact you are experiencing that faulty behaviour means that your code is doing something silly or stupid or improbable.

     

    Once you understand which conditions could cause that behaviour, then trace it backwards from the observed behaviour to its cause.

     

    For instance, I once had a problem which caused a sprite to move in an erratic way. I couldn't find what was causing it, there was nothing in the code that could move it that way. NOTHING, and it was driving me crazy. I then thought of that behaviour and considered what could cause it: it looked EXACTLY as if I were updating the position register of the sprite with random values.

     

    So I accepted that assumption: something, somewhere is updating the position register -- but what and how? I put a watch on the register and indeed saw it being updated with random values. But there was no code that did so!

     

    I made a mental list that could explain the behaviour and went through it one by one:

    • My code updated the register -- Nope.
    • My code updated the buffer that gets copied into the register -- Nope.
    • I used the wrong variable or address when updating something else -- Nope.
    • The register is updated by itself -- ???
    • Something is corrupting that buffer in memory -- Possibly.

    OK, so the last one seems the likely candidate. What could corrupt the buffer in memory? It turns out that the buffer was the very first variable allocated in RAM, right after the CPU stack!!! IT'S A STACK OVERFLOW!

     

    That must be the answer. I could not trace it or directly observe when it happened in the debugger, but a race condition looked to be causing a stack overflow.

     

    So my new assumption: the stack overflows and writes some strange value into the very first variable in RAM, which happens to be the position buffer of the sprite. Considering that none of the other values were corrupted it seemed the stack overflowed by a single address.

     

    The solution was to find the race condition which caused the stack overflow and prevent it or work around it. That fixed the problem.

     

    I could have put code to try to fix the problem till the cows came home and NEVER would have hit on the actual problem. Only by focusing on the behaviour and the problem rather than reactive solutions was the issue actually solved.

     

    -dZ.

    DoctorSpuds

    Posted

    I don't like the Intellivision II. Back when I was younger, I thought it looked slick and "futuristic," and sort of wished I had one. As an adult, I can see that it's plasticky and cheaply made. It feels like a cheap imitation from China or something like that.

     

    The hand-controllers are absolutely horrid. I don't care if the action buttons are "pressure sensitive touch pads" -- that's just a silly rationalization. They were intended to be buttons, they are called "buttons" in the documentation, and the manuals indicate that you "press them." They were just poorly designed with cheap materials, saving half-a-penny for a spring or something. Blah.

     

    Let's be clear, it wasn't a "new version" of the console, it was an attempt at making a cheaper one. Only that instead of saving on the electronics only (as many other companies do), they cheapened out and cut all sorts of corners on the physical device and user interface surfaces. :mad:

     

    -dZ.

    • Like 1
    DoctorSpuds

    Posted

    I actually like Star Strike. I played it endlessly when I was young, and remember it fondly. Yes, the controls are a bit wonky, but that is the same for most of the old Mattel titles.

     

    I remember the thrill of winning the game with mixed feelings: If you fail, the Earth is destroyed in a spectacular explosion that leaves you in awe. If you win, the enemy base shakes and breaks up one square at a time until it's completely gone.

     

    I always thought there should be some fanfare or fireworks, or at least some message of victory. The rewards for saving the Earth from total annihilation seemed ... meh.

     

    In the end, I never cared about the problems with the game, and always enjoyed it -- it was a thrilling experience to play the Death Star trench battle back then. :)

     

    -dZ.

    DoctorSpuds

    Posted

    Sea Quest rocks! It is my favorite Atari VCS game -- and I am actually an Intellivision guy who doesn't like Atari VCS games. (Well, it has to compete with Stay Frosty 2 for my favor, because those are the only VCS games I like to play.)

     

    Back in the late 1990s and early 2000s I used to play this game in an old Playstation Activision Anthology collection, which came with a "1980s Jukebox." It's one of those games collections that presents itself like a retro-feel arcade room, playing popular contemporary radio songs in the background.

     

    Anyway, my point is that it would play 1980s music while you enjoyed the games to give you the "full retro" experience. For some reason, every time I played Sea Quest, it always started playing "Tainted Love" by Soft Cell, so to me, that song became the game's anthem.

     

    To this day, I still bind those two together in my mind, so that Tainted Love and Sea Quest are inseparable. Ah, memories of my youth ...

     

    In any case, great game! :thumbsup:

     

    -dZ.

    atari2600land

    Posted

    What software are you using to draw the pictures? You need something slightly better, with anti-aliasing, to avoid the jaggies on the lines.

     

    If you are trying to be stylish with "pixelated" artwork, then I suggest you make all your pixels the same size. Otherwise, it looks cheesy.

     

    -dZ.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...