Just For Fun

[MausGames]

I did this earlier while I was watching Married With Children. This would be a fun game to actually port, if it weren't for all the damn text. Be sure to press Alt+p in Stella to avoid a headache.

 

z2aol.bin

[+grafixbmp]

I did this earlier while I was watching Married With Children. This would be a fun game to actually port, if it weren't for all the damn text. Be sure to press Alt+p in Stella to avoid a headache.

 

z2aol.bin

WOW! That worked extremely well. This leads me to want to know what a dual color mix chart might be like. Stuff like this opens some awesome gaming potential. That is some breathtaking imagery you got there. There is nothing the atari 2600 can't do... atleast to some extent.

 

Besides, on a Harmony/Melody cart, much of the problems with text go out the window.

Edited November 1, 2009 by grafixbmp

[MausGames]

http://www.youtube.com/watch?v=m1OwLYDiXTw Edited November 1, 2009 by MausGames

[+Random Terrain]

http://www.youtube.com/watch?v=S55gDKUlCfQ

Shortest video . . . ever.

[MausGames]

Switched it out for a lesser version

[+Random Terrain]

Switched it out for a lesser version

 

 

Don't you hate it when people won't let you embed?

[MausGames]

Yes. And I wonder about 35 downloads, one comment. Even if something really sucks, you guys can take the time to say so.

[ScumSoft]

Very cool, I like it. Any massive hardware tricks required?

I'm still learning how the 2600 all works and just got Visual Batari running under Win7's XP virtual machine.

 

Would you have enough cycles left for player movement and enemy updates? If so it would be really cool to play.

[yuppicide]

Will this be doable on a real 2600 or only on emulator? Looks great!

[MausGames]

Very cool, I like it. Any massive hardware tricks required?

I'm still learning how the 2600 all works and just got Visual Batari running under Win7's XP virtual machine.

 

Would you have enough cycles left for player movement and enemy updates? If so it would be really cool to play.

 

I'm not using any tricks, just two playfields shown on alternate frames. Updating the entire playfield on every frame does require a considerable amount of cycles in bB; what could be fit in what's left would depend on programming skill. Clean efficient code is a weak point for me.

 

The reverse, a port that is all substance with no emphasis on style, could be very true to the original and a lot of fun to play. I'd posted in another thread about even/odd frame playfield flicker, and I wanted to see it in action.

 

Do you think you will be posting any of your bB projects here?

 

Will this be doable on a real 2600 or only on emulator? Looks great!

I don't really know how to update a 32x32 playfield, in every build of bB that I've tried there are not enough cycles to do that. If that is the resolution used in Cave In, I have no idea how AtariusMaximus managed to do it. If I scaled it down to 32x30, it would work on real harware; but the flicker would be so ugly and painful that it would lose any appeal it might have almost instantly.

[+Random Terrain]

Yes. And I wonder about 35 downloads, one comment. Even if something really sucks, you guys can take the time to say so.

This doesn't suck, but what is there to say? Nice recreation of a screen from some game I don't remember? I'd have to see a screenshot from the original game to compare.

 

 

I try many things that I think suck that other people goo their pants over. "This is great!" " A lot of fun!" "This is hard! I love it!" "This game is so much fun it makes me want to touch myself!" I often think, "OK, are you guys playing the same work in progress that I am? In its current condition, this game is as much fun as watching paint dry while stabbing yourself in the balls with a rusty fork." You can't say what you really think if you don't like it because many people are too sensitive and will quit for months, years, or forever because of one 'negative' comment.

 

A lot of people seem to love jumping over or avoiding mindless enemies or obstacles that bounce up and down or jump from side-to-side, like you'll find in games such as Keystone Kapers and Pitfall II, but I like a bit of AI in games. I think you should have to 'play' the game and not memorize dance steps (. . . 1 . . . 2 . . . 3 . . . jump . . . 1 . . . 2 . . . 3 . . . duck . . . 1 . . . 2 . . . 3 . . . jump . . .). It's usually best if I don't say anything. Even if I'm trying my best to be helpful, my words can be as sharp as a sword and someone will get cut.

 

[MausGames]

You missed the point, I meant 'lame attempts at color blending in bB, yay or nay.' I know what you mean, but people can get over it. Especially if you are just being earnest and not condescending or mean. Posting something in a forum opens you up to critique unless you specifically request none. Please feel free to let me know what you don't like about anything I post, especially if it's something close to a real, playable game.

Edited November 2, 2009 by MausGames

[jrok]

You missed the point, I meant 'lame attempts at color blending in bB, yay or nay.' I know what you mean, but people can get over it. Especially if you are just being earnest and not condescending or mean. Posting something in a forum opens you up to critique unless you specifically request none. Please feel free to let me know what you don't like about anything I post, especially if it's something close to a real, playable game.

 

I think it looks real good!

 

It might be interesting to see what would happen if you incorporated great Michael's copy-to-RAM method as an experiment. I know that you would necessarily have blank lines between your playfield rows, but that might not necessarily be a problem given that you can define multiple heights.

 

