7800basic beta, the release thread

[Synthpopalooza]

I got a question:

 

I want to make a chess-like game for the 7800 using this language. It would need about 33 pieces for each side, placed onto a gameboard, and each of these would need to be moveable. They would only be moved during each player's turn. Would it be best to do all of these as sprites?

[+RevEng]

Question: Can the double-buffering be done at 60 fps?

 

Had an idea for a demo which could increase the number of colors onscreen at once by swapping out charactermaps and/or palettes at 60 fps.

Just to be sure we're talking the same language... You can switch the buffers every TV frame, so the switching happens at 60 fps. (for NTSC)

[+SmittyB]

I got a question:

 

I want to make a chess-like game for the 7800 using this language. It would need about 33 pieces for each side, placed onto a gameboard, and each of these would need to be moveable. They would only be moved during each player's turn. Would it be best to do all of these as sprites?

 

 

That would depend on just how complicated you want to make it graphically. An 8*8 chess grid could be made to fill a good portion of the screen by having a 24*24 tilemap giving you a 3*3 tile area to draw your pieces. You could then try and fit each piece and board colour combination in the current character set so it's entirely tile based. If you wanted to have a piece move between spaces on the board smoothly you could then remove it from the tilemap and draw a sprite copy in its place, animate it, then edit the tilemap to have it in its final position.

 

Though I don't know how well the 7800 would cope I'd be tempted to have a tilemap for the board, a tilemap for one side's pieces, and another tilemap for the other side's pieces too. That way the board can stay static, and I could reuse graphics for both players by just having different palettes for each of their tile maps.

If, after that I was still under the zone's object limit by a decent amount I would have the piece graphics overlap the grid 'behind' by having the lower portion be drawn via the tilemap, and the upper, overlapping portion being a sprite. This would give a nice 3D effect as long as it wasn't over-used.

[+RevEng]

@Synthpopalooza, I missed your chess-game question last night while I was responding to the other.

 

As SmittyB said, it depends on how you want your chess board to look/play. A few things to keep in mind here...

• Avoid any scheme that involves nearly a full screen/line of characters being plotted over another screen/line of characters. MARIA doesn't have enough DMA rendering time to cope.
• For 7800basic the sprite-count limit for non-double-buffered display is in the low-to-mid 20's. This is due to CPU running out of time prior to the visible display.
• Any sprite you "savescreen" to the display list doesn't have to be redrawn and count against that limit in subsequent frames. If you really want to get tricky, you can modify a sprite's display list entry to change it's data, palette, and horizontal position. (including off-screening it)

You could certainly draw your pieces as tiles. Just keep in mind you'd have to make 2 sets of tile graphics for most pieces, one against a dark checkerboard background, and one against a light checkerboard background. This is a bit wasteful of your color indexes in the graphics data, since you lose one index. You'll also need an index for each player's color too.

 

An alternative idea for pieces=tiles springs to mind - you could plot each row of the chess board background as a large sprite, and then plot the character buffer on top, and then bake it all into the DL with "savescreen". This is a bit wasteful of ROM, but then you wouldn't have to bother with incorporating chess-board background colors in your chess-piece tile data.

 

If you use pieces=tiles, the main advantage is moving pieces is extremely fast. You just need to update the character buffer in memory, without using any plot* commands at all.

 

But if this were my game I think I'd be tempted to just turn on double-buffering, and draw all of the pieces as sprites. Even if it takes a couple frames to flip buffers, it's just a slow moving game of chess. It also means you have more than a tile's width and height available. You could even make the pieces a few sprites tall and plot them in reverse Z order, similar to SmittyB's idea, for a pseudo 3D effect. Or go whole hog and actually draw the board in 3D.

 

For double-buffering, you'll want to either use "set extradlmemory on" to sacrifice RAM at $2200+, or use on-cart memory with "set dlmemory $START $END.

 

If the chess-piece sprites do overlap vertically, just keep in mind you'll need enough memory for 21 or 22 display objects in each zone. 7800basic will report how many display objects per zone you get, as a game compilation message. Using double buffering and "set extradlmemory on" (with zones that are 16 lines tall) you should get 23 objects. A bit tight, but do-able. (with on-cart memory, you can do ~50 display objects per zone)

 

