Newbie with a game idea

[+Propane13]

Ok, some information as to the multiple screenshots that have been posted below.

Of course, this is meant for informational purposes, and not to discourage.

 

1) Missiles can only be of width 1,2,4, and 8.

So, your stalagmites/stalactites will look a little different in reality.

And, if you're using Missiles for platforms, they are also limited to 8 pixels in width.

BUT, for the platforms that use player graphics, you are not limited to 8 pixels.

You can "fatten" player characters by a factor of 2 or 4.

So, this means that you can have a 16-character platform (with 2-width pixels), or a 32-character platform (with 4-width pixels).

Check out pitfall 2:

http://www.atariage.com/screenshot_page.html?SoftwareLabelID=359

In the second screenshot, the ledge over the water I believe is a fat player graphic.

 

2) I definitely recommend borrowing the "red" from the 2600 palette. You can borrow it from one of the screenshot attempts above.

Actually, you can find all available colors here: http://www.qotile.net/minidig/docs/tia_color.html

 

3) When doing a 48-pixel graphic, it has to be kept in mind that this is a very timing-intensive procedure.

What's happening is that this graphic is a combination of 2 overlapping triple-player sprites.

Translation: It looks like this: P0,P1,P0,P1,P0,P1.

Generally, P0 and P1 are supposed to be the same graphic.

Look at Atari's "Football":

http://www.atariage.com/screenshot_page.html?SoftwareLabelID=186

You'll see that the players are the same guy repeated 3 times.

So, picture 2 sets of these mixed together.

The question then becomes-- how do we change the graphics?

Well, it's crazy, actually. While the electron beam of your TV is drawing a single scanline, you have to time where it is.

When you know that it is finished drawing the first P0 graphic, you update the P0 character to have a different graphic.

But, by the time you've completed that, you just finished drawing your P1, and need to update him.

And then, it goes back and forth a few times. In short, the timing on this is quite intensive.

So, what does this mean for the screenshot?

It pretty much means that changing colors on the fly during this graphic (from white to red) is not possible.

If time were taken to do this, then the P0/P1 graphics would lose an update, and it won't work as desired.

 

4) Just because the background changes from black to white, doesn't mean that the platforms automatically invert colors.

You can change the color of the graphics on the fly, but the timing required to do so would be pretty intense.

So, if you want to have white platforms in there, I would not recommend having them "change" at the black border.

Instead, you could have white platforms only in the black area of the screen.

But, if I remember right, you want this to be a side scroller.

Because of that, I think TokuMaru's example should be an inspiration.

In his screenshot, the black background became grey.

If you kept it black, you could just make the platforms grey.

That way, you don't have to update them "on the fly" and can use your cycles for more interesting things.

 

It's improving, and I'd be very interested to see a fully realizable screenshot.

Keep it up!

 

-John

[Brian O]

Ok, some information as to the multiple screenshots that have been posted below.

Of course, this is meant for informational purposes, and not to discourage.

 

1) Missiles can only be of width 1,2,4, and 8.

So, your stalagmites/stalactites will look a little different in reality.

And, if you're using Missiles for platforms, they are also limited to 8 pixels in width.

BUT, for the platforms that use player graphics, you are not limited to 8 pixels.

You can "fatten" player characters by a factor of 2 or 4.

So, this means that you can have a 16-character platform (with 2-width pixels), or a 32-character platform (with 4-width pixels).

Check out pitfall 2:

http://www.atariage.com/screenshot_page.html?SoftwareLabelID=359

In the second screenshot, the ledge over the water I believe is a fat player graphic.

 

Does this mean that I can only use widths of 1,2,4, or 8 (with a maximum of 8 pixels) for the stalagmites? Can this sprite leverage multiple widths, to show it tapering (e.g. -- Having it start 8 pixels wide, and then taper to 4 pixels, to 2 pixels, etc?)

 

