Newbie 7800basic questions

[Turbo Laser Lynx]

Hi, guys! First of all I want to thank everyone that's been involved in creating 7800basic, it's so much fun playing around with such an easy to use fantastic game framework for a "retro system". There's not many that are this good and has this great documentation! ? ?

Could anyone kindly help me of a couple of basic questions if you'd happen to know them from the back of your head? (I'm using mode 160A by the way). I have been reading the random terrain documentation quite a lot already, but it's too much taking in everything at once.

1. If I use tallsprite, do all the parts of the tallsprite have to use the same palette? I already managed to stack two separate sprites for more colors of a main character, but I was thinking that maybe tallsprite is more "efficient in the background" or something. There seems to be a bit of flickering on my main character that didn't go away with using doublebuffer either, so maybe I coded the animation functionality in a stupid way, will try mksmiths animation examples next time I have coding-time.

2. How is the frame parameter of plotsprite "connected" to the imported images / sprites? So if I increment the frame variable, where does it take the next image/frame from? Has it something to do with naming the sprites sprite_1, sprite_2 etc. or is it the order they are imported or perhaps location in memory? I wasn't able to wrap my head around how this animation line is working either (from the plotmapfile example), the variable temp1 is then used as the frame parameter in plotsprite:

temp1=(herodir*2)+((walkframe/16)&1)

it's probably not that hard but trying to program tired, late at night after the kids have fallen asleep isn't always that easy.

3. What would be a smart "keeping it simple" way of making a title screen? Should I just draw the title screen in some pixel art program and split it up into 16x16 parts and draw it on screen with characters or sprites? I saw @KevinMos3  great looking remake of the Rampage title screen, is that done in 160A or something else? I wasn't able to scale the picture properly and put up a grid to analyze how many colors there is in it. Also the Xenophobe title screen looked really cool, but was too tired to understand the graphics mode used. I already read the thread about bankswitching so I'm being optimistic in being able to pull that off in some simple way (but it seems it can get hard when rom gets stuffed).

 
4. What is the meaning of the numbers and the palettes under the sprites/characters in the "plotmapfile" example? Does it have to be there or can I get rid of it (does it eat rom/memory)?



Thanks for any hints/replies!

Edited September 25, 2020 by Turbo Laser Lynx

[RevEng]

Thanks for the kind words on the language and docs! Some answers to the questions...

 

1. All of the parts of tallsprite use the same palette, so to use unique palettes for different sprite sections, you'd need to manually drawsprite the different sections yourself. tallsprite is slightly more efficient than issuing 2 plotsprite commands, but it's such a small amount that it's not worth worrying about. I think whatever issue you're running into is separate from plotsprite efficiency.

 

2. the frame parameter literally tells plotsprite to take the base image location in memory, and add frame*sprite_width to it. Which sprite that actually is depends on how you're incgraphic'ing them into memory.

 

the "temp1=(herodir*2)+((walkframe/16)&1)" animation frame example is perhaps a bit too fancy for example code. Split into 2 parts... the left-hand side of the calculation "(herodir*2)" either returns 0 or 2, depending on if the player is facing left or right. The right-hand side of the calculation ((walkframe/16)&1) basically divides the walkframe animation so the character walking doesn't animate too fast. The "&1" is a bitwise operation that says to throw away all bits from the value except the lowest one, to ensure the value used to control the walking animation is always 0 or 1.

 

Putting that together, walking in one direction will change the frame from 0 to 1, and walking in the other direction will change the frame from 2 to 3.

 

While it shouldn't be done at all cost, using calculation instead of if...then is typically more efficient. (in 7800basic, and other languages too) Here too I'd say the efficiency in one bit of code isn't worth worrying about, but if the code in question is at the heart of a looped routine that displays a bunch of enemies, small efficiencies become magnified.

 

