Ben_Larson

That's the code alright, but often times it takes me several tries to get it right. I think you do have to finish the code before the opening title screen finishes scrolling too...

Ok, added 2 more songs - press joystick left/right to switch songs. The revised playlist is now: 1 - Jingle Bells 2 - Deck The Halls 3 - Silent Night 4 - We Three Kings 5 - Carol of the Bells 6 - Adeste Fideles I guess this makes it an EP now. Time to start thinking about the visuals... very2600xmas.bin

I love these demos. Makes me want to try one myself... not that I would be able to match this type of quality though. The plot sphere is especially impressive. I found myself saying "no way!" out loud on that part.

It has come to my attention that there has been a disturbing lack of Atari holiday cheer 'round these parts in recent years. To rectify this situation, I have taken the liberty of embarking on a crash homebrew project which I am tentatively calling 'A Very 2600 Christmas'. Basically I am arranging a bunch of Christmas songs for the Atari 2600 using some of the music code I took out of Panky the Panda as a starting point. I've got 4 songs done so far, which I am previewing here in this rom. The songs done so far are: * Jingle Bells * Deck the Halls * Silent Night * We Three Kings Use joystick left right to change songs. There's no visuals yet (literally it's just a black screen ), so I'm open to suggestions (or help!) in that regard. Let me know what you guys think... very2600xmas.bin

PM sent...

The reason I didn't make a PAL50 version of Panky the Panda is because I didn't want to mess around with all of the fixed point math in the game. Mainly I'm not entirely sure it's possible to increase the values used right now without messing up the landscape collision detection. I guess it would be fairly easy for me to whip up a prototype PAL50 version for the show that runs at 83% of the speed of the NTSC version if nothing else though... Edit: Ok I'm an idiot. I just realized I already have PAL50 support in the source code - I just didn't include it in the final zip file because of the lack of speed correction...

Ah poop... I just realized I actually never did a PAL50 version of PtP yet. All I have completed is a PAL60 version in the zip file...

Well the ROMs of my 2 games are always available on my website and I do have PAL50 conversions included in the zip files. I'm not sure if you're only looking for WIP games, though - in that case then I guess I got nothin'. But if that's not the case, then feel free: http://www.blarworld.net/software.html P.S. PtP uses F6 bankswitching...

Oh I forgot to mention one thing, though: the 'pig' in the game was actually supposed to be my attempt at an armadillo. It does kind of look like a pig though now that I look at it...

Sorry it took so long to respond, Brian - I haven't logged in to Atariage in a while. That box art is indeed pretty awesome. I haven't made any plans for a physical release, though, and I don't know if Al is planning any new releases anytime soon either. Maybe if enough people pestered him though...

v1.0 came out in Sept. 2010. I made an minor update the next month to fix an issue in JStella, which I'm using to emulate it on my site. Here's a link that version which is the latest (v1.01): http://www.blarworld.net/Panky1.01.zip I wasn't really planning on making any more tweaks (except maybe for bugfixes)... Ben

I don't want to discourage you, but assembly language is hard, even for professional software developers. That's why almost nobody still uses it anymore... we have better, much easier tools at our disposal nowadays for most all programming tasks. But allow me to elaborate further: When you're programming in assembly language, you're basically one step away from the 1s and 0s that the CPU actually uses and understands. The assembler is the program that takes your assembly language text file and converts it directly into the 1s and 0s. If you've used PHP, you're probably familiar with *some* of the principles you'd still see in assembly language, like variables, conditional statements... stuff like that. But you're still pretty far removed from the details, and there's a lot of things you will run into that are going to be new: like binary number representation, binary math, bitwise operations, addressing modes. That's all stuff that you don't normally worry about in most high level programming languages like PHP, because the compiler or interpreter abstracts it all from you. And there's a reason for that: most of this stuff is a pain in the ass to deal with manually. It's kind of like the difference between driving a car and working on a car. Most people can drive a car without understanding all the details of how exactly the car works. That's like high level programming. Assembly language programming is more like working on the car, because you have to know how everything under the hood works. So I guess what I'm saying is, if you really want to program for the Atari 2600 and avoid the hassle of dealing with the frustration, you *could* try writing something in Batari Basic, which is the one high-level language available specifically for writing Atari 2600 games. Sure, you won't have as much flexibility in terms of capabilities, but it's going to be much easier and probably more enjoyable for you. Anyway just my $0.02. Feel free to ask any other more specific programming related questions you might have though...

No that would just mean you're in violation of the copyright agreement set forth in the GPL for the original GPLed software. Otherwise I could "accidentally" include Microsoft Windows in a GPL project and *boom* - free Windows for everyone. Right?

