How would I go about making 7800 screenshot mockups?

[ApolloBoy]

What settings do I need to use? I've already got a good program (GIMP) and I have the 7800 color palette, so I'm not concerned about those.

[Inky]

I made a Sinistar mockup once, using bits and pieces from other 7800 games...

 

I should dig it up ...

 

 

 

Here it is

Edited May 24, 2007 by Inky

[ApolloBoy]

That's neat, except I actually want to make everything from scratch instead of using pre-existing pieces.

[Bakasama]

Actually you CAN use his screenshot but only to get the exact dimensions of a typical 7800 screen size. A canvas you can use if you will.

[Robert M]

In general, Your working resolution is 160 across by 200 vertical, or 320 across by 200 vertical.

 

Everything on the screen is a sprite. There is no background hi-res screen. Sprites are tiled on the screen to make the background/playfield/platforms.

 

A sprite can be any width or height, but sprites of height 8 or 16 are more common because the hardware helps you draw them that height.

 

Games made with sprites at 160 resolution contain up to 3 colors from one of 8 pallettes.

Games made with sprites at 320 resolution are 1 color from 8.

 

If you need more colors on an object, then overlay 2 or more objects together.

 

If not too many objects are on a line it is possible to use the extra time to change the colors in a pallete mid screen thus increasing the maximum number of simulataneous different colors on the screen.

 

Text display is not hard to do at all.

 

Look at screenshots of existing games to get a feel for the density of objects possible.

 

Cheers!

Edited May 24, 2007 by Robert M

[kenfused]

In general, Your working resolution is 160 across by 200 vertical, or 320 across by 200 vertical.

 

Everything on the screen is a sprite. There is no background hi-res screen. Sprites are tiled on the screen to make the background/playfield/platforms.

 

A sprite can be any width or height, but sprites of height 8 or 16 are more common because the hardware helps you draw them that height.

 

Games made with sprites at 160 resolution contain up to 3 colors from one of 8 pallettes.

Games made with sprites at 320 resolution are 1 color from 8.

 

If you need more colors on an object, then overlay 2 or more objects together.

 

If not too many objects are on a line it is possible to use the extra time to change the colors in a pallete mid screen thus increasing the maximum number of simulataneous different colors on the screen.

 

Text display is not hard to do at all.

 

Look at screenshots of existing games to get a feel for the density of objects possible.

 

Cheers!

 

(1) Bitmaps can be used for backgrounds, but is not too useful due to the limited RAM unless you add some SRAM to the cartridge. I would think you could pull a fixed background bitmap from ROM though.

(2) 160 mode sprites can also have 12 colors (using the first 4 or last 4 palletes). 320 modes can also have more than one color but 320 modes are kinda weird and limited. both of these options causes MARIA to eat a lot more cycles and probably is more practical in backgrounds when the screen width is limited to 128 (in 160 mode) pixels. for sprites unless you really need 12 colors you are probably better off overlaying a couple of 3 colors ones.

(3) you can have both 320 modes and 160 modes on screen but not on the same scanline.

(4) sprites can have the 4th color be transparent or background color. transparency works weird in 320 wide modes.

 

As Robert said there really is not distinction hardware wise between background and sprites. You more or less are giving the graphics chip a list of stuff to display in each zone. The only limit is how fast you can built these lists and how fast the graphics chips can pull data for the display.

 

--Ken

[gdement]

If not too many objects are on a line it is possible to use the extra time to change the colors in a pallete mid screen thus increasing the maximum number of simulataneous different colors on the screen.

True, and I'll just add that an easy way to work around the time problem is by drawing a single blank scanline (or a pretty simple one) before making the transition. This makes a perfectly normal looking divider between the status display and the playfield, for example.

 

unless you really need 12 colors you are probably better off overlaying a couple of 3 colors ones.

A 12 color sprite is only twice as much data as a 3 color sprite, so it takes almost twice as long to render (overhead should be a constant for both cases). Rendering two 3color sprites will take truly twice as long as rendering one, so I don't think there's any advantage to doing this.

 

 

Two other details:

-Strips of tiled sprites are possible, which eliminates some overhead from rendering them individually. However, every tile in the strip has to use the same palette. You can draw the tile strip in 12 color mode, but that's slow.

 

-The background color can also be changed between scanlines, just like everything else.

Edited May 26, 2007 by gdement

[kenfused]

A 12 color sprite is only twice as much data as a 3 color sprite, so it takes almost twice as long to render (overhead should be a constant for both cases). Rendering two 3color sprites will take truly twice as long as rendering one, so I don't think there's any advantage to doing this.

Yea true. I meant if you have only oddball sprite out of all of them it might be more worthwhile to do that then to have to have a special case or flag for the one sprite.

Edited May 26, 2007 by kenfused

[Bakasama]

Here's a Frenzy mockup screenshot I did some years ago. It's based on the demo from Frenzy and this is what I THINK it might look like if someone programmed it.