jrok

Is "pfcolors & pfheights & background" really a legal kernel option set? It sounds to me like the normal pfcolors statement is substituted to color the background. If that's the case, then how would you define the color of the playfield rows?

Well if the conversation really is about aethetics, than I agree 1000% with this statement. There isn't, nor should there be, one "style" of artwork that should prevail over others. If that was the case, we might as well play all those dull modern games that brag about pixel shaders and polygon counts. What looks like an attractive presentation to one player might seem hideous to another (i.e. the "Imagics barf-fest"). If I like Rembrandt and you like Picasso, who is "right"? I work in the animation industry, and part of the reason I was drawn to Atari programming was the challenge its of graphical capabilities. I wanted to see what I could do with extremely limited resources, and if I could make use it to make graphics and animation that I was proud of. I can accept the fact that some other programmers think that this approach is "lame" or "missing the point"; it probably is. But I didn't get into this hobby to seek approval from anyone, so I'll probably continue to hog ROM space and cycles to try to make more detailed graphics. As far as gameplay is concerned, my wife and I own a first-edition Xbox, but I don't think we've played any games on it in a few years - we mainly use it to watch DVDs. The games seem to be all genre cliches, or limited variations on a theme. They tend to be "Terminator vision" games, where you run through a cheesy Hollywood script with a H.U.D and unlimited saves/continues, beat'em versus games that feel like you're in a typing class and the other player is punishing you for spelling mistakes, or sports games that are so "realistic" that they make you want to watch real sports instead. The same goes for "survival horror" games... if I wanted to watch stilted dialogue and gory ketchup-fests, I'd kick back with a bottle of Jim Beam and a copy of "Nightmare on Elm Street." At least that way I don't have to perform gymnastics with my thumbs while watching a crappy movie about zombies. Classic games that rely on one or two strong mechanics are more interesting to me. They have exploits and easter eggs and strategies to be discovered, and they give you that old arcade cyborg feeling of trying to master the machine. I like games that test your reflexes and patience, while gradually ramping up the difficulty. I also like games that have a few mysteries in them and offer you something new every once in awhile as a reward for getting good at the game.

Okay, I'm responding as both a boxing nerd and an Atari nerd. First of all, I think that from both a technical and creative standpoint, the game is outstanding. The use of color and shape is top notch, and the presentation in general is polished and professional. Besides that, the overall rhythm of the game is near perfect, with a real tension that I think could be enhanced by more use of sound. The A.I. and automata jibes pretty good, although I think the "expectation" of certain behaviors might need to be counter-balanced. There's a bit of a top-down space invaders feel to things right now, where the opponent acts as a moving boundary. As others have suggested, a shove function might help to make the game feel more physical. Ring generalship and imposing your will is part of boxing, and it would be nice to have a feature that simulates moving your opponent into a place you want him to be in (of course, the opponent should be able to do this as well). It may be a little late in the game to experiment wih something like this, but what if punches were activated when you "released" the fire button, rather than when you rocked the joystick left or right with the button. The notion of having to lock in place when you punch seems counter intuitive to me... it's sort of like the old boxing axom "letting your hands go." More fluid movement might equal more nerf-free fun. You could even "store up" a punch this way, differentiating between jabs and power punches by the length of time the button was held. If you hold too long, the power meter could reverse or recycle to zero, to reinforce the timing factor. Whether you implement the above or not, it seems like there are a great deal of "empty" inputs. Atari can manage at least 17 (8 directions + 8 button directions + button w/no directions). For instance, how about body punching when you hold down-right or down-left, head punching when you hold up-right or up-left and blocking high with button+up or blocking-low with button-down? Could really diversfy the challenge Keep the final opponent a secret! Also, if possible, it would be nice to see a "randomly generated" opponent after the second or third loop... random color palette, random behavior nodes but increasing speed/power. Anyway these arent' really criticisms, because I think your game is great! I'll play it either way. Cheers, Jarod.

Latest version: I've incorporated a limited amount of Z-depth scaling of the treeline... it might look better with a higher playfield resolution. Knight_Rider_1_14_09.bin Cheerio, Jarod.

