freshbrood

I keep getting confused on where to post.. But iirc Enduro has persistent off screen cars. If there's no map you could get away with using a single variable for off screen cars like in Enduro, say 127 is even to the player, and anything below say 107 is off screen behind and anything above say 147 is off screen ahead. (assuming the visible screen is divided into 40. Set a few seconds delay for how often the same car can pop on and off screen, so that the randomized lateral movement makes sense. If that makes sense.

I would think you'd only need two variables for the x,y of each car. (That's if you wanted some kind of map that shows where they are) If you go by how Enduro does it then you really only need one single variable for every off screen car- using 127 as being parallel to the player (and onscreen, drawn) and say anything less than 107 is off screen behind the player and anything above say 147 is off screen ahead of the player. (my wacky phone keeps quoting the wrong topics! As to the offscreen cars, etc.. Iirc they are persistent in Enduro)

The contrainsts are what's fun! And especially that last part- creativity and ingenuity! Don't worry about making graphics look good- just focus on making them functional and easy to understand first. The bare minimum. Add the bells and whistles later.

In short, yes. I know its possible.

Hi. Ninja Kombat dev here. I am also currently working on a Texas Holdem Poker game in 2600 using 6ai players + 1human. (Forthcoming demo for that one as well) I think the math is very possible to do a Solitaire game because thats less complicated than Holdem, and I have already figured out a way to do it using just BBasic and no special kernels. So in my humble opinion, if you are only using Bbasic then I would only display the very top face cardss. (Any solitaire player understand all under cards are consecutive and same colored- no need to show a portion of the under cards. This would minimize flicker to only having 4 sprites at a time. You could show how long the card stacks are in a few ways. For example: 1) A "2" card sprite could actually be 6 pixels tall, while only drawing the number 2 at the bottom 5 pixels and setting the height to 5. Then as you stack it on top of an A it becomes 6 pixels tall and moves one y position down. Voila. Not fancy but now you can represent all 52 cards as only 4 stacks with varying heights. You only need to flicker twice- po for Hearts and Diamonds, p1 for Spades and Clubs, etc.. A third flicker maybe for the unplaced card. Not fancy but doable 2) Option 2 would be to use missiles to extend the stacks of cards and have all sprites fixed at (e.g.5?) pixels. But getting a white background with a red or black number card might require a colored playfield or additional flicker tricks. 3) Draw the selected card in your hand in the corner of the screen using playfield blocks, but using a missle or ball just a white square you can place down onto the other 4:stacks. Once placed the giant pf card display disappears and the white block you placed becomes the top sprite card on top of the stack. I might favor this 3 option most. Card held in your hand is just a white square represented by pf blocks in the corner that you place on top of the 4 flickered card sets. It would fill the negative space on the screen nicely, minimize flicker and be the easiest to code not having to use special kernels and just whole simple colors.

Holding down+fire in the air performs a jump punch. Simply pressing fire without moving performs a low kick. During the knee bend animation press up for a high kick or away for a round house. I wanted standing block to be a hybrid of SF2 but without locking you in place, so you continue to walk away but upon hit it becomes a block. I chose the moveset based on what hand movements felt more natural to the sprite animations. E.g. while I really wanted Scorpions spear to be down, back, fire, it felt too unnatural to do down, forward, fire for his ghost punch which moves in the opposite direction. The jump punch has the character sprite leaning down/forward in the air and jump kick seemed to be used more during play so that's how I went with the controls. I left a DEBUG in the game, so doing a straight up jump punch will change to the next character for testing. (forgot to remove it for the demo)

The jump forward/back is just a straight line up, then up+over, then over, then over+down, then down. Basically 5 straight lines approximating the arch as closely as possible. This saves a lot of memory and allows for just simple intergers. The delay on arching jump- just a variable counter that decides how long to move up, then up plus over, then over plus down, etc.. There is also a separate variable to delay the up/down jump. The frames are ALMOST as many as in MK2 on Genesis. But not quite, so to make up for lack of frames and telegraphing an attack (aka seeing it coming and having time to block it before the final frame of animation) the punch (for example) will instantly appear with arm fully extended, but damage is delayed a split second so it can be blocked if the opponent is fast enough. This way it feels like a responsive input for the attacker while being fair to the blocker. I think sprites are totally maxed out or else I'd try to squeeze one more frame of the starting punch. So for now that's how it works.

Thanks! Fun fact: Raiden's body torpedo is actually only 7 pixels wide- the fewest horizontal pixel count in the game!.. but the VCS has 2 very rudimentary scaling options that let each pixel be stretched twice or four times as wide. All other sprites are 8 pixels wide- but they stretch double when attacking. Goro is fixed at double stretched for proper proportion. As a result I've altered some of his melee attacks to be a Shao Khan like shoulder smash instead. (because quad stretching him lost too much detail and looked awful) Also when doing Raiden's flying torpedo against the edge of the screen he will push through the opponent instead of going off screen. This is because the 2600's memory is so limited there is no room to "hide" sprites off screen, they just wrap around. So he pushes faster until the opponent is at his hands then matches speed, always ending up in the correct position. It was the most elegant solution I could come up with and I think it works.