BTW, either way you do this, I think a chess game is a nice addition to the 7800 library.

[Synthpopalooza]

Well it's going to be different from Chess.

 

First off its a 15x15 board with lots of off board areas. I have pac-man-red working up some graphics and it will look good of course. Each side has 36 pieces to work with.

 

This is an original strategy game a friend (now deceased) and I invented in the 1990s but never got produced. An actual board and set of pieces do exust.

 

I will start a thread soon and post some graphics to give you an idea ...

[+frankodragon]

A suggestion for a future build of 7800. How about extra plotvalues like score2 and score3? Sometimes I use score1 as a counter to plot sprites or use it for 'if..then' codes instead of using it as a 2nd player's score. At times though I'd like to have an extra visible counter for extra code, debugging, etc.

[Mord]

Rather than add a few extra special purpose variables, might be a better option to just make a way to declare a "score" variable as needed?

[+RevEng]

Sure, sounds like a good idea. I think the way I'll implement it is to just rely on the game code to dim it's own extra "score#" variables. (keeping in mind each one will require the next 2 bytes to be free). The math routines will be made to treat any "score#" variable as a 24-bit number. That will give you up to 10 scores. (more if I allow alphas in that # character)

[+RevEng]

New Release: I added in the code to handle multiple score variables, and I fixed the issue with "set zoneprotection on" not working with double buffering turned on.

 

As always, download it from 7800.8bitdev.org.

[+Random Terrain]

The differences between the latest PDF and the one before it were checked using WinMerge. The only two places that seemed to have changes were The Score Variables and BCD Variables section and the Random Numbers section. If you think I missed something or screwed something up, please let me know.

 

Thanks.

[Synthpopalooza]

OK, a question ...

 

I am working with my Sky Scraper game again, and I wanted to set the screen resolution to 208. I did this, and the bottom two rows of the screen (there are 26) aren't getting printed. Have I done something wrong here?

 

The other question is, is there anyway that the unused space to the right of the screen can be used for a scoring area? How would I go about printing to this area?

 

 

ramcharmap3.bas

ramcharmap3.bas.bin

[Mord]

Printing to the right side of the screen just means you'd set the horizontal position at a higher value than 0. Right now you're using 0 I believe for your map.

 

For the bottom of your map not showing up, going over the code I'm guessing you didn't update how much to read from rom to ram in your loadlevel routine? It's saying 768 bytes, which would be consistent with 24 zones of 32 bytes.

[Synthpopalooza]

I am using 160B mode for chars, which reduces the number of horizontal chars to 32. As it stands now nothing can be printed past that limit, if my understanding is correct.

[+RevEng]

I am using 160B mode for chars, which reduces the number of horizontal chars to 32. As it stands now nothing can be printed past that limit, if my understanding is correct.

You can put anything you want to the right of those 32 160A/B characters - more characters or sprites. You just need to use a plot* command with an X coordinate over in that part of the screen.

 

Try not to think of it as an A8 full-screen character-mapped display, because it's not. On the 7800, you plot an character-buffer object, and it's positioned as you want, and covers as much (or as little) screen area as you want (up to 32 bytes wide - plot 2x objects if you want a buffer that covers more than 32 bytes). Currently you have one plotted object that displays 32 chars wide, but that doesn't stop you from plotting more.

[Inky]

Does 7800 Basic allow for use of the 2600 Driving controllers?

[Dauber]

Given that it's not paddle-compatible, I'd doubt it, unless the driving controller uses similar readings as the joystick does....(which could theoretically be possible -- Indy 500 can work from the joystick, right??)

[Mord]

7800Basic doesn't stop you from tinkering with all the registers even if there are no built in commands for paddles/driving controllers so technically it would be possible to do a driving game with 7800Basic.

 

However from what I remember the 7800 itself isn't too suitable for paddle type controllers since the program has to reliably poll the proper ports repeatedly to get an accurate value. (From what I remember from probably a decade ago when I last looked at paddle stuff) As a result you're likely looking at a pretty big hit on cpu time just to get the paddle support in there.

 

I guess if you were were going to do a paddle type game on the 7800 in 7800Basic, you would be best served using the topscreenroutine during most of the visible screen, checking the paddle ports regularly. As I said however, this seriously limits the time the game would have available to do game logic, plotting objects, etc.

 

If you were to attempt this along with double buffering, I'd recommend a conditional check at the start of the topscreenroutine (to act as a boolean flag) to determine if it needs to poll and update the paddle information (otherwise it will do so each frame, even if the game logic is still not finished between frames.)

[+RevEng]

Driving controllers are internally very different than paddles. They work with the joystick direction bits, instead of the paddle capacitor charging lines.

 

Although there aren't any nice higher level functions, 7800basic can easily work with driving controllers... I've been meaning to throw together an example, but it wouldn't be supported under emulation, and I don't have any driving controls here. You just need to check the direction bits, and compare them to what the direction bits were last frame, and from there you know if the controller was turned left or right, or not at all.

[Synthpopalooza]

OK I tried compiling ... I get this error: Cartridge size is not a multiple of 4k bytes!

 

I am wondering if there is funny business going on with my image files.

 

 

 

 

ramcharmap3.bas

walking animations.zip

[Mord]

Doesn't appear to be anything wrong with the images themselves as the syntax errors being reported are all about the color constants being used that should be defined when the images are being imported.

 

I did some tinkering and it looks like the color constants generated by the incgraphic commands are having trouble with the filenames starting with a digit? (Rev would have to verify this, although I noticed when I changed the filename and references to it from "0_top.png" to "top.png" they stopped getting reported as syntax errors.)

[+RevEng]

Yep, you have it Mord. The filename of the graphic becomes a label, and dasm doesn't accept labels that begin with digits. From the manual...

 

The graphic plotting commands will access your image by it's filename, without the .png extension. Because of this, it has certain restrictions on the file naming to avoid confusing the 7800basic compiler…

• Each name should be unique.
• Each name should contain only letters and digits.
• Each name should begin with a letter character.

There's no perfect work around for this on the compiler end - if I automatically changed these invalid characters, I'd potentially run into name collisions, and the game programmer wouldn't know what the automatic color constants are named. But I'll look at making the compiler throw a better error for this.

[Synthpopalooza]

One other question ... is there currently any way to check to see which palette a character has been plotted in ... I noticed peekchar() only checks for the character. This would be useful in 160A mode where you get 8 palettes, and you maybe want to check for a certain color of the same character and re-plot it in a different palette when your man walks over it.

[+RevEng]

One other question ... is there currently any way to check to see which palette a character has been plotted in ... I noticed peekchar() only checks for the character. This would be useful in 160A mode where you get 8 palettes, and you maybe want to check for a certain color of the same character and re-plot it in a different palette when your man walks over it.

I see the utility in that request, but presently there isn't a way to read the palette a character was plotted in, nor is there a way to take a plotmap/plotmapfile screen and change the palette of a single character within.

 

To do that, it would require separate display list objects to represent each character in the display, and there just isn't enough RAM in a stock 7800 to do that.

[Synthpopalooza]

There is one idea I had thought about: define a colormap. For 160A mode, 8palletes are used. This means we use 4 bits for each screen location. This would require a colormap of 480 bytes (40x24 characters) or 240 byres if using double wide.

 

So, every time you plot a character to the screen you must also change the appropriate entry to the colormap. One could also read this colormap to check which palette any given character is in.

 

For 160B mode there are only 2 palettes, so each entry in the map is a single bit, making the colormap much smaller.

 

This could be defined through programming but it would be nice to have this as a part of 7800basic. Something like:

 

set colormap on

x=peekcolormap(x,y)

and have the plotchar command automatically write to the colormap if it exists.

[+SmittyB]

If this were implemented it would have to be optional. You would have to have a very specific requirement for such a colour map and in my games I wouldn't want to waste memory on a colour map that I will never use.

 

If you wanted to get the colour of a single tile map then that's easy, it's the same as everything else on the tilemap.

If you wanted to get the colour of a tile of a plotmapfile call then you should do keep track of it yourself because there's not a lot you could do with that.

 

What might be useful would be a way to redefine the palette of each tile for successive calls to plotmapfile but then those definitions would have to be in RAM instead of ROM and the programmer would have to be aware of the problems it could cause. Even then I can only see a limited use for it.