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

[DracIsBack]

Seeing these anime style graphics on a 7800 is kind of surreal. Good luck with the game!

[gorfcadet]

Thanks! Yeah, it is a little odd to see graphics that style wise were more associated with the Master System or NES. I already spotted an extra color on shop girl I had not intended that will have to go (only 2 pixels so no biggie.) I'll start playing with backgrounds now to take a break from playfield sprites.

[GroovyBee]

A little color heavy, but she'll be on a black screen with white text and leaves room at the bottom for a pallet refresh for the shop items.

 

Not colour heavy at all. I count 12 colours (including the background) but if you wanted to add more colour there are a couple of single coloured pixels at each shoulder blade and a small pink horizontal bar over her left (as you look at her) closed eye. With suitable colour choices from the dominant colours in the palette (used to replace those few pixels) you'd be down to 9 colours leaving a further 4 for more details on her clothing/hair/lips whatever.

 

Don't go too mad on the shop screen yet because there are plenty of tricks to get more highly coloured objects on static screens like that . Just start with its title, girl placement and general look and we'll see what is possible.

[gorfcadet]

Thanks GB! I'll crank up the brightness and root out those darn pixels after lunch! I've been color swapping some sprites and I've gotten the graphics for level one in at 12! I think I have some black colors that are hiding from me, but I'll find them. So here is a populated LVL 1 test shot with baddies and backgrounds! I'll get back to the shop's mock up later today or tomorrow. Thanks again GB, without your help, God only knows how many nitpicks I'd be digging out at the end! You da man! Now you just need to teach a coding class online!

 

Hope everyone is doing well! I'm daydreaming of box art for this one.

 

 

 

 

 

[GroovyBee]

The rogue 4x4 chunky pixels in that image are at (approximately the middle of each "pixel") :-

 

39,172

118,168

156,297

255,173

335,168

372,292

300,81 (the left one of a "pair")

 

I found a few more . I'll check out the level graphics later.

[Stun Runner 87]

Lol, shopgirl cybornetically turns on my circuits

[7800Lover]

It's looking good! You're really doing well with this so far.

[thursday83]

This is killer. Great work, Gorfcadet. It seems like you are enjoying the production of this project as well, which is nice to hear. It's fun to watch the thing come together. The collaboration between yourself and Groovybee is inspiring.

[gorfcadet]

Thanks guys! I fixed Shop Girl's wide pixel problems. It was actually entire vertical rows that had been stretched, but she looks good now. Also got rid of the off color pixels as well. New sprite sheet reflects changes.

 

 

 

[DracIsBack]

Prototype ... droool ....

[GroovyBee]

Thanks GB!

 

No problem.

 

I've been color swapping some sprites and I've gotten the graphics for level one in at 12!

 

Half of what is available to you, but you still need to add explosions.

 

So here is a populated LVL 1 test shot with baddies and backgrounds!

 

Looks good. I've slightly adjusted the status area so that the score digits don't cross a MARIA zone and the pilot's faces are both the same distance from their respective status information :-

 

 

You could have more colours on the score/lives letters and digits if you wanted to by changing their colour every video scan line. Eye candy like that can be done towards the end of the project. Asimilar approach can be taken with the health bar as well.

 

I'll get back to the shop's mock up later today or tomorrow. Thanks again GB, without your help, God only knows how many nitpicks I'd be digging out at the end! You da man! Now you just need to teach a coding class online!

 

Looking forward to the next mock. Unfortunately, I don't really have the time at the moment to put together an online class . If you have specific questions there is always the 7800 programmers forum.

 

I'm daydreaming of box art for this one.

 

"Stay on target! .... Stay on target!" Hmmmm.... Wonder what film those lines came from?

 

Soon you'll have to start thinking about level layouts and enemy sprite patterns. For level layout the common tools are TileStudio and Mappy. I've used Tile Studio quite a bit over the years because it supports a user programmable script language that can export your map data in a variety of ways. It has its quirks as a package but it saves quite a few headaches. I can't really help with Mac level design tools I'm afraid .

 