Cheers,

Jarod.

[MausGames]

If it were possible to use pfcolors, background, and pfheights together and with multiple definitions, then I would give something like that a try. As it is, I have no application for a mod that can only be defined once and isn't compatible with 32x30 playfields.

 

I'm glad I tried this flicker method though, I found out that light gray on white is the least offensive flicker I've seen yet.

Edited November 3, 2009 by MausGames

[+Random Terrain]

Thanks for the screenshot. If the Stellacon (the Stella console) ever gets made, programmers will be able to go crazy with flicker and not have to worry so much about it since just about anyone who cares about the Atari 2600 will buy a Stellacon.

[MausGames]

If I were going to wish for something to be developed, it would be an extra chip for the Melody that somehow allows 40 playfield color changes per scanline, with little to no cost from a programming point of view. Full color, full resolution bitmaps with no playfield gaps or flicker are something this system might never see, but it would be amazing. I'm not sure I would want to develop something that I knew wasn't enjoyable on the original 2600, and I hadn't ever heard of Stellacon.

Edited November 3, 2009 by MausGames

[jrok]

If it were possible to use pfcolors, background, and pfheights together and with multiple definitions, then I would give something like that a try. As it is, I have no application for a mod that can only be defined once and isn't compatible with 32x30 playfields.

 

I'm not sure what you mean by this. Michael's demo certainly contains multiple playfield definitions. That was pretty much the point of his project there, from what I could grasp.

[ScumSoft]

Yeah I'll be posting something good once it's at a presentable state. In the mean time I am trying to pickup on everything that assists me in understanding the 2600 better.

 

I am curious though, I was under the impression that the 6507 didn't have enough umph to push the TIA for more than 9 color changes per scanline. How would a chip on the cartridge feed the TIA when it must first pass through the slow 6507? Is there direct access to the TIA from a rom space?

 

[MausGames]

If it were possible to use pfcolors, background, and pfheights together and with multiple definitions, then I would give something like that a try. As it is, I have no application for a mod that can only be defined once and isn't compatible with 32x30 playfields.

 

I'm not sure what you mean by this. Michael's demo certainly contains multiple playfield definitions. That was pretty much the point of his project there, from what I could grasp.

 

Sorry, I meant if it could be used with multiple pfcolor and pfheight tables. I've never made anything that uses both, or only allows one table like this.

 

I am curious though, I was under the impression that the 6507 didn't have enough umph to push the TIA for more than 9 color changes per scanline. How would a chip on the cartridge feed the TIA when it must first pass through the slow 6507? Is there direct access to the TIA from a rom space?

 

I was told this wouldn't ever be possible, that's why it is just a wish.

[jrok]

 

Sorry, I meant if it could be used with multiple pfcolor and pfheight tables. I've never made anything that uses both, or only allows one table like this.

 

But that's exactly what SeaGTGruff's modified superchip kernel lets you do. When you set the constant "RAM_PFcolorandheight" the playfieldcolorandheight table is accessed in RAM instead of ROM during assembly.

[MausGames]

Ok I'll take your word for it, and go back and study it some more. I was only going by what I thought I remembered, that it wouldn't work with anything but a 32x12 playfield, and the code is over my head so I couldn't really change it at all. I almost always use 32x30, and in this demo I used 32x32.

Edited November 3, 2009 by MausGames

[MausGames]

I've read through the thread again, but I haven't tried it yet. I agree with you it would be interesting to see what could be done with it, but I kind of consider this experiment a failure; I don't like playfield flicker, even at 30hz.

[+batari]

Yeah I'll be posting something good once it's at a presentable state. In the mean time I am trying to pickup on everything that assists me in understanding the 2600 better.

 

I am curious though, I was under the impression that the 6507 didn't have enough umph to push the TIA for more than 9 color changes per scanline. How would a chip on the cartridge feed the TIA when it must first pass through the slow 6507? Is there direct access to the TIA from a rom space?

 

I don't remember exactly what I said my planned dynamic kernel could do, but I wouldn't have said 40 color changes per scanline - I may have said a 40-wide playfield with color changes for all objects (ball/PF, player0, player1) on every scanline.

 

That said, the kernel still does feed instructions through the 6507 to write to the TIA.

 

However, there has been talk of making a kernel of nothing but stores to TIA registers and overriding the data bus during the store. This is of course out of spec for the poor 6507 but data sheets suggest it may work anyway as the output drivers appear to be relatively weak for a logic 1. So far I've been afraid to even try to see if this works as it could potentially damage both the 2600 and a Harmony/Melody cart.

[MausGames]

I asked during Chimera development if full color playfield bitmaps would be possible, and was told nothing could make that work. It's just something I would wish for if it were possible.

 

I would happily volunteer a 2600 if you wouldn't mind paying shipping, if a data stream kernel is something you want to pursue. What would be the benefits, and are they worth the work involved for you? The output drivers/logic 1 talk is over my head; wish I knew the hardware better.