RetroFiends

You can use playerxpointer, but it doesn't work like you'd expect it to in the standard kernal. In standard kernel you can pretty much just say player0pointerlo-player1pointerlo, but that is not happening in multisprite. In the tonetoy example, all the sprites graphics are defined in player0, and it uses the data table to get the correct "chunk" of that definition. Since there is a (correct me if I'm wrong on the exact number) 256 (0-255) sprite height limitation, you may need to cut up that player into two segments. I'm still not quite understanding it, but the playerxpointerhi in this case determines which iteration of "player0" you use, and player0 can actually be any player, it does not care. It just loads up the first sprites available. Sorry if my explanation is confusing and only brings up more questions, but if it does that's exactly how I feel right now. Edit: You can indeed have data tables of any length, you just must keep in mind that your program won't try to go OVER otherwise you'll get junk, which makes sense. I think I have sufficient understanding to hack this into my game now but if anyone has any more explanations on anything please do chime in.

I'm so close to finishing this game, and I need the extra sprites, and need the game to be under 4k for supercharger-ification. So I'm kind of stuck with it. Edit: Bad news: because it doesn't care what the player is, adding more player sprites of any number will screw up the data table. If you use this method it seems that every single sprite must be placed in the original definitions. Not impossible, but a tad difficult to read. Still no clue why the data table starts where it starts, and no clue if you can have data tables less than 32 entries, will test that momentarily.

More wtf moments emminent. I subtracted 1 from the data tables. I changed player 0 to player 1, and now they're perfectly aligned again. This data table literally does not care what number the player is, so long as it's a player. So that begs the question even further, why the hell is it 91.

Oh god I wish I understood any of that edit: okay, I kind of understand it. the big old player0: there holds all the data sequentially, but I don't understand how the data table is calling to that sprite nor how they're actually being separated. edit: edit: Further examination shows that in that example plo's data table is built in a linear sequence of 6, which lines up with the sprite data which is 5 lines+1 row of zeroes which divides the sprites. the last 5 numbers of both data tables correspond to the last 5 digits which are in the second player0 sprite, denoted by 252, and starting the sequence over again. Kind of rubber duck debugging here, but I still have no clue why the data sequence starts from 91 rather than any other number such as, oh, 0. more edits: There is a real reason why the sequence starts at 91, I tried starting it at 0 and things come up garbled. conversely, I added and subtracted 1 to the data table and it shifts how it's supposed to. So this begs the question, why 91? What makes 91 magic? do all player0 sprites start at a value of 91? At this point I could probably hack something together by just accepting things for how they are and questioning nothing but I feel like I need to know.

I know it's possible to share sprites between player 0 and player 1 in the standard kernel using player0pointerlo and player0pointerhi, and I know that entries exist for player2-5 pointers, but I cannot seem to use them whatsoever. I've searched around and I found in this thread http://atariage.com/forums/topic/136873-player-pointers-and-the-multisprite-kernel/ but unfortunately SeaGtGruff never replied again. Batari Basic guide doesn't show much on the matter other than that they exist and the addresses to them. Can anyone help me peace this together? four of my objects have the same exact sprite and they all share the same animation counters. Even if someone can help me jury rig this in ASM it'd be a huge help as I'm in need of extra space like nobody's business.

I just tried dig dug and I'm A-OK there, but I tried stargate and it does indeed have some issues, although I can't verify other dumps of the game. First game I've run accross. The tv goes spastic and makes whine if you try to run it almost like you're wiggling the cartridge.

Be careful what you wish for, stardust4ever.

kind of late to the party, but you could always put a little teensey atari age logo somewhere non-competitive so that they're more identifiable as reproductions.

I'm not quite sure I understand what you're attempting to accomplish. A tiny atari 2600? It's possible, but it's already been done. One was built into a controller, which you just plug in a cartridge to the controller, there have been handheld ataris, and then to a lesser degree all those atari joystick tv games and atari flashbacks.

It probably has to do with the way DPC+ structures it's content. Certain things have to be in certain banks in order to fit. if you chose a 16k rom, you'd only have like 4k-ish of useable space or something and for projects ambitious enough to use DPC+ that seems pretty restrictive. That said, if DPC+ didn't have to be quite so "big" I would have chosen it on my current project that needs to be under 4k, so I'm going with multisprite instead. I'll probably be using DPC+ for my next project though, and I'm going to need every damn bit I can get my hands on.

Well, if these ASM by Andrew Davie tutorials say anything to me and I'm actually understanding it, You'd have to update COLUBK or COLUPF at the appropriate point using WSYNC in order to be able to touch PF0. SeaGtGruff made an example at one point updating the colors in PF1 & 2, or the actually touchable portions of the screen for us bB users, and while it's impressive, it's also a bloody mess in bB code and wholely innefficient use of cycles It looks far, far easier to do something like this (keeping it in mind from the beginning) in ASM. I keep running into things like that. If it keeps up I really will learn ASM.

Can life color be changed in single bank 4k games too, or is this just a weird thing with multibank games? If it can, it's just that much more color we can display Now if only I could change the PF0 side colors to something else in the multisprite kernel...

Atari box art gets a lot of crud today. You'll hear people say everything from "It doesn't even have to do with the game" to "it's false advertisement" and so forth, yet this is probably the first I've seen someone actually defend the artwork openly. I'm a lover of box/cartridge art, and to me it is indeed a big part of the game. It doesn't have to be "accurate", it has to make me notice it, identify it, and that's exactly what the point was all along. To get noticed. If you just have a boring black box with nothing but the title in yellow, that does far less to give the game an identity for me. Games with semi-true to game images are rare even today, because a screenshot simply does NOT give you any idea of how a game players, it's more a status quo type of deal. This line kind of solidifies that mentality. The only games I know (that matter) that have true to the game box art were the first party NES games and even then they took a lot of liberties. Video Games are interactive, constantly moving beasts, they are not a still shot of blocks. A screenshot is only approximately 1/60th of a second of gameplay, and it can never be any more than that. Good cover art tells a story. Even the screenshots of the games may be interpreted "facsimiles" if you will, to help convey the game better. Musicians have known this for decades, but I guess considering the relative age of both industries, the video game industry is still in it's infancy.

I'm crossing all my fingers and it's making it difficult to type. It's like typing with a lobster claw.

I'm only gay like 30% of the time, so I should be alright so long as I'm careful.

Homebrews aren't exactly easy to sell on ebay in comparison to the hundreds of other listings of official games listed for 10$ including box. You'd have to be able to produce the games so cheaply that I don't think it can be done for a profit unless the homebrew is notable enough to be worth that much. I forsee Princess Rescue being one of those games, there's already one listed for 150$ but it appears to be legitimate. Whether it will sell or not is another thing, but I digress. Original sale price is not indicative of after market value. In most case that number actually goes down. You're better off making counterfeit prototypes.

Will program ideas for food

Fund it.

Oh look, people of previous generations dissappointed with the current one. Just remember, you helped make it! I for one, consider AVGN funny. It's off model, it's absurd, it's outrageous. Even beyond the vulgarity, the shere honesty in his expressions and body language show that it's more than just an act; it's repression. There was once a time where smashing watermelons could be considered vulgar.

I actually already have my Harmony Cart and Princess Rescue is on there. There's just something about owning an actual cart for me. This is one of those instances where I wouldn't feel right using ebay. Sprybug wouldn't get anything out of it, either. Blows all around. In the end, it's my fault for waiting so long. I wouldn't be so sure. The current IP holders of the Giana Franchise, Black Forest Games, are extremely cool dudes, and are open to communication; at least they were when I reached my hand out to them on numerous occasions. If you explain the situation to them honestly, bring this whole escapade up, your fears of continuing to develop this homage, I think your chances are very good that you can get the go-ahead.

This is the second time I've seen Princess Rescue brought up on this. I need to find the thread with the deets on it. Edit: I hope this doesn't mean it's not available anymore. I was saving up for a cart Edit: Oh, wow. That blows. It's like Great Giana Sisters all over again. Yet nintendo at least forgave that one enough to release Giana Sisters reboot on DS...

If you flesh it out more, I'll probably put it on my harmony cart Some suggestions/notes on things as they are now -I love when levels are designed to like like things, like the smiley face -Because the player sprite is effectively double the width of playfield pixels, moving vertically is a bit unintuitive and hard to line up. It would feel more intuitive if the player moved two playfield pixels at a clip. -I agree the game is a bit slow, but I don't think the pacing is the problem here, but rather the jumpy movement. If you had the player move into each position of the "grid" a single pixel at a time (think final fantasy NES grid based movement) the game could keep it's current pace yet feel a lot smoother, and would allow players to line up their next shot plus minimize the chance the player will accidently move by holding the direction just a hair too long. -a little sound effect with each movement would probably go a long way to emphasizing the pace/rate of movement. As for suggestions not related to the game at this point: -A time limit might help to introduce more challenge -Some degree of randomnization to keep things interesting.

Asking someone to give up all the rights to something they created for a lump sum of cash is kind of outrageous, especially when being approached with the intent to put said IP into a specific product. It would seem to make more sense to license it. I could probably be convinced if the number was high enough, AND I was sure I wasn't going to do anything else with it. On the flip side, I wouldn't be bothered at all if someone made derivative work of something I'd done. In fact I'd be flattered.

Thanks for the responses guys. This looks like the one instance where using asm is actually easier