RetroFiends

This is absolutely insane. This is NES ROM size territory. We're talking, near the end of the console's life NES ROM sizes. I'm just going to go out on a limb here and guess my Harmony isn't going to touch these ROMs? Edit: Of course it wouldn't, and it says so in the thread. I Just saw 256 and my mind was blown across the wall.

Just showing my support. I'm stoked for when this project is finished.

I agree. Make the ad part of the experience, don't make the ad detract from it.

You may need to offer a cassette tape with an infinite loop to be played at the same time for the soundtrack

I'm not too familiar with DPC, but it looks like you set a rom size maybe? DPC defaults to 32k and you're stuck with 32k

Hey man, you can always make your own Pizza Hut and Taco Bell cartridge And yeah, it's definitely lame when brand names get removed in rereleases of games. Crazy Taxi just isn't the same without Pizza Hut, Tower Records and The Offspring music.

I really can't decide whether I like Halo 2600 or Pac-Man4k the most. I play Pac-Man4k quite a bit more, but the sheer novelty factor of Halo 2600 brings it right up there, too. Halo 2600 is also a great game to have around when you have more modern gamer friends around. They always get a kick out of it, guaranteed.

Yep, my playfield is already just reflected. It's also only two rows of playfield pixels. The single biggest use of space is definitely the titlescreen, of which is about 1k or something crazy. I'm sure when I'm done with the game, creating a 4k version will be no problem if I go with a "titlescreen" rendered in playfield pixels. As well, since cassettes are double sided, I could easily put game modes onto separate sides. For the time being I'll keep work on this cartridge version since it will probably have more chance to be noticed than the supercharger release, which is mostly something I really just want to do with no rationale behind it

I'm surprised other people are as pleased with the title as I am I wanted to keep the title as close to what you could expect from gameplay as possible, while still rolling off the tongue in a sinister way. Pretty much, the name needed to sound good as voiced by a gravely voiced 80's horror movie trailer guy. Currently, I'm reworking the difficulty curve. In the current build, difficulty is kind of "hacked" in, but this next build will have difficulty levels 1-20 as their own entries so I can tweak the gameplay up to the maximum difficulty. The modularity of it should all me to make quicker adjustment if say, level 5 turns out to be way more difficult than level six, somehow. This was all hardcored into behaviours before, for demonstration purposes. Flashing will be removed as well, and the addition of mines which will periodically appear on screen and float up to the top of the level.

I may be in the minority here, but I absolutely LOVE product placement in video games. Almost breaks the fourth wall, but not quite. I like when soda machines pop out DELICIOUS "MOUNTAIN DEW" rather than generic "Citrus Drink". Billboards in games are obviously a great way to do this, but it's probably best to mix real and invented products/brands so it's not so forced. Sometimes forced is good, such as the PSX game "Pepsi Man" or the Cool Spot games. That said, I don't think this does anyone any favors in homebrew games. If you want to have someone pay to develop a game, then commissioning it is probably a better option. But as you personally experienced, getting someone interested in a 2600 homebrew commission isn't so easy.

No worries, I already opted to break the 4k restriction, what with the titlescreen there just wouldn't be enough room. I may opt to make a 4k version later for the Super Charger, so if you're still up to it at that point I'd love to have you look at my code when it comes time to see if we can't squeeze it into 4k.

Thanks for the feedback. I was actually considering mines, and now I'm definitely going to see if I can't get them in there. The ball object isn't an option, as in the multisprite kernel they are fixed at one pixel high. But At any given time I reserve player 5 for random drops such as the treasure chest, so having a more convincing mine is no problem. Yes, this is the multisprite kernel. I was originally going to opt for a 4k rom, but I'd rather flesh this out as much as possible, specifically a title screen and a few extra game modes. And the name is final

I was thinking the flashing might be a bit much. I'll be sure to remove it from the next build. I'll try it with the shark.

Eat people to avoid starvation, but watch out for that pesky Coast Guard! Controls and gameplay: In Hunger Shark you play as a shark with an insatiable appetite. - To move Hunger Shark, point the joystick in the direction you want him to move. - To eat people, Hunger Shark must sufficiently overlap them. Doing so gains you points, and replenishes a bit of your Hunger Bar. - If your Hunger Bar drains completely, you will die of starvation. - After some time, when the water becomes blood red, the Coast Guard will send a patrol ship and shoot at you. - Touching a squid collects it for later use. Using a squid, by pressing fire, will replenish your health completely, but will spray ink, thus turning Hunger Shark and the water black for a time. You can carry up to three squids at a time, but touching them will always yield 1000 bonus points. - Treasure is known to pop at the sea floor from time to time. It may not be nutritious, but it does yield 1000 bonus points. - Mines will periodically spawn near the bottom of the screen, so be on your guard! - The game increases in difficulty slightly with each level. Build Updated: February 12th, 2014 Download .BIN hungershark.0.2.4.bas.bin Criticisms and Suggestions Welcomed. Thanks for everyone who has helped me with questions across numerous threads, and thanks to Random Terrain, of which I lifted the movement from his 8 direction missile example proved to be better than my own for the game. Thanks to Batari, for letting me finally realize a childhood fantasy to create a game for a video game console. Thanks to sharks, as well.

Yeah, it compiles still, but the glaring red error message is still spooky nonetheless. Setting constants did some really strange stuff, though. Changing y position beyond a certain point changes the sprites, and the x position of sprites changes with calls to the pointers as well. I've since removed those and am currently just "dealing" with having to find the addresses as I'd rather devote time to furthering the game itself which is nearing completion anyhow. Unfortunately I really don't have any variables to spare. In fact I'm trying to think of some clever ways to re-use them. No worries, I saw where you were going with it.

