jbs30000

Well, so far, (without looking at Combat or bB kernel*) I know how to put in code to display two sprites (single color) and both missiles, with no code left over to display the ball. I even figured that I have enough cycles left over to write to the VDELP1 register as suggested in post 6. And still being a beginner at 2600 asm programming** reading disassembled programs or even Batari kernels isn't easy. I've decided that I'll have to make notes, and probably even charts, on all of the code before I can decipher what's going on. * I tried looking at the bB standard kernel. It was hard to make out. ** I'm not new to asm, I've studied Intel asm. I'm just new to the 2600 registers and timing issues and so on.

Well, I played around with the timing and found I could use two sprite display routines and two simple routines to display missiles 0 and 1, but not the ball. But if I have to time when to turn on the displays...this will be interesting.

Yes, but I'll look over it again later. Thanks.

I made the changes but all it did was make that one area act slightly different. I played around with some other areas of code that I thought might effect it but that didn't work either.

OK, so I'm playing around with sprite positioning. Everything is OK, but at a certain point at the left side of the screen my sprite (player0) will shift up one pixel. So it's like a small vertical strip on the left-hand side is one pixel lower (for sprites) than the rest of the screen. Just curious. Thank you. - BlankB.asm

So it's a ball. Thank you.

Yar's Revenge question of course. I mean is it a sprite, missile, ball, or part of the playfield (or background)? On levels with the the neutral zone it's a big multicolor block. On levels with the zone it's three lines. That just seems kind of weird.

In some post I think I saw Batari say he'd try to implement setting multiple sprites to the same shape with something like: players1-3: %00111100 %01000010 ...and so on end But I guess he's pretty busy as I've haven't seen any updates in about a month or so.

I suppose it's possible.

You'll need to ask someone like Batari, SeaGtGruff, or RevEng about that.

OK, here is something strange I've found, and I don't know why. Sometimes you'll see free memory, sometimes you won't. It seems to depend on the size of your program. Try adding something to the first bank, like a=a. Sometimes adding code makes the output show free memory again.

Could be. Somewhere on this board there's a version 1.1d. It's too much of a pain for me to search, but you can try using my files if you like. In fact, if I remember correctly I think I got a copy of them from jwierer. DPC.zip

For a long time I've wanted to do a 2600 version of Renegade. So I took snapshots of the main character walking and made three sprites. I ran into a couple of problems, so it looks like making an arcade like sprite may not be possible. If somebody like PAC-MAN-RED can improve on these, then awesome. If not, no biggie. These are sprites made up of players 0 and 1. They are cropped on the side because to make it more like the arcade game I'd need three sprites side by side and that would create flicker. But honestly, without a third sprite, I don't know how you could get the character to punch and kick. Oh, and this looks better on the double-high sprite kernels. On the single height DPC+ it looks too short and fat. TestField.bas.bin I did make an 8x38, but it didn't turn out so well, and to punch you'd either have to add another sprite or use a missile for his arm or leg. Oh, almost forgot the spritesRenegade.zip

