So, so happy to see that you have not given up on this. Very sorry to hear about your misfortune though, take good care of yourself and as you said, be sure to get out more and stay active. The game is shaping up nicely, I really like the idea of a ship to control and the pilot getting out and running around. The lasers in the map room look great too, I imagine that you're going for a 8 or 16K cart? In any case keep up the good work and happy holidays. Don't forget to get out more, the world outside is where inspiration lives ;)

Glad to see an update to the game but sorry to hear about the reason for the delay. I hope you continue to feel better and don't have a repeat. I haven't tried this type of math in my own bB game ideas but I've been bouncing between various games of various types without making serious progress in any one in particular towards completion unfortunately. I also use a simple frame counter for animation though I usually only have three walk poses (one of which is also the default standing pose) just to save space. Thanks for the explanation on the fractional movement and I'll have to take a look at it. I've been most recently playing around with a platformer and I definitely agree that the movement can be too fast. My very simple ad hoc "solution" has been to just move every second frame instead but I do run into issues with diagonal jumping being faster as you mentioned.

I'm not sure about that Christopher Gronlund guy, but the rest of the cast was sooooo great! And, of course, your sound design always blows me away 😀

Just checking in after a few months to see if there was any progress on the game. As a fellow first time bB coder, I definitely understand when life gets in the way and you take months off (I certainly have as well!) but figured I'd chime in for a morale boost regardless.

I’m thinking about creating my own audio drama, what do you think would make a good program for beginners?

One way to make sure you dont go over cycles is to open Stella's prompt and type breakif {_scan>#262} then return to the program. This will open up the debugger if your scanline count ever exceeds 262. Then at the end of your loop you can add some code to intentionally waste cycles by doing some commands with known cycle counts like WSYNC or nop, which will pause the cpu until the start of the next scanline, which could be anywhere up to 76 cycles for the first one and 76 for each additional one. If you want an accurate count, use lots of WSYNC until your program goes over, then remove one WSYNC, then add some nop before the WSYNC's until it goes over again. Then add up the cycles! Example: asm nop ; 2 cycles 2 total sta WSYNC ; 76 cycles 78 total sta WSYNC ; 76 cycles 154 total end

Thank you so much for this tutorial. It's going to help me so much with future chapters in my Star Wars fan series when i need a hologram voice.

Which Kurosawa film did you see first? Mine was RAN-- rented on VHS from Blockbuster...!

Looking forward to seeing more as an aspiring future bB user myself!! I'm curious about your comment regarding not checking collision every frame to save on CPU cycles. Would that actually matter unless you're alternating between different checks depending on the frame? Admittedly I'm not a programmer (or more accurately haven't been since a sophomore year class in the early 90s!) but I was under the impression from following various AtariAge threads that the only CPU cycle count that matters is the worst case scenario based on if/then situations per scanline. Would it matter then unless you're in desperate need for those cycles for some other function that frame?

So, your issue with 'rand' is more related to the '&' operator than with 'rand' per se - the value 68 is 01000100 in binary, and the & operator masks out any other bits in 'rand', thus only allowing 4 separate values, as these would be 00000000, 00000100, 01000000 and 01000100. You might want to use values that are (power of 2)-1 on (rand&n), as they would produce bit patterns that would not mask off any value of rand lower than n, as they would operate like the modulo (%) operator in these cases, which is more what you are looking for - but unfortunately modulo division won't be anywhere near performant enough for use with the poor 6507. I think what you might want is to compose your random number as a sum of multiple (rand & ((2^n)-1)) values, where the (2^n)-1 values summed up will amount to the range you want. Ex.: if the range is 68, you can use (rand&63) + (rand&3) + (rand&1) + (rand&1), where 63 is (2^6)-1, 3 is (2^2)-1 and 1 is (2^1)-1. This gives you a range from 0 to 68, but with a heavy shift away from the numbers 0, 1, 2, 66, 67 and 68, due to the nature of averaging pseudorandom distributions.

