Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

jrok

Members
 View Profile  See their activity

  • Content Count

    1,156

  • Joined

  • Last visited

  • Days Won

    5

Posts posted by jrok

  1. Posted

    Here's an updated version with a power pill in the middle. Now I need dots for Batari-Man to eat. What is the limit, if any? I'd like 59 dots if possible. If Space Invaders for BASIC can have up to 6 sprites with 6 different aliens without flicker, then that's at least 36 dots I could have without flicker, right? And how do I make more than 2 copies of a player or missile, and set them at different places around the screen like in the Space Invaders BASIC program? I suppose since the dots wouldn't be moving, only removed, then it would be easier than if the dots were moving, right? BTW, the .bas file has remarks (rem).

     

    I think it can be done with bB's multisprite kernel:

     

    player0: pac(batari)man

    player1-2: four ghosts (w/ 30 hz flicker)

    player3-5: 18 pellets (w/30hz flicker and NUSIZx)

    missile3-5:18 pellets (w/30hz flicker and NUSIZx)

     

    Cheers,

    Jarod.

  2. Posted

    Thank you for the detailed explanation. I have a couple of of questions.

     

    When you *define* a macro, it doesn't use up any ROM at all-- but when you *call* a macro, it uses up ROM. A subroutine would be stored in ROM once, and then would use only 3 bytes of ROM each time you call it, and have an overhead of 12 cycles to call it (6 cycles to call it, and 6 cycles to return from it). But a macro always uses up *some* amount of ROM (which could vary each time depending on the circumstances), but it has *no* extra cycles of overhead to call it.

     

    I'm a little confused about what's going on behind the scenes, here. When we compile a program that contains a macro, does the the compiler tally the total number of calls and write them into ROM? I assume one shouldn't do even do this, but how would the compiler handle a macro in a looping or iterative statement, such as:

     

      dim my_var = a

 macro my_macro
 missile0x = {1}
end

 myLoop
 my_var = my_var + 1
 callmacro my_macro my_var
goto myLoop

     

    Also, I'm a little confused by the use of "{#}" in the below definitions and calls. What happens when the program executes "callmacro backgroundcolor {2}."

     

    You can't *define* a macro inside the definition of another macro, but you can *call* an already-defined macro inside the definition of another macro. For example:

     

       macro backgroundcolor
  COLUBK = {1}
end

  macro playfieldcolor
  COLUPF = {1}
end

  macro screencolors
  callmacro playfieldcolor {1}
  callmacro backgroundcolor {2}
