jrok

Okay, I've tried a simple walk cycle with my model. Left or right joystick input cause her to walk in either direction, including an 8-frame turning animation when swtiching directions. It was just too awkard to draw simple clothing on this experiment, so in order to PG it somehwat I've only used the rear 180 for turning and have turned her skin to uh "marble." The animation still looks a little "Mr. Roboto" so it needs work, but I thought I'd post some progress. FHuman_turn_walk.bin On a side note, I'd love to see some other ongoing 2600 graphics projects on here if possible. I've gotten a glimpse of some really artsy stuff by some AA members over the past few days, and would love to see a real 8-bit art thread come to life! Cheers! Jarod.

That's not geeky! That is COOL!!!

What parts are confusing? What are your specific questions? Jarod.

Hey, Porky's had nudity, and that was even sold in 'ordinary' stores. Heh, yeah. Although it's a little unfair to call those lego blocks "nudity." Maybe we need to come up a new term for that stuff. Crudity?

If I understand you correctly, you're asking how "wide" a sprite can be? The quick answer is that each of the hardware sprites can be 8 pixels wide (no limit on height). If you are using Visual bB's nifty sprite editor, you probably noticed that the editor allows you to set the width anywhere from 1-24 px. But this is really only for "planning" purposes, since the max hardware resolution is 8 px. Using NUSIZ0 or NUSIZ1 to make the sprite double or quadruple wide will "stretch" the image (pixels are rendered at 2x or 4x wide), but won't allow for a higher resolution. If you want to create the illusion of a higher-res sprite with bB, AFAIK you have to do one of the following: 1) Use both the player0 and player1 sprites to create each half of the image. You can then line the sprites up on the same vertical position, and have them move together, i.e. player1x = player0x + 8 : player1y = player0y 2) Same as above, except use 30hz flicker, so that on the even frames a player sprite displays the left half of the "big sprite" and on odd frames it displays the right half. i.e. frame1 player0x = x gosub ShowLeftSide goto frame2 frame2 player0x = x + 8 gosub ShowRightSide goto frame1 The second method is *probably* preferably for in-game graphics, since method one would use up both sprite objects and leave you with just the ball if you are using multicolor sprites. I've been experimenting with some higher res graphics over at Homebrew Discussion if you want to check it out. Its basically "method 1" but if I was going to make a game out of it, I'd probably convert it to method two. Cheers, Jarod.

I'm a big fan of the arcade game. I remember making it to the third loop one time, and getting KO'ed by Glass Joe. How humiliating.

Spread? And sum tekkno music for it. Yuuppeeeeaaaaa!!! LOL. Okay, I'm beginning to think now that it was a mistake to make this a "nude study." I better draw some clothes on this girl right quick... the vultures are circling

I think I get what you are saying. A rough display could be cobbled together using the score objects and the playfield graphics, so certainly this would be possible - although the cost in ROM would be be intense for something that is virtual to gameplay. I've been looking into ways to store player shape tables in the SARA RAM instead, which could open up a lot of graphical opportunities... if it were possible. I guess I tried to start a thread about graphics because it's the last thing folks think about when they think of the 2600. I vividly remember those CV and IV commercials from when I was a kid - even before our family had a 2600 - that would tout "better graphics." But as I get older, it occurs to me that better graphical "capability" doesn't always equal better graphical "sensibility." Graphic experiments will probably seem absolutely insipid and beside the point to a lot of AA programmers, but I am curious how much of the grpahical limitations of 2600 were due to hardware limitations as opposed to limitations of imagination or the imposed restrictions of the business model. I agree, but I think "can" is the operative word there. I think it is possible, but then the question becomes whether it's desirable, and what you would have to give up. The 9/18 interactive frame loop I've attached here consumes 2500 bytes, which, while massive, still renders the illusion fairly well. If they were going to consume that much space for this animation,most programmers would want it to be at least be constant, if not vital, to gameplay. A walking cycle for one of 9 possible facing directions would be impossible to pull off in 4k ROM, while some sort of rails movement (surfboard?) might be doable. I guess it's all about decisions, which is proabaly why most programmers leave graphics and polish for the end of development. Thanks for the input! Cheers, Jarod. FHuman_360_9f_interactive.bin (Joystick Left and Right to turn character)

Thanks! The text is no problem. I would probably use the score graphics. As for several characters, I guess it depends on what "several" means. I suppose you could get two different figures in there at 30z, but there wouldn't be room for much else. Even the 17-frame version I posted gobbles up almost an entire 4k bank. I just made a 9-frame version of this animation that *might* be suitable for use in a bankswitched game, although I'm a little foggy on what kind of a game can be made with a character whose arms are basically glued to her sides. Sun-Tan Simulator? Riverdance-Dance-Revolution?

