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

Dionoid

Members
 View Profile  See their activity

  • Content Count

    494

  • Joined

  • Last visited

Posts posted by Dionoid

  1. Posted · Edited by Dionoid

    1 hour ago, Lord Innit said:

    The colour loss on my PAL cart doesn't bother me too much. What does is  the whole screen flickers/flashes making it very hard on my eyes during the duck shoot. Does that happen for others too? 

    For me the Duck Shoot starts in black&white for a second and then starts flashing, alternating between green and pink. It is hard on the eyes, but playable for me.

    Also, my '2600 Jr isn't affected by the "bunny bugs", so I can basically play though the game (although I never reached the final sideshow 🙂)

  3. Posted

    Wow, I was blown away watching the ZPH stream! What an amazing graphics and great racing gameplay. And that 'hilly road' effect is really good and adds another dimension.

     

    I've never played Turbo arcade before, so I felt that the transition from & to the curved wall level (with the ocean view) was very abrupt. But then I checked out the original arcade game, and found that the transition is the same there.

     

    Looking forward to playing the first official demo!

    • Like 3
    • Thanks 1

  4. Posted · Edited by Dionoid

    5 hours ago, Andrew Davie said:
    20 hours ago, Dionoid said:

    My guess is that the PAL game testers for Circus Convoy didn't use the Developer mode in Stella, and probably also didn't do thorough testing on an actual console, causing the PAL color-loss bug in the Duck Shoot sideshow to be unnoticed.

    I'd be wary of blaming playtesters for bugs in a game. Often they do this work for a pittance, and purely out of a love for gaming. Bugs are a developers' responsibility, and they will almost for sure get through most testing processes. It's a shame that these bugs (two I know of) have made it through to production. The real issue here is how Audacity responds. I know that a severe bug in one of my programs led to me doing a recall, which was a bit of a personal disaster, actually.

     

    Edit: I'm not suggesting/implying there should be a recall. My point being, a bug screws everyone. Developers don't want to release games with bugs. Consumers don't want to play games with bugs. Playtesters don't want to feel responsible for bugs.

    I fully agree that bugs are a developer's responsibility, so in hindsight I should have referred to "game testing" instead of "game testers".

    Anyway, it was more of an observation, really. Even for an obvious bug like the PAL color-loss in one of the sideshows, I realize that this was the result of a late code change, probably bypassing the normal regression testing.

     

    I'm still a bit frustrated by the lack of empathy in Audacity's (indirect) response to my bug report, which came across like "sorry, but for most other people this isn't a problem at all":

    Quote

    Thank you to those who reported the issue, and the speculation is correct. Even with 2000 hours of Beta Testing, we missed a frame rate anomaly on the Duck Shoot game.  (In our testers' defense, it has an insignificant effect on NTSC and only really shows up on PAL.  And even then only on real hardware - the color effect does not show up on emulation.)

    ...

    As I have bought the PAL cartridge edition, I don't care if the bug has no effect on NTSC or on emulation; that doesn't fix the problem for me. In this case, letting the developer handle customer service probably wasn't a good idea 🙂

     

    And what to think about the words "In our testers' defense, ..." ??  I'm not sure we all agree that bugs are the developer's responsibility 😉

     

    • Like 1

  5. Posted · Edited by Dionoid

    8 hours ago, Thomas Jentzsch said:

    What seems to miss is, why sprites get shifted if you skip one RESPx. Which is the reason why e.g. my Space Invaders game needs a 4 cycle interval.

    I think @SeaGtGruff explains that with that paragraph about the +5 color clocks after a STA RESPx ends, right? Probably not as detailed as Andrew Towers' hardware notes, but sufficient for me.

    And kudo's to the Stella team for emulating this TIA quirk correctly!

    Quote

    When you do STA RESP0, the player0 sprite gets repositioned at the color clock that's +5 after wherever the STA ended-- e.g., if STA RESP0 begins on cycle 23 (as in your code above), the cycle after STA RESP0 ends is cycle 26 (23+3=26), which is color clock 78 (3*26), so player0 gets positioned at color clock 83 (78+5=83). The first 68 color clocks are the HBLANK persiod, so that would be pixel number 15 on the visible scan line (83-68=15).

     

    The reason for the +5 delay is explained in Andrew Tower's hardware notes, but we'll just accept it without trying to fathom the why of it-- but I recommend reading (and rereading several times) Andrew Towers' document.

     

  7. Posted · Edited by Dionoid

    Yes, the "Rabbit of Death" glitch is 100% reproducible by checking the "Drive unused TIA pins randomly on a read/peek" box.

    I think this indicates a bug where a memory address is read instead of an immediate value?

     

    My guess is that the PAL game testers for Circus Convoy didn't use the Developer mode in Stella, and probably also didn't do thorough testing on an actual console, causing the PAL color-loss bug in the Duck Shoot sideshow to be unnoticed.

    • Like 2

  8. Posted · Edited by Dionoid

    On 5/17/2021 at 1:53 PM, Colmino said:

    So I'm trying to figure out how games like the original Galaxian port, the homebrew Galagon, and the homebrew Space Instigators manage to display 7, 8, and 9 simultaneous horizontal sprites, respectively.

    I've also been investigating this RESPx multi-sprite trick yesterday, and finally this detailed information on the multi-sprite trick by @SeaGtGruff made it all "click" for me.

    • Like 1

  9. Posted · Edited by Dionoid

    On 8/22/2013 at 7:40 AM, SeaGtGruff said:

    Now, even though strobing RESxx doesn't trigger a "start" signal, it just so happens that if you strobe RESxx at just the right time-- such that the RESxx instruction ends while a "start" signal is active-- that "start" signal will cause copy 0 (main copy) to be drawn. It can be argued that this is actually copy 1 (or 2 or 3) being drawn (depending on which "start" signal was active when RESxx ended), but for all intents and purposes it's copy 0 that's drawn, since the other copies will follow as expected.

    I've spent last evening trying to understand the RESPx multi-sprite trick, reading both Chris Tumbler's "The Multi-Sprite Trick" and Andrew Towers' "TIA Hardware Notes - The Re-trigger Trick, and all that jazz", but felt that the information there was not 100% correct, or at least not on par with what I was seeing in the Stella debugger. 

    Also, I was a bit confused by Andrew's statement, saying "If you hit RESPn at least twice on every scanline, you will never see the 'main' copy of that player, ever, on any scanline", which I could not match with the sprite-copies that got displayed.

     

    Maybe it's a matter of semantics and terminology, but for me, the detailed information on the multi-sprite trick by @SeaGtGruff, made it all "click" for me. So a big thanks to @SeaGtGruff, 8 years after that information was written down 🙂

     

     

    • Like 2

  10. Posted · Edited by Dionoid

    18 hours ago, CapitanClassic said:

    In that case, as I said with NES Doom, the developer wrote a VGA to PPU display driver. If someone were to do something similar for Doom2600, they would have created a VGA to TIA display driver.

     

    18 hours ago, kisrael said:

    If someone made a whole game w/ that... like just used it as a a 48x192 display... eh, for me that's the darkest of the grays :-D to totally ignore the stuff in the TIA except as as blank a slate as possible... to me that feels closer to the "gimmick" as you say.

    I see your point. In case of a VGA to TIA display driver, the developer wouldn't have to care about the TIA or the 6507 assembly kernels anymore. For me, this would take away the fun of programming for the Atari 2600. Luckily, using the ARM doesn't take away this fun 🙂

     

    Still, I think it would be cool if someone would create a VGA to TIA display driver and run DOOM on an Atari 2600, using a Raspberry Pi inside a cartridge shell!

     

    • Like 2

  11. Posted · Edited by Dionoid

    On 5/17/2021 at 2:40 PM, Thomas Jentzsch said:

    Since 1 CPU cycle equals 3 display pixel, you cannot position or move sprites smoothly horizontally this way. I suppose that was the reason of the spacing.

     

    I am sure @johnnywc can explain better.

    In Galagon, I see that the enemy multi-sprites are semi-smooth scrolling horizontally, moving 1/2 pixels alternately. Because the sprites are 7 pixels wide, the trick being used here is to shift the graphics a single bit, and for the next move add 1 CPU cycle and shift the graphics back.

     

    [Edit]: I just found that Galaxian's enemy sprites are 6 pixels wide, which is probably the reason why that game shows smooth horizontal scrolling of the multi-sprites.

     

  12. Posted · Edited by Dionoid

    1 hour ago, kisrael said:
    On 5/19/2021 at 3:05 PM, Dionoid said:

    To me, the only limitation of a cartridge is that it has to fit into the cartridge port.

    What if it was a cart that was a rasberry PI with its own HDMI out, that only used the Atari as a 5V power supply or whatever? And maybe joysticks? But what if it used Bluetooth wireless controllers or its own USB ports?

    You have a point there. If a cartridge has its own video output and only uses the console for power, then I don't think you can consider it a cartridge anymore. Then it's more of a "gimmick" IMO. A cartridge should be part of the system architecture, communicating using the internal busses.

     

    1 hour ago, kisrael said:

    Again, not total hate - I mean I personally still ask "isn't it arbitrary to target the 2600 if you don't want to be constrained by its constraints?" but there's absolutely a middle ground - where you're still using the TIA and its objects. 

    To me, the fun in programming for the '2600 is working with the limitations of the TIA (+ discovering its quirks) and writing tight 6507 assembly kernels where every cycle must be counted. When using the ARM coprocessor, these constraints are still there; they are only a bit widened:

    • you can gain some cycles in the 6507 assembly kernel(s), which can be used to enrich the game's graphics.
    • game logic can be offloaded to the ARM, which allows you to enhance the gameplay; or in some cases, making the gameplay possible/feasible at all.

     

    Of course ultimately, the fun in programming a game is to know that other people enjoy playing your game. It still amazes me that 44 years after the '2600 was initially released, people are still pushing the bar with new games!

     

     

    • Like 2

  13. Posted · Edited by Dionoid

    15 hours ago, kisrael said:

    It raises a question: why the Atari, then, for people who are firmly in the "lets push what we can cram into carts" camp?

    I actually never owned an Atari 2600 back in the day (I had a C64 which I loved) so I have no nostalgic connection to the '2600 itself, but only to the 65xx microprocessor inside.

     

    In the beginning of 2018, I decided to try to fulfil one of my childhood dreams: to create a game for the Commodore 64, so I started to learn 6502 assembly and the inner workings of the C64. During that process, I came across a video by @SvOlli called The Atari 2600 Video Computer System: The Ultimate Talk. I was intrigued/amazed by the limitations of the '2600 (mostly the TIA) and the fact that you have to count all your program-cycles to be able to draw stuff on the screen. The fact that the Atari 2600 only works with cartridges, made it even more interesting. Then I discovered the amazing Stella debugger, and decided that -instead of the C64- I wanted to make a game for the Atari 2600. And I didn't look back at programming the C64 since 🙂

     

    While I understand why people strictly want to create games that are within the original 4K limits (I actually used these self-imposed limits for my first game), I think it becomes a sliding scale when you start to consider hardware-based improvements like bank-switching, additional RAM (SARA) or co-processors (DPC, ARM). Any line that you draw here is arbitrary.

     

    To me, the only limitation of a cartridge is that it has to fit into the cartridge port.

    And I bet no-one complained that the DPC co-processor in Pitfall II was 'cheating' when this game hit the market in 1984 🙂

     

     

    • Like 1

  16. Posted

    On 5/1/2021 at 9:00 PM, PitfallCreator said:

    Thank you to those who reported the issue, and the speculation is correct. Even with 2000 hours of Beta Testing, we missed a frame rate anomaly on the Duck Shoot game.  (In our testers' defense, it has an insignificant effect on NTSC and only really shows up on PAL.  And even then only on real hardware - the color effect does not show up on emulation.)

    No worries; even the best can make mistakes ;-)

    However, the defense that there is no effect on NTSC and the issue doesn't show up on Stella doesn't help me much, as I have bought the standard edition PAL cartridge. 

     

    Well, at least I got a nice story from the old days for reporting the issue 🙂

     

  23. Posted · Edited by Dionoid

    Hi, this is a fun game! Reminds me of Fishing Derby 🙂

     

    I noticed that pushing RESET brings you back to the menu screen, which isn't standard behavior for Atari 2600 games.

    Usually, the SELECT button is used to go back to the menu/select screen, and the RESET button is used to (re)start the game. Just check some classic games like Pac Man, Asteroids, Berzerk or Space Invaders, and you'll see that they use SELECT to let you select the game options. This also goes for homebrew games like Draconian, Galagon, Fall Down, Assembloids, etc.

     

    • Thanks 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...