Graphics modes in Atari BASIC

[rdefabri]

So I think I've finally landed on an idea for a game that I believe I can program.  The game would be turn-based, but rely on static graphics, almost like in a graphic adventure game.

 

It obviously needs to be in color, and if memory serves, in Atari BASIC, the highest resolution mode you can "access" is Graphics 7?  Is there a way to get use Antic E / Gr. 15?  I think that's the highest resolution mode with color options.

 

If you can't - do the other BASICs (e.g., Turbo BASIC, FastBASIC) let you access the "hidden" modes?

[+CharlieChaplin]

Well,

if you own an XL/XE or emulate one of these, simply type GR.15 or GR.15+16 and look what happens... 

Of course you can also use line numbers like 10 GR.15 or 10 GR.15+16 or 10 GR.31

 

[rdefabri]

Ok I see it works on an XL/XE, how does that translate backwards to a 400/800 - does it just throw an error 141 code?

[vitoco]

46 minutes ago, rdefabri said:

how does that translate backwards to a 400/800

In that case, you could use GRAPHICS 8 (+16) and then use a FOR-NEXT loop to change ANTIC F to E from the display list (pointed by vector at address 560).

 

[phaeron]

GRAPHICS 12-15 are only available with the XL/XE OS. The underlying graphics modes are supported by the hardware on all models including the 400/800, but OS-B doesn't support setting up GR.12-15. As BASICs defer to S: to set up the graphics mode, they'll all fail on these modes if run on OS-B.

 

You can edit the display list to switch the hardware mode from ANTIC F to ANTIC E, but OS-B won't know how to draw into it -- you'll be drawing 1-bit pixels on a 2-bit pixel screen.

 

[rdefabri]

15 minutes ago, phaeron said:

GRAPHICS 12-15 are only available with the XL/XE OS. The underlying graphics modes are supported by the hardware on all models including the 400/800, but OS-B doesn't support setting up GR.12-15. As BASICs defer to S: to set up the graphics mode, they'll all fail on these modes if run on OS-B.

 

You can edit the display list to switch the hardware mode from ANTIC F to ANTIC E, but OS-B won't know how to draw into it -- you'll be drawing 1-bit pixels on a 2-bit pixel screen.

 

Yea that would be a problem.  So I guess I would revert to Gr.7 if I do this.  Should work fine for what I need, just need to render the pic.

[+Stephen]

1 hour ago, rdefabri said:

Yea that would be a problem.  So I guess I would revert to Gr.7 if I do this.  Should work fine for what I need, just need to render the pic.

If these are going to be static pictures, I would recommend setting up your own display list then, and simply loading the image data to the screen.  Unless your plan was going to be using PLOT, DRAWTO, and XIO fill routines to do each image.  That way, it will work on any machine regardless of OS.  The only caveat being, the required screen RAM will double when using ANTIC E compared to D.

[rdefabri]

31 minutes ago, Stephen said:

If these are going to be static pictures, I would recommend setting up your own display list then, and simply loading the image data to the screen.  Unless your plan was going to be using PLOT, DRAWTO, and XIO fill routines to do each image.  That way, it will work on any machine regardless of OS.  The only caveat being, the required screen RAM will double when using ANTIC E compared to D.

I will definitely load the image - would be too complex to do plot / drawto / etc.  I don't know that RAM will be an issue, but always good to be frugal if I can.

 

Ideally, the image would be a digitized image, but I'm getting ahead of myself.

Edited October 24, 2022 by rdefabri

[+MrFish]

30 minutes ago, rdefabri said:

I will definitely load the image - would be too complex to do plot / drawto / etc.  I don't know that RAM will be an issue, but always good to be frugal if I can.

If you're trying to be frugal, using a character mode might be helpful. Depending on how complex the images are, they may fit into single character sets. At that point, you're just talking 1024 bytes for each set and 960 maximum bytes for screen ram (for a full-screen image).

 

As an example, the bottom portion of my slot game uses Antic 2 (BASIC Gr. 0). Each image is contained in a character set that resides in ram. Switching images just requires pointing to the necessary character set, and then loading the relatively small amount of screen data (compared to bitmapped-mode data). This also makes switching between the screens very fast.

 

    

    

 

 

Edited October 24, 2022 by MrFish

[rdefabri]

16 hours ago, MrFish said:

If you're trying to be frugal, using a character mode might be helpful. Depending on how complex the images are, they may fit into single character sets. At that point, you're just talking 1024 bytes for each set and 960 maximum bytes for screen ram (for a full-screen image).

 

As an example, the bottom portion of my slot game uses Antic 2 (BASIC Gr. 0). Each image is contained in a character set that resides in ram. Switching images just requires pointing to the necessary character set, and then loading the relatively small amount of screen data (compared to bitmapped-mode data). This also makes switching between the screens very fast.

 

    

    

 

 

That looks awesome by the way!