Action RPG Game - MAUS LAB

[A Sprite]

Well, since you asked, I'll tell ya.

 

The graphics you crafted are really more suited to for an NES game than an Atari 2600 game. The pixels you're using aren't the ones used by the 2600. The pixels for that tend to be horizontal rectangles. The 2600 has an, uh, interesting way of displaying colors. A horizontal line of pixels can only have two colors.

 

I'm sure someone that knows how the 2600 better than me can explain this in more detail.

 

Thank you, I had thought this game was intended for the 8 bits.

 

Is the 2600 more like this?

Edited July 19, 2007 by A Sprite

[Bakasama]

yeah, that's more doable on the 2600.

[SeaGtGruff]

yeah, that's more doable on the 2600.

... except for the number of pixels across. Players are 8 pixels wide, unless you put player0 and player1 together, or add the missile(s) to it. But I think that image could be reformatted a bit to be 8 pixels across (leaving out the text).

 

Michael

[A Sprite]

 

Close? Cold? Suggestions?

[A Sprite]

MausBoy, I know my ideas are hit and miss...but if you could at least tell me what style you're looking for?

[MausBoy]

I already have the mouse sprites, I need enemy sprites. Here are the sprite types allowed:

 

8 x 44 two colors

16 x 44 single color

 

The sprites are not animated, and if you haven't played Dragon Warrior or Phantasy Star then you probably aren't going to be able to understand the type of sprites needed. The cat over the mouse is great, I really like that one but so far nothing you've posted will work for this game, specification or style-wise.

[SeaGtGruff]

MausBoy, I know my ideas are hit and miss...but if you could at least tell me what style you're looking for?

I like your mouse, but there are still a few too many pixels across, and the pixels' aspect ratio is off. The aspect ratio thing is kind of tricky. The smallest pixels on the Atari 2600 have an aspect are approximately 5:3-- i.e., dividing the width of 1 pixel by 5, and dividing the height of 1 pixel by 3, would give us 15 more-or-less square "subpixels," as shown in the drawing below:

 

 

However, the batari Basic kernels are "2-line kernels," meaning they draw 2 scan lines at a time, therefore the height of each player pixel is 2 scan lines, rather than 1 scan line, so each player pixel actually has an aspect ratio of about 5:6, as shown in the drawing below:

 

 

On the other hand, if the mice/mouses/meeses are shown at double-width during combat (like zooming in on them slightly), then the double-width player pixels would have an aspect ratio of 5:3 again (or 10:6 if you will, which reduces to 5:3).

 

