DZ-Jay

And speaking of Christmas traditions ... I have my tree dolled up with its favorite ornament. :) Oldie, but goodie. MERRY CHRISTMAS TO ALL! and a HAPPY NEW (non-Covid) YEAR!!! -dZ.

Here's an old explanation I provided some time ago on how it works. It may not seem as intuitive as most other "bitmap" graphical systems, but it very similar in spirit to how painting programs work. Think of the Color Stack background colors as "flood fill" of backgrounds, and the "Stack Advance" flag as the boundary where you switch colors to continue "flooding." If you think of the GROM graphical cards as purely "geometric shapes" to fill patterns, you end up with "programmer art" scenes, which understandably, may not be precisely what you want. What I do instead is try to align my scene to tile boundaries in a somewhat "organic" way and exploit the fact that geometric shapes do occur in our natural surroundings, and sometimes even fit to cover certain regions. Essentially, I design my "ideal" scene, rip it into tiles, then try to match as much as possible each tile to a commensurate GROM card, sometimes slightly adjusting the other tiles around it in order to make them "fit." It's time consuming and a lot of effort, but it's quite effective, in much the same way that exploiting the four-color-per-8x8-tile in a C=64 has been used to create very impressive scenes. I've even used a GROM lower-case letter on a MOB, slightly offset from the background grid, to cover a spot in a scene; something which would be impossible in FG/BG mode. Let us be clear, GROM cards are not just special-purpose shapes like clubs and diamonds; the set includes useful pictures like lines of various width and offsets, triangles, small blocks at differing alignments, etc. -- all of which may occur to some degree or another in any part of some random scene -- and that's before considering actual stamp-patterns. Something as innocuous (and exceedingly useful) as an 8x8 solid block (card $5F) is out of limits in FG/BG mode. Now, this is mitigated by more background colors being available in that mode; but in Color Stack mode, you can actually fill the sections of your background with actual pixels of a solid color with no GRAM cost whatsoever. Highly complex scenes can be built with Color Stack by cleverly mingling GRAM and GROM cards and exploiting color variance between them. Is it better than FG/BG? It depends on your expectations of what "better" means. If you feel, like I do, constrained by the graphical potential of only 64 custom GRAM cards, then Color Stack opens up a whole new world of possibilities with GROM shapes. If you feel that it is too hard and cumbersome to manage a set of only four background colors which -- to add insult to injury -- can only be used in sequence; then FG/BG offers a larger universe of colors. Both are perfectly good and valid positions to take. Like we say in Spanish, "para los gustos, los colores"; which translates roughly to "for every taste, a color," and has a similar meaning to the English idiom, "horses for courses." :) -dZ.

For what it's worth, I prefer Color Stack myself. However, both modes have their advantages and limitations. In Color Stack, the BACKTAB can use all GRAM and GROM, but the background colors of cards are limited to the four sequential colors in the stack, and there are some limitations on the colors available to GROM cards. In FG/BG mode, you get independent background colors for each card, which can use all 16 colors, but the foreground color is limited to the primary set. However, the biggest limitation of this mode is that you can only access the first 64 cards of GROM for both BACKTAB and MOBs. Essentially, Color Stack is more flexible graphically and limited in colors; while FG/BG is more flexible in colors but more limited graphically. However, a clever hand can make beautiful artwork and scenes in either mode. I personally find Color Stack more powerful because the color limitations can be worked around with some clever tricks like reverse-video and MOB overlays; but nothing in the world can make FG/BG access more graphic pictures than the 64 GRAM cards and the ASCII set of GROM. I rather have access to the full GROM to gain more picture variety. :) -dZ.

I got that. I just didn't quite understand what was the problem. Was it that he was loading too many GRAM cards on the same cycle? There is an easy way to find out: Enable the debugger in the emulator and issue the command "^" (show GRAM dropped writes) in the prompt, followed by "r" (run). It the debugger should tell you if writing to GRAM failed at any point, and where, due to the VBLANK access window ending. If you are using the IntyBASIC SDK, you can enable the debugger using the "INTYDBUG" command. If not, you can just issue the option "-d" at the command prompt when running the emulator. -dZ.

Looking good, although I wonder if there is more that could be done by aligning the graphics better to card boundaries, in order to remove some of the weird colour "bleed" across them. Is there a new build ROM to try? -dZ.

I don't quite understand what you mean about the DEF20 thing. Could you post some code and maybe we can assist in finding what was wrong? To be honest, you shouldn't have to update GRAM for everything on every cycle, just those cards that need to change. Also, if you'd like to share some screenshots, that would be nice. :) -dZ.

