Cybearg

I had it in there due to calculations I was doing that involved dividing by ten. Cutting it out makes no difference. I tested it without that as well. Same bounce. Let me test. EDIT: If I take it out, the playfield is a garbled mess.

And in case you want to blame the gosub for that flicker, that's not it, because this version cuts out the gosubs and just puts that code directly in line, and it still jumps in exactly the same way: rem batari Basic Program rem created 2/27/2013 2:26:04 PM by Visual bB Version 1.0.0.565 rem ***************************************************** bank 1 rem ***************************************************** temp1 = temp1 include div_mul.asm set tv ntsc set kernel DPC+ set smartbranching on set optimization inlinerand set optimization speed set kernel_options collision(playfield,player1) rem DEFINE VARS HERE dim level = a goto levelinit bank2 rem ***************************************************** bank 2 rem ***************************************************** temp1 = temp1 levelinit level0 DF0FRACINC = 32 DF1FRACINC = 32 DF2FRACINC = 32 DF3FRACINC = 32 DF4FRACINC = 64 DF6FRACINC = 64 bkcolors: $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $02 end pfcolors: $84 $94 $76 $66 $56 $48 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 end playfield: XXXX.XXXXXXXXXX..XXXXXXXXXXXXX.X XXX...XXXXXXXXX..XXXXXXX..XXXX.X XXX...XXXXXXXXX..XX...XX..XXX..X XX.....XXX...X...XX...XX..XXX... .X........................X.X... .X........................X..... ..........XXXXX................. ..........X.XXX................. ..........XXXXX...............X. ..........XXXXX...............X. ..........XX.XX...............X. ..........XXXXX..........XXX..X. ..........XXXXX..........X.X..X. ..........X.XXX.........XXXXXXXX ..........XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXX.X....XX.X.XXXXXX.X X.XXXXXX..XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXXXX..XXXXXX.XX.XXXXX XXXXXX.X..XXXXX..XXX.XX.XXXXXXXX XXXXXXXX..X.XXX..XXXXXX.XX...XXX XX.X.XXX..XXXXX..X.X..X.XX...X.X XXXX.XXX..XXXXX..X.XXXX.XX...XXX end scorecolors: $0C $0A $08 $06 $06 $08 $0A $0C end MAIN rem INSERT GAMEPLAY LOGIC maindraw drawscreen goto MAIN rem ***************************************************** bank 3 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 4 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 5 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 6 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 7 rem ***************************************************** rem You may be able to place your TitleScreen here with no consequences There's not much more I can cut out. jumpy.bin

Well, I cut basically everything out except for the background. It still bounces. I'm pretty sure that I shouldn't be over-cycling from just drawing a playfield. rem batari Basic Program rem created 2/27/2013 2:26:04 PM by Visual bB Version 1.0.0.565 rem ***************************************************** bank 1 rem ***************************************************** temp1 = temp1 include div_mul.asm set tv ntsc set kernel DPC+ set smartbranching on set optimization inlinerand set optimization speed set kernel_options collision(playfield,player1) rem DEFINE VARS HERE dim level = a goto levelinit bank2 rem ***************************************************** bank 2 rem ***************************************************** temp1 = temp1 levelinit gosub setlevel MAIN rem INSERT GAMEPLAY LOGIC maindraw gosub godraw if !switchreset then goto MAIN reboot godraw drawscreen : return thisbank setlevel on level goto level0 level0 DF0FRACINC = 32 DF1FRACINC = 32 DF2FRACINC = 32 DF3FRACINC = 32 DF4FRACINC = 64 DF6FRACINC = 64 bkcolors: $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $02 end pfcolors: $84 $94 $76 $66 $56 $48 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 $94 end playfield: XXXX.XXXXXXXXXX..XXXXXXXXXXXXX.X XXX...XXXXXXXXX..XXXXXXX..XXXX.X XXX...XXXXXXXXX..XX...XX..XXX..X XX.....XXX...X...XX...XX..XXX... .X........................X.X... .X........................X..... ..........XXXXX................. ..........X.XXX................. ..........XXXXX...............X. ..........XXXXX...............X. ..........XX.XX...............X. ..........XXXXX..........XXX..X. ..........XXXXX..........X.X..X. ..........X.XXX.........XXXXXXXX ..........XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXX.X....XX.X.XXXXXX.X X.XXXXXX..XXXXX....XXXX.XXXXXXXX XXXXXXXX..XXXXX..XXXXXX.XX.XXXXX XXXXXX.X..XXXXX..XXX.XX.XXXXXXXX XXXXXXXX..X.XXX..XXXXXX.XX...XXX XX.X.XXX..XXXXX..X.X..X.XX...X.X XXXX.XXX..XXXXX..X.XXXX.XX...XXX end scorecolors: $0C $0A $08 $06 $06 $08 $0A $0C end return thisbank rem ***************************************************** bank 3 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 4 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 5 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 6 rem ***************************************************** temp1 = temp1 rem ***************************************************** bank 7 rem ***************************************************** rem You may be able to place your TitleScreen here with no consequences

