UN Squadron 7800 graphics... Any advice/feedback is welcome

[gorfcadet]

 

 

Not sure what my target width/height should be per sprite. This is my starting point for a four color sprite for the 7800. UN is one of my favorite arcade games of all time so I thought I'd noodle around a bit. Of course I started with the F14. I'll post the Thunderbolt when I'm happy with it or I have a better idea of what format/target resolution I should shoot for. Sorry if is tiny; I'm not sure how to resize it for easier view.

 

Hope everyone is having a terrific weekend.

 

Vic

[Jinks]

cool...

[Stun Runner 87]

Looks good to me.....would like to see that game on 7800.

[GroovyBee]

Looks good. But you are actually using 5 colours: dark grey, light grey, blue, yellow and background (transparent) so you'd need to draw them in 160B mode (which has 12 colours plus a common background colour). For data storage each sprite is 31 pixels wide which is an odd number of bytes at 4BPP ((31*4)/8=15.5) so you need to round it up to 32 by adding a column of transparent pixels to the right edge. To display the sprite you'd need a 4 byte Display List (DL) header, so in terms of MARIA cycles it'd be 8+(16*3)=56. With a blank background you could display around 7 of those sized sprites on a scan line (avoiding flicker), less if they are placed into a zone with background/missiles/whatever graphics. Is that enough for the sprite formations seen in the game?

 

When using 160A and 160B modes all graphics are stretched in X by a factor of 2. Basically they are "fat pixel" display modes. So you might want to adjust the original sprite widths accordingly to prevent things looking too distorted when displayed on screen. In my opinion dropping the widths to 20 to 24 pixels would be better with the added bonus of having more sprites available per scan line too.

[Jess Ragan]

Were there any computers with hardware similar to the 7800? Because there were several ports of UN Squadron for home computers, including the Amstrad CPC.

[GroovyBee]

If its 6502 based then its an easier task (easy being a relative term ). The Amstrad CPC is Z80 based so you'd need to know 2 assembly languages pretty well to attempt a conversion.

[GroovyBee]

There is a C64 version starting at 2:27 in this comparison video :-

 

http://www.youtube.com/watch?v=7Jkp1E06FHk

 

It'd need quite a bit of work to get it running directly on the 7800.

[gorfcadet]

Thanks GB! I should have known transparant was a color value! I'll yank the amber color I was using for the wing highlights and cut the exhaust. I'll mess with it some later today and build it into a 160x240 image to check scale in space using your recommendations for sprite size. Well, as long as my mac's batter holds out. I need to start bringing the charger home.

[gorfcadet]

Not counting missiles, most enemies come in "swarms" of 6 to 8, but in two lines. So your fighter would occupy an x axis with up to 4 enemies at a time. Behavior of the swarm is similar to 1942, but sideways. Can the 7800 handle custom missile sprites or would I need to think similar to what I saw in the vid for the C64? I miss my C64 btw.

 

I see what you mean about fat pixels now. Never noticed it before. I'll start thinking in terms of wider blocks and see where that takes me. The color limitations scale nicely for power ups and enemy fighters. The swarms that would produce power ups were usually red/orange.

Edited December 16, 2012 by gorfcadet

[GroovyBee]

Thanks GB! I should have known transparant was a color value! I'll yank the amber color I was using for the wing highlights and cut the exhaust. I'll mess with it some later today and build it into a 160x240 image to check scale in space using your recommendations for sprite size.

 

No problem! Its fine to use only some of the colours in a 12 colour palette. Its easiest to think of the 12 colour palette as consisting of 4 mini palettes numbered 0 to 3 (or 4 to 7) each containing 3 colours (and a common background (transparent) colour to all). You can still use the rest of the colours in the 12 colour palette for other sprites. Lets say you grouped the colours in the 12 colour palette as follows :-

 

Yellow, blue, dark grey, light grey

 

So yellow, blue and dark grey would effectively be in mini palette 0, and light grey in mini palette 1. You'd still have 2 colours in mini palette 1 to use on other 2BPP sprites. If those 2BPP sprites used the light grey even better! Mini palettes 2 and 3 would be completely free to use for any 2BPP sprites.

 

I'll mess with it some later today and build it into a 160x240 image to check scale in space using your recommendations for sprite size.

 

Draw your mock at 160x192 (w x h) and then apply a x2 pixel zoom in X so that you view it at 320x192.

[GroovyBee]

Not counting missiles, most enemies come in "swarms" of 6 to 8, but in two lines. So your fighter would occupy an x axis with up to 4 enemies at a time. Behavior of the swarm is similar to 1942, but sideways.

 

Shouldn't have a problem with that but ultimately it depends how the backgrounds are constructed and whether graphics are 2BPP (160A) or 4BPP (160B).

 

Can the 7800 handle custom missile sprites or would I need to think similar to what I saw in the vid for the C64? I miss my C64 btw.

 

Everything is a sprite (unless you use indirect mode) on the 7800 so missiles need to be assigned a palette, width and a pointer to graphics data in their Display List (DL) entry.

[gorfcadet]

Here is some updated spritework based on feedback. Thanks again GB!

Here are the png files.

I'm going to start rethinking the other two fighters and the status/face images before I construct a full screen mock-up. Hope everyone is doing well.