There was a tool recently released (in December I think) by one of the Coleco programmers for creating sprite attack patterns. I've never used it but it might come in handy for coming up with something that looks like its a pattern from the original game. The other options to getting the sprite data are to reverse engineer the data tables and algorithms in the game's ROM or painstakingly analyse frame by frame video footage from an emulator (with no compression so you can count pixels). Both of those approaches are likely to be quite time consuming so in my opinion you might want to do your own thing.

[GroovyBee]

Also got rid of the off color pixels as well. New sprite sheet reflects changes.

 

Yep! 9 colours if you nuke the rogue pixel at 346,282 . Those 4 remaining colours could be used in her immediate background if needed.

[DracIsBack]

Thanks! Yeah, it is a little odd to see graphics that style wise were more associated with the Master System or NES.

 

Odd, but in a good way! Unexpected!

[gorfcadet]

Thanks again! I will definitely do my own thing based on experience with the game. As always you are a fount of knowledge! Yes sir! On target sir!

 

So in this display mode I actually have 24 on screen? I thought 12 in a row was a limit not to mess with? That does make explosions and power ups more interesting.

[gorfcadet]

Rogue pixel is down! I won't update just for that, but I got it. It was the stray bluish one on the right model near her left elbow right?

 

I also need to figure out what special attacks play well to the 7800's strengths and what should I consider when putting together oversized bosses? How big is too big and should it be part of the background or a moveable sprite?

[GroovyBee]

Thanks again! I will definitely do my own thing based on experience with the game. As always you are a fount of knowledge! Yes sir! On target sir!

 

No probs! I had been writing games for quite a while before I appeared on AA .

 

So in this display mode I actually have 24 on screen? I thought 12 in a row was a limit not to mess with? That does make explosions and power ups more interesting.

 

If you don't use any programmer tricks then MARIA supports 24 colours and a common background colour. You can never go above 25 colours per video scan line because once MARIA halts the CPU it doesn't hand control back until its DMA'd the data for the complete scan line (its actually data for the scan line yet to be drawn). By using a combination of Display List Interrupts (DLIs) and WSYNCs (if needed) you can change more than one palette colour per scan line of your choosing under software control. The exact number of colours depends on how many CPU cycles are left for that scan line which is ultimately controlled by the complexity of the Display List (DL) in that zone. So in a zone with a NULL DL header (e.g. displays nothing at all) you can change multiple colours. In a zone with a load of sprites in you can change fewer. Its all game dependent.

 

So in a game port to the 7800 scenario: if the original game had parallax scrolling and you can't match it (not enough MARIA cycles, not enough RAM/ROM resource or whatever) you could have a colour gradient horizon to add some visual variety to the game. The 2600 game Battlezone is a good example of a colour gradient horizon :-

 

[GroovyBee]

Rogue pixel is down! I won't update just for that, but I got it. It was the stray bluish one on the right model near her left elbow right?

 

Its the purple "pixel" in this image :-

 

 

I also need to figure out what special attacks play well to the 7800's strengths and what should I consider when putting together oversized bosses? How big is too big and should it be part of the background or a moveable sprite?

 

For a large sprite with a fixed attack pattern like a boss you wouldn't bother cutting it into MARIA zones in the boss control routine because you waste a bunch of cycles every frame doing the same thing all the time. Personally I'd just pre-compute a bunch of tables (manually or make a tool) and update the fields in the Display List (DL) headers as necessary.

 

For a boss composed in 2BPP then the limit is 124/128 pixels wide (depends on if you use a single 4 or 5 byte DL header). For a boss in 4BPP the limit is 62/64 pixels (4/5 byte DL header). Ultimately its game dependent and based on an analysis of the worst case scenario taking into account :-

 

- What the boss is moving over.

- How many of its shots will be in a zone (and their size/BPP).

- How many of a player's hots will be the zone (and their size/BPP).

- What zone the player is in.

 

There is no real distinction to MARIA between the "background" and a "sprite" its all sprites. The distinction comes from what the artist/coder calls the background/foreground/tiles/sprites in their game.