Also, for the platforms, any platforms that use the Player graphics will have to be 16 or 32? If I use the Missle for the shorter ones, do they have to be 8 wide, or can they be 1, 2, 4 or 8 wide? If so, can these sizes vary? I don't want to have too many big platforms, because that wouldn't be too challenging. There should be some smaller, harder-to-land-on platforms as well.

 

 

2) I definitely recommend borrowing the "red" from the 2600 palette. You can borrow it from one of the screenshot attempts above.

Actually, you can find all available colors here: http://www.qotile.net/minidig/docs/tia_color.html

 

This is helpful, thanks!

 

 

3) When doing a 48-pixel graphic, it has to be kept in mind that this is a very timing-intensive procedure.

What's happening is that this graphic is a combination of 2 overlapping triple-player sprites.

Translation: It looks like this: P0,P1,P0,P1,P0,P1.

Generally, P0 and P1 are supposed to be the same graphic.

Look at Atari's "Football":

http://www.atariage.com/screenshot_page.html?SoftwareLabelID=186

You'll see that the players are the same guy repeated 3 times.

So, picture 2 sets of these mixed together.

The question then becomes-- how do we change the graphics?

Well, it's crazy, actually. While the electron beam of your TV is drawing a single scanline, you have to time where it is.

When you know that it is finished drawing the first P0 graphic, you update the P0 character to have a different graphic.

But, by the time you've completed that, you just finished drawing your P1, and need to update him.

And then, it goes back and forth a few times. In short, the timing on this is quite intensive.

So, what does this mean for the screenshot?

It pretty much means that changing colors on the fly during this graphic (from white to red) is not possible.

If time were taken to do this, then the P0/P1 graphics would lose an update, and it won't work as desired.

 

I am going to make the name in the lower left all red, and leave the score all white. Will this work?

 

 

4) Just because the background changes from black to white, doesn't mean that the platforms automatically invert colors.

You can change the color of the graphics on the fly, but the timing required to do so would be pretty intense.

So, if you want to have white platforms in there, I would not recommend having them "change" at the black border.

Instead, you could have white platforms only in the black area of the screen.

But, if I remember right, you want this to be a side scroller.

Because of that, I think TokuMaru's example should be an inspiration.

In his screenshot, the black background became grey.

If you kept it black, you could just make the platforms grey.

That way, you don't have to update them "on the fly" and can use your cycles for more interesting things.

 

I want the dark square to remain solid, so it may just be best to not have the platforms visible once the dark passes over them, as opposed to showing them in the inverse color.

 

It's improving, and I'd be very interested to see a fully realizable screenshot.

Keep it up!

 

Thanks! Once I fully understand the Player and Missle graphic limitations, I can update the screenshots accordingly.

 

And thanks again for all of the information! Really appreciate it.

 

-B

[+SpiceWare]

Does this mean that I can only use widths of 1,2,4, or 8 (with a maximum of 8 pixels) for the stalagmites? Can this sprite leverage multiple widths, to show it tapering (e.g. -- Having it start 8 pixels wide, and then taper to 4 pixels, to 2 pixels, etc?)

Yep, only widths of 1,2, 4 or 8. It can be a different width on each scan line. It does take extra kernel time though, as not only would you be changing the size, but also the X position.

 

Also, for the platforms, any platforms that use the Player graphics will have to be 16 or 32? If I use the Missle for the shorter ones, do they have to be 8 wide, or can they be 1, 2, 4 or 8 wide? If so, can these sizes vary? I don't want to have too many big platforms, because that wouldn't be too challenging. There should be some smaller, harder-to-land-on platforms as well.

If your sprite image is drawn with 7 pixels on, the widths displayed would be would be 7, 14, 28. 6 pixels on would be 6, 12, 24 and so on.

[Brian O]

Does this mean that I can only use widths of 1,2,4, or 8 (with a maximum of 8 pixels) for the stalagmites? Can this sprite leverage multiple widths, to show it tapering (e.g. -- Having it start 8 pixels wide, and then taper to 4 pixels, to 2 pixels, etc?)

