-
Content Count
9,937 -
Joined
-
Last visited
-
Days Won
35
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by Gemintronic
-
Thanks for the ideas so far! Yeeeah.. would be cool. Not sure if Batari BASIC has direct support for that. As well, Atari 2600 is already a niche market.. people with Savekeys will be rare! Even trying to get to the Vectrex.biz site isn't working right now. www.atariservice.com is down for maintenance still. No one can buy new AtariVox either As a kid I didn't even known about DragonStomper or the Starpath. Games that rely on peripherals have a tougher time I think. @GroovyBee: (in regards to the post below) Touche
-
UPDATE: I guess my point is I could probably get away with 16 (0-255) variables. Well, you'd have to figure in the standard RPG data such as: HP 0-255 SP 0-255 XP 0-255 LEVEL 0-255 Class + Skills Learned (8 Classes + 4 Possible Skills = 1 variable) Base Attack 0-255 Base Defense 0-255 Location Game Saved At 0-255 Point in Storyline 0-255 Markers for Current Quest (Talked to King = TRUE) 8 boolean values Inventory 8 0-255 values (maybe more?)
-
Yeah, I totally agree! But, if I can manage 256 values per place in the password then the game player will have less to write down. If I go 0 - F then each variable in Batari BASIC would be represented as 16 characters to input into the password screen! F + F + F + F + F + F + F + F + F + F + F + F + F + F + F + F = 256
-
Still thinking about MausBoys Holy Grail of a proper RPG for the 2600. As the Melody boards and Batari BASIC don't support save games a password system is needed. I'm thinking A-Z plus 0-5 will net 32 possible combinations per place in the password. The last place in the password will be a checksum of sorts.. basically adding up the total value of the other password digits. I'm also thinking about 32 possible characters with 8 styles of boxes around them for 256 values per password place. ._. |A| .-. So you would enter 0 - 5 and A - Z and then 8 combination of lines surrounding the character. I suppose the interface would be up and down to select the character, left right to move position in the password and fire to cycle through line combinations. Any feedback or ideas on better schemes given the limitations of a 2600 and Batari?
-
What were the dimensions for 2600 manuals?
Gemintronic replied to Gemintronic's topic in Homebrew Discussion
Atari manuals are typically 5" x 7". AtariAge has a great collection of fonts that mimic that old Atari look: http://www.atariage.com/2600/archives/AtariFonts/index.html?SystemID=2600 You, Sir, rock! As an aside here is the homebrew manual and game that this tid-bit of info will help: http://forums.tigsource.com/index.php?topic=13761.new -
So, my forum-fu and Google-fu is failing me. How big were the Atari 2600 game manuals? I made a simple manual for my homebrew but I'm at a loss for the proper dimension it should be printed in. Any clues fellows?
-
I've seen a few threads on making Homebrew Copyright-free versions of popular games. I think we can come up with a list of Batari related titles for such games. Check out my ideas so far: Quimbys "Down Under" - Custers Revenge remake set in the Outback Peanut Butter Batari Time! - Plaque Attack clone Faster Fred - Fast Freddie remake BASIC Instinct - Beat 'em & Eat 'em clone Colonel Options - Artillery Duel clone Fatal Assembly Error - Hard Hat Mack clone
-
Yeah, the graphics are better than I expected. I thought it would suck after realizing multi-colored sprites wouldn't work (they went rainbow/LSD every frame). I used a pfpixel block to add the pink to the Chefs face. Made his movements a bit fast and choppy. I think it works though. You can lose by running out of time. The background gets progressively redder as time runs out. If time runs out it's back to the title screen for ya! The box for CandyBar states it has a "special feature" for younger children. I figured not having a GAME OVER screen would apply as GAME OVER seems to be "negative reinforcement". Random Terrain is a big fan of no "negative reinforcement" or competition. Thanks again Yuppicide! This gives me more to work with when making the manual. Definitely have to describe how to win and lose.
-
At this point in time the object is to feed the icon a goal amount to attain the next level. Higher levels reduce the alloted time, the goal amount becomes greater and the icon starts to move around (eventually moving and warping). In the later levels the candybar boxes move faster too. You can move left and right to catch stray candybar boxes. I do this when a white box appears as they are worth more and thus worth moving around for. My instructions must not be clear enough what the objective is. Thanks for giving me the heads up!
-
okay! I hope this is the final version. Should be submitted to TIGSource as my final competition entry. Compile errors kept on creeping up as I reached only 105 bytes free. 4k is tough. The music had to be cannibalized to make room for more code! On a real TV the blue used for the 5 point candybar and icon above Chefs head looks a very white lavender. The Chefs face and title-screen candybar look too bright as well. GAME INSTRUCTIONS: Press fire to start game. Once in-game left and right moves the Chef. Press fire in-game to pick up boxes of candybars. Each candybar box has a different point value: blue/lavender is 5 magenta is 1 and white is 10. The currently held candybar box is indicated on the bottom left-hand side of the screen. Feed the Hungry Icon above Chef to increase your score. When the score reaches a certain amount the level will increase. After each level the score resets to 0 and the Hungry Icon needs even more candybars to gain the next level. The screen palette shifts towards red as time runs out. Each level introduces new challenges such as less time and less predictable Hungry Icon behavior. KNOWN ISSUES: * Not being able to select level at title screen is not industry standard. * You can win the game by simply pressing up and fire. * Lack of game over screen is a "kid friendly feature" - less punishment for losing.
-
Search for Batari's 4 way scroll example/game
Gemintronic replied to Gemintronic's topic in batari Basic
Many thanks! That appears to be the example. Although in the newest BB the player car seems offset from the map. I guess this is an opportunity to learn and debug at the same time I'm not see'n the Death race example in my Batari -> Samples folder. I mean, I guess zombie_chase.bas could qualify.. Not really 4 way scrolling as it seems to only adjust the distance of the zombie compared to the player. Maybe you were talking about an example that's like Death Race for the NES? That had 4 way scrolling for sure. I'd eat a bucket of Natto to see that! -
Didn't Batari make a 4 way scrolling car maze example? I know his SuperBug demo does 4 way scrolling but I can't find the source to that. Ages ago I thought I saw him post an example of 4 way scrolling but Google and forum searches don't come up with anything.. Am I just out of my gourd again? Does such an example/source for 4 way scrolling exist?
-
I thought it was pretty cool when it came out. The Nintendo was still a toaster and my Master System could be used as a speedbump. The Jr was slim, sleek and black: nothing like the Ford Pinto woodgrain monstrosity that was the original 2600. Now that I'm "grown-up" I've got nostalgia for things I didn't miss like the original 2600. My Jr. has horrible reception and the reset button is about as responsive as a dead hamster.
-
Many thanks for putting the time and effort into this example These comments help in that, just reading through I gain a more comprehensive understanding of Batari concepts. One such surprise was using the same variable for different 1 bit variable names. I just never knew! I would explain why this works: dim Left_Selection = p dim Right_Selection = p Explain what this does and why it's good Atari game etiquette to put it in: if switchreset then Start_Restart Explain how your "debounce" technique works to wrestle down joystick response rates: if !joy0left || Debounce<>0 then L_Done Debounce = 15 : if !Left_Selection{0} then Skip_L .. if Debounce>0 then Debounce = Debounce - 1 Explain how you get a solid or striped score bar from things like "Tracker_Left = Tracker_Left / 4" or "Tracker_Right = Tracker_Right * 2" That's all I can think of for now
-
I've got the custom score code printing 00 to 99 on the top corners of the screen. Just have game mechanics, sound effects and title screen music to go. Oh, yeah. The manual too I forget about them since I never read 'em. The box for CandyBar specifies 8 "games" which are actually 4 game variations with 2 difficulty levels each. Anyone have any ideas for gameplay? I thought of these so far: 1. Feed the icon a set amount of candybars. Amount needed to sate the icon increases with level. 2. Each color of candybar has a different value - such as blue = -3 white = 5 and red = 1. You must feed the icon an exact amount to proceed. 3. Each icon requires feeding in a specific color sequence. The sequence gets longer each higher level. any other ideas guys?
-
Recreate "safety" zone effect from Yars' Revenge?
Gemintronic replied to yuppicide's topic in Atari 2600 Programming
Couldn't the effect be achieved by using the pfcolors kernel options in Batari BASIC? I think the pfcolors are static only if you use both pfheights and pfcolors together. Just rotate pfcolors at the horizontal lines that will be the "safety zone" -
AtariAge can whip up a cart but what about the box? I've seen CPUWIZ offer a template. I've seen the tutorial on making your own. Is there a service out there that does both box making and printing? If needs be it doesn't have to be Atari 2600 box size - just as long as a cart can fit in it nicely.
-
My Google-fu failed me. The NUSIZ thing is using a hardware feature to enlarge or copy the sprite. I think an assembly guru would be needed to hack the kernel for small sprite support. In the mean-time the only cop-out method I can think of is simply editing your sprite to use less pixels. Something like: playership player0: %01011010 %01111110 %01011010 %00011000 %00111100 %00011000 %00111100 %00011000 end ..hmmn. Might not work. The ship is starting to look like a naughty personal massager!
-
Looks good so far. Ship sprite looks spot-on classic Atari 2600. Choice of playfield resolution is, er, choice! Higher res than default but not enough to make coding or spriting issues pop up. I shall learn from your example. The PRESS FIRE can be done in pfpixel commands. bBpf rocks my world with an iron fist of steel! http://www.alienbill.com/2600/basic/bbpf.cgi Also, consider using a for next loop for the sides. You can pfpixel draw just the sides instead of changing da whole screen. You can still use pfscroll down ya know? According the the docs only horizontal scrolling is nerfed on SuperChip hi-res: I added a pfscroll down in the main loop and it worked in Stella. May need a little cleap up work though. Try it!
-
Sorry, was keeping quiet as I can't recommend any way to optimize the code. Definitely a downloadable file. Seems to be something that would be greatly enhanced by comments. I'm still trying to decipher how the solid line score bar graphics work in this. No deficiency in your code - just my inexperience with Batari BASIC.
-
Thanks for the reality check For some reason my thinking got warped by trying to use that pfscore1/4 kinda math. Nothing wrong with such examples of usage. Just, %10011001 as a representation of X..XX..X (pixel space space pixel pixel space space pixel) seems to fit. pfscore1/4 or pfscore/2 feels like a clever hack to make certain patterns out of the score bar. Unfortunately, some users (me) aren't so clever Chrome doesn't like your handy online tool. I blame Chrome for that one. Firefox works fine!
-
Ooooh, yeah! Using the current seems more intuitive. I can't count the times I've been all over my code and forget that sprite changes aren't live. Sometimes I end up dragging and dropping a completely blank sprite if it's a newly added one Random Terrain just explained the whole %10011001 way of representing score bars to me. Much simpler!
-
Drag and Drop Sprites to code requires Save-All first to take into account changes after editing a sprite (at least for me in XP SP3.) The correct behavior should be unsaved sprite changes get dragged to the code window. Please forgive me if this is an unreproducible problem for others. I'll provide more details if I can Also, what about a score bar editor? Sounds trivial but hopefully it would be easy to code: 8 horizontal pixels with a live conversion to pfscore decimal value. The fact that the pfscore value is the binary score bar graphic and not a bar representation of a decimal value trips newbies up I suspect. At least having a VisualbB score bar editor would ease people into the concept
-
Windows has a built-in score bar design aid! Open Windows Calc by clicking Start -> Run and then typing calc in the Run field (hit OK when done) Alternatively click Start -> Programs -> Accessories -> Calculator Set the view to "Scientific" or mode to "Programmer" in Vista/7 Change the number type to (*) Bin You can now enter 1's for pixels and 0's for blank spaces. Up to 8 1's and 0's can be displayed by the Batari score bars. The calculator will not display the leftmost 0's/blanks so a half full bar like this: 00001111 is gonna look like this in calc: 1111 If we want to convert that score bar design back to a Batari pfscore value simply switch back to (*) Dec mode in the calculator. In this case 1111 becomes 15. In Batari you can now use that value to set your score bar. Use pfscore1 = 15 or pfscore2 = 15 depending on which bar you wanna put your design in. -- EXAMPLE -- Let's say we want a left score bar that has a pixel at both ends and two pixels in the middle like so: X..XX..X In the calculator in (*) Bin mode we would type in: 10011001 Switching back to (*) Dec mode we get our pfscore1 value: 153 In our Batari code we would insert that value like so: pfscore1 = 153 That's it! Yay! Score bars demystified for the masses! Have fun with Windows Calc: Your built-in score bar designer
-
Better than Real-Time Weapon Change! CandyBar for the Atari 2600 is a tribute to PANIC INC. CandyBar utility for the Mac. I'm putting it up as an entry for TIGSources "A Game by It's Cover" competition. http://forums.tigsource.com/index.php?topic=13392.0 Very much a work in progress. The title screen has no animation or music. Gameplay consists of moving left and right across the screen. Have 'till the end of July to complete. Couldn't upload the custom score_graphics.asm but that's easy to reproduce via VisualbB. Having the player multi-colored caused the sprite to go LSD/Rainbow effect for some reason. I worked around that by having a single colored sprite with a playfield pixel that is flesh colored for the face. Managed to get 3 different colored "candybars" on the conveyor belt. As PANIC INC. decided to use the score area for their trademark I had to fake the score up top using playfield pixels. Using pfheight is quirky but it worked out somehow. Wish me luck lads! candybar.bas candybar.bin