[gorfcadet]

Not as sexy as the shop girl (she needs a name), but meet the level one boss.

 

[gorfcadet]

 

One more before bed. Boss took forever so I'm enjoying looking at it.

 

[GroovyBee]

Not as sexy as the shop girl (she needs a name), but meet the level one boss.

 

Its a good start. You can reduce the colour count to get him into 2BPP by replacing the highlighted purple "4x4 pixels" :-

 

 

The animation needs a bit more work in my opinion. The tank doesn't look like its rolling forward to me. It looks more like the engine is stuck and the tracks are vibrating .

 

Looking at where you've placed the tank vertically in the mock you might want to raise it to be the same height off the "floor" in the tile sheet. If you don't do that there will be two DL entries per zone per tank "slice" which will double its DMA bandwidth requirements. In reality 2 DL tank entries per zone might not be a problem because it all depends on how complex those zones are (as mentioned in a previous post) and how tight the graphics ROM budget is.

 

Once you've moved the boss up a bit he'll effectively become a 62 x 80 (w x h) sprite with background colour above and below. At that size and colour depth (2BPP) you can have 3 complete frames of animation occupying a 16 pixel high holey DMA region in ROM. Looking at the sprite you could claw some ROM space back by not storing "empty" background colour. This will make the boss sprite control logic and tables a bit more complex but it means you'll be able to store more sprite data per bank.

 

When you design a boss sprite try and make things happen on good vertical pixel boundaries. By "good" I mean good for MARIA (after all she does all the hard work ). So in the case of that boss if its design was adjusted so that the bottom of the launcher was 16 pixel boundary aligned vertically you could move it backwards and forwards as it launches/recoils and get the animation for "free". Its not really free because it adds a bit to the tank's animation code but it is an optimum use of ROM for a simple but good effect. Similarly if the tank base was kind of generic and well animated you could have different launcher "tops". The tank base and "tops" could be done using different palettes to make them more visually appealing too. It just makes what limited resources you've got go further and enhances the game for the player.

 

Another thing to think about in boss design would be that you can change colours vertically every 16 pixels for little CPU cost by using different palettes for the boss DL per zone. That will get you more colourful bosses even at 2BPP.

 

Flying bosses are another area to think about. Most of the time you'll end up having 2 DL entries per boss "slice" as they move vertically (when moving at 1 pixel increments vertically 2 DL entries are required 15/16 of the time). In which case you'll have to trade off sprite width against overall scene complexity and sprite height against pattern movement complexity.

[gorfcadet]

Thanks again GB! I hope I addressed the things you were telling me. I'll be doing graphics housekeeping later today to break down sprite sheets by type and adding pallet bars to the side of each for reference and cleanups should they be necessary.

 

I added enemy fire and rockets, explosions, and my first attempt at a power up icon though I think I want it smaller. Also reworked animations for the level one boss tank. She now has three frames of animation and looked ok in my browser just cycling through the images.

 

Hope everyone is doing well and thanks again for the support from everyone! GB, as always without your advice this would all be a hot mess... well, a worse one anyway.

 

 

 

 

 

 

 

[GroovyBee]

Also reworked animations for the level one boss tank. She now has three frames of animation and looked ok in my browser just cycling through the images.

 

Getting better! I put together an animated *.gif at x4 zoom (inter frame delay of 1/10 of a second) :-

 

(<---- Click to animate)

 

The track movement doesn't quite gel visually to me. Its good on the top and bottom of its travel providing most of the visual cues that its travelling forwards but it still looks a little odd in 2 places :-

 

- As it moves down the front of the tank and the top left knee of its travel.

- As it moves back upwards at the bottom right knee.

[GroovyBee]

I'll take a look over the new graphics later.

[gorfcadet]

Fixed some things here and there on the tank. Not quite perfect, but better.

 

[Stun Runner 87]

Wow, I'm very impressed with the graphics so far.......This potentially could beat out any homebrew to date for the 7800.........Keep it up......GorfCadet may be Atariages next homebrewing superstar....