[GroovyBee]

Here is some updated spritework based on feedback. Thanks again GB!

 

Much better!

 

I'm going to start rethinking the other two fighters and the status/face images before I construct a full screen mock-up. Hope everyone is doing well.

 

Static screens are good candidates for programmer tricks like Display List Interrupts (DLIs) to change palette colours on the fly. That way you can have more than 25 colours displayed on screen simultaneously.

[Greg2600]

Wow, UN Squadron, that's quite ambitious. Make note that the only 8-bit system where the game didn't run like a cow was the C64, because they sacrificed graphics and music for frame rate.

[gorfcadet]

Battery is dying so I guess I'm done for the day. Wanted to adjust one pilot before I lost battery power. Hope all is well with my fellow AA'ers.
I forgot to unconstrain proprtions on the 7800 stretched image, but you get the idea; just imagine it taller. I'll have to wait until tomorrow to fix the proportions.
I hate not being able to work due to battery life. Edited December 16, 2012 by gorfcadet

[GroovyBee]

Good start but you might want to think about the the make up of whole status screen instead. If there is no text to be displayed around the face then you could use a 12 colour palette for the whole face. If there are several faces in a row, maybe they could all be done in the same 12 colour palette? Then you'd have more colours available for shading/highlighting etc. If you need to display text then you might want to consider changing to one of the 320 modes. You can only change graphics modes in a vertical orientation on screen which means you can't mix 160A/B or 320A/B/C/D modes in the same zone. If the text looks too plain in one of the 320 modes you can always change its colour(s) on the fly using DLIs and WSYNCs to change them on a per video scan line basis. The number of colours that can be changed per scan line depends on the split between MARIA cycles and the CPU cycles in that zone. More CPU cycles means more colours but less graphics. More MARIA cycles means more interesting graphics but less colour changes.

[gorfcadet]

Doh! Other than the white and black, I'm thinking the status area will include the health bar, score, money, ammo count, and high score. Other than the status face, the health bar uses a blend of red, orange, yellow, and a white outline. The original status faces only used 6 colors if I'm correct. That would be neat to have a more detailed status graphic than the original.

OK, I'm counting 12 colors on the faces. I'm supposing I could recycle those colors throughout the status area, though the health bar colors would change based on the pilot? Hmm. Snes used 6, but the critical faces used two shades of red on top of that color scheme.

Edited December 16, 2012 by gorfcadet

[GroovyBee]

Doh! Other than the white and black, I'm thinking the status area will include the health bar, score, money, ammo count, and high score. Other than the status face, the health bar uses a blend of red, orange, yellow, and a white outline. The original status faces only used 6 colors if I'm correct. That would be neat to have a more detailed status graphic than the original.

OK, I'm counting 12 colors on the faces. I'm supposing I could recycle those colors throughout the status area, though the health bar colors would change based on the pilot? Hmm. Snes used 6, but the critical faces used two shades of red on top of that color scheme.

 

As long as you have some blank lines (e.g. background colour) below the last part of the status display and before the active area of the game you should have plenty of time to change the colours of palettes that are used by sprites in the game area.

 

Don't worry about changing health bar colours depending on pilot they'd be pulled from RAM and set when necessary.

[gorfcadet]

Hmm again. Everytime you give me new knowledge it makes me think of new possibilities. If I use the full 12 colors up top and convert the snes graphics and do some color swapping, I could build 6 color snes style status images for two player at the same time and still get the health bars and scores without overusing any colors. It would mean probably limiting the colors for enemy ships and the number of on screen enemies because differentiating p1 and p2's palet is very important, but at this point it is all hypothetical anyway.

[GroovyBee]

I'm not familiar with the game (not a fan of shmups) . Can both players be on screen at the same time?

[gorfcadet]

In the arcade version it was 2p simultaneous. The snes version infamously was one player just like the snes Final Fight. Capcom couldn't count to 2 back then for whatever reason. Luckily, I have the arcade cab in my rec room and the snes cart had good points as well: upgradable jets and cash run missions. Unfortunately, the cab has a screwed up monitor right now and everything is very, very blue. It really is fun, not as insane as many shmups, but a lot of fun.

[GroovyBee]

So for 2 player simultaneous you'd have 1 mini palette for each player, 1 mini palette for a scrolling background and 1 mini palette for explosions (maybe shots can come out of that one as well?). So thats 4 mini palettes always in use which leaves 4 mini palettes for the enemies and power-ups. Are there more than 2 types of enemy on screen at the same time?

[GroovyBee]

Hmm again. Everytime you give me new knowledge it makes me think of new possibilities.

 

Yep! Thats game design all over. Plenty of different ways to get what you want.

[gorfcadet]

The game alternates enemy jets and choppers while tanks and cannons populate the ground. They could easily share palets with a red palet reserved for swarms that will drop a powerup.

Powerups will share the same palet as the fighter swarm that dropped it just to keep things simple and p1/p2 fire will be constructed out of their own palets. The F14 will shoot using the blue from the cockpit with grey highlights.

Edited December 17, 2012 by gorfcadet

[Jinks]

So would this be a xm game then? If so how could it be made better other than the sound as the obvious upgrade from a standard 7800 game?

I know your just starting to get ideas but just wondering...