jrok

My Nigerian business partner told me this is totally legit.

Atari Video Chess is also a disgusting cheater. If you're not keeping track of the board on the side, it's possible to get reamed by an impossible move and not even notice. A totally safe piece will be captured, and you'll sit there wondering "how in the world did I miss that?" The answer is: You didn't. You got jacked. After 30+ fair and gentlemanly moves, Video Chess decided to mug you and dump you in the river. The one thing I am curious about is if these "magical moves" were programmed on purpose to enhance the "challenge", or if they are simply the result of genuine bugs. Either way I'd be fascinated to hear Whitehead interviewed about this subject.... preferably while being waterboarded. :x

Yes, that's my understanding too. That's also what I assumed. But I am currently using a 32x24 playfield in my project, and when I've tried to write to the playfield using *any* of the wXXX vars, nothing happens. There aren't any "pfclears" or anything else taking place before the drawscreen, either.

Thanks for that, RevEng. I guess I'm mainly fuzzy on the difference between the redefs in "2600basic_SC.h" and "superchip.h". They appear to be using different memory locations, and vars 0-47 don't appear to use superchip memory locations at all. Is that because those named vars are replacing ones formally used to store the playfield in the standard kernel? I suppose the big question I really have is this: In the version of the standard kernal modified for the superchip, are named variables var0-47 and w/r000-127 all free for use by default, and what (if anything) limits their usage (other than the obvious read versus write restrictions of the latter)?

I think I am a little confused about the way superchip memory is managed, particularly when it comes to the naming convention used and RAM playfield data storage. For a long while now, I've been working under the assumption that var0-var47 were the named variables representing all the memory available after the 32x24 playfield was stored in SARA RAM. But then this morning I read this: Which are the read and write addresses that this extra 32 bytes of memory correspond to? I noticed that the values defined in the superchip header seem to all be accessible, but I'm not sure how they correspond to the named variables 0-47, or to the RAM playfield. When I experimented with some of the named variables (w000-127, r000-127) I've yet to find a conflicts with the named vars 0-47. Is there a superchip memory map that illustrates the differences between var0-47, w/r000-127, and the RAM superchip playfield? Sorry if this is a dumb question, but I just can't seem to figure it out, and am afraid I'm not even thinking about it in the correct way. Thanks in advance, Jarod.

I really like the look and feel of the blob creature. It's a simple design, but it has a lot of personality (the eyes and the idle animation are nice touches.) The scrolling platforms are an interesting mechanic. One suggestion I have is to incorporate fixed-point math into the jump function to simulate momentum and gravity. A debounce for the button might be nice, too. Perhaps holding down the fire button can build up momentum for a jump, then the jump is executed when the button is released. In other words, the player could tap the button for shorter jumps and hold and release for longer/higher ones. A really nice start! Jarod.

http://www.youtube.com/watch?v=6CCOufrvFBc http://www.youtube.com/watch?v=kL_S5POJbns

I guess I'd disagree with that last bit. I tend to think there's a pretty big difference - technically, philosophically and in every other way - between porting games between platforms with compatible display capabilities and doing a conversion to a legacy platform. I imagine there are a whole bunch of wheels being re-invented in the latter.

These are all excellent points. Someone made a sculpture analogy earlier to describe Oystron, and I also think you could compare a great port (Lady Bug, Thrust, Medieval Mayhem, etc) to a great Rembranbt painting. Using an easel, a brush and primitive oil-based pigments, Rembranbt was able to vividly reproduce people, places and scenery in an awe-inspiring way. It seems to me that designing an accurate raster arcade port for the VCS is probably far more challenging and difficult than designing an original game. With an original game there is less overt pressure to invent or learn new techniques in order to surmount technical limitations. You could simply scale back or eliminate features that are beyond your prowess. But designing a fun new game mechanic is a separate challenge from designing a display kernel that can simulate an existing one. They are both challenging in their own way.

It may also be a byproduct of the culture at large. For at least the past 15 years, producers have focused their efforts on recycling TV shows, films, comic books and video games based on proven intellectual properties they already own or license, rather than take risks on untested material. This seems completely relevant in terms of their world. The science of marketing has grown tenfold over that period in step with the speed of information processing, and nobody wants to be known as the person who took a big-budget risk on a colossal flop. When it comes to homebrews, there might be some runoff. It's strange, but the dynamic probably isn't even as different as it seems on the surface. None of us are working with massive budgets and teams of producers, but the sheer amount of personal time a programmer invests in finishing a game for a classic system is probably tantmount to this. And a flop of a homebrew could be more deeply and personally disapointing then the multimillion dollar movie that tanks on its second weekend. Even if it's just a hobby, who wants to spend hundreds if not thousands of hours of their lives creating something that nobody wants to play and enjoy? Setting out to make a accurate port for an extremely limited console requires tremendous knowledge, resourcefulness and creative problem solving. But designing an original, popular game purely from your imagination is probably even more challenging, even if it's just with a deck of cards or a rock and a stick. Not only is there the whole matter of "there's nothing new under the sun" to conquer, but if people dislike your game then the whole damn thing is your fault.