Latest download above

I am actually fluent in Megazeux! Lol.. Ironically I started to port Ninja Kombat to MZX first before I lost interest and learned Batari Basic.

Timing and possibly some magic damages are off and need to be tweaked. This is nowhere near complete. PLEASE DON'T MESSAGE ME WITH BUG UPDATES! - I know it's still very glitchy and buggy and I am aware of all of them! Please don't ask me why I programmed it this way instead of that way, etc.. It's the Atari 2600. Compromises had to be made and what you see is the best I know how to give you. I apologize for all the false alarms and taking so long to release this latest update. I got sidetracked with trying to survive and put this off for a while. There is a 4 count beat and then a melody ONLY at the character select screen. The volumes are completely off and player 2 glitches the timing. Pressing fire on joypad two will allow player 2 to enter after player 1 is selected. There is no cpu ai programmed yet. This engine is based on MK2. The good news is because this is mostly in BBasic when I do release it, it should essentially be the MUGEN of the Atari 2600 and easily customizable by non coders. I really want to squeeze it down to 32k if possible for compatibility on all cartridges and consoles, without needing to emulate, but that is to be determined. Before I forget special thanks to Karl G particularly with the scanline counts being controlled by .05% assembly plugs and for figuring out a routine to duplicate color tables for full pallete swaps that saved a ton of memory, and for Maggie Vogel for helping with the chiptunes and for Chris Spry for helping me to understand the sounds, and to Albert & co. for running such a cool page. (And to the many other homebrewers who have inspired.) I hope you enjoy! I love you my fellow Atarians! Ninja Kombat wip v03.1 DEMO.bas.bin

Thanks for this Albert. I'm about to upload a latest wip demo and I will link to this.

Nothing I've tried has worked. I sure would love to see a simple 2 bank .bas sample.

I can't figure out music with bankswitching. It seems to work fine when all the code is in the same bank, but the timing gets thrown off and breaks when bankswitching. Does anyone have any sample .bas of a bankswitched game with tunes?

I can't figure out music with bankswitching. It seems to work fine when all the code is in the same bank, but the timing gets thrown off and breaks when bankswitching. Does anyone have any sample .bas of a bankswitched game with tunes?

I believe I have found a fairly clever reason for this that I hope to show off soon. Two actually, one of them being a password system that is basically your invisible maze idea.

Thanks Karl. In short, is there ANY way to see the ball (if only even a pixel or two) along the very eges of the drawn screen if the pfblocks and background colors are the same?

Another question about the ball: Does it ALWAYS get drawn BEHIND every other object on the screen? (unless you specifically set the p0 and p1 sprites to appear behind the playfield blocks?

Rygar on the NES is vastly superior to its og arcade version.

Will try this, excellent, thanks. I think with a randomized playfield this could at least free up one variable if reading a particular row. I love tricks like this.

But in short, I was just trying to get the widest arena practical with 2 constantly animating sprites that need to be perfectly symmetrical and behave exactly the same way either on the left or right edges as their sprites multiply by 2x and 4x in width. It's not been easy, but I think aside from a tolerable brief wrong facing sprite it's mostly complete.

Thank you for your explanation. I think I've addressed it well enough, I was just hoping there might be a better way so I could optimize and squeeze some more code space out. But I think you answered it well and confirmed my worst fear. On another note, is it possible to read an individual playfield row's color? I am trying to find as many "non variable" variables as possible (e.g. reading an individual of row's color could tell what level the program is on vs. using a stored number variable, etc..) Is there a hidden list of all the read only options in bbasic somewhere ? Or is RevEngines page as through as it gets?

Hi Kev, not sure if this is in response to my question about viewable starting area.. but I have no idea how to make a macro or kernels, and my concern isn't about making coordinates easier to read but finding an elegant and low memory way to fix screen wraparound.

I hate to post here but no one's responded to the new topic I created, re: in bbasic is it possible to change the default viewscreen position? Instead of x0, y0 starting at the upper left most pixel, maybe have that viewable pixel be x50, y50? This sure would save a lot of headache on sprite wrap around when it gets to the left or top borders..Or conversely is there any code snippets that make wrap around smooth in bbasic? I have a topic started if anyone would care to respond. Thanks.

Remember you also have the ball, for 3 missiles as it can be programmed to collide with anything too. Don't use multi color kernels. Remember there are only 9 combinations of 3 copies - 1 of them. You can just program the collision to redraw them as one of the appropriate remaining 8 combos, with proper x offset.