Hi, I've been using VisbB for about a month now, and its really a great IDE. I'm finding it makes bB development a breeze. Thanks for all your hard work on this! I have one feature request, and it may seem like a sort of bizarre one. In the Sprite Editor, we are given the option of creating sprites that are larger than 8px wide. I assume that option exists for those of us who are using two or more adjacent hardware or virtual players to create larger, more detailed sprites for title screens or even in-game elements. I've done this a few times, and its quite a painstaking process. The way I've been doing it, I have to copy and paste the sprite data into my program, than go line by line deleted the appropriate sprite bits from each player instance. For a large single sprite, this isn't a huge hassle. But for multi-frame animations it becomes incredibly labor-intensive, and if you decide to make any changes to individual frames, you pretty much have to edit the original "large" SPR file and manually split it all over again. Would it be possible to develop a Sprite Action that took such 9+ wide sprite and autmatically split it into consecutive "sub-sprites" at 8px intervals? Basically, if we have a 32 pixel wide Sprite saved as "Big Spaceship", and click "Split", VisbB would generate, save and open four 8px wide SPR files called "Big Spaceship_A" "Big Spaceship_B" "Big Spaceship_C" and "Big Spaceship_D," which we could then insert into our programs? Anyway, thanks again for great toolset. Cheers, Jarod

Okay, I finished the figure. Shes got legs, but she doesn't know how to use them. Seriously, I am trying to keep this a 4k, 18/36 frame animation, but as it stands I had to cut back to 17/34 frames for the time being. If I have any chance of getting this the full 18 frames to fit in one bank, I think I might need to make her shorter. FHumanFull_360_17f.bas.bin Cheers, Jarod.

Thanks!

I'm not going to comment on the changes too much, since I loved the original so much. I'll assume that the 'nerfing' elements do work well for critics who want their blankies, but thankfully none of the intense goodness of this game have been lost in translation. This is a GREAT, HARD game, in the tradition of great coin-gobblers like Defender and DK, but without the one-armed bandit aspect of having to feed a quarter in every forty-five seconds. I love the polish and professionalism of this game. As far as I can tell, it is one of the most unsung homebrews in terms of relative greatness. It really harkens back to the days when individual virtuosos, not giant corporate hives, ruled the gaming world. BTW I think this new version is begging for a HSC '09 competition, just to see what everyone can do with the nerfed gates. My trigger finger is ready.

It must've been the same bastard that painted her hair the same color as her skin. But, seriously I considered putting, you know, details in this experiment, but I was sort of worried it might be taken the wrong way. This is more about trying to simulate the movement, really.

I already put them back. Cool graphic demo. Thanks.