Hi Michael, I have two quick questions about your superchip version of 2600basic. From what I can gather, it is using var28-47 to store the colors and row heights for rows for ten rows if the RAM_PFcolorandheight constant is set, with the rest of the superchip RAM available for general use. If I wanted to increase the pfres and number of rows stored in RAM to 12, could I use these to do it instead of, say, using $F1-$F4? I mean, if I didn't want lives or pfscores. What about $F6-$F9 in the stack? Also, would I have to reserve new rows in 2600basic_SC.h, or could I DIM them in my bB file? And if I did the latter, would it just use up consecutive variables (i.e. $A6, $A7, $AA...). EDT: And if I dimmed them, would I dim them consecutively (i.e. var0 = pfrow11height, var1 = pfrow11color, etc). Thanks, Jarod

Great question. I've been trying to experiment with blank lines in a project, without much luck. Is there a good thread that explains how blank lines operate in the bB kernel? Jarod.

Is that like, the conquistador conquers you and then... keeps rearranging your furniture? Or is it... uh... Oh. Yikes.

How about "Alpha Male!" Or "Ultimate Primate" "It's a hawk! It's a comet! No, it's..." ...aw, nevermind.

No way would I ever try to sell this. This would be a BIN only (although I'd maybe make one vanity cart for myself). My best friend is an assistant director in DC Comics licensing division, and she would be the first to tell you that DC (well, actually their parent Warner Bros. Entertainment) would sue-sue-sudio the pants off of you if you tried to make a dime off of their intellectual property without a license. Marvel isn't much better from what I understand. IIRC, a couple of years ago they sued NCSoft for allowing players to design costumes that resembled some of their characters. Apparently, some kid made a big green avatar that sort of looked like the Hulk, then had the audacity to name it "The Hulk." Of course, Marvel's legal department immediately inflated to three times their normal mass, burst out out of their $5000 Brooks Brothers suits and began rampaging the NCSoft server farms with orders of injunction. I suppose Marvel was within their rights to pursue legal action. But then again I gave my nephew a deluxe box of crayons for Christmas, and he used it to draw a picture of Spiderman. If he writes Spiderman on it, does that mean Marvel gets to sue Crayola??? Anyway, no money-making scheme here. I just like Superman (and did NOT like the original flickering candlelight version for the 2600) so I thought it might be cool to give it a whirl, John Williams score and all. Cheers, Jarod.

IIRC, Blaster Master was pretty easy, as long as you knew the PAUSE trick.

I totally agree. In fact, I think I wrote something similar about Demon Attack and its ingenius use of color in my AA blog. Since the A2600 graphics capabilities are so spartan, I think use of color becomes incredibly important. And in Demon Attack, not only was the use of color aesthetically pleasing, but it served the gameplay mechanics as a sort of visual cue for progress. As you progressed through the game, you didn't have to "count levels"; it was like your eye would almost subliminally track colors and shapes that your brain would use to gauge your performance. For that reason, I still believe that Demon Attack was graphically superior to most RGB-raster arcade shooters of that day, including some of my all-time favorites like "Galaga." Great point! Jarod. I disagree completely. I think if you are playing Atari 2600 games in the year 2008 because they have "awesome" graphics, then you are wasting your time. IMO what makes VCS any retro game worth playing is the gameplay.....Graphics mean nothing. Gameplay means everything. Well, if you check my post, I wasn't talking about "eye candy," but rather how graphics can be integrated as a formal element of gameplay. In Demon Attack, the re-combination of color and shape tables in the enemies and their missiles was informative to the current game state, which was pretty unusual back in the day even in the beefier raster arcade shooters. So, I agree with you as far as aesthetics being meaningless (and, indeed, Imagics "barf fests" aren't everyone's cup of tea). But graphic design in general is important insomuch as we are designing games for a video display. For me, that means that basic graphic design rules such as "form equals function" shouldn't be thrown out the window... unless of course the number of cycles prevents it. Yes, but could you get to level 83 that way??!! LOL, I personally love Demon Attack AND Adventure, but for different reasons. But to be fair I have some pretty weird tastes when it comes to the VCS... Artillery Duel is also one of my favorite games. Love it when those little army guys come marching out to drag your corpse away, heheh. Cheers, Jarod.

Whoa, we can count hours testing our homebrews??? Circus Galacticus - 40 hrs Honestly though, we probably shouldn't count our own games.

This is shaping up to be a fantastic game! I'm a big boxing fan too, so I can't wait to get my mitts on this little beauty. Cheers, Jarod.

The colors look really nice this way. Although I'm not sure about the galloping effect, I mean, the horse is galloping, not the camera, right? Thanks. You may have a point about the camera. I guess in my head the camera was a steady-cam that had a fixed focus on the horse, rather than a camera dollying along beside. I agree though that is a very weird camera... I'll come up with an alternate treatment after work today. Cheers, Jarod.

Does anyone know if there's a way to modify the standard kernel to include blank lines in PF0? Thanks in advance, Jarod.

New version: Thanks to assistance from Michael Rideout, I'm now storing my playfield colors and rowheights in superchip RAM. With the ability to redefine heights and colors on the fly, I've tried to work a bit more on the "galloping" effect of the perspective view. Now, the camera rolls up and down in time with the horses feet when you are moving vertically, and the color gradient of the terrain shifts as it moves into the foreground. (I've ommitted the soldier line for now while I'm sorting out the camera angle.) Knight_Rider_1_12_09.bin Cheers, Jarod. EDT: An alternate title: "A Knightmare on Helm Street"

Thanks Nathan! I still can't seem to resist the lure of 8-step, but the more I work on this the more I'm guessing I'll probably have to trim everything down to 6 FPS to fit all the enemy sprites in. Cheers, Jarod.

How are you compiling? Are you using 2600IDE, Crimson Editor, Visual bB, or something else? Michael I started out on Crimson, but for the last few weeks I've been using VisbB. I think that there is a step in the batch that cuts/pastes the final BIN to my output directory, and that for some reason that final step is being cut off, but so far I can't figure out where that's happening. Thanks again for the help, Jarod.

That's actually a great name for it. How about "Is That A Lance Or Are You Just Happy To See Me? Yeah it sort of does. It's not finished yet. Ultimately it will be rolling hills over a sky that changes color. Uh, hopefully... Pretty much. In my head it sort of plays like a sideways, 3Dish version of Space Invaders, where you have to kill ranks of advancing soldiers and knights while dodging dragon fire and sorcerors' spells.

Ahhhhh... my apologies, Mr. Rideout. I just realized that, despite the "compilation Failed" report, it actually did compile... just not where I expected it to. I was looking for the BIN in my default compilation directory, but for some reason it created the file one level up (in the same folder as my source). Thanks! Jarod.

I just downloaded my original files (from post #1 in this thread)-- just in case I'd made some changes on my computer since then-- and then I recompiled the sample, using the bB v1.01 compiler and DASM v2.20.07. It works fine for me-- but you *will* get a lot of "errors" when it compiles: ---------- Capture Output ---------- > "C:\Atari2600\bB\2600bas.bat" "C:\Atari2600\bB\Projects\test_pfcolors_with_pfheights_SC_0.bas" batari Basic v1.01 (C)2005-2007 User-defined bankswitch_SC.inc found in the current directory User-defined banksw.asm found in the current directory 2600 Basic compilation complete. User-defined superchipheader_SC.asm found in current directory User-defined std_kernel_SC.asm found in current directory User-defined startup.asm found in current directory User-defined pf_drawing.asm found in current directory User-defined pf_scrolling.asm found in current directory User-defined std_routines.asm found in current directory User-defined std_overscan.asm found in current directory User-defined score_graphics.asm found in current directory User-defined banksw.asm found in current directory User-defined 2600basicfooter.asm found in current directory DASM V2.20.07, Macro Assembler (C)1988-2003 bytes of ROM space left in bank 1 bytes of ROM space left in bank 2 2600basic_SC.h (68): error: EQU: Value mismatch. old value: $00a4 new value: $00a6 2600basic_SC.h (69): error: EQU: Value mismatch. old value: $00a5 new value: $00a7 2600basic_SC.h (70): error: EQU: Value mismatch. old value: $00a6 new value: $00aa 2600basic_SC.h (71): error: EQU: Value mismatch. old value: $00a7 new value: $00ab 2600basic_SC.h (72): error: EQU: Value mismatch. old value: $00a8 new value: $00ae 2600basic_SC.h (73): error: EQU: Value mismatch. old value: $00a9 new value: $00af 2600basic_SC.h (74): error: EQU: Value mismatch. old value: $00aa new value: $00b2 2600basic_SC.h (75): error: EQU: Value mismatch. old value: $00ab new value: $00b3 2600basic_SC.h (76): error: EQU: Value mismatch. old value: $00ac new value: $00b6 2600basic_SC.h (77): error: EQU: Value mismatch. old value: $00ad new value: $00b7 2600basic_SC.h (78): error: EQU: Value mismatch. old value: $00ae new value: $00ba 2600basic_SC.h (79): error: EQU: Value mismatch. old value: $00af new value: $00bb 2600basic_SC.h (80): error: EQU: Value mismatch. old value: $00b0 new value: $00be 2600basic_SC.h (81): error: EQU: Value mismatch. old value: $00b1 new value: $00bf 2600basic_SC.h (82): error: EQU: Value mismatch. old value: $00b2 new value: $00c2 2600basic_SC.h (83): error: EQU: Value mismatch. old value: $00b3 new value: $00c3 2600basic_SC.h (84): error: EQU: Value mismatch. old value: $00b4 new value: $00c6 2600basic_SC.h (85): error: EQU: Value mismatch. old value: $00b5 new value: $00c7 2600basic_SC.h (86): error: EQU: Value mismatch. old value: $00b6 new value: $00ca 2600basic_SC.h (87): error: EQU: Value mismatch. old value: $00b7 new value: $00cb 2600basic_SC.h (88): error: EQU: Value mismatch. old value: $00b8 new value: $00cc 2600basic_SC.h (89): error: EQU: Value mismatch. old value: $00b9 new value: $00cd 2600basic_SC.h (90): error: EQU: Value mismatch. old value: $00ba new value: $00ce 2600basic_SC.h (91): error: EQU: Value mismatch. old value: $00bb new value: $00cf 2600basic_SC.h (92): error: EQU: Value mismatch. old value: $00bc new value: $00d0 2600basic_SC.h (93): error: EQU: Value mismatch. old value: $00bd new value: $00d1 2600basic_SC.h (94): error: EQU: Value mismatch. old value: $00be new value: $00d2 2600basic_SC.h (95): error: EQU: Value mismatch. old value: $00bf new value: $00d3 2600basic_SC.h (245): error: EQU: Value mismatch. old value: $00a4 new value: $10d0 2600basic_SC.h (252): error: EQU: Value mismatch. old value: $00a4 new value: $10d0 Possible duplicate label: L08 d141 2292 bytes of ROM space left in bank 2 3601 bytes of ROM space left in bank 1 2292 bytes of ROM space left in bank 2 Complete. > Terminated with exit code 0. DASM should be able to resolve these "errors" by the time it makes its final pass through the code, in which case the compilation should end with the number of bytes free in each bank, "Complete.", and "> Terminated with exit code 0." What happens when you compile it? Michael I get the exact same output, except the compile fails, and no BIN is created. Instead of the exit code, I just get "2600 Basic Compilation Failed!" (see below) DASM V2.20.07, Macro Assembler (C)1988-2003 bytes of ROM space left in bank 1 bytes of ROM space left in bank 2 2600basic_SC.h (68): error: EQU: Value mismatch. old value: $00a4 new value: $00a6 2600basic_SC.h (69): error: EQU: Value mismatch. old value: $00a5 new value: $00a7 2600basic_SC.h (70): error: EQU: Value mismatch. old value: $00a6 new value: $00aa 2600basic_SC.h (71): error: EQU: Value mismatch. old value: $00a7 new value: $00ab 2600basic_SC.h (72): error: EQU: Value mismatch. old value: $00a8 new value: $00ae 2600basic_SC.h (73): error: EQU: Value mismatch. old value: $00a9 new value: $00af 2600basic_SC.h (74): error: EQU: Value mismatch. old value: $00aa new value: $00b2 2600basic_SC.h (75): error: EQU: Value mismatch. old value: $00ab new value: $00b3 2600basic_SC.h (76): error: EQU: Value mismatch. old value: $00ac new value: $00b6 2600basic_SC.h (77): error: EQU: Value mismatch. old value: $00ad new value: $00b7 2600basic_SC.h (78): error: EQU: Value mismatch. old value: $00ae new value: $00ba 2600basic_SC.h (79): error: EQU: Value mismatch. old value: $00af new value: $00bb 2600basic_SC.h (80): error: EQU: Value mismatch. old value: $00b0 new value: $00be 2600basic_SC.h (81): error: EQU: Value mismatch. old value: $00b1 new value: $00bf 2600basic_SC.h (82): error: EQU: Value mismatch. old value: $00b2 new value: $00c2 2600basic_SC.h (83): error: EQU: Value mismatch. old value: $00b3 new value: $00c3 2600basic_SC.h (84): error: EQU: Value mismatch. old value: $00b4 new value: $00c6 2600basic_SC.h (85): error: EQU: Value mismatch. old value: $00b5 new value: $00c7 2600basic_SC.h (86): error: EQU: Value mismatch. old value: $00b6 new value: $00ca 2600basic_SC.h (87): error: EQU: Value mismatch. old value: $00b7 new value: $00cb 2600basic_SC.h (88): error: EQU: Value mismatch. old value: $00b8 new value: $00cc 2600basic_SC.h (89): error: EQU: Value mismatch. old value: $00b9 new value: $00cd 2600basic_SC.h (90): error: EQU: Value mismatch. old value: $00ba new value: $00ce 2600basic_SC.h (91): error: EQU: Value mismatch. old value: $00bb new value: $00cf 2600basic_SC.h (92): error: EQU: Value mismatch. old value: $00bc new value: $00d0 2600basic_SC.h (93): error: EQU: Value mismatch. old value: $00bd new value: $00d1 2600basic_SC.h (94): error: EQU: Value mismatch. old value: $00be new value: $00d2 2600basic_SC.h (95): error: EQU: Value mismatch. old value: $00bf new value: $00d3 2600basic_SC.h (245): error: EQU: Value mismatch. old value: $00a4 new value: $10d0 2600basic_SC.h (252): error: EQU: Value mismatch. old value: $00a4 new value: $10d0 Possible duplicate label: L08 d141 2292 bytes of ROM space left in bank 2 3601 bytes of ROM space left in bank 1 2292 bytes of ROM space left in bank 2 Complete. 2600 Basic compilation Failed!

Just curious if anyone was ever able to get Michael's sample program to compile. If so, what versions of of bB and DASM were you using with his superchip kernel mods? I've tried several combinations of both without any luck. Thanks in advance, Jarod.

Well, since this is being programmed for bB, why not aproach a bB porgrammer for music. For example, Chris Reade (atari2600land) composed a simple but very good version of "Greensleeves" for his game "Jack and the Bean Stalk." As long as he doesn't mind it being used, he has posted his bB source in that thread. Jarod

I don't understand why we are contacting anyone about contributing music. There isn't even a workable demo yet... just a "brand name." Why not just throw any simple song in the engine and attempt some gameplay... even "Mary Had a Little Lamb" would do for now.

Okay, now that I got my bad Knight Rider joke out of the way, here's the real deal on this game. The gameplay will take place on a medieval battlefield. Your mounted knight will knife through the enemy ranks like a runningback, slashing at footmen with his sword and jousting enemy knights he comes across. The movement is 3D-ish, although the gameworld isn't a contained space right now, just a limitless, axononmetric plane. In this build, I've included a sample sprite of a line of enemy soldiers that respond to the movements of the gameworld. They are also an "eternal" line for the time being, but the goal is to pull array data that determines the length and depth of each rank. I sorta like the effect so far, but it would be much better if I could turn the battlefield into a gradient plane (i.e. playfield lines become brighter as they get closer to the foreground). Right now I'm trying to figure out a way to store both the playfield rowheights and colors in RAM. If I could do that, I may even be able to incorporate scaling horizon elements, which could be sort of cool Latest version: KnightRider_1_10_09.bin