No, only the first frame has 270 scanlines. It's 262 after that. I'll go back and fiddle to see if I can chop some stuff out to simplify it, though how am I to test whether or not it legitimately goes over scanlines if Stella's scanline readout isn't accurate? Well, I guess the answer to that is obvious--I'll have to test it in the Harmony each time. Drat.

Yeah, I updated the firmware and the problem is the same. Oh... So Stella's scanline count can't be trusted? :/ I'll try chopping things down and see. The reason I suspect the kernel is because, if I remove the DPC+ guts (that is, swap the DPC+ specific stuff for standard kernel stuff, such as for the colors), it works perfectly. The problem only comes when I use the DPC+ kernel. Yeah, the RC 7 or whichever. It was linked to from the top of the first page.

But I've done a test game in DPC+ (still in early stages) and it has solid 262 scanlines except for the first frame, where it gets up to 270, yet the game (on the Harmony, not in Stella) has the playfield continuously bouncing. Since there is no flicker in the scanlines for any other time in the game, it must come from that first 270 scanlines in the very first frame, which does ruin the game because it's annoying and very distracting.

Apparently it's just me, then, because no one else mentioned anything about needing to initialize any timer. Even if it runs fine after that first bit, that first bit would ruin any game made with it, so how can I deal with that initial excess of scanlines? EDIT: The Space Rocks demo does work for me. it's an extremely impressive 2600 version of Asteroids, but I can't say I understood why I would randomly die all the time when nothing visibly hit me.

So where do I get the latest firmware? You linked to where I can get the Harmony Porgrammin Tool, but where do I get the eeloader.bin and hbios.bin files that update the bios? EDIT: Apparently the files are included in the Harmony Programming Tool, and the latest is the 2010 1.0.5 firmware, which I've installed. I see no change, however--Atarius' move example just gives me a garbled explosion on the screen and my own stuff flickers as it did before.

I don't know what the heck is going on, but I can't compile/run your code. I just get a blank screen and Stella flickers the scanlines, thinking it's trying to render PAL (even if I enable your rem'd-out "set tv ntsc" code). I'm thinking that my batariBasic version is broken. Again. But Atarius gave me his which seemed to work great for everything else. ... Sigh. Here we go again trying to track down what magical combination of assorted updates, patches, and random files will give me something that doesn't crap all over. There for-serious needs to be a stickied thread denoting the absolute standard files to be downloaded and used, because I'm sick as hell of trying to find compatible versions for every time I make a new project. (Sorry for the tone, i'm more than a bit frustrated at this whole DPC+ ordeal, if my posts in this thread haven't made that crystal clear)

I got my Harmony Deluxe a couple weeks ago. I thought that it should have come pre-loaded with the latest firmware? Why, then, does the skeleton DPC file that I posted earlier cause overscans on my 2600/Harmony and why do I get immediate overscans in Stella on the first frame as well?

Good to know, though that doesn't remove the core problem. I wasn't actually using the reset switch on the Harmony, anyway--just to test how many scanlines the very first frame had. I made the change you described and it certainly doesn't change anything on the Harmony. It's garbled and nothing viewable comes in either way. I'm pretty shocked that no one noticed that DPC+ doesn't work on real hardware until now. I thought that ByteKnight's game came out on carts.

Great demo! But it also demonstrates what I was talking about. If you add: if switchreset then reboot ... right after the main loop and then check the scanlines immediately after rebooting, it overcycles. I also tried putting it on my Harmony and testing it on a 2600 and the move demo isn't even viewable--it's just a garbled, shaking mess of white and grey. Have there been any confirmed cases of DPC+ working on real 2600 hardware?

When you say that the data is stored in bank 7, you mean that it's automatically placed there in the assembly (which is why it comes at the end of the .asm file), correct? Because I actually define the graphics in bank6 because I can't make gosub calls to bank7 or it doesn't work. But my big question is: why is the game overcycling on the first frame? It happens both in the game I'd worked on (which does have graphics) and on the above bare-bones sample.

