Looking for 7800 programmer to assist porting a game

[peteym5]

I believe the arcade and the Coleco versions had a resolution of 256x200, 32 columns of text. That is a great resolution because the pixels height to width is close to a perfect square. I thought about 320 mode and making everything mono. Maybe I can draw an alternate set of sprites for this mode and try both when developing the game.

 

What I am doing for the first batch of games is doing them in phases. Like the graphic images first, then maybe start figuring out this 7800 basic. If something works with one game, the code can be copy and pasted into the other one. There will be ML code bought over from their 8-bit / 5200 counter parts like data tables and information on where to put things on the screen since it will also be using a 40x24 character screen. Some stuff used overscan mode at 48x24 screen.

Edited October 25, 2017 by peteym5

[peteym5]

With the 7800/7800 Basic, is there a way to display 2 lines of text at 320a mode, and the rest of the screen at 160b? Been looking through samples and roms. I am not sure if the pro-system is capable of combining modes similar to setting up a display list on the 8-bit with more than one graphics mode.

 

Edit, I found a way to do it. For these split screens, can the characters be 8x8 for the top line, and 16x16 below for the sprites?

Edited October 26, 2017 by peteym5

[Trebor]

From the original retail line combining screen modes is seen in several games. Often with the status/score area set to 320A mode and the rest of the game in 160A or/and 160B.

 

Some examples:

 

Commando = 160A, 160B, 320A.

Desert Falcon = 160A, 320A

Barnyard Blaster = 160A, 320A

Double Dragon = 160A, 320A

Fight Night = 160A, 320A

Pete Rose Baseball = 160A, 320A

Scrapyard Dog = 160A, 320A

Summer/Winter Games = 160A, 160B, 320A

Touchdown Football 160A, 320A

Xenophobe = All modes except 320D.

 

A split mode demo [160A & 320A] example under 7800basic was posted a while ago:

 

[peteym5]

I examined the code. I am wondering instead of a bunch of WSYNC, can something like a DLI handle things to free up CPU time?

[peteym5]

I am doing the sprites as a big tile set PNG image files, but all the samples I am seeing has these as single PNG per sprite or the series of animations. Can tile sets be used for sprites and how do I set the width and height of the tiles? I am looking into using this incmapfile command thing. Just wondering if there is a direct way to divide up a PNG file.

[Mord]

When it comes to sprites, it's best to have them in individual files I find, then include them in the order you want in the source. That way you can have the plotsprite command reference the base sprite in an animation, and use the optional "frame" parameter to jump ahead to the sprite you want in the animation. (All sprites have to be the same size however for that to work as intended.)

 

For tiles/fonts that you'll be using with plotmapfile or plotmap, having them in the same file is expected (Although not necessary) Well, with plotmapfile, you'll likely want to split the tiles up so that the tiles using the same palette will be together.

[peteym5]

I was thinking about splitting up the big image into individual images. I found an utility around to split the images into separate files. https://imagesplitter.net/and use bulk rename utility to shorten and sort the file names.

 

Here is what I came up with for Laser Blast X for the 7800, 4 frame animations.

 

I need to ask. How hard is it to have the sprites be 16 pixels tall and the background characters be at 8 characters tall?

Edited October 27, 2017 by peteym5

[Mord]

To do that in 7800basic, you would set the zone size for everything to 8, and then import your sprites as banners. banners are basically sprites that are taller than 1 zone. This will make 7800basic cut up the sprite into 1-zone sections and store them in a particular way. (top half first followed directly by the second half).

[peteym5]

16 pixel height should meet the demands of many of my games. Games like Venture and Secretum Labyrinth had sprites at 20 pixels high, I cut and reworked the Venture images down to 16 pixels tall for the 7800. I thought about that issue of being limited to 16 pixels high and if the 7800 basic did have a work around, will try this banner method and see if it works. I did notice that doing 16x16 does make the sprites look fat because 160 pixel wide resolution does not make even square pixels. To make them even you need to make them at a 4:7 ratio, (8x14, 12x21, etc..). There is an engine on the 8-bit that has the player/missile graphics with 8x14 sprites. For a few games I am setting up the sprites at 12x16 and not drawing them fully to the left or right edge, so they won't appear fat.

 

We are putting things together as we are learning new things about the 7800 Basic. I am playing around with some of the samples to see if I can alter them to make them do what I need to do.

[Trebor]

...I did notice that doing 16x16 does make the sprites look fat because 160 pixel wide resolution does not make even square pixels. To make them even you need to make them at a 4:7 ratio, (8x14, 12x21, etc..). There is an engine on the 8-bit that has the player/missile graphics with 8x14 sprites. For a few games I am setting up the sprites at 12x16 and not drawing them fully to the left or right edge, so they won't appear fat...

 

Indeed. In another thread Defender_2600 provided a nice illustration (posted below), while PAC-MAN-RED created many examples of taking a typical sprite with a square pixels perspective in mind and slimming it down to not appear "fat" under the 7800's 160 modes:

 

 

That 14h sprite left unmodified winds up looking "fat" under the 7800 160 mode. Trimming down just 3h pixels makes quite the different providing a sprite that appears properly proportioned.

[peteym5]

If I use 12x16 sprites, it should and not draw everything to the left or right edges, it should keep the sprites appearing proportional. Player/Missile graphics had a limit of 8 pixels wide unless you set to double or quad width. The 8-bit venture did 1 player + 1 missile to get 10 bit wide sprites. Should look great if I use 3 color sprites. I will be involved with these games during the graphics porting and design process.

[peteym5]

Are there any special parameters with these PNG files that 7800 Basic imports??? I saved them indexed 2bit or 4bit, and sometimes get fatal error, unable to resolve assembly, cartridge data must be at least 4k. fatal error when attempting to compile.

