Jump to content
IGNORED

7800basic beta, the release thread


RevEng

Recommended Posts

Looks good! A few tips....

 

It seems you're setting the palette registers for each imported graphic. When you have sprites with the same colors, you only need to set the palette colors once, for one of the images. ie. ditch the byronr02_color*and byronr03_color* lines.

 

Later, when you want something else on-screen with the bear but using different colors, use a different palette index to display it. (e.g. P1C1=monsterr1_color1)

 

So far as animation, there's nothing wrong with what you've done, but it eats up a bit more ROM. So long as your sprites are next to each other in memory, plotsprite can take an optional "frame" parameter (after the y coordinate parameter) and it will skip sprites depending on the value of that parameter.

 

In your code you're using "a" as an animation index. Currently it ranges from 1 to 3, but if you change that from 0 to 2, you can replace your three "if a=..." lines with a single line: "plotsprite byronr01 0 x y a"

 

When a=0, it will display byronr01, and when a=1 it will display byronr02, etc.

 

The only limitation is that the sprites you skip need to all be the same width. (which they are here)

Edited by RevEng
Link to comment
Share on other sites

Sweet, that's exactly what I needed!

 

Now, can I swap palettes on the fly for the lead character? You know, if his status changes for any reason, I might need to change his color a bit.

 

Also, can I use different sprite widths for other characters? Byron will consistently be 16x16 pixels but his gunfire should be around 8x8. Maybe some of the enemies need to be that size too, I dunno. (I do worry that the Byron sprite is too chunky for the kind of game I want to make, but I'm pretty insistent on him staying that size for detail's sake.)

 

Oh yeah, a couple of other things. Can the sprite be flipped horizontally or will it need to be redrawn depending on the character's direction? Also, is text currently available and if so, can I change its palette on the fly to do that nifty color pulsing that Williams used to do for games like Robotron: 2084?

 

I've got a lot of questions, actually. My apologies in advance if I start to get on your nerves!

Link to comment
Share on other sites

No worries about the questions, so long as you don't get frustrated if I point you to the Guide when a detailed answer is required. :)

 

 

Now, can I swap palettes on the fly for the lead character? You know, if his status changes for any reason, I might need to change his color a bit.

Sure. Just change whichever palette register you want whenever you want. You can use hex values, variables, or the _color# constants. If you use Palette 0 to draw your character on the screen with plotsprite, then change P0C# values. If you use Palette 1, then change P1C# values, etc.

 

 

Also, can I use different sprite widths for other characters? Byron will consistently be 16x16 pixels but his gunfire should be around 8x8. Maybe some of the enemies need to be that size too, I dunno. (I do worry that the Byron sprite is too chunky for the kind of game I want to make, but I'm pretty insistent on him staying that size for detail's sake.)

Yep, mix and match away with the widths. The only requirement is that different animation frames of the same sprite need to be the same width and next to each other in memory, and that's only a requirement if you use that "frame" parameter with the sprite in question.

 

 

Can the sprite be flipped horizontally or will it need to be redrawn depending on the character's direction? Also, is text currently available and if so, can I change its palette on the fly to do that nifty color pulsing that Williams used to do for games like Robotron: 2084?

The 7800 has no hardware sprite flipping, so you need to store left and right facing versions of the sprites.

 

Text is currently available. See plotchars and plotvalue in the Guide.

 

Palettes can be changed on the fly to do the color pulsing. I'm working on a game that does the same right now. :)

 

The one note there is the color palettes are write-only, so you can't do something like "P2C2=P2C2+1". Instead go with "z=z+1" and "P2C2=z".

Link to comment
Share on other sites

All helpful information. I'll have to dink around with the compiler for a while and see what I can do with it.

 

Looking at the "Hello World" program makes me wonder how many character blocks I'll have to play with. I could very easily sacrifice the lower case letters for background graphics if I still have the capital letters for text. Also, what's the size of the character blocks, the usual 8x8?

Link to comment
Share on other sites

The size of the character blocks actually depend on which 7800 graphic mode you're using. There's a table with that info for each mode in the Guide, under the "7800 Hardware Overview->Graphics->Graphics Modes" section.

 