I'll run it by my lawyers and get back to you. I mean, it's not that i will be selling my (no existent, yet) version (if i wanted to, i'd definitely get your permission before so), it's just a remake of the game, like how Activision had different people remake there games for other systems. The game is pretty far from finished. In it's current state it is still a pretty simple concept: "Shoot the Guy!" I guess I can't really stop anyone from making a similar game about shooting-various-guys.

The funny thing is, the phenomenon the article describes is a form of emulation, which to my mind is pretty much the point of Stella development . It's not "nostalgia" so much as it is getting the game to mimic the presentation and logistics of the hardware it was originally designed for... which included the CRT . But you could do much of this stuff by simply screwing with your LCD settings. It sort of like when you mentioned the variance in phosphor sizes and retention. People forget that the human eye is an important component in this system. "What about emulating bigger sets?" Well, move closer to the screen As for DVDs, that is a matter of compression that occurs during media translation, compressing hi res source frames to fit onto portable media. Its a practical concern, not an aesthetic one. Perhaps the more apt analogy is comparing a Gauguin still life to a Rembrandt. Rembrandt's style had sharper definition of line and form than Gauguin's.. does that mean his still lifes were superior? Jarod.

I think you're missing the point somewhat. Programmers were, to some degree, exploiting the CRT's phosphor display to the benefit of their games, not trying to figure out a "way around it." The example of Enduro's sunrise and tires is a perfect example, although there are many others. Some of the effects were intentional, while others were likely happy accidents. The analogy of 35mm film versus digital video is probably a better one. I know many movie buffs who prefer film precisely because of it's "imprecision", with it's chemical bleed helping to meld disparate frames and present a more dreamlike illusion of movement. You could make a pretty good argument that the CRT was an important component of the VCS as a medium. Jarod.

I'll run it by my lawyers and get back to you.

But that's exactly what SeaGTGruff's modified superchip kernel lets you do. When you set the constant "RAM_PFcolorandheight" the playfieldcolorandheight table is accessed in RAM instead of ROM during assembly.

I'm not sure what you mean by this. Michael's demo certainly contains multiple playfield definitions. That was pretty much the point of his project there, from what I could grasp.

Thanks for explaining about the player colors. No problem. And remember, its not as if all that RAM is "gone" just because it's used it to color the sprite rows. I can still use a-thru-p to store temporary values before the sprite coloring subroutine is called. Have you checked out Michael's superchip RAM sprite demo?

I think it looks real good! It might be interesting to see what would happen if you incorporated great Michael's copy-to-RAM method as an experiment. I know that you would necessarily have blank lines between your playfield rows, but that might not necessarily be a problem given that you can define multiple heights. Cheers, Jarod.

Maybe that was worded badly. What I mean is, I'm storing the color table of the player1 sprite in RAM rather than writing it to ROM. I've reserved sixteen RAM colors (p1color_row1 -thru- p1color_row16) that coincide with the 16 lines of a gladiator's shape data in ROM. For instance: dim p1color = a dim p1color_row1 = a dim p1color_row2 = b dim p1color_row3 = c dim p1color_row4 = d dim p1color_row5 = e dim p1color_row6 = f dim p1color_row7 = g dim p1color_row8 = h dim p1color_row9 = i dim p1color_row10 = j dim p1color_row11 = k dim p1color_row12 = l dim p1color_row13 = m dim p1color_row14 = n dim p1color_row15 = o dim p1color_row16 = p For general purpose, I could use this to define to color of each row as a hex or decimal number (i.e. "p1color_row4 = $CA" or "p1color_row4=202") and to perform color transformations in RAM (i.e. "p1color_row4=p1color_row4+2"). But for practical reasons, I reserved an additional three pointers for palette swapping. dim body_col = var13 dim head_col = var14 dim hair_col = var15 That way, I could just retrieve one color for an enemy's outfit, then perform the gradient color changes (1) dynamically (2) only when necessary. For instance: body_col = $D4 head_col = $EA hair_col = $66 p1color_row1 = body_col p1color_row2 = body_col p1color_row3 = body_col p1color_row4 = body_col + 2 p1color_row5 = body_col + 4 p1color_row6 = body_col + 4 p1color_row7 = body_col + 6 p1color_row8 = body_col p1color_row9 = body_col + 2 p1color_row10 = body_col + 4 p1color_row11 = body_col + 4 p1color_row12 = head_col if sprite2dir = 0 then p1color_row12 = hair_col if sprite2dir = 1 then p1color_row12 = hair_col if sprite2dir = 7 then p1color_row12 = hair_col p1color_row13 = head_col if sprite2dir = 0 then p1color_row13 = hair_col if sprite2dir = 1 then p1color_row13 = hair_col if sprite2dir = 7 then p1color_row13 = hair_col p1color_row14 = hair_col p1color_row15 = hair_col p1color_row16 = hair_col I've been reorganizing and squeezing things down this week, and have found a bit more RAM. I think the "ideal" situation would probably be to define the final five rows of player1's shape data in RAM as well, to free up some additional ROM in my last bank, while adding additional flexibility to the player1sprite. Cheers, Jarod.

Some people claim that Joust was "cooperative", but whenever my brother and I jammed on that game in the arcade, it was Deathmatch City.

That's an easy choice.... "random." I remember the random maze generator you made awhile back. Are these randomly drawn, or does it select from a set number of mazes? Or is it more that random quadrants are selected and assembled? Anyway, nice start. Jarod.

Well, not really. I reserve 19 vars to color player 1. Then there's four to track the XY positions of the two flickered players, four more to store their last known XYs and another four to track their playfield positions. Two more to track the direction each sprite is facing, and one to track the current animation frame of the sprites. So that's 34 variables right there just to get multicolored gladiators moving around the screen. From what I understand, M1 is what is used to color P1, with the color change defined every other scanline, so when you enable the missile it will color all the pixels at the missile's X. It does rather look like a mirror or reflective surface. What I am curious now about is whether we can restrict the enabled m1's display to the player's height (minus it's Y). In other words, I'm curious if we could turn off the missile below and above the P1 sprite, before a drawscreen or during the vblank. Something like this might look a little like a shield: Sounds cool If more Vox's go on sale, I might pick one up as a Christmas present to myself (along with Juno First). Cheers, Jarod.