[+SmittyB]

If you're getting an assembly error then the image is fine as far as 7800BASIC is concerned. If you're doing more than just importing it I'd suggest checking that you're treating it as case sensitive (I'm not sure if it is or not). Also if the image is too wide to fit in a graphics block you might get the same thing.

[Mord]

You should make sure the filenames of any graphics your importing aren't identical to some other variable/command/etc in 7800basic as well. Since 7800basic will use the filename as a label it could end up causing conflicts.

[peteym5]

You should make sure the filenames of any graphics your importing aren't identical to some other variable/command/etc in 7800basic as well. Since 7800basic will use the filename as a label it could end up causing conflicts.

Actually I was figuring out how to do things by altering samples that are included or floating around here in the forum. I forgot to remove something that was trying to display digits from a file no longer present.

 

Here are some screen shots of title screens we ported so far.

 

If you are wondering about Venture, it is among the basic games in my first set we are porting over right now.

Edited November 6, 2017 by peteym5

[Jinks]

Cool!!! Great work!

[peteym5]

I am currently undecided about doing another asteroids clone for any system right now. Megaoids was originally intended to be more like Blasteroids, but had problems getting it to work on the 8-bit. Maybe I will have more luck with the 7800.

 

Here are a few other title screen shots I managed to make up. Some with Gradients. Should remind people none of this stuff is final and is subject to change.

Edited November 10, 2017 by peteym5

[peteym5]

I should rename this thread to "Needing help porting games to 7800 Basic"

 

I know the 7800 is capable of DLI (Display List Interupts) to change registers at certain points during the drawing cycle. But the way 7800 handles the Display Lists and Zones to split up the sprites makes it difficult to manipulate until the program is compiled into assembly. Wonder if some extra commands can be added so we can do things like color register changes mid screen. I know this will not be needed as much as we do on the Atari 8-bit/5200 systems. I may be looking to change the background color to Blue to Brown for a Sky and Ground effect for a game.

 

I am currently trying to figure out how to port over my Sine and Cosine tables used with games like Delta Space Arena, Megaoids, Putt 18, and Tile Smashers. Those games have objects moving in any direction. 72 possible directions with Delta Space Arena and Megaoids (every 5 degrees) and 256 possible directions with Putt 18 and Tile Smashers (every 1.4 degrees). Did anyone do something like this yet?

 

As you can see, I do a lot of copy and paste code between multiple programs if they need a common piece of code. Eventually I will be focusing on one game to get it done and release before the others. We will be releasing the games one at a time as they become ready.

[Synthpopalooza]

In theory it is possible to change registers but you don't want to do it too often as it will eat into your game cycles.

[peteym5]

I made up an animated demo and releasing the source code with it. It just has a bunch of spinning triangles moving in various directions on the screen. This demonstrates sprite multiplexing and using a trigonometry sine and cosine tables to create direction vectors that can range for 0 to 255. It is over 90% assembly.

 

There are 2 demos, one with only 24 sprites moving around, the other is with 32 sprites moving around. It seems when it gets up to 32, there seems to be some random flickering of sprite parts popping up around the screen. Not sure why yet, but this is still a work in progress. However 32 probably more sprites than most games will have on screen at once and it is a test of limits on the 7800.

Animated_Moving_Demo_24.zip

Edited November 28, 2017 by peteym5

[Mord]

It's possible the display lists aren't being capped reliably. If it's a case of too many objects in the same horizontal zone, you could be overrunning the ram set aside for the Display List, making it read parts of the next zone as well. You can try adding "set zoneprotection on" at the start of the program to see if it clears things up.

 

Additionally/alternatively, you can use the commands to allocate additional ram for the display lists.

[tep392]

Pete,

 

http://atariage.com/forums/topic/161355-a78psd-prosystem-save-state-file-analyser/?do=findComment&comment=1986861

 

Check out this tool if you haven't seen it yet. It will open the save states from Prosystem emulator and give you analysis of the display list. It will show you how many headers you have in each DL and how much Maria time is being used. Looking at your demo, your DL's are setup for 74 bytes each, which will allow max of 14 objects (5 bytes per header) per zone. The Maria time is only 266 cycles with 14 objects, so your ok with timing. I made several save state snapshots and one of them just happened to have the max of 14 in one of the zones. I didn't see any exceed that.

 

The tool also lets you view the contents of the 4k RAM.

[peteym5]

I will check it out. It will help me along in the development of my games. Like I said, 32 sprites on screen is more than most games can handle.16 sprites is normal for what I do with multiplexing. I am doing this through the 7800 Basic and been looking at the asm code generated at the compile to figure out what it is doing with the display list and stop it going over a limit. I need to go into the source, but I have it stopping something around 70 bytes before it starts skipping sprites.

[RevEng]

You're exceeding the cpu limits of a vanilla single-buffered sprite routine. When the time comes around for the start of the visible display, Maria halts the 6502 at the start of each scanline, ready or not.

 

The "or not" case includes being in the middle of drawing a sprite, in which case there will be a display list isn't correctly terminated. You'll also likely get a doubled-up frame, because after the halt on the 6502 is done the rest of the sprites will be added to the DL, and those routines refuse to run on a visible screen.

 

Also, if CPU usage isn't exactly the same from frame to frame (it rarely is) then sprites will wink in and out of existence, because one frame had enough time to draw them, and another didn't.

 

The rule of thumb I usually give is to treat 24 sprites as a theoretical maximum, unless you're double-buffering.

[peteym5]

I am not sure if this is a glitch with the 7800 Basic, but I tried double buffering on with setting screen height to 208 or 224 and the screen is jumping. But I will be looking into trying a few things when I have some free time.