Jump to content

rdefabri

Members
  • Posts

    663
  • Joined

  • Last visited

Posts posted by rdefabri

  1. Rare I see an Atari game that exists on multiple platforms (C64, ZX Spectrum, Atari 2600) that isn't on the A8 line.  Didn't realize Road Runner is ported to nearly all the other platforms BUT the A8.  This one came out around 1985 I think, so the "heyday" was over, and certainly a big reason we don't have this one.  It's not the greatest game, but kind of sucks since it is an Atari title.

     

     

    • Like 4
  2. 1 hour ago, Preppie said:

    Machine language subroutines are not allowed in the 10 liner BASIC competition.

     

    It's possible to use strings to move players faster vertically but it's a little tricky and has a lengthy setup routine.  Info can be found here: 

     

    Or you could design a game around your limitations eg. just have players move horizontally.

    Yep I know you can't use machine language in 10-Liner, I kind of gave up on that until I can actually program something that works!

  3. I forgot how simultaneously frustrating and enlightening programming could be (although I suck, so it's more frustrating than enlightening).

     

    Creating PM graphics in Atari BASIC is simple enough - the POKEs to set up virtually everything, including horizontal movement, are all there.  It's obviously vertical movement that becomes an issue, and standard practices yield a much slower moving sprite moving up / down.

     

    There are known machine language VBI subroutines, and I can get them to work.  However, I have some issues when I determine a collision (in this case, PM0 to playfield) - if I end the program, the PM stays on screen and when I go to run again, the program is corrupted and/or doesn't run.

     

    So a few questions - is there a standard way to clear all the memory out and reinitialize?  I've tried CLR, and even loops to zero out everything.  No dice.  The other question I have is that the VBI subroutines I've leveraged (mostly from Atari BASIC programming books) use lengthy DATA statements.  Not a big deal per se, but if I were ever to attempt a 10-line BASIC game, it's a non-starter...is there some simplified or smaller machine code subroutine to handle fast vertical movement?

     

    I know the simple answer is to use a different BASIC.  BASIC XE and Altirra BASIC have built in PM commands that make it easier, but now I'm hellbent on doing this in BASIC.  Any advice?

     

  4. 5 hours ago, vitoco said:

    Sometimes I have to decide between X and Y features, because there is room for only one of them, and I keep the one that maximizes the gamplay.

    Sometimes, while I'm writing the comments for the required explained source code, I find better ways to code something.

    Sometimes I find that two statements could be reduced to just one with a variable that changes the behavior to the corresponding one.

    Sometimes, when the order of the statements does not matter, I could make them fit better in the lines.
    And sometimes I move to the next category and include all the features that I want...

    Moving to the next category might be an option.  First I have to get this stuff to work - I'm a hack!

  5. 24 minutes ago, vitoco said:

    In my BASIC tenliner games, I usally have a main loop with a global counter. Then, some subroutines are performed depending on that counter (a condition using a modulus function for instance). In that way, some routines are executed on each loop, some routines every other loop, or even the same routine using different "parameters" on each call. Sometimes, the routines are called based on an "is X element active?" condition. An X element could be a player, a bullet or even a sound effect.

     

    You can look some examples in my BASIC tenliners page (Chase Me! is not there yet). Every game has its source code with comments, some in Atari BASIC, some in TurboBasic XL, and some in FastBasic.

     

    This is kind of how I had the program structured.  Main routine initializes the PMs, movement, collision detection, etc.  Each turn has a physical change to the playfield, and I need that change to be "animated" or drawn.  To do that, I would call a subroutine to each playfield change.  Once the playfield is drawn / redrawn, it would return to the main program.

     

    As I thought through it, because the subroutine has to slowly draw the playfield change(s), I began to wonder if that would stop / halt the main routine(s).  For a counter - definitely.  For PM movement, I'm not sure.  Either way, the counter stoppage would be a problem as that's the main scoring mechanism.

  6. 27 minutes ago, vitoco said:

    GOSUB just transfers the flow to another statement of the code, saving the position where the jump was done. There is no thread waiting for the subroutine to finish. At the RETURN statement, the flow leaves the subroutine and returns to the saved position and continues with the next statement.

     

    Again, there are no multiple threads that could interact or perform tasks by themselves. VBIs and DLIs are another animals in the wild, not directly related to BASIC.

     

    Then, if you have a main loop with a counter, you can only increase it after each GOSUB included in the loop is done, one by one.

     

    Note that variables are "global" to the whole program. If you set a variable to a given value, then call a subroutine with GOSUB, you can use or update that value from the routine.

     

    Yep, I knew this but was hoping there was some "trick", like doing something with the VBI.  More I look at it, the more I realize how much more complex this is in BASIC.  I'm sure there's some way but it's over my paygrade.

  7. 54 minutes ago, TGB1718 said:

    In BASIC, it's essentially linear, the only way to do anything like that is to have a machine code

    routine in the VBI, BASIC could interact with that routine, but you couldn't rely on the timing

    without some sort of flag(s) passing between the VBI and BASIC.

    Yep as I suspected.  Everytime I think I've made a breakthrough, I hit a wall...gotta keep thinking through it.

  8. My understanding of Atari BASIC is that it performs functions in a serial fashion (e.g, interprets a line, executes, goes to next line).  Obviously, you can "interrupt" the flow with commands like GOSUB to run subroutines.

     

    What I'm not sure about is how you can run certain functions in "parallel" (I'm putting "parallel" in quotes because I know it's not really parallel but to the human eye - it is for all intents and purposes).  For example, if you initialize a PM, have it moving around a screen, then want to have a background drawn behind it, will that work?  In this case (unlike my previous thread), I want the background to "build" - you see it drawn.  Assume that's done in a subroutine, does the main program handling the PM graphic / movement / collision detection stop?

     

    Take another example - you run a subroutine, but the main program has a timer.  Let's say the timer increments every second, but the subroutine intentionally takes longer than a second to "build" / draw...does the timer not increment until you return to the main program?

     

    I know there are orders of execution, but I'm drawing a blank, I feel stupid that I can't remember or figure this out.

  9. 39 minutes ago, Rybags said:

    Digitized pics will only really look good in certain conditions or with certain modes.

    APAC, TIP, RIP, HIP etc. RasterConverta pic, G2F.

    Graphics 9 (luma only mode)

     

    For something like Gr. 15 a mono pic in 4 shades could be made to work.

     

    PC based graphics editors do have helpful tools like posturize to reduce number of luma levels.

     

    A lot of this sort of thing is trial & error.

    For the idea I have, even mono color would work.  What wouldn't work is a slow load time of the screens, which likely makes hi-res (320x192) a non-starter.

     

    The sample game in the Adventure Studio almost perfectly mimics what I want to do without the text choices on bottom.  In that sample game, when you click to leave a room, a new room appears (almost) instantly.  If you want to close the door, you see the door close - not really animated, but the effect is one where you have closed it and it visually appears that way.

     

    I can get creative and minimize interactivity and animation / PMs, but to make this concept work IMHO, it needs some degree of both.

  10. 9 hours ago, MrFish said:

    Give an example of something you'd like to use.

     

    I think I’ve (sort of) found what I’m looking for.  @ilmenit created a tool called “Adventure Studio” that allows for creation of graphical point-and-click adventure games.

     

    The graphics can be created with RastaConverter and used in the game you create.

     

    What I'm looking to do isn’t an adventure per se, but you would be in an environment that would require the player to click on different areas of the screen to access some sub-functionality or a different screen.  The main screen would need to be semi-realistic, not something I could feasibly draw using Atari-based tools.  I want to draw / paint it physically and “scan” it into Atari format.  As I understand RastaConverter, it lets you convert a standard JPEG or other modern graphical formats and convert into an Atari format.

     

    I don’t believe Adventure Studio is completed, but there may be enough there to get me started.  I’m toying with it…gotta push myself, I’m easily discouraged but I’m giving it the old college try!

  11. 44 minutes ago, Beeblebrox said:

    Sometime in 2021 or 2022 I'd heard there was interest from the developers of the game called Asteroida, the cause of lifes troubles (which BTW I've not since heard anything about) - to be taking the Adventure studio engine forward.

     

    Check this out https://atarionline.pl/forum/comments.php?DiscussionID=5850&page=1

    ?PostBackAction=Download&AttachmentID=16386

     

    I had hoped that:

     

    1) Asteroida, the cause of life's troubles - which looks a great point and click game - was going to be completed and finished

    2) That the excellent Adventure Studio, which looks like an amazing engine for much needed colourful point and click games, would be finally realised.

     

    I mean look at what it can do!!

     

     

    Maybe both are still being worked on?

    So Asteroida wasn't finished?

     

    Point and click is pretty much exactly what I am thinking.  I was actually thinking more of a keyboard actuated interface, but then remembered the Adventure Studio thread and now that I am looking at it, that's what I need.

×
×
  • Create New...