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

satyrsfaction

Members
 View Profile  See their activity

  • Content Count

    75

  • Joined

  • Last visited

Posts posted by satyrsfaction

  2. Posted

    Found dasm version: DASM 2.20.12
    Starting build of text_adventure2.bas
    batari Basic v1.4 (c)2020
    2600 Basic compilation complete.
    --- Unresolved Symbol List
     
    free ram: 0
    DPC free RAM= 603
    8 bytes of ROM space left in bank 1
    3624 bytes of ROM space left in bank 2
    522 bytes of ROM space left in bank 3
    897 bytes of ROM space left in bank 4
    3626 bytes of ROM space left in bank 5
    3919 bytes of ROM space left in bank 6
    885 bytes of ROM space left in graphics bank
     
    text_adventure2.bas.asm (3876): error: Illegal Addressing mode 'bit '.
    text_adventure2.bas.asm (3970): error: Illegal Addressing mode 'bit '.
    text_adventure2.bas.asm (4064): error: Illegal Addressing mode 'bit '.
    text_adventure2.bas.asm (4296): error: Illegal Addressing mode 'bit '.
     
    Fatal assembly error: Source is not resolvable.
    Build complete.
    Cleaning up files generated during compilation...
     

    Can someone tell me what this means and how to fix it?

  3. Posted

    3 hours ago, iesposta said:

    To optimize your source code, use one line when values are the same. 

     

    Example: 

    DF0FRACINC = 0: DF1FRACINC = 0: DF2FRACINC = 0: DF3FRACINC = 0

     

    Not:

    DF0FRACINC = 0 

    DF1FRACINC = 0

    DF2FRACINC = 0

    DF3FRACINC = 0

     

    It can save hundreds of bytes of ROM per bank. But this can make the source code harder to read when one line gets very long. 

     

    This is something I wish the compiler would optimize.

    The first way compiles to “load 0, store 0 in these registers”. 

    The second way - the way everyone codes - compiles to “load 0, store 0, load 0, store 0, load 0, store 0, load 0, store 0”.

    Thanks!

  4. Posted

    well, another update....now the final maze, instead of becoming entirely visible when you have the Seer, i did a halo of light like in the original Adventure. I finally figured out how to do it. theres still one bug that I can't figure out...the Harp keeps going back to its original room when you drop it. Grr.

    text_adventure.bas.bin

    • Like 1

  6. Posted · Edited by satyrsfaction

    18 hours ago, TwentySixHundred said:

    During collisions the screen jumps and changing rooms seems fine. DFxFRACINC lines need to be in the mainloop and anytime before you call drawsceen.

    OK, i put the lines in every time I call drawscreen. Did it help?

     

    text_adventure.bas.bin

  7. Posted

    Ok, well I do switch banks when the player switches rooms...i look into your suggestion. So the DFxFRACINC lines should or shouldn't be called before draw screen and should or shouldn't be part of the main loop? At any rate, I updated the game so it has two levels now. The second level has random placement of the objects and companions.

    text_adventure.bas.bin

  11. Posted · Edited by satyrsfaction

    I finally finished my first ever Atari game, which I made in Batari Basic. I call it Text Adventure. I made it mainly as a means to learn the language. It's a small Adventure-style game, but the items, monsters, etc. are represented by words instead of pictures. My idea behind this is to, in some small way, capture the feel of the tabletop RPGs where you use your imagination. I figured that seeing the word would more readily inside one to imagine the thing than seeing a picture or icon. Whether or not my theory holds up is up to you, I guess. Haha. 

    Anyway, the object is to find the Gem and bring it to the temple. The Gem is in the Castle, and you'll need the Key to get inside. You can use the Axe to fight monsters, or the Harp to put them to sleep. There are also two companions you can find: the Hero, who increases your combat abilities, and the Seer, who helps you see in the dark castle. Hope you enjoy, Thanks.

     

    Thanks to orange808 for all his help.

     

    Below is the really, really final, updated, corrected version of Text Adventure! (3/22/20) Enjoy!

     

     

     

     

    text_adventure.bas.bin

    • Like 3

  13. Posted

    18 hours ago, Lillapojkenpåön said:

    use pfpixels like this to find the pixel above, below, to the left of and to the right of

     

     temp5 = (ballx - 9)/4

     temp6 = (bally + 14)/8

     pfpixel temp5 temp6 on

     

    I also made some examples a while ago, but they are for the standard kernel, in the standard kernel playery is the bottom of the player, and the top would be playery - playerheight, so not like the DPC+ kernel, but left and right is probably the same, so it might be useful.

     

    ok, I'm confused ... when i put in your numbers and use pfpixel, the pixel appears way to the right and up from the player position. Shouldn't it be right on top of it? Or am I just not understanding this at all?

  17. Posted

    OK, i still don't have a handle on this. my playfield is 30 playfield pixels high, and I'm using the ball as my player -- it's 6 pixels tall by 4 wide. since the the playfield is 88 tall, that means i'd be dividing by roughly 3, right? when I put in that value I get this:

     

    --- Unresolved Symbol List
    div8 0000 ???? (R )

  18. Posted

    4 hours ago, Random Terrain said:

     

    The numbers used with pfread can be used with pfpixel. When I change the screen resolution, I comment out the collision detection code with rem and put in pfpixel so I can see if things are lined up properly. Since you are new, do it with a working example program first so you can see exactly where pfpixel is supposed to be in relation to the sprite. Then you can play with the numbers until it looks the same in your program.

     

    OK, i tried it and with the sample program, the pixels appeared on top of the sprite. So i tried it with my game, and I'm having difficulty lining up the pixels. what do the numbers mean? which ones should I try changing? thanks for your help.

  19. Posted

    42 minutes ago, Random Terrain said:

    Use pfpixel. Once you get the pfpixel where it should be, you can use those numbers. You might want to try it on an example program that works and see how that looks, then try it on your adapted version.

    Thanks, but  I'm not sure I understand what you mean -- i'm just a beginner. 

  21. Posted

    Hi, i'm very much a beginner at this -- i started a little adventure style game as a means of learning Batari Basic....I hope to expand on it later. I'm having two major problems. First, the collision detection i came up with is terrible. I wanted to use the collision prevention in Random Terrain's manual, but it doesn't seem to work, perhaps because my game is a different play field size? Second, i'm out of memory and unfinished. what can i do to save memory, or to move stuff to other banks -- i'm just not sure how that works. will variable values stay assigned if you switch banks? Will play field information stay if you assign it from a different bank?

    textadv.bas.bin textadv.bas

  23. Posted

    I'm just starting out in Batari Basic, and I decided to convert my initial attempt into DCP+ in order to have more sprites available. but now, the play field won't show up -- the player still collides with it, but it's invisible. Can anyone tell me what I'm doing wrong?

    game5.bas

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...