Yes, and for a level of polish it would be nice to customize your costume as well (as long as I can reserve three variables for this). I haven't really looked into Vox in depth yet, let alone a bB implementation. Have you experimented with it at all? Yes good point, Maus. Right now I'm reorganizing my memory allocation to allow for something like this (I was using the missile variables to store other values, mostly because I was lazily assigning variables to to stuff that would be better suited to bit operations). Missile0 would indeed be a very useful object to bring back into play. Cheers, Jarod.

Yes, it's still Batari BASIC. I'm flickering at my sprites at 30hz and duping/flipping some sprites, which probably accounts for what appears to be more detail. I believe these pictures pretty fairly represent what most people will see when they play the binary in an emulator, and particularly if they set the phosphor effect in the game's "Game Properties" menu in Stella or in Z26's Configuration>>Video settings. Even without phosphor set, the flicker doesn't seem terribly noticeable to me (except maybe for the left and right shield zones, which I could probably resolve by just flooding PF0 every frame, instead of every other frame).

Given the concept (which I think could be pretty neat) one thought I had was that, although the action takes place in various time periods, perhaps it could all take place in the same, well, "place" (as in the "Back to the Future" series.) As the players time travel, they can see how the various areas they explore change and evolve over time, so that there's always that element of familiarity balanced with something new. It could make for some interesting logic puzzles too, where certain actions you take in the past directly shape and effect the future time frames. You thwart a plot to assassinate the mayor in 1926, but when you jump forward to 1952 you find that he went on to become a ruthless dictator, with posters of him hung everywhere like Kim Jong Il. Or maybe you nuke a massive boulder in the Paleozoic era, allowing settlers in the 1600's to expand into an area they otherwise would have avoided. Or how about if you travel back to the middle ages and trade a modern 21st century device for something you need in the moment, like a bow and arrow, accidentally sparking the information age a few centuries too early. You return to the "present" and instead find a bizarre "future" that merges medieval culture with sci-fi technology. I realize this sort of mechanic would get a little hectic if taken to its extremes, but it might be an interesting way to approach design, with the world dynamically changing according to the actions of both you and your enemy. It would also provide some opportunities for humor, I'd imagine, with recurring characters popping up as "ancestors" throughout every time period: "Bob Johnson" is a bastard in the Middle Ages, the Renaissance, the Industrial Revolution and the Space Age... Bob Johnson is, has been and always will be a bastard.