Cybearg

But what can be done with the way that the virtual sprite disappears when near the bottom/top of the screen? EDIT: Yeah, wish I'd have thought of the obvious solution of just lining them up by having the virtual sprite's coords equal sprite 0's coords. But there's still the bigger issue of the virtual sprite flickering at the bottom/top of the screen. Player 0 can move pretty much off the screen on the top/bottom while still remaining partially visible, as it should be, but the virtual sprite flickers and then vanishes when nearing the vertical borders. Can anything be done about this? moveshow.bas.bin

Just made this example. No list file was generated. rem batari Basic Program rem created 7/19/2013 10:27:38 PM by Visual bB Version 1.0.0.566 set kernel multisprite dim counter = a pfheight = 7 gosub resetall main if (counter & 1) then goto skipmove if joy0up then player0y = player0y + 1 if joy0down then player0y = player0y - 1 if joy0right then player0x = player0x + 1 if joy0left then player0x = player0x - 1 if player0x > player1x then player1x = player1x + 1 else player1x = player1x - 1 if player0y > player1y then player1y = player1y + 1 else player1y = player1y - 1 skipmove if collision(player0,player1) then gosub resetp1 12hi player0: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 end 16hi player1: %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 end COLUP0 = $0E: _COLUP1 = $0E drawscreen goto main resetall player0x = (rand & 127) + 16 player0y = (rand & 63) + 8 resetp1 player1x = (rand & 127) + 16 player1y = (rand & 63) + 8 return thisbank moveshow.bas moveshow.bas.asm moveshow.bas.bin

I initially asked this of bogax in a PM, but I'm really itching for an answer, so I guess I'll bug everyone with it: I'm trying to get player 1 to chase down player 0, but there are a couple problems: 1. There are "safe points", such as in the lower-right corner of the screen, where player 1 nuzzles up close to player 0 but never actually reaches player 0. I assume this has something to do with the coordinate system, because I'm simply using: if player1x > player0x then player1x = player1x - 1 else player1x = player1x + 1 if player1y > player0y then player1y = player1y - 1 else player1y = player1y + 1 ... And yet there are places where the sprites will never touch each other. If it matters, player 0's sprite is 12 pixels high and player 1's sprite is 16 pixels high. Player 0's sprite is 8 pixels wide in some frames, but player 1 is only filling out the center 6 pixels, with a column of pixels empty for the highest and lowest bits. Any idea what I can do to deal with this coordinate problem? 2. There are places, such as at the bottom of the screen, where player 0 remains visible but player 1 becomes invisible -- the sprite doesn't get rendered. I would assume this was simply coordinate-based, but I'm currently using soft collisions instead of hardware collisions and I (sometimes) still get soft collisions even when the sprite isn't showing, so it's possible it has something to do with the sprite's positioning. Any idea what's wrong there to make player 1 vanish while player 0 remains visible?

Do you like that it says Survival, or would you prefer that it says The End, instead? The "PRESS FIRE" command can always be hidden for that screen without any trouble.

I think you would have more enthusiasm if it only featured characters that appeared on the 2600. From what I've read of the thread, most of the disappointment came from the use of non-2600 characters. I don't understand what the problem is with necro-posting. Why is it better to create a whole new thread (which would take more database space and have to have all the context for its content re-explained) rather than to continue an old discussion where it left off?

I know what you mean about the enthusiasm. No offense to the folks doing them, but sometimes it feels like people only want existing games remade for the 2600 and have little interest in an original game.

You're a freakin' genius with batariBasic. Wow!

I expanded the title screen I submitted earlier to include an ending screen now. I went with "Survival" instead of "The End" to convey kind of a somber, "you have survived... for now" tone that would come with a zombie apocalypse, but I can always change the word, the colors, etc. (I kept them the same for consistency with the title screen). The attached .bin has both the ending screen and the title screen, which is toggled by a bit, so in your actual game, you just have to set a single bit and then switch to the title screen bank, or however that would work (I've never made a game with an implemented title screen before, just stand-alone ones). This uses up one 4k bank, but the rest is free for other things. You can switch between the title screen and the ending screen in the attached ROM with joystick fire. EDIT: Maybe I misunderstood what you wanted. I thought you wanted a final win screen for when the boss was defeated as kind of a reward for winning. I'm not sure exactly how one would implement two different title screens in one game. Probably possible, and I could try again to make scrolling text in a separate title screen, but I'm not sure how you'd merge them together. ProjectZ_Title.bas.bin

I think the words stand out more with the blue, but the title "Project Z" is red on the cartridge label, so it's kind of obligated to share that. There's already a gradient, so it does get brighter, although, as you pointed out, it's still kind of dim. Making it any less saturated would make the title appear pink, though.

Well, if there are no other entries or you decide to go with mine, just shoot me a PM and I'll send you the raw files.

Thanks, this is the response I was looking for, unfortunate as it may be. Thanks for letting me know.

So I'm in a situation where I'd like one player to move behind the playfield while another player moves in front of the playfield. Is there any modification that can be made (not worried if it costs extra memory) to the kernel to allow for this?

Looks great so far! Really cleverly done with a lot of those programming tricks.

Yes, you would most certainly save space, though I'm not sure how to enable mirroring with the standard kernel. I assume there must be a way. If not, it would be great if someone implemented a way, because sometimes mirroring is ok. I assume it should work if you just study the way that the light gun detects a hit, then mimic it. With the NES light gun, I believe that the screen flashes black and the target becomes white, right? Just do the same when the light gun's trigger is pressed. Not sure how you confirm a hit, though.

Alright, here are a few different options, then. Let me know which one you prefer and if you want any other changes. ProjectZ_Title_redblue.bas.bin ProjectZ_Title_redpurp.bas.bin ProjectZ_Title_redred.bas.bin ProjectZ_Title_redyell.bas.bin

But wouldn't the memory be cleared each time the kernel was loaded? I don't fully understand Deb's description. I assumed this is the same framework he gave me for the compilation I am working on. With what I have, each 4k bank is isolated, able to have any kernel, and memory is wiped by jumping. Is this one different, Rev?

How much more will boards for this bankswitch method cost as opposed to the 32k version?

I'll do that tonight when I get home from work. Initially, the title was red, but I felt it didn't stand out enough from the moon/sun background and a gradient of blues didn't have the same color variety as yellows through reds, but I'll give it another shot!

Looks great so far!

16 banks WOULD be great. Though, as you say, it would be nice if graphics could be pulled from other banks. Is that a particular reason why they have to be in the last bank, aside from batariBasic choosing to put them there? Though I'll admit I don't really know what I'm talking about, that board doesn't look overly complicated, so is this bankswitching method more efficient as well, meaning there could be cheaper bankswitching boards in the future as well?

Well, here's my attempt. Let me know what you think. Note that it will basically gobble up a whole 4k bank for the title screen and there's really no way around it. I can always change around the colors, of course, if you'd prefer things different. ProjectZ_Title.bas.bin

fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bas.bin fake_gravity_platformer_with_duck_and_fire_and_pfres23_2013y_07m_08d_1559t.bas.asm

Is there a particular reason why the missiles are fixed to 1 pixel high in the multisprite kernel? Is there anything that could be done to ease this limitation, allowing for taller missiles as in the standard kernel?

Ah, i see. And to add that particular combination would require rearranging all the sleep values?

No, nothing.