To answer your first question, yes, there is a pfpixel. As for the code not working, in this post ScumSoft posted a template to use for making DPC+ programs. ; ***************************************************** ; * BANK 1 ; ***************************************************** bank 1 temp1 = temp1 set tv ntsc set kernel DPC+ set smartbranching on set optimization inlinerand set kernel_options collision(playfield,player1) rem DEFINE VARS HERE goto MAIN bank2 ; ***************************************************** ; * BANK 2 ; ***************************************************** bank 2 temp1 = temp1 MAIN rem INSERT GAMEPLAY LOGIC goto MAIN ; ***************************************************** ; * BANK 3 ; ***************************************************** bank 3 temp1 = temp1 ; ***************************************************** ; * BANK 4 ; ***************************************************** bank 4 temp1 = temp1 ; ***************************************************** ; * BANK 5 ; ***************************************************** bank 5 temp1 = temp1 ; ***************************************************** ; * BANK 6 ; ***************************************************** bank 6 rem temp1 = temp1 not required here as this bank is for graphics only rem However I have placed my TitleScreen here with no apparent consequences Also note that in bank one you you only have a little over 100 bytes (I forget and I'm having a hard time searching for the exact amount) so that bank should just or mostly be used for creating variables, defs, and so on. Also, except for using bank 6 for the title screen, you really can't use banks 6 - 8 for anything.

1. Yes, don't RIM out set kernel_options collision(playfield,player1). That's what allows virtual collision detection. 2. While playing around I found that virtual collisions don't seem to work quiet right. For example, about a month ago or so I posted how while testing collisions between sprites 0 and 2 sometimes it would register as a collision between sprites 0 and 2 and other times between 0 and 1. Actually, any collision between sprites 0 and 1-9 register as a collision between sprites 0 and 1. So what I had to do for my DPC+ Mario game I'm working on, is detect a collision between sprites 0 and 1 and then check the locations of sprite 0 and sprites 1-9 to see which sprite that sprite 0 collided with. I haven't checked to see if collisions between sprites 1 - 9 have any glitches though. So maybe what I wrote won't apply. Oh, and I don't know if you're aware, and this may not affect your game, but currently there is no pfread or pfscroll.

If I may ask, just how many bB programs did you write?

A few months, maybe even closer to a year ago, my hard drive died and I had to start from scratch too. Although in this case there was only one bB program that I was working on that got lost. Thank goodness I have a backup drive now.

Thank you.

SeaGTGruff thank you for your advice. Yeah, I did figure out that sometimes WSYNC is needed. And thank you for advice about unrolling loops. It's so simple, yet I didn't think of it. Sometimes it's the little things that slip my notice.

It turned out to be 100% cross boundaries. I throw in a few ALIGN 256 statements and low and behold I have 16 cycles left instead of 11. Well, thanks for your help everybody. I'm pretty sure I've got it figured out now. Well, displaying playfields anyway .

OK, that makes sense, but I'm still coming up short. For example, counting the code that comes after the sta WSYNC I should be able to put in code that takes up to 16 cycles, yet I can only go up to 11 cycles (I tested this using SLEEP).

Sorry to start three threads in such a short time, but once I get help figuring this out, I'll be good for while . OK, for each scanline there are 228 TIA clock cycles or 76 CPU cycles. According to this Website: lda zero page,x is four clock cycles and sta zero page is three clock cycles, so a pair is seven clock cycles. For the basic routine to display a 40x192 image I have 6 pairs (three read/write for the left side of the playfield, and three read/write for the right side of the playfield. That makes 7 * 6 = 42 cycles. I also have two SLEEP 4 statements so that's an extra 8 cycles so 50 cycles altogether. The last part of the code is sta WSYNC inx cpx #192 bne VisibleScreen Now it seems to me that the since the last three opcodes are after WSYNC then they're inbetween scanlines and shouldn't count towards the 76 cycles, right? If so then the sta WSYNC should be 3 cycles, so that's a total of 53 cycles and I should have 76 - 53 = 23 cycles left. If those opcodes do count, then that's an extra 6 or 7 cycles, so at most 53 + 7 = 60 and 76 - 60 = 16 cycles left. Yet, inbetween the last sta PF2 and sta WSYNC if use anything more than 11 cycles the screen goes wonky. So I am I incorrect about the timing, doing bad math, or...? Thank you.

I understand completely. Thank you.

Wonderful, thank you. I did read the manual, but I guess I misunderstood the part that explained that.

Well, I've read through all of the tutorials, and I'm very slowly trying my own code now, but you make an excellent point. Even if I could initialize it, it would get wiped out with the reset code. But I am still curious. The wording for DS says it fills the memory location with a default of 0. That makes it sound like you can intialize a DS variable to something else. So if you can, then how?