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

[GroovyBee]

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

 

Nearly there! The front track still doesn't look right to me :-

 

(<---- Click to animate)

 

Still using 1/10 of a second as the inter frame delay.

 

There is still a rogue pixel on the tank. Its at 13,34 on the last tank image. Its in the same location on all 3 tanks too.

[GroovyBee]

my first attempt at a power up icon though I think I want it smaller.

 

Personally I think it'd be better as an icon rather than text. The icons can be explained in the manual or even in the game itself. If its an icon they can pretty much all be the same size as well. Don't forget that you can also colour cycle any graphics so that the player can have their attention drawn to a collectable item.

[gorfcadet]

Yeah, I think I was getting to that point with the power up icon as well. Fixed the rogue pixel. Actually I fixed a lot of rogue pixels! I spent the afternoon color cataloguing and rooted out all of the rogue colors in my sprites and consolidated some pallet choices. Talk about a chore!

I'm seeing what you're saying GB about the tank tracks on the front. I may just have to give her a nose job to make the animation smooth. I'll draw something out in the morning.

 

A superstar!? HA! Thank you so very much Stun Runner, but I'm a design guy who tinkers in programming. That made me feel so good though! Thank you for that! I do want to be part of a quality product and the 7800 has a special place in my heart since childhood. Once the graphics are done, I will make an attempt to get something working provided one of the REAL superstars around here doesn't jump in first. I know I can get something working; I just know programming isn't my gold medal event.

 

Anyway, I know you can't see much has been accomplished, but I rooted out discolored pixels in about 1/3 of the sprites so today was a very productive day. Also, took GB's advice and made and dated sprite sheets by category, foldered them, and placed pallet swatches on each one then verified that they matched the swatches and cross referenced. The header does have a truer black than the gameplay area, but since it is a different pallet, I left it alone. Need food now. Cheers everybody!

 

 

[gorfcadet]

Here is another look for the level 1 boss. Introducing the slimmer, more perspective friendly level 1 boss mk 2. After studying various versions of this boss on different formats, it appears that the designers used an impossible perspective for the sake of drama and showing the cool bits. Yes, it was cheap and it creates all kinds of perspective issues when trying to re imagine it, but it was really cool, so I forgive them. I decided to change some lines to strengthen the idea of forced perspective and still give the eye candy of the barrel of the cannon which admittedly, you should not be able to look down from the gamer's perspective. It is a little leaner and lower to the ground, but real estate can be a real issue when trying to convince the eye that what it is seeing should make sense when really it shouldn't. If the cannon's POV was realistic the gamer would also be able to see the inside of his/her jet's exhaust and never see the nose cone. I haven't stared at my Warpath Transformer so long since I was 9 trying to figure out the perspective problems and tank tread issues! Thank God for my toy collection! I thought I was going nuts.

Well, I hope everyone is doing well and be sure and let me know what you all think.

 

[GroovyBee]

I like the look of the latest tank. The reduced height also means you get a bit more leeway where it can be placed in a 64 pixel high block and you've clawed back some ROM space.

 

Here she is animated :-

 

(<---- Click to animate)

 

I took the liberty of adding a few extra animated pixels to the tracks which seems to make it flow better in my opinion. Feel free to ignore the enhancements :-

 

(<---- Click to animate)

[gorfcadet]

Tanks, I mean thanks GB! I like the upswing pixel at the back a lot actually. Man, holiday vacation has gone fast! I want to come up with some ground explosions, power up icons, and a third level shot sprite before thinking level 2 assets. I want level two to take place above a cloudline with the moon passing slowly in the background. The stealth boss would appear here, but then I also have an idea for the player to fight a weapons satellite being carried into orbit by a shuttle after that to add something new.

[GroovyBee]

