Commander X16

How does the basic relate to the bitmap requirements described?

Can you apply/implement what you described in the last three explanations with Basic or has
Basic set its memory limits so tightly that you should choose a different language for such
games that are super interesting.

is the basic overwhelmed?

Thanks.
greeting

All the below projects are Written in BASIC. Some with just a little ML Help some entirely in BASIC.
You be the judge of what CAN be accomplished.


Graphics Slideshow
viewtopic.php?t=6953

Crazy Tetronimoes
viewtopic.php?t=6607

Crazy Snake
viewtopic.php?t=6606

Crazy Boulders
viewtopic.php?t=6610

Crazy Lander
viewtopic.php?t=6614

Craps
viewtopic.php?t=6496

HangMan
viewtopic.php?t=6887

Audio Book: "The Origin of Species"
viewtopic.php?t=7320

Grazy Lander's is good.

Thanks.
greeting

funkheld wrote: ↑Sat Mar 23, 2024 10:16 pm Grazy Lander's is good.

They are all good, especially in the meaning of having something to rely on when new adventurers get starting to code for the X16. It is really great to have working games which one can debug and use to dive in, whether coded in BASIC, ASM or even C. Any code helps, and having a community like this one here is very valuable.

I really hope that the Commander X16 can bring back some simplicity in modern life. I don't have time to install gigabytes for games, deal with online registrations and I also don't wanna get tricked into service payments, thus I really hope there are more people out there who also wanna downsize the complications of life. And the CX16 seems to have all it needs to add its bits. Great community, great code examples, great help, thanks to everybody.

funkheld wrote: ↑Sat Mar 23, 2024 6:47 pm How does the basic relate to the bitmap requirements described?

Can you apply/implement what you described in the last three explanations with Basic or has
Basic set its memory limits so tightly that you should choose a different language for such
games that are super interesting.

is the basic overwhelmed?

Thanks.
greeting

For Basic without additional ML support routines, the default bitmap Layer0 and char/tile Layer1 is a good overall pick. And you can do quite a bit with a well designed tile layer and a pretty bitmap sitting behind them.

To use 320x200x8bpp Layer0 bitmap and 320x320x4bpp Layer1 bitmaps in Basic, you would need some helper ML routines for the Layer1 ... the Layer0 could use the Basic or Kernel routines so long as Layer1 is going to block the view of the bottom part of the Layer0 display.

But that's part of the benefit of the approach of Basic supplemented with ML support routines ... you can develop that incrementally, starting in Basic and then identifying bottlenecks and working out SYS routines to help with those.

As I recall, there's a lot of room still available that was reserved for the ROM.

And even without such official platform support, I could see someone creating something along the lines of the old DOS extenders....

Like there are proficient developers in the community, someone was asking about using BASIC to manipulate the odder combinations of VERA settings, there's no particular reason that the person that develops the ML routines has to be the one who would be using them from BASIC ...

The main bottleneck would be really identifying what is needed most, how the API should work, etc...

But like my personal project I am working on needs to extend the sprite capability... Organizing the sprites into up to 255 Z layers and doing more then 128 sprites by efficient copying in software...

Which I could 100% see someone making use of that from basic and maybe making a space shooter or something... I dunno, I only know why I need it.

At least this copying sprites around should work.. the blitter is still theoretical since I got distracted playing around with color quantization and dithering stuff... In Python... So can prep files on another machine to import into x16 code...


Anyway, my ADHD aside, I'm all for helping or advising on making libraries, modules, loaders, TSRs, etc etc...as I can find time...

I recall a few that were critical of the x16 being desirable as an educational platform to learn computer stuff on... And maybe we're all just nostalgic for this stuff cuz we had something sorta like it back in the day... But the lower you can make the requirements to get really into it, the more people will find themselves in this rabbit hole with us.

hstubbs3 wrote: ↑Sun Mar 24, 2024 4:39 am
But like my personal project I am working on needs to extend the sprite capability... Organizing the sprites into up to 255 Z layers and doing more then 128 sprites by efficient copying in software...

At least this copying sprites around should work.. the blitter is still theoretical since I got distracted playing around with color quantization and dithering stuff... In Python... So can prep files on another machine to import into x16 code...

Just a suggestion: I'm looking at copying Sprites around myself. Take a look at memory_copy ($FEE7)


On the Graphics layer side I have also found GRAPH_draw_image ($FF38)useful (It's basically bit_blt or Put_Image).

The current GRAPH_draw_image is not "BANK Aware" thus when blitting from BRAM you are limited to 8192 bytes (Practical limit a 90x90 or 100 x 81 image). That's still a bigger image than a 64 x 64 Sprite. In the Newest ROM build MooingLemur has extended the routine to be "BANK Aware" So it can blit up to a full Screen 320x240 image. It takes about 14 Jiffies to Blit a Full Screen Image to the Graphics Layer if it is preloaded in Banked RAM. With a 100x75 image I'm blitting >15 fps. https://cx16forum.com/forum/viewtopic.php?t=7191


At the risk of Blatant self promotion. GRAPH_draw_image is used in HANGMAN when showing the Body Parts I'm loading from BitMap. It's also used in the 'FLAWLESS VICTORY" Animation. I don't use any Sprites in HANGMAN at all.

Hi good afternoon.

I loaded the latest x16 from Artifacts.

where does that appear please:
BANK Aware



Thanks.
greeting

Where did you hide the 4 values, I can't find them.
what do the values mean please?

$FF38 :
r0 r1 r2 r3 r4

REPBLIT:
BANK GRAPH.BANK
SYS GRAPH.DRAW.IMAGE:RETURN

thanks

funkheld wrote: ↑Sun Mar 24, 2024 12:12 pm Where did you hide the 4 values, I can't find them.
what do the values mean please?

$FF38 :
r0 r1 r2 r3 r4

REPBLIT:
BANK GRAPH.BANK
SYS GRAPH.DRAW.IMAGE:RETURN

thanks

the "r" variables are set in the GOSUB SetRegVars
BANK x: Switchs the Ram Bank so that address from $A000-$BFFF are mapped to the Bank indicated.

Current Ram Bank can be determined by Peek(0). (Treat BANK 0 as READ ONLY !! This is used by the ROM)

GRAPH.BANK is a variable where I'm keeping track of the BANK I'm using.

GRAPH.DRAW.IMAGE is a variable holding the Entry Vector for GRAPH_draw_image in the system ROM ($FF38)

SYS (Address) Calls a Machine language routine at (Address). Can be ROM or user installed. The CPU registers are loaded from the BASIC Register Cache values at $030C, $030D, $030E & $030F. Those are reloaded on System return. (In my Code A.REG, X.REG,Y.REG & C.REG)