Wow~ 😮 Seeing letters as variables reminds me of the little games I've made in the TI-82 calculator... At least one can make aliases and access the vars bit by bit there (unless that last bit 😋 is also true on the TI and I never realized it). Making something complicated like a ship going to various places with screens and all would be almost impossible there... at least with the standard programming, I remember there were "apps" that probably had way less restrictions and more vars~, though the TI also had array and even matrix stuff too 😎

That video is really comforting in some strange way. I already knew all that concepts but it's so interesting to see it applied to such an old hardware

The quality of these videos is truly outstanding. You explain the material very well and add historic bits and pieces, really well made stuff. If I'm honest, I've never used the random function in bAtari, I had a variable or two left over so I got lazy and set up a counter a=a+1 that ran each and every cycle. So when I wanted a number between 0 and 255 I called A, it's wasteful but gave a true random value ;) I've heard that using division (/) somehow gives a more random, random number, but again I've not tried. You're doing a really great job on the development of your game. Working really hard getting things to work just like you want and learning so much in the process that after a while you find that you could easily improve what you've done, so you start over. I wish you the very best of luck and look forward to your next video and of course maybe playing a wip demo at some stage. Anyway a very merry Christmas to you, or if you don't celebrate Christmas I wish you happy holidays and take good care of yourself ;)

In honor of Warren Robinett hiding his credit on-screen in ADVENTURE-- which arachnid-infested cartridge did I "hide" in this video?

Great insight! Thank you 😊

Good luck with making the game! I will soon be in the same boat as my New Year's resolution is to start my own game from scratch. So far my only experience was in making a "hack" (what the retrogame scene calls a mod apparently) of a game that was fully annotated in assembly. To answer your question either in this video or the other about the pixel shape/size, the basic kernel in Batari is what's called a "two line kernel" with square pixels (two rectangles stacked on top of each other) whereas Pitfall was a "one line kernel" using the rectangular single pixels. In the two line variant, the sprites are only updated every two display lines to save on processing power. That incredibly limited CPU cycle limit is also why you can't use the missile when you have a multicolored sprite. If you're programming in assembly and counting CPU cycles manually to stay under the limit, you can do both but Batari is trying to simplify things to make sure everything comes under the limit so adding one option typcially means you're losing another just to make sure. I actually asked that exact question over on the AtariAge forums a couple months back because I was also under the assumption that it was somehow being used in the color change. Hope that helps! I've been studying the limitations and principles behind 2600 coding but pretty much almost all of my knowledge is theoretical instead of practical so add salt as needed.

It's fascinating hearing how limited things are...but how much developers then (and now) can do with it. I'll definitely share this with geeky developer friends who love this stuff, too!

In honor of Warren Robinett hiding his credit on-screen in ADVENTURE I "hid" an Atari 2600 cartridge in this video-- did you catch the brief appearance of a game timed to me quoting the main character //and// the sound effect of his iconic accoutrement?

I like your game idea a lot. Having multiple screens and mission based game play is very interesting and gives a little challenge bAtari wise ;) BTW I really love the sprite you made at 1:18 the little green fella with the flashing pixel ;) Can't wait to see where you go with this. Great video too by the way.

In honor of Warren Robinett hiding his credit on-screen in ADVENTURE I "hid" an Atari 2600 cartridge in this video-- did you catch the brief appearance of a game designed by Howard Scott Warshaw that wasn’t YARS’ REVENGE?

Yar's Revenge was an all-time fave! Man, I friggin' loved it...and...never knew about the album! But this isn't about that. Simply: you make the act of making things so cool. Of course, you've helped me with audiofiction through your videos and chats. I have always been fascinated by game design, but it's not a thing I ever see doing. But man, I love watching and listening to people chat about it.

I always admire how much you put into even a short video like this. Definitely look forward to following along!

I love how an ending that was meant to be a bridge between films has turned out to be the mysterious capstone, somehow entirely fitting, of a self-contained masterpiece. Really enjoyed your reflections on this. Kudos.