Jump to content
IGNORED

7800basic beta, the release thread


RevEng

Recommended Posts

1 hour ago, RevEng said:

Yeah, not really a good clean way to do that. The plot* commands build the underlying display lists that Maria parses, and it does them in object order.

 

You could kind of get away with what you're talking about by plotting 2 off-screen hidden sprites in every zone wherever you need them, and then manually replace them with something like "under the hood", but it's kind of ugly.

 

If it's for minor z-masking, you can try plotting another copy of the underneath-object over top of the sprite you want to block. I tried this out a while back, with success. It's a bit complicated too, but less under-the-hood.

 

occlude.bas.bin 32 kB · 2 downloads occlude.bas.a78 32.13 kB · 1 download occlude.bas 12.41 kB · 1 download

 

 

Thank you! Regarding the first method, the two sprites you would plot would be the sprite to be covered, and the covering sprite, in that order? How does one plot a sprite offscreen? Something like X >= 160?

 

I was aiming for a dark maze with a small visible radius around the player sprite, but I may end up redesigning it to be a dark maze where the whole thing becomes visible for a moment if you bump into a wall. That much I know how to do without heroic measures.

 

As a side note, I really like the obstacle dodging code in your demo. Very slick.  ? 

Link to comment
Share on other sites

18 minutes ago, Karl G said:

 

Thank you! Regarding the first method, the two sprites you would plot would be the sprite to be covered, and the covering sprite, in that order? How does one plot a sprite offscreen? Something like X >= 160?

Actually, it should just be the one sprite - not two like I originally said - since the top one doesn't need to get inserted into the background.

 

And correct, you can hide the sprites in the X area > 160.

 

Thanks for the kind words on the demo. Nobody likes it when you get stuck on the corner of a tile. :D

Link to comment
Share on other sites

I don't suppose there is any way to change the stored palette number of an imported graphic? I set the palette number because I am using the tiles with plotmapfile. I would like to use the tiles from one of the graphics files in a different area with a different color palette. It seems like the only way to do this would be to have an identical PNG file, then import it separately with a different palette number. I know I could just change the palette entries, but those are used for other objects as well, and I'd ideally like them to not change colors in different areas. Just wanted to check to see if there's an option that I was unaware of that doesn't waste graphics space.

Link to comment
Share on other sites

I encountered a small bug with a *_length constant generated from a data table not getting treated as a constant, and therefore not working correctly. E.g.:

 

    for Temp4 = 1 to orange_fortress_rooms_length

Looking at the generated assembly, it doesn't use it as an immediate:

 

.L0848 ;;  next

	LDA Temp4
	CMP orange_fortress_rooms_length
	INC Temp4

 

Manually prepending '#' to orange_fortress_rooms_length in the basic code allows this to work, but presumably shouldn't be needed.

  • Thanks 1
Link to comment
Share on other sites

On 3/22/2021 at 11:56 AM, Karl G said:

I encountered a small bug with a *_length constant generated from a data table not getting treated as a constant, and therefore not working correctly. E.g.:

 


    for Temp4 = 1 to orange_fortress_rooms_length

Looking at the generated assembly, it doesn't use it as an immediate:

 


.L0848 ;;  next

	LDA Temp4
	CMP orange_fortress_rooms_length
	INC Temp4

 

Manually prepending '#' to orange_fortress_rooms_length in the basic code allows this to work, but presumably shouldn't be needed.

Actually, nevermind on this one. I had missed the compiler warning about using the constant before the data statement that generated it.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

When converting a project to 128k from 48k, my plotmapfile commands now complain about not being able to find the palette for images:

 

*** (1040): ERROR, plotmapfile didn't find a palette for asteroid_wall

My incgraphic line that loads asteroid_wall does indeed specify the palette. The only change that was made was moving all of the incgraphic lines to bank 8 (last bank, so it should always be available?). Does it have to do with the incgraphic line getting parsed after the plotmapfile command? If so, how do I prevent this?

Link to comment
Share on other sites

Yep. It's a known issue with bankswitched games. If the "incgraphic" happens later in the cart, the plotmapfile command doesn't know what palette you assigned it.

 

The work around for now is to stick the plotmapfile in the last bank, and gosub to it if necessary. Sorry, less than ideal, but it's a bit of a tough issue to sort out.

  • Thanks 1