Well... to be honest.... I already didn't feel very motivated to make more changes at this point. But I can at least answer your points! This is mostly due to the level storage design. Each screen only holds a maximum of 2 objects (an object being an enemy, ladder, save point, item). Each screen's data is basically 16 bytes long: Tile pointer data - 6 bits per tile (5 actually, but high bit is reflect bit) x 12 tiles = 9 bytes Adjacent rooms (left, right, top, bottom) = 1 byte per room x 4 rooms = 4 bytes Room object types = 4 bits per object x 2 objects = 1 byte Room object X/Y positions = 4 bits per axis x 2 axes x 2 objects = 2 bytes Each tile pointer points to one of 32 tiles that all the rooms are built from. Well it doesn't really restart the game. You still keep everything in your inventory... You don't, really. The only object is to explore and eventually open all the doors so you can get to the end of the game. I think I'm going to plead lack of RAM and ROM space here. According to my handy text file that has my notes (last updated in July, so possibly out of date) there's only 148 bytes free in Bank 1 and 69 bytes in Bank 2. Banks 3 and 4 handle the title/ending screen and music, respectively. I don't think the situation there is much better either...

Thomas, Are you talking about how the jumps are not always completely parabolic, or that gravity is too low/high, or something else? Ben

Probably not much, maybe $1 a game. Which is, of course, more than $0 a game.

Hey sorry to resurrect this dead thread, but I just thought I would weigh-in on some new thoughts I had regarding digital distribution today: So I've been perusing Steam the past couple days, looking over all the games they had for sale via digital download. I noticed all their indie game packs they're selling as part of their holiday sale right now. A little while later I noticed that Sega is now offering ROMs of some old Genesis/Megadrive titles through Steam for a couple dollars each. Then I had the idea that you could basically solve all the problems being mentioned in this thread at once (piracy, reaching a wider audience, adding value) if you packaged a bunch of *embedded* ROMS together of a similar theme (adventure, action, strategy, etc.) *with* an emulator *and* the extras, etc. While it might be a longshot to actually get something on Steam, all they could possibly say is no, and you'd still have the package to distribute elsewhere (i.e. here on AtariAge, maybe). Of course then there's the small matter of licensing an emulator... which I suppose would be the necessary first step

Ok guys, I'm gonna call it a game. Here ya go: Version 1.0 Changes since Beta 5 -------------------- * Fixed bug related to having an item equipped, quitting, and then starting a new game * Fixed slight horizontal motion judder * Ice screens are now light blue instead of white/gray * Fixed the order of keys in key display to be more consistent color-wise * One minor sound effect change * Altered color of red key in the key status display to be darker This version also includes a PAL 60Hz binary ( SECAM 60Hz too... for the 0.0 people who probably want that. ) I don't plan on making a 50Hz version unless somebody really wants it. BTW, in case anyone is interested in how much time is involved in making a game like this, I've been (anal retentively ) keeping a log ever since I started. Looks like the total LOE is about 242 hrs. That includes time in front of the computer, programming, as well as all testing... but doesn't include, say, time spent passively watching TV while also thinking about some implementation detail. If you add that in, it may be closer to 300 hours or so. I think I remember reading once that David Crane spent something like 1000 hours on Pitfall. Not saying this is equal to Pitfall, but I think this may say at least something about the benefit of modern development tools vs. what they had back in the day... Panky_the_Panda_1.0.zip

Well I could conceivably add one more item/enemy, but there's no memory left to 'keep track', for example, of whether the player has fetched a certain extra life item yet or not. I've already gone through 3 times to squeeze out more bytes for features too - first time for the random movement of the bat, second time for the music, then once more for the sound effects...

Quick update: I'm now working on the PAL conversion right now, then I think I'll be done. For anyone from Europe, which do you prefer: true 50Hz PAL conversions with squished screens or 60Hz conversions with a non-squished screen? (which I guess may not work on some older TVs, right?) I plan to offer both, but I can't say for sure there won't be issues with adjusting the gameplay speed for the 50Hz version...

Another new version. Changes since the last one: * Added 'continue/quit' screen * Fixed a couple minor bugs I guess I still need to test on a real system with a joystick and not a gamepad, but barring any difficulty changes I think I might be done... Panky_the_Panda_1.0_Beta5.bin

And without further ado I present to you... SQUARE RAID. In 1K of javascript: http://www.blarworld.net/squareraid.html Your mission is simple: carpet bomb the SHIT out of hapless enemy squares. Controls are W/A/D for up/left/right and B for bomb. Score appears in the title bar, the screen wraps from left to right and top to bottom (for you, not for bullets and bombs), and enemy squares spawn faster as you progress. This uses the HTML 5 canvas element BTW, so it won't work in Internet Explorer (yet)...

I figured this might interest some of the minigame coders here. There's some 1K javascript competition going on online, with submissions due next month: http://js1k.com/demos There's some really really impressive graphics demos - only a few games so far, though. I'm actually working a game right now that I might submit... assuming I can fit it into the requisite 1K, of course. Ben

Your sarcasm is coming across loud and clear With that said, I vote for Nethack. I think that would be the most doable for a couple reasons: #1 because it would involve procedurally generated content, which means less content to create (and hence less work). Underestimating how long it's going to take to create content is one of the major reason these projects fail IMO. #2 doesn't seem too impossible from a technical standpoint: You could use the playfield to create the room walls, and then use some 4x8 player sprites for the player, objects, monsters, etc. You could probably even use Batari Basic to do it...

There have been other attempts as well. The most promising IMO was the Homestar Runner RPG, although it died like 6 years ago: http://www.qotile.net/rpg.html There was another attempt at an RPG-like overworld-engine someone wrote a while back too, but I can't seem to find that one at the moment...