I somehow missed that post entirely! Yes, the address changing has been getting on my nerves, so I'll definitely look into setting constants. I'll chime in again if I have any further questions. Edit: also, a side note, I am not using data tables with this. My sprites are accessed according to need and not sequentially, and are of varying heights, so I just set the lo-pointer to whatever it needs to be along with it's player height and I define all the high pointers towards the beginning of the program. Not the most efficient use of space, but it's a bit more readable and intuitive for the time being. Edit: Edit: attempting to set constants gives me an error: 2600basic_variable_redefs.h (85): error: EQU: Value mismatch. old value: $0034 new value: $0025

I could probably do that, yeah. I think in most cases it's more of a pain than it is worth. If I wasn't working within a 4K rom I would probably avoid this technique, but when you need every last byte you can get your hand on, this is definitely a place to look. Once you figure it out, it's a matter of keeping up with where the multisprite kernel puts your player0, You never no what changes you make will upset it and then you'll have to look up the address again and then redefine your pointers. I'll do a more thorough walk through in a bit, maybe make an example .bas or something for a bare bones implementation of it.

A little update: I got shared sprites working, completely! I had some additional considerations to consider. The first sprite required an additional blank byte at the top, otherwise it'd continue drawing. I have sprites of varying sizes so I had to set the playerheights on their associated frames, which meant it wasn't quite as simple as just using a data table. I'm sure this could have been done a lot more efficiently, but the 484 bytes I have now is MUCH better than the 145 I had left before. Thanks everyone for your help! It's time to tweak a few things. Edit: Spoke too soon on those savings. Turns out since I didn't have my statusbar include at the beginning anymore, it had been left out!. Fixed that, and I'm only at 252 bytes now It's something I guess.

Noble quest aside, I'm pretty sure this is the wrong section. Unless, of course, you actually have a means of programming such a cartridge and the means to create the custom hardware that'd be required. The most robust "repurposing" internet program for a retro console I've seen is probably breadbox64, a twitter client for the 64. (Which seems to have disappeared) And, as much as I get a thrill from an old TV, for the environments sake, the sooner they're gone -- the better. Not only are they outdated on a technical level, they are wholly energy inefficient and hazardous. You're right, we should keep these out of landfills-- take it to a local recycling entity that has the experience and expertise to dismantle and repurpose these machines. NEVER throw them away. The same goes for CRT computer monitors and similar electronics. I keep an old(er) TV around for my own retro game systems and my VCR, because these things look much better on their intended display ratio/output, but I won't even pretend that we need to preserve these machines.

The first thing that comes to mind is to do it in such a way that is similar to software collisions. Simply check if there is a playfield pixel at a y coordinate that is +- the sprites' y positions. Of course, this is easier said and done, and will likely include many if statements, especially if it needs to be true for both players. You'll probably need to use pfread, which can take variables and arrays as arguements. So, you'll probably need to set a counter that goes from 0 to 31 to check each position to see if there's a pixel, then plug that into an array which gives you the actual x positions of those pixels, the y position in the pf read argument can be the playery's y position rounded to the pixel rows as you see fit. Then, you check the second player, and see if they match up. In practice however, it would seem that this code would take up way too many cycles to ever actually be useful. If you know the places where the pfpixels are, you can cut down on the redundant checking and go straight to the comparison. In the case of a game like maurader though, this whole thing is way more complex and out of my jurisdiction. Pretty much what you're asking for is line of sight. and in that case, you'll need to check if there is a pixel within the player's line of site, and if not, show the sprites in the direction of the player's line of site. You will definitely need to do some calculations for something like that.

Thank you for the clarification SeaGtGruff, this makes a bit more sense. From what I'm aware, sprite data is always shoved to a certain area of code, so 91 should be the starting point in any program, right? Moving the sprite data into other locations in the tone-toy program seems to have no affect. Concerning data tables, am I correct to assume that all data tables really do is jump to an address? I'm a bit confused at to how in normal use data tables pretty much store whatever numbers you throw at them, yet in this instance they're pointing to the player data. Is it purely because using playerxpointer looks to the players in rom and you're effectively borrowing the data table to nudge it in the right direction? It seems like some really neat tricks could be done with data tables if this is the case. If I can get off my lazy bum and get to programming, I'm going to try to implement this. The savings in bytes would be tremendous. Thanks to everyone who replied, and thanks for baring with me with my constant barrage of questions regarding bB Edit: I found out by looking in the ASM that NO, the player data is not always at the same address. In my program, the zero shape is at FD5A. So if I'm understanding this right, I'll need my playerxpointerhi to be 253 to reach that 91. Any more or any less and I can't access that address. Edit: Edit: And progress! 253 is indeed the number! But unfortunately it draws all the sprites in a single strip. I must have botched something up.

Thank you! Now it kind of all makes sense!

Based Ed Fries making superb 2600 titles, can't wait to give this a go. On a side note, I showed my friend Halo 2600 yesterday and I finally got to legendary mode, and we were cracking up at how damn slow the chief walks across the screen. Genuine good times.

I'm not ready to admit defeat just yet. I see no reason why I couldn't implement this, I just want to understand more of the "why" in the equation now, at this point. As for why I'm looking into this, my program has four players that share the same exact sprite. Without sharing sprite data, I'd have to duplicate the data of player 1 for three other players, and the animation is four frames long. That's (guesstimation, sprites are 6 rows high in most cases) 578 bytes wasted if there's the possibility of sharing them. If vertical flipping of sprites was possible, I could reduce that by half, and I may even opt for a two frame animation altogether depending on how desperate I am for space when I'm down to the wire.

In a sense the tonetoy program does exactly that, and not much clarity comes from it.