Yep, only widths of 1,2, 4 or 8. It can be a different width on each scan line. It does take extra kernel time though, as not only would you be changing the size, but also the X position.

 

Also, for the platforms, any platforms that use the Player graphics will have to be 16 or 32? If I use the Missle for the shorter ones, do they have to be 8 wide, or can they be 1, 2, 4 or 8 wide? If so, can these sizes vary? I don't want to have too many big platforms, because that wouldn't be too challenging. There should be some smaller, harder-to-land-on platforms as well.

If your sprite image is drawn with 7 pixels on, the widths displayed would be would be 7, 14, 28. 6 pixels on would be 6, 12, 24 and so on.

 

Thanks, SpiceWare!

 

I have updated my screenshot as per the comments you and Propane13 have provided. I have done the following:

 

• 
   
  
• Changed the colors of the graphic elements to match the 2600 color palette.
  
• Updated the platform graphics to reflect the following sizes: 5, 10, and 15 pixels across
  
• Updated the Missile1 platform graphic to be 8 pixels across
  
• Updated color of platforms to be gray/dark gray, so color would not have to change when the black box is behind them
  
• Changed stalagmite graphics to 8,4, and 2 pixels wide, tapering in.
  
• Made "Fear of the Dark" logo in bottom left of screen red, as opposed to red and white.
  

 

Any feedback is welcome.

 

Only question I have is: if the power up graphics (the green box in the screenshot) is going to leverage the Player1 sprite, does it have to be a multiple of 5? Right now, it is 8 across.

 

Thanks again,

Brian

[+Propane13]

I think maybe a quick tutorial on player (p0/p1) graphics is in order.

 

The player graphic is generally 8 pixels long.

Let's assume that for each "row" of that graphic, we can turn pixels on and off.

We turn on a pixel with a 1, and off with a zero.

So, for a player graphic that is "regular size", we can do the following:

11111111 = he's 8 filled in pixels.

00000000 = he's not filled in at all, and will be background color

11000011 = it'll look like there's a hole in the middle

 

Now, we can fatten the guy from 1x to 2x or 4x size.

What this means is that for each 1 or zero above, it'll look like it's doubled or quadrupled.

11111111 becomes 1111111111111111 for 2x size sprites.

11111111 becomes 11111111111111111111111111111111 for 4x size sprites.

10000001 becomes 1100000000000011 for 2x size sprites.

10000001 becomes 11110000000000000000000000001111 for 4x size sprites.

 

So, this gives you lots of options for sizes.

The "base case", where it's all 1's will give you something that's 8,16, or 32 pixels long.

But, if you change the 1's and zeros, you'll get different values.

Let's say we had:

11111000 (5 ones).

That would become:

1111111111000000 when doubled. That looks like a 10 pixel long platform. But, in reality, it's actually 16 pixels long, but 6 pixels are "invisible".

When we make it a 4x size sprite, it becomes:

11111111111111111111000000000000

This makes a 20-pixel long platform, but in reality, it's 32-pixels long with 12 "invisible".

 

So, you should always think of it as being 8 pixels, 16 pixels, or 32 pixels long.

However,

1) For an 8-pixel graphic, you can turn on or off all pixels

2) For a 16-pixel graphic, you can turn on or off pixels, but it has to be 2 at a time.

3) For a 32-pixel graphic, you can turn on or off pixels, but it has to be 4 at a time.

 

Make sense?

 

-John

[Brian O]

John,

 

I think I understand now. So, the platforms leveraging the Player graphic, anything above 8 pixels requires you to add or subtract pixels 2 at a time. So if we created one that was 14 across, it would technically be 16 across.

 

Aside from the platform sizes, which I'll fix, does the screens look accurate?

 

Thanks

 

-B

[+Propane13]

No problem. Glad you're taking this and building on it.

 

The only other thing that comes to my mind immediately that may need a tiny bit of tweaking is the vertical distance between platforms.