Have you tried it with parenthesis for the operations, like ones = number - (10 * times)?

I'm trying out my first DPC+ game and I found a rather large problem: as soon as the game starts, it overcycles, leading to rolling for the entire game. This puzzled me,because I first built the game (or what exists of it so far) in the standard kernel and it worked fine without rolling. Then I went into Stella and tested the game line by line immediately after a reset. Sure enough, the first frame (and only the first) overcycled. So I put a drawscreen immediately after the kernel options, and I was STILL hitting 270 scanlines for the first frame and a solid 262 after that. ...Does this mean that DPC+ is broken for real 2600 hardware? I have attached the absolute minimum required to get the DPC+ to work and, if you go into Stella, hit reset, and watch the scanlines in the console, you'll see that it overcycles. So is DPC+ isn't any good on a real system? DPCbase.bas DPCbase.bas.bin

Is there any way to have sprites drawn at double height in DPC so that they won't have to all be remade with double the lines? Since all pixels are the same width, that double resolution doesn't necessarily add the potential for significantly more detail, so it'd be nice if I could save half of the bytes and just have the pixels rendered square. Also, is there a way to specify a single color for a whole sprite anymore, or are multi-line definitions required? Ditto for score colors.

That works for me now. Thanks so much, Atarius!

I finally tried out the DPC Game demo you posted in the Getting Started with DPC+ thread. I hadn't really had the chance to until now. I saved the .txt file as a .bas file, saved, and compiled, but it doesn't work for me. I just get an error: [3/3/2013 2:56:22 PM] bblint found the following errors in dpcgame.bas warning(): Found 29 commands that use end, and 31 "end" commands. DASM V2.20.07, Macro Assembler ©1988-2003 free ram: 7 $1ae1 bytes of ROM space left in bank 1 --> HMdiv 1a41 bytes of ROM space left in bank 2 bytes of ROM space left in bank 3 bytes of ROM space left in bank 4 bytes of ROM space left in bank 5 bytes of ROM space left in bank 6 $d1a0 bytes of ROM space left in graphics bank free ram: 7 2199 bytes of ROM space left in bank 2 3923 bytes of ROM space left in bank 3 3923 bytes of ROM space left in bank 4 3923 bytes of ROM space left in bank 5 3923 bytes of ROM space left in bank 6 $d1a0 3206 bytes of ROM space left in graphics bank free ram: 7 2199 bytes of ROM space left in bank 2 3923 bytes of ROM space left in bank 3 3923 bytes of ROM space left in bank 4 3923 bytes of ROM space left in bank 5 3923 bytes of ROM space left in bank 6 $d1a0 3206 bytes of ROM space left in graphics bank --- Unresolved Symbol List Fatal assembly error: Source is not resolvable. Errors were encountered during assembly. Same goes for dpcgame2, except I get the additional error: --- Unresolved Symbol List COLUM0 0000 ???? (R ) COLUM1 0000 ???? (R ) Fatal assembly error: Source is not resolvable. Errors were encountered during assembly. Anyone know what's wrong? I'm using bB 1.1d with VisualbB 1.0 (build 565) and DASM 2.20.07 (the 2003 version that comes with bB). NOTE: I also get the error with an absolutely-basic DPC+ game (attached) with basically nothing in it. DPCbase.bas

You can, of course, adjust how strong the oil slick's effect is by increasing/decreasing the numbers added to the player's velocity.

Do you have a special includes file you're using? The bas shows as -287 bytes left to me. I'm guessing you cut something out, though. EDIT: The bin works well for me. I think that you did a great job setting all this up! It feels pretty great to play and I can already see how addicting it could be!

Apparently it doesn't have a per-pixel hit detection on those sprites, hence them still being hit even when blanked out. Personally, when I'm not using a sprite, I always move it to 0,0 to make sure it's out of the way.

It's not just a tip to save you a single byte. It implements the effect that I described, with the oil slick increasing your left/right velocity rather than just jittering the player back and forth. Sorry, I guess I didn't explain that.

How about these? player0: %00011100 %01111110 %01000011 %10000000 end player1: %00011100 %01111110 %01000011 %10000000 end

Woah, we get pfcolor changes every other line AND background changes every line at the same time?!

Please do, Steve! I'd love a repository to help understand how DPC+ really works. I've been too afraid to really bite into DPC+ yet, but if I come up with any examples or anything, I'll post them. Thanks to iesposta for the demo! I'll definitely be checking it out!