Link to comment
Share on other sites

I have a problem with running 7800basic on Linux, trying to compile generates an error: 

 

7800basic.sh simple.bas: ERROR: couldn't find 7800basic binaries for Linux(x86_64). Exiting.

echo $PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/x/7800basic

echo $bas7800dir: /home/x/7800basic

 


Where to look for the cause? 

 

Link to comment
Share on other sites

Another day, another question...

 

I went with two fixed banks (144k) for my game to make my life easier. All of my graphics are in bank 1, so they should presumably be accessible from any bank.

 

I notice there's graphics corruption when graphics are between two different zones. What could be causing this?

 

136635322_ScreenShot2021-04-04at5_04_50PM.thumb.png.7797ec68a23760b4fe951e8325fc7e68.png

Link to comment
Share on other sites

I had a thought the other day. I wonder if it might be possible to create some sort of batari Basic wrapper for 7800basic? Since the kernels in bB are canned, it occurred to me that it might be possible to write a set of headers, includes and other code that can simulate (at least parts of) the standard and/or multisprite kernels. In order to make the transition nicer, though, maybe the playfield blocks could be replaced with character set tiles, initially filled in like playfield blocks but fully customizable to make things look nice, and if sprites won't translate well, maybe they could come in as placeholder graphics to encourage creating nicer sprites.

 

How a wrapper might work: maintain the zero page presence of bB memory. Then, "drawscreen" calls a module that reads the zero page memory that bB set up for the frame (that pertains to the graphics) and translates it into some sort of semi-compatible 7800 DLL/DL setup. Could that possibly work?

 

I am bringing this up because I can think of some games that I started but I ran out of resources on bB, so they were kind of abandoned. If there were a way to more easily port some works to 7800basic, maybe some of these projects could have new life breathed into them. In addition, maybe some finished bB projects could even get a retooling and aesthetic improvements and could maintain much of the game mechanics without needing a ground-up rewrite.

 

Clearly not everything is going to translate, such as bankswitching, possibly other things like NUSIZ, collisions, etc. Some things would have to be entirely rewritten in your source code. I am not thinking that anything will just plain work out of the box. The idea is more as a semi-functioning framework to encourage adapting existing games.

  • Like 2
Link to comment
Share on other sites

I challenge the assumption that there's a need for a ground-up rewrite to reuse code. There have already been a few ports and co-developing of bB games. All of the logic, data structures, and TIA sound should come over as-is, with the graphical stuff and collision handling needing to be unique. (I include a boxcollision function, so the latter isn't a huge hardship)

 

The flow is remarkably similar to bB, since I also have a drawscreen command, which similarly waits for a part of the frame to begin. (though in 7800basic the wait releases near the top of the visible display, where the most-abundant and least-strategically useful cycles are on the 7800)

 

The stuff that needs to be updated is also the stuff that's the hardest to pull off here. player copies, widths, and reflections don't get stored with the sprite definitions, they get updated on the fly. I could try to store multiple copies of each sprite with baked-in pixel delay, but it gets even more complicated when the zone height is different than your sprite height.

 

It seems a lot of effort and rom space to pull off what would ultimately just allow for inferior ports of 2600 games. I'm not saying the idea doesn't have merit as a mid-ground for ports, so much as I I'm saying there are other features I need to tackle first, with not enough hobby time in the day for those. e.g. scrolling, native sprite-based-tiles, qr codes, etc.

  • Like 1
Link to comment
Share on other sites

I would have loved having this option when I was first experimenting with 7800Basic, but I think the learning curve also helped me break out of the 2600 mindset when designing games. The idea of a translation layer is definitely an interesting one, though.

 

I'm wondering now if there would be value in a bB->7800Basic porting guide? Like taking a real game, and going through how to rework the sprites, turn the playfield into characters, handle collisions, etc. It could be handy not just for porting bB games, but also for learning how to do things in 7800Basic.

 

Edit: I mean something written by me, if there's an interest. 

  • Like 2
Link to comment
Share on other sites

I wasn't implying that this would stack anyone's work pile much higher (except my own, as I would likely be the one to figure out a translation layer.) I suppose I am more just asking the crowd about feasibility as I am not all that familiar with 7800basic, sadly.

 