3. you can break the title screen graphics into characters like you describe, but you have a hard limit of 256 characters. (or 128 characters if you're using double-wide chars) This is adequate for some graphic designs, and insufficient for others. incbanner was written to translate your image into sprites instead, to overcome that limitation (but yes, all in one palette, and not as rom efficient compared to carefully repeated characters used as compression)

 

This obviously depends a lot on the game design, but generally speaking ROM is usually the least problematic constraint on the 7800. You can always use a format with more ROM, with very little cost-impact on physical cart production. CPU, RAM, Maria DMA, and palettes tend to be more precious.

 

4. you can get rid of the numbers. They're just there to illustrate where the natural character boundaries are. When the last bit of an image is less than a full zone height, 7800basic doesn't import that last part. This allows you to include small notes or palette samples in the images. Up to you, and using it or not using it doesn't impact your rom usage.

[Turbo Laser Lynx]

Thank you very much for taking the time and answer all my questions in detail! ? This clears everything up for me, very kind of you! And sorry for taking long to answer back, I was exhausted after a long week at work so I fell asleep early last night.

 

On 9/25/2020 at 8:05 PM, RevEng said:

Thanks for the kind words on the language and docs! Some answers to the questions...

 

1. All of the parts of tallsprite use the same palette, so to use unique palettes for different sprite sections, you'd need to manually drawsprite the different sections yourself. tallsprite is slightly more efficient than issuing 2 plotsprite commands, but it's such a small amount that it's not worth worrying about. I think whatever issue you're running into is separate from plotsprite efficiency.

Ok, thanks, good to know! I will use separate sprites and look over the animation code.

 

Quote

2. the frame parameter literally tells plotsprite to take the base image location in memory, and add frame*sprite_width to it. Which sprite that actually is depends on how you're incgraphic'ing them into memory.

I assume this means the order you incgraphic them into code then, because you can't set a specific memory address with incgraphic? ? (I will test it out).
 

Quote

the "temp1=(herodir*2)+((walkframe/16)&1)" animation frame example is perhaps a bit too fancy for example code. Split into 2 parts... the left-hand side of the calculation "(herodir*2)" either returns 0 or 2, depending on if the player is facing left or right. The right-hand side of the calculation ((walkframe/16)&1) basically divides the walkframe animation so the character walking doesn't animate too fast. The "&1" is a bitwise operation that says to throw away all bits from the value except the lowest one, to ensure the value used to control the walking animation is always 0 or 1.

 

Putting that together, walking in one direction will change the frame from 0 to 1, and walking in the other direction will change the frame from 2 to 3.

 

While it shouldn't be done at all cost, using calculation instead of if...then is typically more efficient. (in 7800basic, and other languages too) Here too I'd say the efficiency in one bit of code isn't worth worrying about, but if the code in question is at the heart of a looped routine that displays a bunch of enemies, small efficiencies become magnified.

Thanks for clearing that out. Ahaa, that's interesting! Actually I didn't know that. I haven't read that in any code optimizing tips for old computers and consoles either, but it makes sense so very interesting and good to know. However my brain ties to a knot trying to think about it in that approach haha, it's having to think about solving different problems in a whole new approach. I'm trying to think of doing platforms "mathematically" with as little logic operators as possible, but my brain draws a complete blank! I guess it gets easier when you get used to it, even the walkframe=1 walkframe=0 thing took a while to decipher for me. Actually I found this now, will have to read it tonight: https://atariage.com/forums/blogs/entry/11915-7800basic-tutorial-sprite-and-tile-interactions/
 

Quote

the "temp1=(herodir*2)+((walkframe/16)&1)" animation frame example is perhaps a bit too fancy for example code. Split into 2 parts... the left-hand side of the calculation "(herodir*2)" either returns 0 or 2, depending on if the player is facing left or right. The right-hand side of the calculation ((walkframe/16)&1) basically divides the walkframe animation so the character walking doesn't animate too fast. The "&1" is a bitwise operation that says to throw away all bits from the value except the lowest one, to ensure the value used to control the walking animation is always 0 or 1.

 

Putting that together, walking in one direction will change the frame from 0 to 1, and walking in the other direction will change the frame from 2 to 3.

 

While it shouldn't be done at all cost, using calculation instead of if...then is typically more efficient. (in 7800basic, and other languages too) Here too I'd say the efficiency in one bit of code isn't worth worrying about, but if the code in question is at the heart of a looped routine that displays a bunch of enemies, small efficiencies become magnified.

 

 

Yeah I've started to notice that rom is usually the least of problems now a days on old systems, thanks for notifying me on incbanner as well! I got to try out some bankswitching and see if I can get that to work in an early stage for intro screen -> different level graphics -> ending etc.
 

Quote

4. you can get rid of the numbers. They're just there to illustrate where the natural character boundaries are. When the last bit of an image is less than a full zone height, 7800basic doesn't import that last part. This allows you to include small notes or palette samples in the images. Up to you, and using it or not using it doesn't impact your rom usage.

Ok, thanks for this. Pretty handy feature actually!

My brain is on full retro-steam right now so unfortunately I came up with a bunch of follow up questions if someone would be so kind to help me out:

5. Is it possible to incorporate TIA sound effects and pokey music at the same time in a 7800basic game? That'd be pretty amazing. Probably the best sounding sfx chip (TIA) combined with one of the best sounding music chips (Pokey).

6. Is it possible to import pokey music from some widely used pokey tracker to 7800 basic?

7. Does the background color always "leak" to the top and bottom of the screen outside "screen boundraries", or is it just BupSystem? I saw this in some other thread, but can't find it anymore.

By the way, I was a bit bummed that Aseprite (really fantastic pixel art program) png's didn't work in 7800basic. It has indexed color mode and they work for me on the Atari Lynx, but I had to import the png's to gimp afterwards and export them from there for them to work (otherwise the 7800basic compiler complained about too many colors). I'm not complaining though, I have no idea how png's even work, so still happy it works at all for me and 7800basic is fantastic. ^^

Edited September 27, 2020 by Turbo Laser Lynx

[+SmittyB]

1 hour ago, Turbo Laser Lynx said:

Is it possible to incorporate TIA sound effects and pokey music at the same time in a 7800basic game?

Yep, the TIA and POKEY are completely independent so you can do whatever you want with either or both.

 

1 hour ago, Turbo Laser Lynx said:

Is it possible to import pokey music from some widely used pokey tracker to 7800 basic?

Maybe, but 7800BASIC doesn't provide any tools for this so it would be up to you to do the hard work of importing the music data and writing a tracker for it.

 

1 hour ago, Turbo Laser Lynx said:

Does the background color always "leak" to the top and bottom of the screen outside "screen boundraries", or is it just BupSystem? I saw this in some other thread, but can't find it anymore.

Yes, and this isn't unique to the 7800. BupSystem will show you more of the overscan area that wouldn't normally be shown on older NTSC TVs compared to other emulators. The higher resolution of PAL signals mean that the overscan area will always be visible and is what people refer to when they talk about 'borders' on PAL games.

Unless your background colour is always flashing or something you shouldn't worry too much about making the overscan area look good.

[Turbo Laser Lynx]

Thanks for taking the time to answer SmittyB ?

 

6 hours ago, SmittyB said:

Yep, the TIA and POKEY are completely independent so you can do whatever you want with either or both.

That's pretty fantastic!

 

Quote

Maybe, but 7800BASIC doesn't provide any tools for this so it would be up to you to do the hard work of importing the music data and writing a tracker for it.

Oh damnation! *Cries a river*. I feel a few nice looking games with TIA sfx and "euro 8-bit style" pokey music (with a lot of bubbly arpeggios etc.) could really remove a lot of clueless, unjustified presumptions about the 7800. Of course I wasn't asking someone else to do it, but unfortunately I'm a lousy low level coder at this moment, so I just have to wish really hard every night and day that it becomes reality sometimes in the future.

(I've done a tiny bit of assembly experimenting on the C64, and I understand the concept of poking stuff into different memory addresses, and It's a lot of fun in tiny doses, but it becomes masochistic pretty fast for me at least. It might be the lack of free time in this stage of life that is the problem or perhaps I'm only 10% technical and 90% artsy (fartsy). Sometimes I think the low level stuff is something that should've been learnt at a young age when you had much free time and/or you have to be really intelligent / fast thinking and have good memory. These things become impossible when trying to do them late at night borrowing time from sleep).

 

Quote

Yes, and this isn't unique to the 7800. BupSystem will show you more of the overscan area that wouldn't normally be shown on older NTSC TVs compared to other emulators. The higher resolution of PAL signals mean that the overscan area will always be visible and is what people refer to when they talk about 'borders' on PAL games.

Unless your background colour is always flashing or something you shouldn't worry too much about making the overscan area look good.

Ok, thanks for the info.

One more follow up again if I may:

I saw that examples contained "set tv", but I couldn't find anything on the command in the 7800basic guide. I tried changing it to pal and changing BupSystem to pal, but the colors didn't change for some reason (only the speed). Does anyone know what's going on there? I mean looking at the different ntsc and pal palettes there should be some visible change at least in some of the colors. ?
 

 

[+SmittyB]

I don't know for sure but I think the 'set tv' command isn't used any more but is still valid to allow legacy code to compile. If I recall correctly the system has a minimum amount of zones for the video signal to be built correctly and it slightly differs between PAL and NTSC, but I believe newer versions of 7800BASIC can detect which is needed and build the display accordingly.

[RevEng]

Thanks, SmittyB.

 

Technically speaking the "set tv" was never used to modify 7800basic code itself, nor does it need to. What "set tv" does is set the a78 ROM header to NTSC or PAL, but I believe none of the emulators are actually looking at this flag anyway. So no real benefit to using it.

 

For the issue at hand, It's quite possible that bupsystem is just using the same palette for NTSC and PAL modes. Try the same experiment with a7800 instead.

[Turbo Laser Lynx]

22 hours ago, RevEng said:

For the issue at hand, It's quite possible that bupsystem is just using the same palette for NTSC and PAL modes. Try the same experiment with a7800 instead.

 

On 9/28/2020 at 3:59 PM, SmittyB said:

If I recall correctly the system has a minimum amount of zones for the video signal to be built correctly and it slightly differs between PAL and NTSC, but I believe newer versions of 7800BASIC can detect which is needed and build the display accordingly.

Thanks guys! a7800 indeed shows the palette differences. I'm just trying to figure out in my head if there's a simple way to make a game pal and ntsc compatible with the end goal to puzzle together a game template from the 7800 basic examples/samples that includes everything "end to end" that you'd need for a "real" game, but as minimal as possible, so you could use it as a starting point for more games later. Including all the things you need like drawing a screen, moving a sprite around, sfx, music, game states (intro screen, game, game over), bankswitching, pal/ntsc compability and probably more things that I don't come to think of now. I know it might be a bit rigid approach for good programmers, but a must have for programmitically less inclined types (like me haha).

I found the paldetected variable in the guide now (aah, 7800basic is so deluxe! ?). I'm unsure what the frame skip example does. I guess it skips frames to make pal games run as fast as ntsc games (by skipping frames). Is it really that easy? Then you can use the variable to set palettes for the different formats too.

 

Edited September 29, 2020 by Turbo Laser Lynx

[Turbo Laser Lynx]

Btw. What is the best way to pick up fruits or coins drawn with characters / plotmapfile? I tried using pokechar to just fill the coins with blanks, but I couldn't get anything to change on screen, so I think my "mapdata" parameter might be wrong.

Quote

mapdata is a RAM memory area that you defined with dim.

But I don't know where the map data is with plotmapfile or how to reference the different tilesets ? or would it be better to plot characters on top with plotchar? Or perhaps even use sprites for collectable objects?

Edited September 29, 2020 by Turbo Laser Lynx

[+SmittyB]

When you import a map that is stored in ROM and is fixed. The 7800 can try to write to ROM but nothing changes because that is the nature of ROM.

What you need to do is copy your map data into RAM which can be modified and to make sure that when you draw your maps you're drawing the copies in RAM and not ROM.

That's the gist of it at least.

[TailChao]

On 9/28/2020 at 10:43 AM, RevEng said:

For the issue at hand, It's quite possible that bupsystem is just using the same palette for NTSC and PAL modes. Try the same experiment with a7800 instead.

It shouldn't be...

 

...and upon investigation - the palette isn't getting recalculated upon a region switch. You can force this by navigating to Options -> Maria (Video) -> Adjust Color... (F4) and clicking "Default" or restarting the program. My bad, I'll cross post this to the BupSystem topic.

[RevEng]

8 hours ago, Turbo Laser Lynx said:

I found the paldetected variable in the guide now (aah, 7800basic is so deluxe! ?). I'm unsure what the frame skip example does. I guess it skips frames to make pal games run as fast as ntsc games (by skipping frames). Is it really that easy? Then you can use the variable to set palettes for the different formats too.

It's a bit game-dependant on how you would handle ntsc/pal frame-rate differences. Some games are turn-based and may not require any change at all, others need adjustment of all object speeds, and then there's a bunch of in-between scenarios. So I couldn't make a one-size-fits-all solution for timing conversion.

 

The idea behind the example is that if the sysem isn't pal, then it skips every 6th frame, which is basically converting NTSC systems to PAL frame-based timing, by updating at 5/6th the usual speed.

 

If you want to go the other way, using NTSC frame based timing, and convert to PAL, every 5th frame you can run any logic required to reposition objects twice. (with just one plot and drawscreen) That will move PAL at 6/5th the normal rate. Salvo uses this technique, for the most part.

[Turbo Laser Lynx]

Thanks for your continued help and patience guys!

 

6 hours ago, SmittyB said:

When you import a map that is stored in ROM and is fixed. The 7800 can try to write to ROM but nothing changes because that is the nature of ROM.

What you need to do is copy your map data into RAM which can be modified and to make sure that when you draw your maps you're drawing the copies in RAM and not ROM.

That's the gist of it at least.

 

I'm not exactly a coding prodigy, but I do know what ROM is. I was hoping that perhaps 7800basic copies the screen to ram automagically when you do plotmapfile, because on quite a few old systems you have to put the data into screen ram for it to work at all (like for example on the Vic-20, C64, Atari Lynx), but yes, I confess I'm not properly read up on the 7800.

What I really don't understand is where/how real programmers gather their info like I'm not able to interpret this:

Quote

   memcpy destination source number_of_bytes

Where…

 

destination is a RAM based memory area that you defined with dim.

How can I know not to overwrite something in RAM that 7800basic has put there? Or where in RAM to put the tilemap at all? And how do I define the area with dim? ? Oh wait that seems to be with alphachars! But if I put all tiles into one image I can only use one palette right?

Anyway, I think my question should really have been: Is there an easy way in 7800basic to use plotmapfile and being able to change or remove a few of the background characters? If not, what's the easiest way of drawing a background + being able to use all the palettes for the characters, and being able to change/remove a few bg characters? Or do you have to have deep understanding of the 7800 and 7800basic to do it? I like keeping it simple if possible, so if it's complicated I could probably just use sprites for the coins, since I'm not looking to move that much stuff on screen and Maria seems to be quite a sprite pusher.

 

Also it seems perhaps peekchar might be important for collision and platforms (I guess you could use some other method too but). https://atariage.com/forums/blogs/entry/11915-7800basic-tutorial-sprite-and-tile-interactions/

 

 

4 hours ago, RevEng said:

The idea behind the example is that if the sysem isn't pal, then it skips every 6th frame, which is basically converting NTSC systems to PAL frame-based timing, by updating at 5/6th the usual speed.

Ahaa, I got it mixed up, I thought it was the other way around. Thanks for explaining and clarifying!

By the way @RevEng I meant to say earlier that Time Salvo is such a fun, polished game, and combined with the cover art and the cartridge, wow what a great release for the 7800!

It took me a few late nights but this is what I've got so far, in fact it is also supposed to be about a time traveller. I think most of the time I was fighting gimp and aseprite, but got them setup now for a better flow.

 

Also duh, I had a = missing as in >= in my animation, so there was always one frame where nothing was shown, that's why my sprite was flickering.

 

It's so much fun programming with 7800basic, one could only hope there would be this fantastic game development frameworks for more retro systems.

Edited September 29, 2020 by Turbo Laser Lynx

[+SmittyB]

49 minutes ago, Turbo Laser Lynx said:

How can I know not to overwrite something in RAM that 7800basic has put there?

You can freely use the locations defined by a-z, var0-var99, $2200 to $27FF, and any on-cartridge RAM without interference from anything else.

 

52 minutes ago, Turbo Laser Lynx said:

Or where in RAM to put the tilemap at all?

Wherever it will fit. In the $2200 to $27FF range would make sense as you want a big chunk of RAM for it.

 

54 minutes ago, Turbo Laser Lynx said:

And how do I define the area with dim?

Dimensioning variables is really just giving a name to an address, that way your code can use that name as a start point and then use an offset to get to the bits you're interested in.

 

For example here's a bit that stores the HUD in Spire of the Ancients. The tilemap for the HUD starts at $2223, and is 160 bytes because it's 40 bytes per line and 4 lines long. All I need to do to populate it is call 'memcpy hudTileMap HUDMap 160' to copy 'HUDMap' from ROM to the designated area in RAM.

Even though the HUD data goes to $22C3 I can freely define any part afterwards as it's up to me to know that if I change something there it will affect what's been drawn and I can use that to my advantage by giving names to specific parts of the HUD I want to reference rather than remembering 'hudTileMap+85' is where the HP value is drawn.

To get it on screen I just use the two commands 'plotmap hudTileMap 0 0 0 27 4 0 0 40' and 'plotmap hudTileMap 0 108 0 13 4 27 0 40' to draw it in two halves.

dim hudTileMap = $2223
dim mapName = $224C
dim HUDHP = $2278
dim HUDStr = $2280
dim HUDArm = $2288
dim HUDMP = $22A0
dim HUDFoc = $22A8
dim HUDLck = $22B0	
dim HUDLine1 = $2253
dim HUDLine2 = $227B

dim leftItemTopLeft = $2267
dim leftItemTopRight = $2268
dim leftItemBottomLeft = $228F
dim leftItemBottomRight = $2290

dim rightItemTopLeft = $226B
dim rightItemTopRight = $226C
dim rightItemBottomLeft = $2293
dim rightItemBottomRight = $2294

 

1 hour ago, Turbo Laser Lynx said:

But if I put all tiles into one image I can only use one palette right?

It depends on how hands-on you want to be.

Plotmapfile will effectively draw multiple objects with different palettes for you using a parameter on the incgraphic command as a guide for which to use, but you could do that yourself with several calls to plotmap and specifying the palette directly. If you wanted to get really into it, plotmap is essentially several calls to plotchars to simplify drawing tiles over several zones.

[+SmittyB]

1 hour ago, Turbo Laser Lynx said:

I was hoping that perhaps 7800basic copies the screen to ram automagically when you do plotmapfile, because on quite a few old systems you have to put the data into screen ram for it to work at all (like for example on the Vic-20, C64, Atari Lynx)

This is in my opinion one of the most underrated advantages the 7800 has over systems it's usually compared to like the NES. It doesn't care where your data is, if you tell it to draw something it will with no stupid VRAM limits to get in the way. Static objects that never change? Do it from ROM. Want to change your tilemap on the go? Read it from RAM. Want to directly change the graphic data on the fly for some neat scrolling effects? Stick it in RAM, tell the system where to look, and off you go. 

[Turbo Laser Lynx]

21 hours ago, SmittyB said:

You can freely use the locations defined by a-z, var0-var99, $2200 to $27FF, and any on-cartridge RAM without interference from anything else.

 

Wherever it will fit. In the $2200 to $27FF range would make sense as you want a big chunk of RAM for it.

 

Dimensioning variables is really just giving a name to an address, that way your code can use that name as a start point and then use an offset to get to the bits you're interested in.

 

For example here's a bit that stores the HUD in Spire of the Ancients. The tilemap for the HUD starts at $2223, and is 160 bytes because it's 40 bytes per line and 4 lines long. All I need to do to populate it is call 'memcpy hudTileMap HUDMap 160' to copy 'HUDMap' from ROM to the designated area in RAM.

Even though the HUD data goes to $22C3 I can freely define any part afterwards as it's up to me to know that if I change something there it will affect what's been drawn and I can use that to my advantage by giving names to specific parts of the HUD I want to reference rather than remembering 'hudTileMap+85' is where the HP value is drawn.

To get it on screen I just use the two commands 'plotmap hudTileMap 0 0 0 27 4 0 0 40' and 'plotmap hudTileMap 0 108 0 13 4 27 0 40' to draw it in two halves.

dim hudTileMap = $2223
dim mapName = $224C
dim HUDHP = $2278
dim HUDStr = $2280
dim HUDArm = $2288
dim HUDMP = $22A0
dim HUDFoc = $22A8
dim HUDLck = $22B0	
dim HUDLine1 = $2253
dim HUDLine2 = $227B

dim leftItemTopLeft = $2267
dim leftItemTopRight = $2268
dim leftItemBottomLeft = $228F
dim leftItemBottomRight = $2290

dim rightItemTopLeft = $226B
dim rightItemTopRight = $226C
dim rightItemBottomLeft = $2293
dim rightItemBottomRight = $2294

 

 

Thank you so much once again! This really explains it. I should've known or realised to check variables in the guide, so sorry about that. It makes sense that you can put them at specific locations in ram. But again one step wiser about Atari 7800 programming thanks to you.

 

Quote

It depends on how hands-on you want to be.

Plotmapfile will effectively draw multiple objects with different palettes for you using a parameter on the incgraphic command as a guide for which to use, but you could do that yourself with several calls to plotmap and specifying the palette directly. If you wanted to get really into it, plotmap is essentially several calls to plotchars to simplify drawing tiles over several zones.

 

It would be nice to have full control over the map(s) obivously, but on the other hand it's so convenient when it draws the whole thing automatically. I will have to see, if the game for some reason would get too sprite heavy I will be forced to learn this.

 

21 hours ago, SmittyB said:

This is in my opinion one of the most underrated advantages the 7800 has over systems it's usually compared to like the NES. It doesn't care where your data is, if you tell it to draw something it will with no stupid VRAM limits to get in the way. Static objects that never change? Do it from ROM. Want to change your tilemap on the go? Read it from RAM. Want to directly change the graphic data on the fly for some neat scrolling effects? Stick it in RAM, tell the system where to look, and off you go. 

 

That is really nice! (Actually I wrote a bit carelessly earlier about the Lynx, it doesn't have video ram, you can put aside ram for the screen wherever you want, but anything and everything that you want to use has to be copied into ram first from rom).

 

[Turbo Laser Lynx]

On 9/30/2020 at 1:40 AM, SmittyB said:

It depends on how hands-on you want to be.

Plotmapfile will effectively draw multiple objects with different palettes for you using a parameter on the incgraphic command as a guide for which to use, but you could do that yourself with several calls to plotmap and specifying the palette directly.

Woohoo! I managed to memcpy a map into ram and to use plotmap to draw it out + changing palette in the correct positions. Also I got peekchar working for collecting stuff and almost for platforms (the platforms still need some tweaking to work 100% with the fake gravity, but the peekchar part is working). Thanks again for all the help, pointing me in the right direction.

[+SmittyB]

Glad to hear it.