Why do you need FG/BG mode? The things you mention can be done in Color Stack mode as well ... -dZ.

There's a fresh thread for this year:

Hi, all, I've grouped all the event videos in a YouTube playlist, for everyone's convenience. I also added some comments to describe the contents of each video, including hyperlinks to the respective panelists' sites, and to give credit to the musician who composed the Intellivision musical interludes. https://www.youtube.com/playlist?list=PLg2vTWOVOig1KeLPvIpYDRFiDYQNmvj4V Enjoy! -dZ.

That is very odd. Did you use the SDK installer? I've been using Windows XP (SP3) to test the SDK for years, but didn't even think to test it with SP2. Do you get any particular error message?

I really like that music on the title screen. I tried clicking start and get the first screen with a cursor, but moving the cursor sort of crashes it or causes it to get stuck. I did not know what to expect from this first ROM, so I wasn't sure if I should have been able to do anything else. UPDATE: Never mind. It seems that if I move the cursor too high or too low, the game sort of get stuck. I was able to go into the door and enter the elevator on the next screen. -dZ.

That's how my game room was before. Right now I don't get a "game room"; I get a corner of the living room which, admittedly, is pretty big. I don't get any walls to hang up stuff, just the cabinet and a bit of space in front to sit and play. On balance, that's all I really need.

I love the iCade! When I bought it back when it came out, I loaded up my old iPad with all the classic arcade anthologies I could get: Nampo, Midway, Williams, etc. It was awesome being able to play Pac-Man with an arcade joystick again. Hehehe, yeah. I actually got that when it first came out, and then ended up buying the real thing and never opened the handheld. dZ.

LOL! That's the plan!

I finally got my custom game entertainment center built. They just finished it last Monday, so I finally got to take my collection out from crates, where it's been patiently hibernating since my move back in 2013. I'm still getting everything ready, and the machines haven't been plugged in or wired at all yet, but it's already starting to look very nice. So I thought I would share some pictures. I am going to set it up like a little "living room," with a small sofa and coffee table, and put some LED lights at the top. I even found a spot to put my Star Wars Lego collection (still got more to unpack). I couldn't get a good picture because my make-shift TV center was in the way. It'll be moved eventually to the other corner of the room. Cheers! dZ.

I just started this morning. I finished Óscar's just right now. Man, that was very good and interesting, Óscar. It definitely gives a true picture of the current state of Intellivision game programming to anyone outside our community. Thanks for sharing it. :) -dZ.

I think he meant the other public thread, which has grown to 8 pages now but it's getting a little stale.

Thanks, Steve!

Hi, @dalves, That's probably because the later versions of the SDK "INTYNEW" command include the directive "Option Explicit" at the top, which is good programming practice. This option requires variables to be declared before being used. You can declare a variable with the "DIM" statement. You can declare all the variables you wish to use at the top of your program and then you don't have to worry about it later. The reason this is good programming practice is because it lets the compiler catch typos in variables. Any variable that is not explicitly defined with a "DIM" statement, will result in an error. For instance, if you define a variable called "positionX" but at some place you called it as "postionX" by mistake (notice the spelling), the compiler will catch it. These sort of errors are extremely hard to catch visually because your brain tends to compensate for the missing letters if you are not looking for it. You can find more information about the use of "DIM" and the "Option Explicit" directive in the IntyBASIC manual included in the "Documents" folder of the SDK. -dZ. P.S. If you really, really, really do not want this feature (which, as I say, promotes good programming practices), then you can always remove the line "Option Explicit" at the top of the source file created by "INTYNEW." However, I sincerely do not recommend this.

Here's a crazy idea ... if we're going to make the Intellivision Virtual Expo a thing, do we really need to do it once a year? How about if we plan for a Spring event? :) -dZ.

I have a few Zoom licenses that expire at the end of the month, so if needed, we can use those. :) -dZ.

I imagine that the reason there isn't a standard mechanism is probably because of two main reasons: First, like any other problem, there can be myriad ways of solving it. Second, and perhaps more importantly, it may not be really a problem in practice, and solving it may be more costly than its worth. That second bit is the reason why I did not attempt to solve it. The path-finding algorithm is simple, and elegant, and works exceedingly well for 99.99% of the time. When that 0.01% of the time it breaks down, what is the actual consequence? That the enemy looks stupid while the player remains motionless. Now, is it really worth going through the trouble of implementing potentially costly solutions that may even have a negative impact on the other 99.99% of the time, for what is, in essence, a rare edge case? In my humble opinion, on Christmas Carol at least, it was not. You yourself said that you've played the game and never encountered it. The same applies to most players. In my view, I treat the player as a partner, not as an adversary. My job as a game programmer is to enhance the enjoyment of the player, and to avoid annoying him. In turn, I expect the player to interact with the game in good faith. If this were something that breaks the normal use of the game, then yes, we have to fix it. But if it is just a quirk that may look a little goofy and only triggers rarely, and will solve itself out if the player continues playing normally; then I have better things to do. Yes, it makes sense. It is also similar to what I had thought about before. As you note, it does require that we keep track of the previous positions and compare, which is something that is not built into the mechanism to begin with, and complicates it. It also requires additional memory and CPU resources to process. Of course, if it is something that negatively affects game play (which may be the case in your particular game), then that expense may be warranted. If you have a specific case, I can work with you to come up with solutions, just let me know. However, I wouldn't consider myself smarter than anybody. -dZ.