I am more wondering if 7800basic can easily display a playfield-like character map similar to the dimensions bB uses. I suppose one equivalent for the standard kernel might be characters 8x12 pixels high in at least a 16x12 grid (20x12 maybe) in a 160-wide mode. Or 16x14, if a score is to be done below the main screen. Each character would represent two adjacent playfield "pixels." Initially the characters will be defined as one of four values and would look just like playfield pixels, but could be changed to be actual tiles.

 

On top of that screen, there could be at least 5 sprite objects (players, missiles, ball), nominally just basic shapes to encourage the programmer to enhance them (and add more, of course.) If 7800basic can set up a display like that, and someone knows how to set that up, I would then look into a way to translate the playfield data and the sprite X/Y values to agree with whatever memory footprint 7800basic needs (if this is indeed practical.)

 

The idea isn't to bring in a bunch of bB games but more to help get ports up and running more quickly, which can then be customized from there.

 

If this isn't practical (or, even if it is) a porting guide would still be nice!

  • Like 1
Link to comment
Share on other sites

Ah, excellent!

46 minutes ago, batari said:

I am more wondering if 7800basic can easily display a playfield-like character map similar to the dimensions bB uses. I suppose one equivalent for the standard kernel might be characters 8x12 pixels high in at least a 16x12 grid (20x12 maybe) in a 160-wide mode. Or 16x14, if a score is to be done below the main screen. Each character would represent two adjacent playfield "pixels." Initially the characters will be defined as one of four values and would look just like playfield pixels, but could be changed to be actual tiles.

[...]

The playfield pixel width is easily matched. 16-wide, 32-wide, 40-wide, whatever. The height is a bit more problematic. While other zone heights are possible, a zone height of 8 or 16 are "normal" ones for sprites and characters - any other choice means you need to keep big chunks of the rom empty above and below sprite data - so 7800basic locks you in to one of those.

 

The sprites are no problem, and locating the sprites is done with similar coordinates to bB. Here's the "simple" sample that comes with 7800basic.

 rem *** a simple program to move a happy face around with the joystick

 set zoneheight 8

 dim playerx=a
 dim playery=b

 incgraphic face1.png

 rem *** set the colors of palette 0, which we'll use to draw the happy face
  P0C1=$82
  P0C2=$48
  P0C3=$fb

main
 clearscreen
 if joy0left  then playerx=playerx-1
 if joy0right then playerx=playerx+1
 if joy0down  then playery=playery+1
 if joy0up    then playery=playery-1
 plotsprite face1 0 playerx playery
 drawscreen
 goto main

Adding more sprites is just a matter of adding more "plotsprite" commands before the drawscreen. (which different coordinates, possibly different graphics or palettes)

 

Another sample you might want to check out is the "adventurer" one. It has a sprite, score displays, and background character map.

 

Link to comment
Share on other sites

What would happen if I made a 12-high zone, aside from wasted space? Does it mean the sprites won't work correctly if I tweak the DLL to 12 high zones?

 

Some good news is that the multisprite kernel does use 8-high pixels so that should convert over pretty readily. And, since the playfield is fixed, it only needs to be brought in to the tile system once.

 

As for the 12-high pixels for the standard kernel, the only way I can see that could match things up is to use three 8-high 7800 characters stacked vertically for every two playfield pixels high. It shouldn't be that hard to do. A potential issue with this, though, is converting the 48 bytes of playfield data to 288 bytes of character data in 7800basic. It can be helped with a lot of lookup tables and unrolled loops, but still that is a lot of stores. It'll take thousands of cycles to convert that.

 

Also, a lot of parts of bB source code will need to be changed to work at all in 7800basic. Obviously, 7800basic has no "playfield:" function at all, for example.

 

So the more I think about this, the more I think that the best solution is to put together a set of helper functions along with a quick guide on how to use them.

 

Link to comment
Share on other sites

I had thought that the standard kernel had 16 scanline high blocks, not 12. The play area is 88 double scanlines high, so (88*2) / 11 playfield rows = 16

 

At any rate, doing 11 rows of characters with 16 scanline high zones for the playfield would leave one zone below that to do the score and the equivalent of pfscore bars for a total of 192 scanlines.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...