Anyway, I like your mouse; and if you touch it up a bit, it could probably be done in batari Basic. (Reduce the number of pixels across to 8-- although the tail can stay if it's unbroken, since it could be drawn with a wide missile-- and fix the aspect ratio of the pixels to match what batari Basic can display, either 5:6 for single-wide players, or 5:3-- i.e., 10:6-- for double-wide players.)

 

Michael

[SeaGtGruff]

I already have the mouse sprites, I need enemy sprites. Here are the sprite types allowed:

 

8 x 44 two colors

16 x 44 single color

 

The sprites are not animated, and if you haven't played Dragon Warrior or Phantasy Star then you probably aren't going to be able to understand the type of sprites needed. The cat over the mouse is great, I really like that one but so far nothing you've posted will work for this game, specification or style-wise.

Are these for the battle sequences? Where there are up to three enemies displayed side-by-side in a large display?

 

Michael

[MausBoy]

I already have the mouse sprites, I need enemy sprites. Here are the sprite types allowed:

 

8 x 44 two colors

16 x 44 single color

 

The sprites are not animated, and if you haven't played Dragon Warrior or Phantasy Star then you probably aren't going to be able to understand the type of sprites needed. The cat over the mouse is great, I really like that one but so far nothing you've posted will work for this game, specification or style-wise.

Are these for the battle sequences? Where there are up to three enemies displayed side-by-side in a large display?

 

Michael

 

Yes, the same as Phantasy Star & Dragon Warrior.

[Mord]

Well, since you asked, I'll tell ya.

 

The graphics you crafted are really more suited to for an NES game than an Atari 2600 game. The pixels you're using aren't the ones used by the 2600. The pixels for that tend to be horizontal rectangles. The 2600 has an, uh, interesting way of displaying colors. A horizontal line of pixels can only have two colors.

 

I'm sure someone that knows how the 2600 better than me can explain this in more detail.

 

Since the 2600's resolution is 160x192 (roughly) the pixels tend to be twice as wide as they are high. The 2600 has 2 hardware sprites that are 8-bits long. Each of the sprites have their own color which effectively can't be changed normally within a scanline without using tricks (flickering between multiple frames or using both sprites on top of one another etc) You can change them ideally so that each scanline has a different color, but that depends on how busy the display kernel is and if it has enough time to update the associated registers. Each sprite also has an associated 1-bit missile sprite that shares the same color as it's sprite. You can use this as a 9th bit for slightly larger sprites but that can take up more time than it's worth most of the time. Additionally there are controls that can let you make 1-3 copies of the same sprite at different distances from one another, or have a single sprite that is either double-sized or quad-sized - meaning the pixels for the sprite will be even MORE rectangular/stretched than normal.

 

That's the 10 cent guide.

 

And I should probably make sure I've finished reading a thread before replying to something. *inno*

Edited July 29, 2007 by Mord

[A Sprite]

Removed due to quality concerns.

Edited August 6, 2007 by A Sprite

[SeaGtGruff]

Removed due to quality concerns.

It looked good to me, if not quite doable in bB. Put it back up again, and I'll post some comments/suggestions. The main issue I noticed was not whether the sprite was possible on the Atari, but rather whether it could be accomplished in bB using either the standard or multisprite kernel.

 

Michael

[A Sprite]

Removed due to quality concerns.

It looked good to me, if not quite doable in bB. Put it back up again, and I'll post some comments/suggestions. The main issue I noticed was not whether the sprite was possible on the Atari, but rather whether it could be accomplished in bB using either the standard or multisprite kernel.

 

Michael

 

 

I realized I'd accidentally distorted the pixel ratio to a 3:2 instead of a 5:3, which isn't doable in any form, is it? Rather than start over or continue to fight the space limitations of multicolored sprites, I started work on a more detailed skunk enemy. The color charts above are for background, sprite, and missile....I wasn't sure all 3 were available, to be used in any form that would make this work.

Edited August 7, 2007 by A Sprite

[SeaGtGruff]

I realized I'd accidentally distorted the pixel ratio to a 3:2 instead of a 5:3, which isn't doable in any form, is it?

Actually, I think it's more like 4:3. I've fixed it to 5:3, removed the grid lines, and changed the colors based on a screen capture I have of the Atari 8-bit computer's palette-- but I think the colors look too washed-out; on my TV, my 2600 and 7800 have much more saturated colors (although of course the colors will vary from console to console based on the color phase shift or pot setting, and from TV to TV based on the brightness/contrast/color/tint settings).

 

 

Leaving aside the question of whether the number of colors is doable in bB, the main issue is still the pixel aspect ratio. On the 2600, the smallest pixel size for a player pixel is 1 color clock wide by 1 scan line tall, which has an aspect ratio of 5:3. I actually did a test screen last night and displayed it on my 2600 and TV using a Krokodile Cartridge, and sure enough, a large rectangle 24 color clocks across and 40 scan lines tall was just about precisely square. That reduces to 3 across by 5 down, from which it follows that each pixel has an aspect ratio of 5:3.

 

Anyway, batari Basic uses a 2-line kernel, which means the smallest player pixel is actually *2* scan lines tall, as opposed to *1* scan line tall, so the smallest player pixel in bB has an aspect ratio of 5:6 (basically two pixels stacked on top of each other). At least, that's the smallest player pixel size if you use one of the two "canned" kernels (the standard kernel and the multisprite kernel). So that would make the sprite look stretched vertically, as follows:

 

 

That actually doesn't look too bad, and you could always remove a row of pixels here and there to adjust the sprite so it looks less stretched.

 

Now, the 2600 can display a player at three different widths-- single-wide (each pixel is 1 color clock wide), double-wide (each pixel is 2 color clocks wide), or quadruple-wide (each pixel is 4 color clocks wide). Thus, you could switch to double-wide player graphics and get the 5:3 pixel aspect ratio. But if you do that, you can only use one copy of the player, because the 2600 can only draw multiple copies of a player on a given scan line if the player is single-wide. I think MausBoy wants to have up to three copies of a player, at least that's how the enemies are displayed in Dragon Warrior-- there can be one, two, or three enemies displayed, and they are not necessarily just copies of the same enemy. So a double-wide, or even quadruple-wide, player would be fine if only one enemy is displayed, or if the other player sprite is drawn single-wide for the other enemy (or other two enemies).

 

Of course, you can also overlay two players, and use different resolutions for each, like a double-wide player on the bottom layer, and a single-wide player on the top layer. And you can position playfield pixels behind the player (or behind two overlaid players) to get additional colors. Or you can position the two players side-by-side to get a 16-pixel sprite, and have two or three copies of each, to get one, two, or three 16-pixel sprites. And if you're using bB's standard kernel, you can change the player colors from one row to the next, or change the playfield color.

 

So there are a number of options available that will affect the kind of sprites you could design, and you should probably try your hand at creating sprite designs that would make use of various combinations of options.

 

Michael

[A Sprite]

I realized I'd accidentally distorted the pixel ratio to a 3:2 instead of a 5:3, which isn't doable in any form, is it?

Actually, I think it's more like 4:3. I've fixed it to 5:3, removed the grid lines, and changed the colors based on a screen capture I have of the Atari 8-bit computer's palette-- but I think the colors look too washed-out; on my TV, my 2600 and 7800 have much more saturated colors (although of course the colors will vary from console to console based on the color phase shift or pot setting, and from TV to TV based on the brightness/contrast/color/tint settings).

 

 

Leaving aside the question of whether the number of colors is doable in bB, the main issue is still the pixel aspect ratio. On the 2600, the smallest pixel size for a player pixel is 1 color clock wide by 1 scan line tall, which has an aspect ratio of 5:3. I actually did a test screen last night and displayed it on my 2600 and TV using a Krokodile Cartridge, and sure enough, a large rectangle 24 color clocks across and 40 scan lines tall was just about precisely square. That reduces to 3 across by 5 down, from which it follows that each pixel has an aspect ratio of 5:3.

 

Anyway, batari Basic uses a 2-line kernel, which means the smallest player pixel is actually *2* scan lines tall, as opposed to *1* scan line tall, so the smallest player pixel in bB has an aspect ratio of 5:6 (basically two pixels stacked on top of each other). At least, that's the smallest player pixel size if you use one of the two "canned" kernels (the standard kernel and the multisprite kernel). So that would make the sprite look stretched vertically, as follows:

 

 

That actually doesn't look too bad, and you could always remove a row of pixels here and there to adjust the sprite so it looks less stretched.

 

Now, the 2600 can display a player at three different widths-- single-wide (each pixel is 1 color clock wide), double-wide (each pixel is 2 color clocks wide), or quadruple-wide (each pixel is 4 color clocks wide). Thus, you could switch to double-wide player graphics and get the 5:3 pixel aspect ratio. But if you do that, you can only use one copy of the player, because the 2600 can only draw multiple copies of a player on a given scan line if the player is single-wide. I think MausBoy wants to have up to three copies of a player, at least that's how the enemies are displayed in Dragon Warrior-- there can be one, two, or three enemies displayed, and they are not necessarily just copies of the same enemy. So a double-wide, or even quadruple-wide, player would be fine if only one enemy is displayed, or if the other player sprite is drawn single-wide for the other enemy (or other two enemies).

 

Of course, you can also overlay two players, and use different resolutions for each, like a double-wide player on the bottom layer, and a single-wide player on the top layer. And you can position playfield pixels behind the player (or behind two overlaid players) to get additional colors. Or you can position the two players side-by-side to get a 16-pixel sprite, and have two or three copies of each, to get one, two, or three 16-pixel sprites. And if you're using bB's standard kernel, you can change the player colors from one row to the next, or change the playfield color.

 

So there are a number of options available that will affect the kind of sprites you could design, and you should probably try your hand at creating sprite designs that would make use of various combinations of options.

 

Michael

 

1. You are awe inspiring, good sir.

 

2. Ninja kitten looks better stretched out. Pick up a kitten. Same expression. Same taffy like consistency.

 

3. How did you remove the grid, stretch it out, etc? I'm grateful for your hard work, but I wouldn't take advantage of your generous nature.

 

4. Maus_boy may have to answer this one. Since this is set in a lab, some of the enemies should be humans. Since this is a JRPG style, it needs bosses. Since it's an Atari 2600, it's small sprites only. But, what if there were larger characters presented with flickering lights (and thunder noises) or in the form of a laser scanner running over their bodies, so that only a few rows of pixels are exposed at a time? Can this be realistically achieved, or would I be wasting my time designing near full screen sprites?

[SeaGtGruff]

How did you remove the grid,

I have some grids that I had created in MS Paint, depending on what I'm trying to make a mockup of-- a single-wide player, double-wide player, quadruple-wide player, or playfield-- and I just copy the one I need to a new name and start coloring the blocks. I usually leave the grid lines there, because they help emphasize the individual pixels. But if I want to remove them, then I color them in (carefully!) using the filled-rectangle tool. It's a little tedious, but it works.

 

stretch it out, etc?

I just resized the image to 200% height. In fact, the easiest way to design a sprite with the correct aspect ratio is to just use 1:1 pixels (perfect squares), magnified with zoom so they're easier to see, and then stretch/resize the finished image. For a 5:3 aspect ratio, stretch the 1:1 image by 500% for the width, and by 300% for the height. For a 5:6 aspect ratio, stretch the 1:1 image by 500% for the width, and by 600% for the height-- or, if the program doesn't like anything over 500%, make it 5:3 first, then stretch the 5:3 to 5:6 by making the width 100% and the height 200%.

 

Michael

[A Sprite]

 

It's terrible, this creature is a thief, who steals rings and other shiny "precious" objects. Don't hurt it's "precious"!

[A Sprite]

Beware of skunk!

 

[A Sprite]

Do I make it in the club this time?

[A Sprite]

I'll try again....

Edited August 13, 2007 by A Sprite

[SeaGtGruff]

I'll try again....

I thought they look good, but I didn't have much time for anything this weekend, so I didn't get a chance yet to look at them closely and post any comments about them.

 

Michael

[gambler172]

Hi

This game seems to become nice.Does a bin exist?

greetings gambler172

[Nognir]

Hi

This game seems to become nice.Does a bin exist?

greetings gambler172

 

I think it is actually in the designing phase, but it would be interesting to see some screenshots of it.

[SeaGtGruff]

Hi

This game seems to become nice.Does a bin exist?

greetings gambler172

 

I think it is actually in the designing phase, but it would be interesting to see some screenshots of it.

I think what would help everyone who wants to contribute sprite ideas are a few screenshots showing what the basic game will look like, so the enemy sprites can be designed to fit the same "look and feel," if you know what I mean.

 

Michael

[A Sprite]

Hi

This game seems to become nice.Does a bin exist?

greetings gambler172

 

I think it is actually in the designing phase, but it would be interesting to see some screenshots of it.

I think what would help everyone who wants to contribute sprite ideas are a few screenshots showing what the basic game will look like, so the enemy sprites can be designed to fit the same "look and feel," if you know what I mean.

 

Michael

 

Seconded. Akira Toriyama and Yuji Naka have very opposing styles, despite Naka taking visual cues from Toriyama. I could fuse the two on an 8bit or higher, but 2600 requires one to pick and choose what visual elements will make it in.

Edited August 16, 2007 by A Sprite