It's my pleasure. Understood. Yes. Imagine you are reading a book and every page starts at a different row. In my opinion, the biggest issue with growing upwards is that your eyes do not have time to figure out the point of focus until after the entire window is composed and the text is already starting to show. (Remember, the player will need to read from the top-left corner of the text box.) This delay could be avoided by giving an indication to the brain on where the text will actually start. By growing the box downwards, the player can start focusing his eyes straight away while the box grows. Personally, I think these are subtle cues that most games miss, but they tend to be important in many user-focus disciplines, such as graphic and industrial design; so why not in games as well? LOL! Sorry, it's not really a matter of being family oriented -- it's more to do with the style of games from the era. A game that uses modern graphic language is most definitely not something that could have been released back in the 1980s. So, if you are trying to reproduce the "feel" of the time, why not embrace it entirely? That said, this is not really a problem. I just found it a bit jarring. Especially since "Crap!" is not even a particularly common expletive from the 1980s. Well, I am interested by this game. So far, it looks very much like the type of game I would play. Just bear in mind that writing dialog for games, like for movies or TV shows, is a skill and a discipline, so unless you have such experience, be prepared to have others challenge your writing style. (And I do not mean me, since I am also very much not a dialog writer!) -dZ.

Be aware that there is a very big caveat that comes from Manhattan Distance ... Yup, that's the one: because you are computing the straight paths across a grid, multiple paths may result in the same distance even though one may be actually shorter than the other as the crow flies (i.e., in Euclidean geometry). Because in Pac-Man (as in Carol) the sprites move on a two-dimensional grid, this is fine: They can't really travel like a crow, so being shorter in that manner does not really help. The solution to ambiguity in Carol is even simpler than the rest: we choose the first exit, counting clockwise, starting from North. In practice, the selection is done like this: Starting from North and going clockwise, compute the Manhattan distance. Store this direction as the most likely candidate. Move to the next direction and compute its Manhattan distance. If it is lower than the stored one, replace it. Continue until all exits are exhausted. In the end we have the shortest one or the first one found of multiple paths with the same shortest distance. I believe Pac-Man treats step #4 in reverse: instead of keeping the previous one if they are equal, it picks the new one. Thus, it gives preference in this order: West, South, East, and North. Carol prefers the other way around. :) That is actually true. Because of the way the targeting works, the player can position Carol in such a way that forces the Snowman to go around in a rather tight loop. The Snowman is always trying to get to Carol, so if he is behind a particular configuration of walls and Carol is in the opposite end, he will try constantly turn trying to find the shortest path, and finding always a wall in his way. I thought of various ways to break this loop and force the Snowman to move out of it, all of them requiring invasive changes to the elegant targeting mechanism. However, in the end I decided to leave it alone. In practice, this only happens when Carol is standing idle in a particular corner. The moment Carol moves out of that spot the Snowman will go after her and break out of his loop immediately. Therefore, this will only happen when the player is essentially not playing the game, so why do we care? In order for him to actually complete the level, he'll have to move Carol sooner or later, and the Snowman will follow suite. If the player just stays there, let them get bored to death just staring at the Snowman go round and round. :) Here's an old example from when Joe and I first found the issue: I view it not really as a bug, but more like the Snowman is lurking, waiting for Carol to come out, so he can pounce on her. Here's another example I mocked up to describe the problem. There's actually a present where Carol is standing, so picking it up will cause the Ghost to immediately turn towards Carol, colliding with her. This results in all the presents being reset, which will cause Carol to pick it up again, only to have the Ghost turn right around towards her and hit her again. Over and over, this goes on until the player moves out of the way and lets the Ghost go somewhere else. These are very old issues discovered with the targeting mechanism. Like I said, in practice, they turn out not to be a big problem. Once the player gets bored of watching the enemy loop, he'll just move Carol and continue. :) -dZ.

If you are interested I could help with some simple ideas for AI. :) -dZ.