Generally, you have to figure that there will probably be a buffer of about 3 pixels vertically between platforms.

It'll take that amount of time for your code to "reset" the place where it's going to draw the next platform (about 1-2 pixels), and then do some "fine tuning", which could be another 1-2 pixels. So, I think a buffer of 3 pixels vertically between platforms is fairly safe.

 

Other than that, it is looking more and more like something doable. You've worked pretty hard on this, and it's showing!

 

-John

[Brian O]

No problem. Glad you're taking this and building on it.

 

The only other thing that comes to my mind immediately that may need a tiny bit of tweaking is the vertical distance between platforms.

Generally, you have to figure that there will probably be a buffer of about 3 pixels vertically between platforms.

It'll take that amount of time for your code to "reset" the place where it's going to draw the next platform (about 1-2 pixels), and then do some "fine tuning", which could be another 1-2 pixels. So, I think a buffer of 3 pixels vertically between platforms is fairly safe.

 

Other than that, it is looking more and more like something doable. You've worked pretty hard on this, and it's showing!

 

-John

 

Thanks, John! I am going to update the screenshots to more accurately reflect the correct platform sizes, and also be sure there is the correct amount of vertical/horizontal spacing.

 

Hopefully I will post them tonight or tomorrow.

 

Thanks again

 

-B

[SeaGtGruff]

I figure the objects can be 5 lines tall. Leave 1 blank line between objects and platforms for fine-positioning, so there would be 7 lines between platforms. The platforms can be 2 lines tall, so that makes 9 lines per row. With 192 lines, you have room for about 21 rows. If you subtract some lines for the displays above and below the screen, and use about 200 lines instead of 192, you could still have 20 rows.

 

I was also thinking you could have at least 4 objects instead of just 3: a green object for increased speed, a red object for decreased speed, a blue object for increased jumping distance, and a purple object for decreased jumping distance.

 

Michael

 

 

 

[Brian O]

Michael / John,

 

I think I have it (somewhat) right in this comp. I kept the platforms three lines tall. I wanted to top off the platforms with a dark gray line so that they stand out more.

 

The platforms, vertically, are 9 lines apart. I wanted to have some buffer space at the top of the screen. The powerups would then be 7 pixels high, leaving a blank line above and below each one. I would imagine that horizontally, the platforms would be spaced based on actual pixels. For instance, if a platform has only 12 pixels showing, it would mean 4 are invisible, so the next platform, horizontally speaking, would need to be a minimum of 4 pixels away. I'm not sure if this is right. Either way, I did not place the platforms too close to each other horizontally in my comp -- just in case.

 

Let me know your thoughts. I hope I did this right.

 

Thanks again,

B

[tokumaru]

I noticed couple of things wrong with your latest mock-up. First, the green power up is using 2 colors in its second to last scanline, it should use only one. Second, the platforms. They can be as "random" as you want vertically, but there are some rules to obey for platforms that are in the same scanlines.

 

You are using a player and a missile to draw them, and there is no problem in using both at the same time, but you have to pay attention to their copies. If the player has copies, so does the missile, as they share this configuration. It's also important to note that only non-stretched players can be duplicated/triplicated, which means that you can only have one big (larger than 8 pixels) per scanline, and in this case you will only be able to use one missile. Also remember that there are only 3 options of spacing between copies of the players and missiles (and it's also shared): close (8 pixels), medium (24 pixels) and distant (56 pixels), and that when you have 3 copies you can't use the distant spacing.

 

Some of these limitations can actually be broken if modifications are made to the graphics in the middle of a scanline, but that's not really an option for your game because it uses scrolling. Since the platforms can be anywhere between the far left and the far right of the screen, there is no efficient way to find the correct point to do these modifications.

 

