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

BenMcLean

Members
 View Profile  See their activity

  • Content Count

    38

  • Joined

  • Last visited

Posts posted by BenMcLean

  2. Posted · Edited by BenMcLean

    Depth first search isn't really "modern game theory" ... it's just an algorithm and most of the work on it was done in the '70s unless I am greatly mistaken. Anyway, I have come up with a reason why this won't work: there is no fast enough way to check whether or not you've already searched a particular square before in order to avoid going in circles in your search path. You'd have to progress back through the entire stack at each square you search and that would almost certainly be prohibitively expensive. I'll just have to think of something else. Or maybe use a grid with bigger/fewer squares ... hmm. Will keep thinking this over.

  3. Posted · Edited by BenMcLean

    (When you say depth first I'm thinking

    recursive subroutine calls, but of course,

    it doesn't have to be that way and you

    could probably manage that with a little

    asm trickery)

    Given that you can really only go three gosubs deep, (six bytes reserved / two bytes per gosub = three gosubs) obviously I would want to use goto for the recursion in this case, not gosub, and keep track of how deep in the recursion I am with variables. I do plan to use individual gosub/return pairs within each iteration in order to abstract some parts of the algorithm that are used multiple times.

     

    I don't think I'd need to write any actual assembly for this. It seems like it should be doable within Batari Basic.

  4. Posted · Edited by BenMcLean

    I doubt it will work unless

    it's really really shallow.

     

    The stack is only, like, 8 deep

    at best and the kernel will use some.

    Certain options or addons will use some.

     

    You might be able to get something

    going if you sacrifice some variables

    and create a data stack.

     

    Either way it will be dependent on what

    options you're using and how much of

    RAM they use.

     

    Might be able to use look up tables.

    Random Terrain's web site says, "The DPC+ stack can be used to save and restore your bB variables. There are 256 stack locations available, with the top-most location being #0 and the bottom-most being #255.... Note: The DPC+ stack is a special stack just for you that is 100% dedicated to your push and pull commands. Nothing else uses it. It's all yours."

     

    According to this, I should have 256 bytes of stack space that is only for my program, (not used by the kernel) which is used by the push and pull commands. This would be separate from and in addition to the 26 bytes used for variables and the six bytes used for the gosub and return commands. Is that true or not?

  5. Posted · Edited by BenMcLean

    I have been thinking about using the stack to do depth first search pathfinding for enemies to get around playfield obstacles when chasing the player. If it ran out of stack space before finding the player then it would throw the search away and revert to some simpler rule set for it's next move. I would try to have it get closer to catching the player within the limits of the Atari 2600's stack by biasing the search in favor of moving towards the player. (always searching in that direction first) This might enable it to get around at least some simple obstacles intelligently. Is this doable? Has it ever been done in an Atari 2600 game? (I haven't actually played all that many)

     

    (later edit) Or wait ... the search should be backwards from what I said. It should push the path from the player's position to the enemy's position so that the enemy can pull it's next destination coordinates in the order it needs to follow.

  6. Posted · Edited by BenMcLean

    I must have made a typo when I had already tried what you were suggesting before I posted because the method you suggested works now. Thanks. I finally got playfield collision prevention working, albeit with the rule that all horizontal surfaces in my playfield must be at least 2 blocks long to prevent moving through them vertically. (since I'm only pfreading the edges of the player's box facing the direction the player is moving in, and the player's box is wider than a single playfield block)

     

    default.bas

     

    Now the tricky part is going to be collision prevention and pathfinding for the enemies. ^_^

  9. Posted · Edited by BenMcLean

    I assume you've constructed your algorithm with full knowledge that the collision registers for each sprite are set as they're drawn

    No, I didn't know that. Thanks for telling me. Random Terrain's site should probably mention that right here.

  10. Posted · Edited by BenMcLean

    I've been trying to build something with collision detection and I got the basic idea to store the sprite's current position in temporary variables, move the sprite to the place I want to check, and move it back to where I'd previously stored if there is a playfield obstacle in the way, while leaving the change permanently if it's clear. But for some reason, that basic concept doesn't seem to work. It gets stuck on the first obstacle encountered and cannot move anymore. Any idea why it's doing this? I'm guessing there's something about how sprite positions and/or the Atari's memory work that I'm not getting. A code example that produces this effect (which I've trimmed away most of the other stuff in my program) is attached. The score color changes if collision(player0, playfield) is true

     

    default.bas

  12. Posted

    I was being terribly unclear in your previous topic. That hoodeehoodee.asm file is only for the multi-sprite kernel which doesn't have built-in pfread commands.

    What does it really mean to be on the multi-sprite kernel? I have multiple sprites and I've selected kernel options to enable me to use multiple sprites, so does that mean I'm on the multi-sprite kernel? Or do you mean by posting this to say that I'm not actually on the multi-sprite kernel with those kernel options?

  13. Posted

    I get the error:

    pfread_msk.asm (1): error: Label mismatch...
 --> pfread f268                  

Unrecoverable error(s) in pass, aborting assembly!
    when I try to add "inline pfread_msk.asm" to the end of my code. Test case:

     set smartbranching on
 set kernel_options player1colors playercolors pfcolors

main

 goto main

 inline pfread_msk.asm
    Any idea what that's about?

  16. Posted

    The playfield goes all wonky and doesn't match what I put in visually when I use CTRLPF = $10 with " set kernel_options player1colors playercolors pfcolors". Any idea why that's happening? I've attached a test case.

    default.bas

     

    Also, I am going to need to use pfread with those kernel options if possible. Does this mean I need to add a module? Random Terrain's site seems to indicate this, but doesn't really explain whether one should use the official pfread_msk.asm or bogax's version.

  17. Posted · Edited by BenMcLean

    I'm working on my first Atari 2600 game and I really want it to feel like a complete professionally done product straight out of 1975 when I'm done if possible. I'd like it if I could do it well enough that I could actually fool someone into believing this was a real Atari classic being re-released for it's 40th anniversary in 2015 (not really trying to fool people: just trying to be authentic) and that means making box art, a cart label and a game manual that is stylistically faithful to the period. (Although I will also be throwing in some 18th century style stuff because of my game's setting.) I'd like people to be able to download and print the box, cut it out and fold it into shape. I expect that these graphics will also be useful when making the trailer.

     

    So I've been searching around to find templates and stuff. Unfortunately, most of what I have found is raster graphics instead of vector and I really need vector if possible. I'm alot better with Inkscape than GIMP. If anyone knows of any vector based resources for making Atari box art then some pointers would be very much appreciated.

     

    Here is a list of some useful stuff I've found so far:

    Atari Cart and Box Fonts - fonts are vector so that's good!

    VGBoxart.com has some Atari 2600 templates, although they're all PNG and like I said, vector would be preferable.

    This guy on the VGBoxart forum, although he has just the cover and again, no vector.

    Templatemaker.nl, which would let me construct a box of the correct size, if only I knew what the correct size was.

    Hexels which may be good way to make a cool looking picture out of my game's graphics in lieu of an epic painting for the box cover, because I can't paint.

    This painting which I might crop and blatantly rip off for the box art

    Essays 1743, a font that I may use in the game logo and manual because it seems reminiscent of the 1775 setting of my game.

     

    One big question I'd like to ask those of you who remember 1975 (I wasn't born yet!) is which titles art I should be looking at as inspiration or basing my art on. What titles would you say everyone from that time remembers and which had box art that was typical? What should I be drawing upon? Also did they have any TV commercials for Atari games that I should perhaps be spoofing?

     

    Any suggestions as to additional resources would be much appreciated. It's weird that I'm working on developing for a system I've never owned or even gotten to play except for emulators. Only heard of it because of Homestar Runner.

  19. Posted · Edited by BenMcLean

    (later edit) Ah, needed to use pfcolors instead of COLUPF. Random Terrain answered the question that I had here

     

    I'm also going to be looking into animations if possible. All three enemy sprites move in unison because they're marching soldiers so they can all be on the same animation frame

  23. Posted

    Essentially, what I was thinking of here already exists! I just didn't know what it was called. Well, this is wonderful. Thanks. How can I delete this thread? :)

  24. Posted · Edited by BenMcLean

    I love Batari Basic. Am working on my first game and it's gonna rock.

     

    There is one suggestion I would make about improving the Batari Basic language. It would only require changes to the parser, not the compiler.

     

    The idea is that it would be really cool if I could say something like this:

    a=7
function wut(in) {  in{7} || in{5} }
 
if wut(a) then COLUBK = $02

    That would get translated by the parser into this:

    a=7
 
if a{7} || a{5} then COLUBK = $02

    before going on to be compiled just like Batari Basic programs are now.

     

    That way, you could abstract all of your bitwise operations or other complicated conditions into one section of code, and only have to change them one place in your code to change them. Heck, if I was really determined, I could write a Python script for this. It could make code easier to read while at the same time making it easier to scrape together the use of every last bit in those 26 bytes of RAM. You'd be able to see statements like, "if isHeDead(badguy) then blah" instead of "if badguy{0} = 0 then blah"

     

    Some other keyword like "expression" could be used instead of "function" if that's better.

     

    It wouldn't change things on the assembly end at all. Heck, running a python script on your code before it gets to the batari basic tools could do this.

     

    What do you think? Is there some technical reason why Batari Basic can't be expanded to include this which I haven't thought of?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...