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

Robert M

Members
 View Profile  See their activity

  • Posts

    1,533

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Robert M

  3. Robert M
    Picross is a fun set of logic puzzles in the same genre as Sodoku. Each puzzle consists of a grid of blank squares and a set of numbers for each row and column in the grid. The numbers indicate the sets of squares that must be filled in that row or column to solve the puzzle. For example, if the numbers are {1 2 3} then a single square must be filled, followed by 2 squares then 3 squares. At least one square must remain unfilled between the filled squares. The number of unfilled squares between the filled squares is the missing information you must deduce logically.
     
    You have an hour to finish each puzzle. Making mistakes will cause a penalty of several minutes to be added to the elapsed time. Solving the puzzle completes a picture. If you finish the puzzle in under an hour you get an animation of the picture as a reward. Solving multiple puzzles will unlock simple mini-games and harder Picross puzzles.
     
    This game is a lot of fun, and with the ability to save your current puzzle it is easy to pick up for a few minutes at a time. The puzzles are a fun challenge, and the reward animations are cute.
     
    I have only one gripe and it is about the controls. On larger puzzles you must zoom in to fill squares. As you fill squares the zoomed puzzle will pan automatically. In my haste to get a good time I often find that the puzzle will pan and I will miss the square I was aiming for and suffer a penalty. I wish there was a way to turn the automatic panning off.
     
    Other than that I think the game is very excellent and is very enjoyable for anyone who likes puzzle games. If you like Sudoku puzzles you will really enjoy Picross.
  4. Robert M

    Thoughts on "Doom"

    By Robert M,

    I played Doom for the first time this weekend. I know, I know, where the hel have I been. I have played many FPS games, but I was so busy at college when Doom came out I missed it. I rememeber people mentioning it and talking about how awesome it was, but I never played it.
     
    I must say now that I have played it, I am very impressed. The game plays very well. Control is smooth and responsive. The level designs are exquisite considering the limitations of the game engine. Unlike a modern FPS no 2 areas of a DOOM map can overlap, so there are no over and under design options. Despite this, I found all the levels to be laid out with great attention to what makes a FPS game fun. Lots of places to shoot at enemies with cover. Lots of secrets to root out. It was all very enjoyable. Truly Doom was a banner game that spawned a lasting genre. Many modern FPSs are not as good as Doom, IMO.
     
    Looking at the engine, I can't help but wonder is a primitive FPS would be possible on the 7800. I know that it does not have sprite scaling built in, so that would mean lots of sprites need to be stored in the ROM at all the necessary scales. The walls could be monochrome to minimize CPU time, and lighting effects would not exist. Sort of a Tunnel Runner on Steriods. The end result would probably be more akin to Wolfenstien 3D than to Doom.
     
    It seems to me that hte Lynx, which was able to do an excellent port of Stun Runner, should be able to run Doom considering it has the sprite scalling hardware support. The main obstacle to overcome would be the limit of 16 colors per scanline. Lighting options would probably be defeated by the limit in colors, although blackouts would be simple enough to accomplish.
     
    Cheers,
    Rob
  5. Robert M
    Goals:
    -> Implement enemy shooting.
     
    Design:
    -> Start from last entry.
    -> Up to 3 shots can be in flight at once using ball, M0 and M1.
    -> All three shots are drawn every frame, no flickering at 30 Hz like the sprites.
    -> To make the shots not monochrome, they are rotated round robin fashion. So in frame1, shot1 is the ball. In frame2, shot1 is missle0, and in frame3 it is missle1.
    -> All three shots are 2 pixels wide and one pixel high as limited by the mutlisprite kernel)
    -> Shots are wiggled back and forth by one pixel per line of travel to give them some simple shape.
    -> Shots are reset as soon as they hit the bottom of the screen, but they could be allowed to travel off screen for longer periods to slow enemy rate of fire.
    -> No collision detection yet.
     
    Implementation:
    main013.txt
    main013.txt.bin
     
    Lessons learned:
    -> I still need to learn how to type the word missile consisently
    -> As I found in my early experiments with the multisprite kernel, the positioning of P0, P1-P5 and the missiles all seem to use different positioning routines, so to make one object emit from another requires application of a constant offset.
     
    Recommendations for improving bBasic:
    -> None.
     
    Up Next:
    -> Adding collision detection.
  6. Robert M
    Goals:
    -> Animate all 10 virtual sprites simultaneously to create circulating arial swarm.
    -> Animate player0 under joy1 control to run left and right.
    -> P0 flickers at 30Hz, use the other copy of P0 to give the player a flaming sword.
     
    Design:
    -> Start from last entry.
    -> Reimplement the joy1 reading code from 2 entries ago to use an on..goto statement rather than if-statements.
    -> reintegrate the player animation code with the new joy1 code. Only left and right movement are implemented.
    -> Add flaming sword sprites for player0.
    -> The virtual sprites are stacked vertically at intervals of 10 lines. With flickering at 30Hz there are 2 stacks of 5 sprites.
    -> One stack of sprites moves down 10 lines, and then resets to its starting position. The other stack rises 10 lines and then resets.
    -> Each sprite has status info (color in this demo, it could include image). When the stacks reset the 10 statuses are rotated, and the illusion of circling objects is created.
     
    Implementation:
    main005.txt
    main005.txt.bin
     
    Lessons learned:
    -> When your code compiles but doesn't run, double check for misspelled labels. (more below)
     
    Recommendations for improving bBasic:
    -> When I compile with errors, sometimes I get an error message and sometimes I don't. I don't understand why that is. Usually the problem is an undefined label, but whether I see the error seems to be random. When I can't see any message it looks like the code has compiled, but it will not run, and the binary image is incomplete. Is there a DASM switch I can set that will insure I get all possible error messages?
    -> For example if I take line 253 of the attached source code and change it to this:

    goto playerStand
    When I compile, it appears to succeed, but really it has failed. Why is there no undefined symbol error message printed out by DASM?
     
    Up Next:
    -> Refining animation of the virtual sprites.
  7. Robert M
    Goals:
    -> Explore sprite animation in bBasic using the Multisprite kernel.
    -> Prototyping of a possible game idea using pure bBasic.
     
    Design:
    -> Start from the multisprite test program.
    -> Render the Playfield as a cavern. PF0 is set always on to form left and right walls.
    -> Put player 0 on the bottom of the cavern as a warrior.
    -> Left and right joystick motions move the player sprite.
    -> four frames of running animation are used plus a single standing still frame.
    -> Running left is shown with the original sprites flipped vertically.
    -> Choosing the frame of animation shown is done by taking the two lowest order bits of the sprite's current x-position which form a value from 0 to 3.
     
    Implementation:
    main.txt
    main.txt.bin
     
    Lessons learned:
    -> The REFPx registers are cleared by the score kernel and need to be set every frame.
    -> BUG! There seems to be a bug in the compiler for the multisprite kernel. It seems that sprite images are stored in ROM with both a leading and trailing zero byte.
    The trailing byte is left off for the last Player0: image defined, and the first byte of the playfield graphics bleeds through.
    This can be seen as the horizontal bar above the player sprite when it is not moving left or right.
    I can get rid of the bar by injecting a dummy image of one line with no bits set as the last image for player0, but ultimately this seems like a bug that needs to be fixed.
    -> Sprite animation for player0 is really easy in bBasic, but it seems overly complex for sprites 1 through 5 in the multisprite kernel.
     
    Recommendations for improving bBasic:
    -> I haven't looked at all the details in the kernel, but I am surprised that sprites need to be padded on both ends with a zero byte.
    I can understand a traling zero to turn the sprite off, but what is the leading zero for?
    Could the height of all sprites be reduced by 1 and save a fair number of ROM bytes? More investigation is needed for me to understand what bBasic is doing.
     
    -> The way the language defines sprite images and sets them to a particular sprite does not allow you to reuse a sprite definition for different sprites.
    It seems that I must redefine the same sprite 5 times to set sprites 1 through 5 in the mutlisprite kernel to show the exact same thing. So ROM space is
    used 5x as fast as should be necessary. An alternate method for defining and setting sprites would be a nice addition to the language.
    Let the programmer declare a table of sprites images, and then set the sprite pointers and heights from the table with an index value.
    Each image declaration can start with a user defined label that the compiler sets the label to the table index for the following image definition.
     
    Up Next:
    -> Turning 6 sprites into 12.
  8. Robert M
    Goals:
    -> Get practice using the multisprite kernel
    -> Observe the flicker management algorithm for virtual sprites in action.
     
    Design:
    -> Implement the playfield as a dark grey checkerboard to facilitate line counting
    -> Use numbers for the sprite graphics to identify them on screen.
    -> Arrange the sprites in a tight line so side by side veritcal differences are easier to measure.
    -> Joy 0 moves the sprites. Up and down move virtual sprites 1 through 5 at different velocities to cause combinations of overlap.
    -> Joy 0 left and right moves P0, M0, M1 and the ball vertically.
     
    Implementation:
    multitest.txt.bin
    multitest.txt
     
    Lessons learned:
    -> M0 and M1 are drawn 1 scanline lower than all the other graphics which are aligned to the 2LK kernel line. This is not unsurprising, but may need to be considered for collision detection.
    -> COLUP0 must be set every frame. The kernel resets it to black during drawscreen.
    -> BUG? If a sprite or the ball is visible at the bottom line pair on the screen the last row of pixels is drawn for a 3rd scanline below the last PF graphics.
    -> With the screenheight set to 84:
    -----> P0's lower left corner of screen is x = 0, y = 11.
    -----> P1's through P5 lower left corner of screen is x = 8, y = 8.
    -----> For M0, M1 the lower left corner is x = 1, y = 1, but M0 and M1 droop 1 scanline down.
    -----> Ball lower left corner is x = 1, y = 2.
    -> Flicker behavior is the same for pfheight values of 1, 3 and 7.
    -> Setting pfheight to 0 scrambles the screen as documented in the bBasic manual, but you can see when repositionings are being done.
    -> Virtual sprites require a horizontal gap of 2 lines to reposition without flicker.
    -> Flickering fails for some cases when more than 2 sprites overlap.
     
    Recommendations for improving bBasic:
    -> The language is fine, but the portion of the manual for the mulity sprite kernel has some unclear language.
    ------> What is the default value for pfheight?
    ------> The screenheights of 80 and 84 only work with some pfheights all 7 or less, but pfheight can be 15 and 31. What are the legal screenheights for those values. A table of legal combinations of screenheight and pfheight would make things more clear and complete.
     
    Up Next:
    -> TBD
  9. Robert M
    Goals:
    -> Try to create an animation of pf graphics using the pfheight kernel option.
    -> Gain more experience with bBasic syntax
    -> Still no user interation.
     
    Design:
    -> Base on the HelloWorld program.
    -> Turn on the pfheights kernel option.
    -> Create an on...goto statement that maps to a 16 frame circular animation that bounces and stretches "HelloWorld".
    -> the code for each frame will set the pfheights.
     
    Implementation:
    PFanimation.txt
    PFanimation.txt.bin
     
    Lessons learned:
    -> RTFM! The syntax for an ON...GOTO does not include commas (I was still thinking of the C64 basic ) Putting commas into an ON...GOTO statement makes for some wild compiler errors.
    -> Also, if-statements do not like parenthesis on the condition side.
     
    Recommendations for improving bBasic:
    -> The language really needs an ON...GOSUB statement in addition to the ON...GOTO. I was forced to use a clumsy system of gotos to get back to the mainloop of code from the frame setup routines. The resulting code is brittle and harder to read. Plus I can't reuse my frame routines in a different on...goto statement.
     
    Up Next:
    -> Exercising the multisprite multiplexing algorithm.
  10. Robert M

    bBasic - Hello World

    By Robert M,

    For my first bBasic program I choose to stay with tradition and write a Hello World program. For non-programmers reading this, there is a bit of a tradition in programming with a new language to start with a simple program that simply outputs "Hello World" to the user.
     
    Goals:
    -> Minimal source code size
    -> Simple white text on a black background.
    -> no user interaction.
     
    Design:
    -> Use the standard bBasic kernel to render an asymetrical playfield image of "Hello World". The 32 pixel resolution requires a less than pretty font to show 10 characters, but that is a problem common to all VCS programs and not exclusive to bBasic.
     
    Implementation:
    helloworld.txt
     
    helloworld.txt.bin
     
    Lessons learned:
    -> Remarks need to be indented!
    -> Labels can not be followed by a colon like in DASM.
     
    Recommendations for improving bBasic:
    -> Looking at the .asm output from the compiler I see that the entire language library is included even if I never use most of the functions. Randomize for example and all the PF scroll functions are included in the image even though I didn't use them. I understand why this was done, but it would greatly reduce ROM consumption if unused functions were not included leaving more room for user defined code.
     
    Up Next:
    -> Can we do PF height animations?
  11. Robert M
    Okay, so I have less than a month to complete an entry for the 2006 minigame contest in the 1K category. They sure set that deadline early this year. Oh well, If I miss it, then I guess I'll just have to enter it next year. My game idea is a sword fighting themed game with a top down interface. The player myst kill all enemy warriors in the current room and then proceed to the next. There are 8 rooms with progressively harder enemies to defeat. The backstory is the player was betrayed and left for dead. Now he is back seeking revenge. I have drawn up a software requirements document for the game. It is not great, but I think it will be adequate to get through the design stage and most of the coding in short order. The main point of writing the requirements down was to clarify my thoughts on the game and list all the key aspects of the engine that I need to take in to account so that I don't need to do much backtracking later on. I have including my requirements below if you are curious.
     
    Cheers!
    Rob
     

    Software Requirements Document This document shall capture the requirements for a simple atari 2600 video game. Backstory Summary: You are a warrior, betrayed by your best friend and left for dead. Now you have returned for revenge. Fight your way through 8 rooms of enemies to face the traitor in mortal combat. 1.0 Title: The name of the game shall be limited to six characters to allow it to be drawn on the screen with 3 sprites. 1.1 Proposed working titles include "Grudge, "Hatred", "Return", "Animus". 1.2 OPTIONAL: The opening screen of the game shall display the title using the 3 sprites normally allocated for enemy warriors. 1.2.1 OPTIONAL: If there is ROM space left, consider doing somehting with the missles to spruce up the title screen. 2.0 The game shall fit into 1K of ROM memory to meet the requirements of the 2006 minigame contest. 2.1 To meet this tight memory requirement, several requirements in this document will be prefaced with [OPTIONAL] to indicate that they can be eliminated to meet requirment 2.0 3.0 Description of display. 3.1 All screens in the game shall use the same display engine/kernel. 3.1.1 The display is divided into 2 regions. 3.1.1.1 The larger region on top is where gameplay action is drawn, and shall be refered to as the room. 3.1.1.2 The smaller region shall display a life bar for the player, and shall be referred to as the status bar. 3.1.2 Symetrical PF graphics shall be used throughout. 3.1.2.1 The room region of the screen may contain obstacles made of PF graphics. 3.1.3 Draw sprites P0 and P1 once per frame to any height which is a power of 2. 3.1.3.1 The display engine shall use a bit mask to determine if the sprite should be rendered such that a staggered rendering of a sprite is possible to create an explosive death animation. 3.1.4 The M0, M1 and Ball objects shall: 3.1.4.1 Be drawn once per frame. 3.1.4.2 The height may be 1, 2, 4, or 8. 3.1.4.3 The width may be 1, 2, 4, or 8. 3.1.4.4 The object may be skewed 0, .5 or 1 pixel every scanlines to create a line segment at 0, 22.5, 45, 57.5, 90, 112.5, 135, or 157.5 degrees. Where, 0 degrees is a vertical line. These angles (when reflected) map to 16 compass directions used for control throughout the game. Skewed missles and ball will be used to draw the swords in the game. 3.1.5 The room region shall have an outline of a rectangle made with PF graphics. The top and bottom lines of the room rectangle shall show the suggestion of a doorway. 3.1.5.1 [OPTIONAL] The doorways are made with recycled sprites to allow a different color door than the wall. 3.1.5.2 The top door shall have the ability to be rendered as being either open or closed. The bottom door is always rendered as closed. 3.1.5.2.1 The top and bottom wall bands shall be 6 scanlines high, and the door shall be drawn in the 2 middle scanlines. 3.1.5.3 The open interior of the room rectangle shall be no more than 128 pixels wide, and 160 scanlines tall. 3.1.6 The status bar shall be 128 pixels long. and shall have an indicator object in the form of a sprite or missle to indicate the present health of the player. 3.1.6.1 The status bar region shall be 16 scanlines high. 3.1.6.2 The bar shall be red in color and shall occupy the middle eight scanlines of the region. 3.1.7 The game play shall run at 30Hz allowing up to 4 sprites and 6 missles/ball instances to be active at the same time. 4.0 Game flow: 4.1 On power up the game shall initialize and play will begin in Room 0. (see room descriptions below) 4.2 Pressing and releasing reset shall cause the game to return to the power up initial state. 4.3 When all enemies in the current room are destroyed, the door at the top of room shall open. 4.3.1 Should the player sprite touch the open doorway the gameplay will proceed to the next room. 4.4 Room 0 and room 9 shall contain no enemies. Exiting room 9 shall return player to room 0. 4.4.1 Room 0 is the title screen 4.4.2 Room 9 is the victory screen. 4.5 Rooms 1 through 8 will have a set of 1 to 3 enemies of increasing strength for the player to defeat. Details are to be explained below in section 6.0 5.0 Control 5.1 The player shall control a warrior sprite using a joystick plugged into the left joystick port. 5.1.1 Pushing the joystick left or right shall cause the player to rotate left or right through 16 facings. 5.1.2 Pushing the joystick forward will cause the player to move in the direction currently faced. 5.1.3 Pulling the joystick backwards will cause the player to move opposite the direction of facing. 5.1.4 Pulling back and pushing the button shall place the player in the defensive stance. 5.1.4.1 While in the defensive stance the player can not move forward or back, but rotation left and right is still enabled. 5.1.5 Pushing the button without pulling back on the joystick will begin an attack by the player. 5.1.6 If the player is pushing diagonally, then the left or right action shall be applied before the forward or backward motion. 5.2 All game objects will have a speed value. This value will be added to a remainder. when the remainder overflows 8-bits, the object state is updated to reflect the current control input and previous state. 5.2.1 Different speed constants will be applied for PAL and NTSC to create equivalent gameplay velocity. 6.0 More Detailed rules of combat. - The player's goal is to slay all enemies in each room. The enemies become stronger and more numerous as play progresses. The number and strength of enemies can be expressed as a binary number corresponding to current room Enemy = DCBA -> A set bit in the room number means that enemy is present. Room 0 = %0000 -> Opening screen. no enemies Room 1 = %0001 -> Enemy A Room 2 = %0010 -> Enemy B Room 3 = %0011 -> Enemy A and Enemy B Room 4 = %0100 -> Enemy C Room 5 = %0101 -> Enemy A and Enemy C Room 6 = %0110 -> Enemy B and Enemy C Room 7 = %0111 -> Enemy A, Enemy B, and Enemy C Room 8 = %1000 -> Enemy D (Final Boss) Room 9 = n/a -> Victory screen (special case) - The enemy and player warriors share common characteristics of Speed, Life, and Power. - Speed determines how often the warrior and corresponding sword are updated. - Life, when life reaches zero the warrior dies and is removed from play. - Power is the amount of damage the warrior does when an attack lands - The table below is a proposed set of values for Speed, Life and Power for the player and the 4 enemy warrior types. These numbers need to be fine tuned with actual play time, and they need to be made proportional for NTSC and PAL versions of the game. Speed Life Power Player 128 128 32 Enemy A 96 64 8 Enemy B 112 96 16 Enemy C 128 112 24 Enemy D 144 128 32 - TBD (The action of swinging a sword, blocking an attack, and counter attacking shall need to occur over many frames with the time for each frame of action to complete being controlled by the Speed attribute of the warrior. We want the number of frames to make the game move at a good but manageable pace. This work is slated to be done later once the main engine is up and running). 7.0 Scoring 7.1 There is no score except the life bar level of the player upon completion of the game. 8.0 Sound 8.1 The following sound FX shall be needed - A whooshing sound for the swinging of a sword. - A metallic ding sound for when an attack is canceled - A thud sound for when an attack hits. - A death sound when an enemy or the player dies. 9.0 End Game: - When the player defeats the boss in Room 8 and exits into room 9, then the game is over and the player has one. T - The game shall indicate victory with either a short message like "Victory" rendered in sprites and missles, or simply flash COLUPF. - Room 9 shall have no door at the top. - The game shall remain in room 9 until reset is pressed. - The game will end if the player's life bar falls to zero. The player sprite will have an animated death. The game will remain on the existing room until the player hits reset.
  12. Robert M

    I'm losing my job.

    By Robert M,

    We had a visit from corporate central. They have decided to shut down the group I am with. They are calling it site consolidation since we are a remote engineering group, but I doubt anyone at the office has any desire to move to the HQ in Ohio. I know I don't because I just moved cross state last June, and that was hard enough on my family. I am really not worried about finding new work (yet). There is a lot of high tech stuff around here. I am going to be surprised if I like my new work as much though. It was a nice small group of engineers that all got along really well. Its going to be a shame to see it broken apart. It was inevitable though. Our jobs are collateral damage for the layoffs and troubles at GM and Ford. With job hunting in my near future I doubt I will be able to make an entry for the 2006 minigame competition. I was really hoping to have an entry this year. Oh well.
     
    Cheers!
  13. Robert M

    13 Character Demo

    By Robert M,

    I finally got off my lazy butt and cleaned up the source code for my 13-character no-flicker technique. I have created a completely unexciting demo showcasing the trick. The detailed description of how it works is given in Draw13.inc so I won't go into it here. I plan to use this trick to display the level names in Little Man. I hope other programmers find them useful too. There is a lot of room for fun effects to be done: bouncing text, whirling colored text, scrolling text. I didn't do anything cool like that for the demo becuase I want to get going on my mini-game entry. I am still hoping to squeeze into the 1K deadline. Enjoy!
     
    Rob
     

     
    BTW: This demo will not work correctly in Stella which does not correctly emulate the behavior of RESBL. You will need to use Z26, or real hardware to see it work correctly.
  15. Robert M
    Goals:
    -> Implement player collision detection and hit point tracking.
     
    Design:
    -> Start from last entry.
    -> Life and Shield strength bars at the bottom of the screen. Life is on the left, shield strength is on the right.
    -> Collision detection of enemy shots and sprites hitting the player using hardware collision detection.
    -> Shots hitting the player must be reset to bottom of screen to prevent hitting the player multiple times.
    -> The shield protects the player from hits but loses its own strength.
    -> The bottom most Enemy bat swoops down at the player by simply mulitplying the Ycount factor by 2.
    -> A swooping bat can hurt the player only while descending. This is actually easier to implement since the sprites involved are on the screen together allowing use of hardware collision detection.
    -> Make the player's shot looks different from shield.
    -> Some color changes.
    -> The player's color flashes when he is hit. The player is invulnerable while flashing. The upper nybble of the playerStatus byte is set to %1111 when the player is hit. It is decremented every odd frame and added to the player's base color on even frames to make the flashing effect.
     
    Implementation:
    main014.txt
    main014.txt.bin
     
    Lessons learned:
    -> I must remember to ues the built in bit operators to test/set single bits rather then coding them myself with bitwise instructions.
    -> BUG? The bBasic compiler does not like the bitwise-& operator in the expression for a if-statement. It compiles to a CMP instructon with no branch, rather than a AND instruction followed by a conditional branch. I posted about this in the bBasic bug report thread.
     
    Recommendations for improving bBasic:
    -> None.
     
    Up Next:
    -> Adding more collision detection.
  16. Robert M
    Goals:
    -> Further animate all 10 virtual sprites simultaneously to create circulating arial swarm.
    -> Save on RAM needed for 10 enemies by mathematically generating their positions from counters.
    -> Still animate player0 under joy1 control to run left and right, shoot and shield from last entry.
     
    Design:
    -> Start from last entry.
    -> Implement a single X position counter that counts down to zero from 229 and then repeats.
    -> The existing Ycount from 9 to 0 is kept.
    -> The 10 enemy sprites are like beads on a string separated by multiples of 23 pixels horizontally and 10 pixels vertically in motion.
    -> The position of a sprite is found mathematically from the main X and Y counters.
    -> The X position offset from the base X counter must jump along with the enemy status (color) whenever the Y count resets.
     
    Implementation:
    main012.txt - Sorry the comments are less than stellar at this time.
    main012.txt.bin
     
    Lessons learned:
    -> There is a bug in version 1.0 of bBasic with data statements. If a tab precedes the data
    keyword, the compilation will not include any bytes defined on that line. You must
    precede a data statement with only spaces. Batari has fixed this bug for the next release.
    -> The language is proving to be much more efficient than I expected. I am definitely pleased
    that I have added it to my programming tools.
     
    Recommendations for improving bBasic:
    -> None
     
    Up Next:
    ->Enemy shots, and maybe some collision detection.
  17. Robert M
    This is just a minor update to the game in development. I have extended player control joy0 left and right still move the player left and right. Pressing straight up or down, the player sprite kneels and raises the flaming sword over his head as a shield. If the fire button is pressed, the player kneels with the sword raised, and the flames shoot skyward. While the flames are in flight, the player does not have access to the shield.
     
    main006.txt.bin
    main006.txt
     
    Next I need to refine the animation of the enemies.
     
    Cheers!
  18. Robert M
    Goals:
    -> This is just a brief entry. Small progress, but progress is progress.
    -> Add 30 Hz flicker to the program to double the number of objects shown.
    -> Prototyping of a possible game idea using pure bBasic.
     
    Design:
    -> Start from last entry.
    -> Delete the joystick code, and disable the player animation code.
    -> Add a framecounter and add odd/even frame handling
    -> For now, just separate the two sets of sprites horizontally.
    -> no player control is available.
     
    Implementation:
    main002.txt
    main002.txt.bin
     
    Lessons learned:
    -> I really need to stop typing the word missile incorrectly.
     
    Recommendations for improving bBasic:
    -> None. Looking at the asm file it was nice to see that the compiler optimizes for a + 1 operation by using the INC instruction.
     
    Up Next:
    -> Animating 12 sprites.
  19. Robert M
    I admit it. I am curious about bBasic. I have been avoiding it because there is a sort of community feel about it that it should be left to the beginners and experienced programmers should stick to assembly code. I am at a point of severe frustration at this point , however, and bBasic may provide a solution. I have a stack of half finished projects. Most of them are working kernels with some design work on the side completed. I get the kernel working and then I lose interest as I get bogged down in the painful process of writing the game code in assembly.
     
    So now I am looking at bBasic and wondering if it would be fast enough to write the game logic for my kernels. Or better yet, just use the built in kernels and get some freaking projects DONE! In the end, it doesn't matter if the code written is the fastest possible, it just has to be fast enough. Also, while there is something romantic about cramming a complex game into a 4K cart with some wicked assembly tricks, I find the the continual demands of real life make such a romantic quest impractical. Besides, 32K EEPROMs are getting easier to find and cheaper than 4K EEPROMS, and I suspect most game players could care less what the game ROM size is. So that thinking brings me to this project.
     
    Goals:
    -> Evaluate bBasic as a development platform for my projects
    -> Identify optimal bBasic coding techniques and share them with the community.
    -> Recommend (and possibly contribute to the development of) ways to improve or extend the language.
    -> Integrate my own kernels into bBasic.
     
    More to come...
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...