The default mode (which you've used so far) is 160A. Each character in this mode is 4 pixels wide and has 3 colors. You can turn on double-wide characters with "set doublewide on" if you prefer 8 pixel wide characters, but you need to bear in mind that you'll have a maximum of 128 characters with that turned on, rather than 256.

 

These all reflect the underlying hardware architecture, rather than choices I made with the 7800basic design.

 

Its also worth mentioning that can switch the character sets between frames for a different level or screen type, with the characterset command.

Link to comment
Share on other sites

Here's a question. I'd like to use a PNG to create a number of identical sprites. (Think, for instance, a line of bug ships in Galaxian or a group of robots like in Berzerk or Robotron.) I know I can create as many copies of the PNG and call them individually in the code, but it seems that using a single file would be more efficient, at least on account of the fact that I'm lazy and don't feel like copying the image and renaming all the copies. :) Is it possible to do this or something like it at this point?

Link to comment
Share on other sites

You can call plotsprite as many times as you like with the same image. No need to make png copies. You can even use a different palette with the copies, to create different colored versions of the same sprite.

I did this in the multisprite sample.

Edited by RevEng
  • Like 1
Link to comment
Share on other sites

not as a reminder or rebuke. :)

Actually, I did need the reminder as this example is precisely what I needed. For some reason, though, I forgot all about its existence. So I'll take it as a very kind reminder and I really do appreciate it. :)

  • Like 1
Link to comment
Share on other sites

I'm just wondering how I'm going to put a lot of characters on the screen at once. In most dialects of BASIC you can DIM variables to turn them into an array, then put the AI routines in a FOR/NEXT statement for maximum efficiency. Something like:

DIM enemyx(10)
DIM enemyy(10)

FOR I = 1 to 10
enemyy(I) enemyy(I) + 2 ' Move enemies down two spaces
NEXT I

That doesn't seem to be an option here, since DIM is simply used to rename variables, not array them. What's my best option for dealing with enemy AI if I've got several of them to manage?

Link to comment
Share on other sites

In 7800basic you can treat any memory location, RAM or ROM data, like an array. Here's your example in 7800basic'ese.

 

 dim enemy1x=a : rem to j
 dim enemy1y=k : rem to t

 for i = 0 to 9
 enemy1y[i] = enemy1y[i] + 2 : rem Move enemies down two spaces
 next
Edited by RevEng
Link to comment
Share on other sites

Once again, helpful. Thanks!

 

I just processed the sprites for Byron's walk cycle in all eight directions and discovered that the lot of them came to just shy of 10K in size. Should I be worried? How much can the compiler and system handle before I run out of space? I'm worried that my ambitions might be getting out of hand.

Link to comment
Share on other sites

No problem.

 

You may find your graphics are more compact when imported, but either way I wouldn't sweat it yet.

 

The ROM size is the limiting factor for the amount of graphics you can use. If you find 32k doesn't cut it, 48k is the next size up and you still don't need to deal with bankswitching with that format. If you go with one of the bankswitching formats (128k, 256k, and 512k) you'll need to group graphics together so the active bank has the graphics for the current screen/level.

Link to comment
Share on other sites

Just discovered that multiple JOY statements don't work in IF/THEN statements.

 

if joy0up and joy0right then p = 1
The above line crashes the compiler.
Any suggestions as to how I should address this? I'm thinking of storing the values of joy0up/joy0down and joy0left/joy0right into two separate variables. It'd be a kludge, but it would probably work.
Edited by Jess Ragan
Link to comment
Share on other sites

Oh, man! I am like, doing backflips here!

 

Got my character running around the screen, facing in all directions. If you use a second joystick, you'll note that he'll continue to hold the gun in the direction that stick is held, regardless of where he's running. That's the first step toward making an omni-directional shooter. The next step, of course, is bullets.

 

Give it a run, let me know what you think. It runs fine in ProSystem if that's your poison; I haven't tried it on MESS or the real hardware. Thanks are in order to RevEng and everyone else who offered their assistance!

omnid.zip

  • Like 6
Link to comment
Share on other sites

Thanks, I really appreciate that!

 

I'll probably work on some of the sprites and background art next. I've got an outline for the basic structure of the game, but although it sounds fun in theory, I'm not sure how enjoyable it will be in practice. I'll have to start a thread in the homebrew section of the forum later, just to bounce some ideas off the members of AtariAge.

  • Like 1
Link to comment
Share on other sites

Just going through the manual now. Very excited to see this!

 

A couple of minor typos in the manual:

 

Page 30:

 

psound

7800basic provides the tsound command for conveniently setting the pokey audio registers.

 

 

Page 2:

 

Graphics

... MARIA was designed with an architecture similar to many arcade games of it's era.

 

That last one is just a nitpick, but there should be no apostrophe.

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...