(*I really didn't know whether this was the proper place to post this, but none of the other forums seemed to quite fit.) I've been experimenting with 2600 sprite graphics for the last couple of months, and yesterday I decided to try to see how "realistic" a depiction of human figures I could achieve working from scratch. So far it's been pretty fun (if painstaking), although I'm not sure if any of these experiments will ever be useful for games. Anyway, the first challenge I set out for myself was to try to animate a figure turning 360 degrees in 36 frames. The camera angle here is straight-on (perpendicular to the model). The animation is composed of an adjacent P0 and P1 that progress through 18 frames. The model is symetrical, so at frame 19, the sprites swap positions and flip reflection properties to complete the remaining 18 frames of the movement. Only the top two-thirds of the figure is visible now, so I think the next step for this binary would be to complete the figure's legs, and add some user control to the direction and velocity of the turning movement. Although feedback would be much appreciated, the other reason I started this thread is because I noticed that - while there are some really spectacular artists here - there doesn't seem to be a forum dedicated to the topic of retro graphics in particular. Like a lot of people here, I'm mainly drawn to classic gaming by the notion that gameplay, not graphics, is king. But, also like a lot of people here, I really like seeing graphic artists and animators challenge themsleves with the limited tools of older hardware. It would be nice to have a place at AA for 8-bit animators and graphic designers to showcase their stuff, share ideas and talk about techniques, tools, etc. Cheers, Jarod. Important: Although there's nothing pornographic or explicit about the attached animation, I suppose that the figure is technically a "nude." So, if that sort of thing bothers you, please don't download the binary. EDT: I think the illusion works better at a higher framerate FHuman_360_v1.bin

...Yet. But San Francisco has top men working on it. Top. Men. http://workplacebullying.org/press/SHRM092007.html

First thing, don't even worry about the interface or the current display. In fact, pretend they doesn't exist for now - erase them if you must!!! Here's why... In order to make this program function the way it ought to, there are several relationships that you must create. But rather than trying to tackle them all at once, I suggest that you create the game one component at a time. Start by creating a relationship between song's tempo and the fire button, and try to make the following simple game: Create a conditional statement that sets the volume (AUDV0 and AUDV1) to either the current value in musicData or to zero. The conditional statement should require that the player must tap the button after a new note starts to play and release the button before the next note is played. If the condition is met, than AUDV0 and AUDV1 will be set to their corresponding values in the sdata array. If the condition is not met, the channels will be set to zero after the sdata is read but before the drawscreen happens. Create a subroutine that uses "pfixel x y on" to draw a playfield pixel whenever a new note is played. Since there are 31 possible frequencies and 31 possible playfield positions, just go ahead and use the current frequency in musicData to determine the x property of the pfpixel we are drawing (the y value doesn't matter for now). When the duration of the note is reached, turn the pixel off before the next note is played and the next pixel drawn. Have this routine run separately from any player inputs, meaning that if the player isn't tapping the fire button, he will still see playfield pixels blinking on and off in time with the rhythm of the song. These will serve as the visual cues for when he has to tap the fire button. I think this mini-game would be a good start to a proper Hero engine. Don't think of it in terms of final gameplay. The important thing is designing a functioning relationship between tempo, display and input, which you can then modify and build on throughout development. After that we could start to talk about interface, display, difficulty etc. Hope this helps. Cheers, Jarod.

Yes, that was my question exactly. Thanks!

Thanks for replying. I do have the Stella Programmer's Guide. I guess what I was saying was I still don't quite understand this bit, in terms of what the literal pixel position is of the hardware sprite player sprite when copied.

I've been searching for a good explanation of NUSIZx, particularly when it comes to the pixel positions of sprite copies. From what I can gather, NUSIZx = $x3 produces two sprite copies in the following arrangement, spaced at 8px per character: X.X.X..... But in the above, which character represents the "true" pixel position of playerx's registration point? How would I go about determining the pixel position of the rightmost copy's registration point? Is there a thread I've missed that discusses the number property of NUSIZx in detail? Thanks in advance, Jarod. EDT: This was an accidental double-post. I thought I lost my similar post (browser crash) in the "Beginners" section before the topic was posted. I apologize for the mistake. Is there a way to delete one of the two topics? Thanks-J

I've been searching for an explanation of pixel positions for the copies produced by NUSIZx registers, specifically when it comes to NUSIZx=x3. From what I can gather, the copies produced are as follows, at 8 pixels per character: X.X.X..... In the above, which of the three "X" characters represents the true registration point of playerx? How would I go about determining the registration point of the rightmost copy? Is there a forum thread I've missed that discusses the Number property of NUSIZx in detail? Thanks in advance, Jarod.

I was wondering why your sprites looked so good. Thanks

I never understood why they used that blue background in Pac Man, especially with all that horrible flicker. The background color selection had nothing to with gameplay or with technical limitations, and it made the flicker seem a hundred times worse. Also, I still don't get the altered design for Pac Man. The arcade Pac Man was such a simple yet effective sprite: iconic, non-distracting, and fluidly animated. There doesn't seem to be any reason at all to change him, since he could be duplicated rather faithfully. I don't mind the ghosts so much, though. EDT: I just played the game again, I remembered what I didn't like about the ghosts. Instead of their eyes pointing in the direction they were moving, two shapes were created (eyes up, eyes down) and then "animated" by alternating them once and then flipping REFP1. The result was a stupid looking 4-step animation that made it look as if the ghosts' eyes were constantly revolving, like the hands of a clock. There is proably no technical excuse for this. Atari had four independently moving ghosts, and each ghost had a sprite set which could show the correct eye movement. A very basic explanation of "form equals function" means if an object is doing something different then it should/will look different...and vice-versa. The googly-eyed ghost animation was just a poor design choice, and sapped whatever small bit of slickness and personality was left from the arcade game. I'm pretty sure that DEBRO has fixed this in his homebrew version. There's also no reason for PacMan to continue chewing, endlessly, whether you are moving or not. Or is he talking? Singing? Whatever he is doing, it's not "chomping."

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? With COLUPF. In other words, you get one playfield color. Michael Ah, I see. Thanks! Do you know if there any way to write some of the rows to the playfield's color table and the rest of the rows to the background? Jarod EDT: Or, failing that, could one limit the number of background rows, to make the size of the background smaller than the playfield?