end

     

    Once again, thanks for making all this a little easier to digest.

     

    Cheers,

    Jarod.

  3. Posted · Edited by jrok

    Sure, it seems shallow, but it's the reason why Demon Attack on the 2600 still turns retro snobs into graphics whores over 25 years later. You've been given a big box of crayons - play with them a little.

     

    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.

  4. Posted

    As a player, on average(!) bB games tend to be less good than assembler games. Actually except for Deimos Lander I cannot remember any bB game now which I played a lot.

     

    Well, sir, that almost sounds like a challenge! :)

     

    Thanks for the frank answer! Although I'm still unclear if it's considered taboo to post a bB game to the In Development section.

     

    Cheers,

    Jarod Kitchen

  5. Posted · Edited by jrok

    Aside from what's listed above, there is on..gosub, the number of redefined variables increased from 100 to 500, the postprocessor will let you know if a user-defined header or asm file is used instead of the default, a version message is displayed, bugfixes to multicolored playfields, optimizations to joystick and console switch reading code, support for 0840 banking (use romsize 8kEB), a warning if any includes are ignored due to improper placement, pfscrolling in multisprite kernel (needs asm support to work), optimized storage of some sprite data, optimized complex math, optimized bit access, optimized score addition, bugfix to allow fixed-point number without needing a decimal in it, peephole optimizer (-O switch) improved.

     

    There is also an obscure command called "extra" whose sole purpose is to place data or inline asm in the otherwise wasted space caused by placement of sprite data to prevent page wraps. For some reason it does not work with code (I can't remember why.) If you are writing a game using the multisprite kernel and the last bank is full, using extra might help you recover some of that space (which could be several hundred bytes.)

     

    The syntax is:

     

    extraN:

     

    Where N is a number. End the extra block with "end," not indented, just like data statements, sprite definitions, etc. 0 will attempt to place your data or inline asm in the first block of wasted space, if it exists. 1 will place it in the second, 2 in the third, and so on. I can't remember what happens if the block doesn't exist.

     

    A code example for extra might look like this:

     

     extra0: 
data getsound
2,4,15,8
end

asm
lda #1
...
end

end

     

     

    This all sounds pretty great! Where can we find this new build?

     

    Thanks,

    Jarod

  6. Posted · Edited by jrok

    I'm very new to this hobby, so I've spent a lot of time recently browsing old forum threads and trying to learn a little more about the dynamics of homebrew community, particularly when it comes to batari Basic programming.

     

    When I first got the itch to start programming for the 2600, I started by reading alienbill's website and trying to get my feet wet in Assembly. It was a little daunting, so when I started reading up on the bB compiler's capabilities, it sounded like a lot of fun as well as a way to prototype and to gradually teach myself ASM by studying the output. Its also been really helpful to read the kernel memory maps and to examine and customize some of the batari kernels and mini-kernels. I doubt I'll be programming anything remotely fun or even functional in pure ASM anytime soon, but bB has been a great beginner's tool for me to at least grasp the fundamentals of the TIA.

     

    That said, programming in bB has been really fun for me, and I've noticed a lot of bB games that folks here are developing that seem quite good. At the very least, it seems that many people are putting a good deal of thought and work into these games. And in general, everyone in the A2600 programming threads seems to be supportive of the notion bB could attract fresh blood to the community and the system.

     

    But over the last couple of days I've come across a couple of threads that seem to sort of disparage or in some way stigmatize Atari games that are written in bBasic. They aren't nasty or anything, and I absolutely understand the reasoning behind these opinions, given that simple love for the console is very different from loving the challange of programming for the 6502. That said, I decided to get into this hobby to have fun and talk about Atari games, not to be made fun of for having a smaller brain and/or not knowing the rules... I have a wife for that :).

     

    So when I saw AA's list of games in development, I was curious whether or not it would be considered presumptuous or "bad manners" or something for those of us working on bB games to post there, even if it was one we were very serious about completing. Despite the number of titles people are working on, the list seems quite small, and - at least, from the descriptions and screenshots - it doesn't appear that any of them are being composed in bB (although, I suppose its possible they might have been prototyped in it).

     

    Does the community at large - programmers and collectors and fans - make a firm class distinction between ASM and bB games? Honestly, It's not that I have a fragile ego or anything, but I hate being "that guy" at the party who just doesn't "get it," and who everybody laughs at behind his back (like I said, already got a wife... :) )

     

    Cheers,

    Jarod.

  7. Posted · Edited by jrok

    When you say it seems to work best, do you mean it's seems to be the best "eyeball" approximation of what it would look like on a CRT, or that it provides the best looking display on an LCD? (or both??)

     

    Thanks again,

    Jarod.

    The reason in adding it was for this, not to completely and accurately emulate how a real system would look (although I'm not opposed to improving the emulation of it, if someone has suggestions).

     

    Well, that's okay. If I wanted complete and accurate emulation, I'd have to see a half empty can of Meister Brau sitting next to the TV antennae, and hear my grandad shouting "Again with the bleep-bloop-bleep-bloop?... turn that [email protected]&! off and go outside, already!" :)

     

    But honestly, the main reason I was asking was because I don't have the hardware to test my programs. That said, it might be kind of cool to have a Open GL raster mode that tried to mimic a CRT monitor in a side-by-side comparision... maybe by including an optional Open GL overlay that tries to simulate the old light sweep and shadow masking?

     

    Given that the world has pretty much got both feet in LED and plasma displays these days, being able to reproducing something close to the old CRT might add a nice nostalgic touch to the experience of playing some of our favorite old games on new sets.

     

    Cheers,

    Jarod.

  8. Posted

    Basically, we just emulate an approximate look of the phosphor effect; there's no accurate modelling or anything going on behind the scenes. And you're right that the '77' represents a mixture of 77% of one screen with the other. This seems to work best, and is also the default that z26 uses.

     

    When you say it seems to work best, do you mean it's seems to be the best "eyeball" approximation of what it would look like on a CRT, or that it provides the best looking display on an LCD? (or both??)

     

    Thanks again,

    Jarod.

  9. Posted · Edited by jrok

    When I tried running my program in Stella without phosphor turned on, I saw the strange color change effect you were talking about, but hopefully it won't look like that on a TV screen. If you want to try it with phosphor on you could follow the instructions & screenshots below. The only thing I'm not too sure about what the setting is actually measuring. The real "phospor effect" is analog, so when Stella sets phospor to "77" I assume that means that the frames are 77% blended, but I have no idea what that translates to in terms of actual old fashioned TV screens.

     

    Cheers,

    Jarod.

     

    Instructions:

    - Click once to highlight the game

    - Click Options

    - Click Game Properties

    - Click Display

    - Set Phosphor to "Yes"

    These instructions are fine if you want to always use the phosphor effect with that particular ROM. But if you want to toggle it in real-time, you can use the 'Alt-p' key combo. This won't save the setting, but will dynamically switch between the modes while the game is still running.

     

    Thanks, stephana, I didn't know that. BTW, do you have any insight on any analog metric that the Phosphor setting is based on? I used to be somewhat well-versed in the way the Cathode Ray Tube works, but I'm fuzzing a little on the way that phosphors were categorized/characterized. I know it had something to do with transmission length, and that there was variance depending on the chroma signal and the type of shadow mask it was using, but my memory pretty much fades to black after that. Obviously there's no substitute for testing on a real CRT, but I couldn't find any documentation on this particular feature and I'm kind of curious.

     

    Thanks in advance,

    Jarod.

  11. Posted · Edited by jrok

    Give this game a cart, a box, an instruction sheet and make a small run of 30 copies! :cool:

    I would buy it!

     

    (BTW Circus Maximus Galacticus is a great name for it)

     

    Thanks!!!

     

    There's still a couple more things I want to do and some polish I want to add before I would consider it complete. I'm about halfway done coding my alien wildlife "survival" stage, and I'd like to add in one more level type and a two player mode. I'm also trying (and, mostly, failing) to write a custom score kernel for the game, so I can have a H.U.D. that shows your score, the number of shields you have left and a timer clock for the survival stages. I also want to add a hires title screen and some music. At that point, I think I'd be confident enough to call it "done" and release the game and the source.

     

    As for putting the final game on cart, I would really like to try to do that. The main obstacle I think would be the cost per cart. The cartridge would need to contain eight swappable banks and a SARA chip, which might make it too expensive to make by myself. But if there's a way to do it, I definitely will.

     

    Cheers,

    Jarod

  12. Posted · Edited by jrok

    Yeah, it's because he's transparent, and part of the room is showing through. I don't much like it either, but if I don't flicker him, I'll run into trouble in other things I'm doing. Maybe the center portion of the room doesn't appear until he disappears? I'll try to figure something out.

     

    Good idea, but how about this. Just have NOTHING but the dude in the middle during the opening sequence.. have the two guys running around randomly shooting?

     

    That's a good idea. I think I might do that. And then when you click, maybe the playfield fades in. Thanks.

     

    I use Stella and I have no idea how to turn phospor on or off and what it is exactly. I seen it referenced in another post, but thought nothing of it.

     

    I'm sure this is an incomplete explanation, but in my understanding of it the phosphor effect is supposed to mimic the way that light from the TV's scanning beam would linger in the material that coats the inside of the standard CRT TV screen, creating a sort of glowing effect. So the idea is, when the next beam comes, there's still a little light from the last beam left, which would have the visual effect of "blending" the two consecutive frames. From an Atari programming standpoint, I guess its mainly important for those of us who are only using a single display kernel and need to flicker things to get more of them on the same scanline. Computer LCD screens don't use light in this way, so Stella and Z26 have phospor settings that attempt to show how the game would look on a regular TV.

     

    When I tried running my program in Stella without phosphor turned on, I saw the strange color change effect you were talking about, but hopefully it won't look like that on a TV screen. If you want to try it with phosphor on you could follow the instructions & screenshots below. The only thing I'm not too sure about what the setting is actually measuring. The real "phospor effect" is analog, so when Stella sets phospor to "77" I assume that means that the frames are 77% blended, but I have no idea what that translates to in terms of actual old fashioned TV screens.

     

    Cheers,

    Jarod.

     

    Instructions:

    - Click once to highlight the game

    - Click Options

    - Click Game Properties

    - Click Display

    - Set Phosphor to "Yes"

    post-21152-1228849188_thumb.jpg

    post-21152-1228849208_thumb.jpg

    post-21152-1228849223_thumb.jpg

  14. Posted · Edited by jrok

    Two-player turn-based mode if right difficulty set to B, 1-player is right difficulty set to A. I have 235 bytes and two variables left.

     

    This is great! The game plays really well and has enough variation to stay interesting. I think the game is very good as is, but some people on here had some cool ideas.

     

    As far as a bonus to catch, how about the rare blue jelly that SpongeBob is always after. Obviously, it would have to be very hard to catch.

     

    I think this is a pretty neat idea, since you don't have to draw an additional sprite for it. Maybe it could act as a sort of bonus multiplier when you catch it, or hand you a big chunk of time back. Then, you'd have moments in the game where the clock is ticking down, and you have to decide whether to go for the easy catches, or gamble on the rare fish for a big payoff.

     

    Instead of stopping the game after the time ends, have a certain number of jellyfish you must catch. Then once you have met the quota, continue on until time runs out. If you fail to catch the number of jellyfish for the round, game over. Otherwise, advance to another stage (maybe switch up the playfield colors for each round). Bump up the jellyfish quota by like 10 or so, and repeat. Eventually it will get so frantic the player would eventually fail to get enough jellyfish per round (probably around stage 5 or 6).

     

    I like this idea too, since it would give you the chance to rack up big scores if you're quick and saavy, and still increase the challenge for more advanced players. One other idea I'll throw on top is, what if when the player presses the button at the moment he collides with a jellyfish, he can perform a double-jump, almost like he's hopping off the thing as he catches it. It might provide another level of "checkers-like" depth for savvy players, who could time and plan their jumps to get mult-fish bonuses.

     

    On the other hand, I think its damn fine work just as it is. Great job.

     

    Jarod.

  15. Posted

    How about using Stella instead and turning the phosphor on?

     

    Aha! That works pretty good! Z26 has a phospor setting too, but only captures the current frame, not the blend (unless I'm missing something).

     

    Thanks!

    Jarod.

  16. Posted

    I just realized I never made any screenshots for this game, so I did a few:

     

    cg_1.gif

    cg_2.gif

    cg_3.gif

    cg_4.gif

     

    It was a little tricky. Since I'm doing the game with 30hz flicker, I had to cut and paste elements of some alternating frames. If anyone knows a good way to take a 30hz snapshot with Z26, please let me know.

     

    Cheers,

    Jarod.

  17. Posted

    Thanks for the feedback.

     

    - Do not like that the dude in the middle anymore.. isn't all one color like he used to be. He seems to be two colors. The first guy, for example, at the screen you start off at is yellow and white. Looks like he's wearing a mask, but I didn't like it.

     

    Yeah, it's because he's transparent, and part of the room is showing through. I don't much like it either, but if I don't flicker him, I'll run into trouble in other things I'm doing. Maybe the center portion of the room doesn't appear until he disappears? I'll try to figure something out.

     

    - Loading up the .bin and just sitting there (watching main screen) every so often the playfield changes color? I didn't like that. It looks funky when it goes through the center where the dude is. If you fix the dude so he's all one color without the mask then it might look better, but I am not sure.

     

    I'm not seeing that bug. Are you using Stella or Z26? If it's Stella, do you know if the phospor option is turned on or off?

     

    - I once shot the enemy the same time he shot me. We both did death sequence, but I was able to continue playing. Another time I did same thing and game was over.

     

    That's a bug for sure. I'll work on it.

     

    Cheers,

    Jarod.

  18. Posted

    I like your game, especially the very nice animated sprites! :)

     

    Thanks!!! That make me feel pretty good because I really worked hard on the sprites and the animation in this game. Particularly tricky was getting the up and down animations to function well, since they had to display 16-frames within an 8-frame animation routine. Originally, I actually had 8-directional animations, including up-diagonal and down-diagonal loops, but it was just too much of a ROM-hog. I have a few more sprites planned, but their animations might not be as complex due to the same ROM constraints.

     

    Cheers,

    Jarod.

  19. Posted

    New Build:

     

    Eliminated external walls: After struggling to find the cycles for them, I decided to just eliminate them altogether. The TV screen makes a good enough border. Due to the limitations of the batari playfield, you won't be able to "shoot" in the extreme left and right portions of the screen, but I'll try to figure out some other gameplay element to explain that (Yars-style "safety zone"?, refuel point?)

     

    Expanded hittable areas: I still want there to be a bit of precision aiming in the game, but I expanded the hittable portions of both characters. Basically, you should be aiming either dead-center or at the head.

     

    Added "hit-points": The player must be hit three times to be killed. The enemies start out with a single hit point, but gain additional hit points as the game progresses, up to a maximum of six. Now that each player has two hittable regions, its conceivable I can make it so that head shots cause more damage than body-shots.

     

    "Evil Otto": If the match goes on long enough, the Emperor's face reappears in the center of the screen. Right now it's still a sort of placeholder test, but ultimately he'll shoot a few bullets at you when this happens. The time that needs to elapse before the Emperor appears decreases as you progress through the game.

     

    Revised sound: I've been tinkering with the sound effects a bit, particularly the laser beam effect.

     

    Revised some playfields: The idea is to make you work a little bit for good shooting angles in the beginning of matches. I'm definitely going to have to playtest this idea a lot. Ultimately, I'd like part of the challenge to include how quickly you can dispatch your foe, with bonus points earned for fast victories.

     

    Thanks for all the help and good wishes so far.

     

    Cheers,

    Jarod

    Circus_Galacticus_m12_d7_y08.bas.bin

  20. Posted · Edited by jrok

    Wow!!!!!! I had a lot of fun playing this!! The sounds go great with the game. The players look great. I think I got up to 800 points where the playfield is totally blocked from getting to the other side and the colors change (black enemy).

     

    Thanks!!! It's funny you said that about the sounds, because it's something I haven't been happy with and have been experimenting with in this next build. But now that you said that, I may go back to the original laser sound.

     

    I wanted to suggest that maybe the playfield "grows" back one piece at a time every so often, but I love the game as it is now.

     

    That's a pretty great idea. I'm trying to figure out how that might work. It would be pretty easy to make it all grow back at once, but in order to have it grow back a bit at a time, I guess I would have to figure out some way to store the values of destroyed pixels, and I'm running low on variables as it is so I'm not sure how possible it is. I'll try though.

     

    Still need to work on collision detection a bit? Sometimes when the enemy is facing down it doesn't register when I hit him.

     

    I've revised the collision detection again to expand the hittable area, although you still have to aim fairly careful. The idea is to aim for the dead center of the sprite, or the sprites head. I'll explain more when I post my next build in a minute.

     

    I suggest once you finish up the game to find someone to work you in a nice title screen and music in ASM. This way maybe you can get something high res.

     

    Another great idea. I think I have enough room to include some hi-res screens. Music is another thing all together. Not only am I daunted by the amount of work involved, but I also know don't have the best musical ear around.

     

    Thanks for the advice,

     

    Jarod.

  21. Posted

    Don't like how collision detection is. I very rarely get killed. Even when trying to.

    That's one of the things I need help on.

     

    For collisions, maybe you could track each character's playfield position, which you can do every game loop (or in the vblank) no matter which sprite is flickered. When the jellyfish's playfield x and y match Bob's playfield x and y, treat that as a collision.

     

    Cheers,

    Jarod.

  22. Posted

    OK, this is a timed game now, so the object is to catch as many jellyfish as you can in one minute. To start each game, press the reset switch.

     

    I really like this game a lot, particularly the movement of the jellyfish. Also, not having Bob get stung seems in line with the light-hearted nature of the show (which, I admitedly don't know much about). One thought I had was what if, instead of getting stung and dying, Bob just gets stunned and loses time when he doesn't touch the jellyfish from below? Also, maybe you can work in some kind of a point bonus for catching more than one in the same jump?

     

    Great job so far!

     

    Jarod.

  23. Posted

    jarod.

     

    I like the idea add ons :

     

    1. Fend off groups of alien wildlife that emerge from a pit.

    2. Battle a snakelike creature that moves like a Tron light cycle.

    3. Battle a killer robot that can teleport around the screen.

     

    Paulie

     

    Thanks, man. Of course there will have to be a two player "versus" mode too, but I'm pretty sure I can just jam that into the banks I'm already working in.

     

    Cheers,

    Jarod

  24. Posted

    Here's my latest build:

     

    • Finally got scanline under control with a small kernel edit and some optimization of the player control scheme. The game runs at a smooth 262 except for overflows during the death animations, which I'll have to investigate further.
    • Replaced left and right walls with a PF0=128 vertical frame in the vblank
    • Set a limits on laser beams to stop their progress at the left and right walls (still working on stopping vertical and diagonal beams)
    • Created a color phase animation for the combatants while waiting for a new match to begin.
    • Increased hittable area of both combatants
    • Revised AI routine
    • Expanded number and style of playfields
    • Expanded number of unique enemies

     

    For me, the most exciting part was being able to finally get my core game routines to run at a reliable 262, since I was at the verge of giving up. I have lots of ideas where I want to take the game next, so its a big relief to know that, at the very least, I might still have a program that's functional.

     

    Next:

    Now that I can have scores of unique "looking" enemies, I really want to work on getting unique "acting" ones. I've left placeholders in my enemy data set that I will try to use as pointers for different weapons, and maybe even alternate AI routines. I have plenty of ROM left in my AI bank, so I just have to figure out what I want them to do differently that varies the challenge as you proceed through the game.

     

    I also would like to add in a few new player control options, which will be pretty easy since I'm already tracking the time that the player is holding down the fire button. But I could use some advice:

     

    Quick button "taps":

    Which do you think would be more interesting and/or useful: a quick dodge manuever or a melee attack?

     

    Overcharging the gun:

    Should this produce a negative effect for the player, like the weapon becoming unavailable for a short period of time? Or should it be some sort of super-attack or manuever that can be stocked up like smartbombs?

     

    Also, I've realized if I keep this a 32K game, I still have 2 completely empty banks to create completely alternate gameloops, to keep the player guessing about what's coming in the next level. For instance, instead of facing a lone gladiator with a laser beam, I want to create the following alternate round-styles:

    1. Fend off groups of alien wildlife that emerge from a pit.
    2. Battle a snakelike creature that moves like a Tron light cycle.
    3. Battle a killer robot that can teleport around the screen.

     

    It's probably biting off more than I or bB can chew, but if I can squeeze even one alternate play-style in there I think I'll be happy with this project.

     

    Cheers,

    Jarod

    Circus_Galacticus_m12_d4_y08.bin

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...