I think you still need more level one assets (even if they don't all get used). How about adding more to the industrial complex look? How about storage tanks, vehicle compounds, fences, communication towers, warehouses and the like too? Think about them in different colours so they could be reused on other levels by a simple palette change. You might want to decide how many mini palettes to allocate to background objects too. If you only spare one palette to the background think about the graphics in terms of how to split them vertically so that you can change the palette in software on the fly. Or maybe add a coloured horizon gradient to spice things up a bit.

[gorfcadet]

Sounds good GB. I will probably add some fences and hangers and a few more mountainscapes. It will get recycled on level 3.

Levels to me right now go like this:

1 ENEMY BASE

2 NIGHT SKY SHOWDOWN

3 ENEMY BASE 2

4 DESERT MOUNTAINS

5 OCEAN BATTLE

6 THE CAVES - FINAL SHOWDOWN

 

It gives me a definite finish line and goal. Also, I know I need 6 bosses! My timeframe for the first two sets of level assets is the end of spring break and the rest by July (summer vacation!) Of course, I'm a burst worker, so it could all be finished by June! OCD dontcha know!

[gorfcadet]

Nothing too exciting today, but did want to show the stationary cannons and the new set pieces for level 1. I already see that towers, hangars, and fencing will need some tinkering to keep them from disappearing into the pavement, but you get the idea. If GB tells me that the hangar being set up for collision detection (the plane will take damage from hitting it) will be a problem, then I will scrap it and resize it to sit in the farther background with the towers and such. I wanted to do a double screen mock to show how about 10 seconds of play will work out. Once assets for the levels have been completed, I'll start a pdf design guide with enemy patterns, play mechanics, sprite work, and behaviors outlined and explained.

 

Hope everyone is having a terrific day!

 

 

 

 

 

[PacManPlus]

Wow - that looks incredible! Great job! Looking forward to seeing this in action.

[gorfcadet]

Bob! Thank you! That is high praise! I'm hoping for a hybrid of 1942 and UN Squadron when all is said and done. It was your Scramble, Bob that got me thinking it was possible. The AA community has been a great place to find inspiration and resources.

Maybe I can con GB to add this to his to do list or bribe you to take on a new project someday!

If nothing else, I'll give it the old college try once my design is complete. I've been reading your source code and can't thank you enough for sharing with us.

[GroovyBee]

Nothing too exciting today, but did want to show the stationary cannons and the new set pieces for level 1. I already see that towers, hangars, and fencing will need some tinkering to keep them from disappearing into the pavement, but you get the idea.

 

Looking good!

 

If GB tells me that the hangar being set up for collision detection (the plane will take damage from hitting it) will be a problem, then I will scrap it and resize it to sit in the farther background with the towers and such.

 

Have both! Its not a problem because it'll just get added to the bounding box collision detection list that the player's ship position/size is compared against. With a two player shmup you'll have to start coming up with ways to minimise the number of checks otherwise the frame rate will drop with a ton of stuff on screen.

 

I just had a quick look at the tank and there seem to be a few of my amended pixels missing from the nearest track. I've attached the updated graphics here :-

 

 

I wanted to do a double screen mock to show how about 10 seconds of play will work out. Once assets for the levels have been completed, I'll start a pdf design guide with enemy patterns, play mechanics, sprite work, and behaviors outlined and explained.

 

For your own personal use text files are fine. No need to go mad .

[GroovyBee]

I just took a closer look at the row of graphics forming the building/fences/towers and the road/runway and they overlap the road/runway in the mocks a little bit. This will double the amount of Display List (DL) entries for the zone in which they overlap. You might want to think about having a Display List Interrupt (DLI) to change the background colour to the road/runway colour a few scan lines above where the top of the road graphics will start. That way it looks like the road and the player is none the wiser .

 

To make it easier thinking about mockups in terms of zones get your art package to draw an alignment grid over the mock with a height of 16 pixels per block (4 to 16 is fine for the block width - doesn't really matter). That row of boxes will be the height of your zones as seen/handled by MARIA. So when you cut and paste elements into the scene check out how they are aligned vertically and then think about ways of making it easy for MARIA to handle what you want or change/adapt the graphics to suit.

 

Don't worry about changing the configuration of the DLL or DLs for each style of level you want to make its not difficult to do and it allows much more flexibility.

[gorfcadet]

Oh, pdf is second nature to me. It is actually less work. I spend 5 out of 8 class periods teaching kids layout and design in Adobe CS5. InDesign is second nature. TXT make me go nuts!

What do you think is a safe number of moving bits on screen before the 78 starts to choke? When planning attack patterns, it would definitely make a difference. I could save horsepower by making larger waves not fire on the player, but try ramming the player; smaller waves could fire or fire and leave the screen. <Cadet sits in thoughtful spot and taps forehead> Think, think, think.

Thanks for the help on that tank GB! Thankfully after this the bosses are all aircraft and one boat!

I'm just excited seeing the pieces come together. Unfortunately, today is grade semester test day. It is a teacher holiday most people never hear about because it is awful. If I finish early, I'll take a swing at that power up again.

Cheers everybody!

[gorfcadet]

Thanks for the tip on the Maria and sprite overlap! That will help big time!

[GroovyBee]

Oh, pdf is second nature to me. It is actually less work. I spend 5 out of 8 class periods teaching kids layout and design in Adobe CS5. InDesign is second nature. TXT make me go nuts!

 

Whatever you find the easiest. Again you might want to start some version control on it as well so you can go back to earlier versions.

 

What do you think is a safe number of moving bits on screen before the 78 starts to choke? When planning attack patterns, it would definitely make a difference. I could save horsepower by making larger waves not fire on the player, but try ramming the player; smaller waves could fire or fire and leave the screen. <Cadet sits in thoughtful spot and taps forehead> Think, think, think.

 

There is no easy answer to that. It all depends on the game, the algorithms used and how much you absolutely "have to do" per frame to make the game operate. On the 8 bitters "faking it" is always the best part .

 

I'm not sure Kamikaze attacks would work out too well especially in a formation. But hey, its your game and it can play how you want it to .

 

Reducing CPU workload normally means good data structures and efficient code both of which can be memory hogs. Smallest isn't always best. You might also need to rely on previously computed data or data that is accrued per pass.

 

Thanks for the help on that tank GB! Thankfully after this the bosses are all aircraft and one boat!

 

As I mentioned previously you might want a common silver belly (or something like that) to the plane and different styles and colours of "tops" just to make graphics resources go further.

 

I'm just excited seeing the pieces come together.

 

Its even better when the pieces start moving and then you know its possible to get something out .

[GroovyBee]

Thanks for the tip on the Maria and sprite overlap! That will help big time!

 

No worries. MARIA does all the work so always try to make best use of the fixed number of video/CPU cycles that are available. Its always a trade off getting a game to look and play well on a constrained system.

[gorfcadet]

Its even better when the pieces start moving and then you know its possible to get something out .

 

ONE PROBLEM AT A TIME MAN!!!!

Lol. I'm getting to it! Seriously, I hope to have some time to dig out the P4/winXP comp during spring break and maybe get background colors and a player sprite to animate and shoot. Baby steps. This def isn't Basic or C I'm looking at! My ipad is littered with link buttons to resource pages! Still, this is something I've always wanted to learn and so far it has been very cool!

 

Thanks again for the advice and help GB! You da man! I'll get really needy when I start trying code!

[GroovyBee]

Thanks again for the advice and help GB! You da man! I'll get really needy when I start trying code!

 

No worries. Its an interesting project for me because I spend ages trying to get my programmer art to look reasonable (I can only tolerate looking at squares and triangles for so long ) and then a pixel artist will come along and produce something that is much better than anything I could come up with and in no time flat. I have a feeling that the shoe is now on the other foot .

[7800Lover]

Just a question: can the Atari 7800 handle so many images/pixels/sprites on screen? IIRC, the NES was notorious for image breakup - there'd be slow down plus breaking up of characters when there were a lot of them on screen (I recall this from Mega Man 3).

[GroovyBee]

Just a question: can the Atari 7800 handle so many images/pixels/sprites on screen? IIRC, the NES was notorious for image breakup - there'd be slow down plus breaking up of characters when there were a lot of them on screen (I recall this from Mega Man 3).

 

Unlike the NES the 7800 can have more than 8 sprites per video scan line and more than 64 sprites on screen at once. To get around those limitations some NES games would use a sprite multiplexer that would flicker sprites at 25/30 Hz (like some 2600 games do too) to give the appearance of more objects on the same scan line. On the 7800 you don't really need programmer tricks like that.

 

The exact number of 7800 sprites per scan line is determined by both their width in pixels and the colour depth at which they are displayed. Both of those attributes ultimately determine how many ROM graphics data fetches are required (which is pretty much where all the MARIA video cycles go).

 

The only time you'd see mid sprite tearing on the 7800 would be if the CPU was updating the Display List (DL) headers for a sprite spanning two zones during the time MARIA is accessing the same information.

 

Its not all in the 7800s favour because precious CPU cycles are needed to "cut" and place a moving sprite's DL header into one or more zones and the fact that the CPU can't do anything while MARIA is pulling in any data it needs to create a video scan line.

 

For a good example of lots of sprites on screen at once take a look at the 7800's version of Robotron.

[gorfcadet]

I do love me some 7800 Robotron! I'll love it more when I gets me that modded pad Ax and I discussed! I remember being so amazed the 78 could handle Robotron and do it so well.

 

Ugh. Twenty more freshmen papers to go; then I can relax.

[gorfcadet]

 

Trimmed the pavement and I believe this addresses the issue GB mentioned. The grey background area begins at 32 pixels high. The left side is background colors only, the middle is everything, and the right is sprites only to show elevation.

 

 

Now to put the kids' grades in the computer. yippee.

[GroovyBee]

Just had a look at the mock. Almost, but not quite what I meant. With your version you'll have an odd sized zone to deal with which will slightly slow your sprite cutter and DL placer down. I'll adjust it and reattach it when I've made the changes.

[mmervine]

Gorfcadet...nice start, looks like this is going to be a cool game! GB, thanks for helping out...the true spirit of the AA forum!!!