Also, a useful tip: When saving these low-color screenshots, it's much better to use PNG than JPG. PNG not only results in smaller files in this case (lots of areas using plain colors compress well with PNG), but it's also lossless. JPG is a lossy format, intended for photographic high-color images, meaning it only approximates the original image but is not a 100% faithful representation of it. The images you saved have very little compression noise (probably because you used a high quality setting), so it's almost impossible to see, but if you try to paint over the colors in MS Paint you'll be able to see where the noise is. I only noticed it because I tried editing some of your images. Try for yourself: Take a noise-free image and export it to both PNG and JPG. The PNG will not only be over 10 times smaller it will also be artifact-free, so there are absolutely no disadvantages.

[Brian O]

I noticed couple of things wrong with your latest mock-up. First, the green power up is using 2 colors in its second to last scanline, it should use only one.

 

I have made this fix.

 

 

Second, the platforms. They can be as "random" as you want vertically, but there are some rules to obey for platforms that are in the same scanlines.

 

You are using a player and a missile to draw them, and there is no problem in using both at the same time, but you have to pay attention to their copies. If the player has copies, so does the missile, as they share this configuration. It's also important to note that only non-stretched players can be duplicated/triplicated, which means that you can only have one big (larger than 8 pixels) per scanline, and in this case you will only be able to use one missile. Also remember that there are only 3 options of spacing between copies of the players and missiles (and it's also shared): close (8 pixels), medium (24 pixels) and distant (56 pixels), and that when you have 3 copies you can't use the distant spacing.

 

Some of these limitations can actually be broken if modifications are made to the graphics in the middle of a scanline, but that's not really an option for your game because it uses scrolling. Since the platforms can be anywhere between the far left and the far right of the screen, there is no efficient way to find the correct point to do these modifications.

 

This one has me pretty confused. I would need to see this put into a more graphical representation, I think, to understand better. Would you be able to put the platforms in in a more realistic fashion?

 

 

Also, a useful tip: When saving these low-color screenshots, it's much better to use PNG than JPG. PNG not only results in smaller files in this case (lots of areas using plain colors compress well with PNG), but it's also lossless. JPG is a lossy format, intended for photographic high-color images, meaning it only approximates the original image but is not a 100% faithful representation of it. The images you saved have very little compression noise (probably because you used a high quality setting), so it's almost impossible to see, but if you try to paint over the colors in MS Paint you'll be able to see where the noise is. I only noticed it because I tried editing some of your images. Try for yourself: Take a noise-free image and export it to both PNG and JPG. The PNG will not only be over 10 times smaller it will also be artifact-free, so there are absolutely no disadvantages.

 

I have attached the original screenshot in PNG format, as well as a screenshot with no platforms (FOD_NEW_No_Platfrms_1_11201.png), also in PNG format. I usually safe as GIF, but was in a hurry last night so I just saved as JPEG right out of Photoshop. Will make sure I save as PNG moving forward. Thanks!

[tokumaru]

This one has me pretty confused. I would need to see this put into a more graphical representation, I think, to understand better. Would you be able to put the platforms in in a more realistic fashion?

I don't have the time for graphical edits right now (I'll try to do them soon), but I think that the basic rules are (all rules refer to platforms on the same scanline):

 

1. Use only one width of missile platforms and one width of player platforms;

2. The player and the missile must have the same number of copies;

3. All copies must be horizontally spaced by 1 of 3 possible distances (8, 24 or 56 pixels);

4. If the player is stretched (double-sized or quad-sized) there can't be any copies of it or the missile;

 

By "copies" I mean multiple instances of the same objects (player or missile) in the same scanline. Like in most 2600 games, most of the "randomness" will have to be vertical rather than horizontal, because the rules are very strict for each scanline.

 

I usually safe as GIF, but was in a hurry last night so I just saved as JPEG right out of Photoshop. Will make sure I save as PNG moving forward.

GIF is OK for these kinds of images too (it's lossless as long as you use 256 colors or less), but since PNG is a newer format and more versatile (it can also handle high-color images and alpha transparency, GIF can't) it is often preferred over GIF.