Lillapojkenpåön

That sounds useful. The problem was with my harmony encore, no need to test any of the old roms, I will upload something new to test soon.

Thanks, worked after the hex edit! Is there a 50Hz version of the DPC+ kernel btw? So I can try my game on my crappy TV.

Another question.. What can be the cause if your batari Basic DPC+ game works perfectly in stella but stopped working on the harmony and just spin/load the whole time and never starts? I can upload the game if that helps.

Thanks to my trusty tester sramirez2008 I could try to optimize my game and even managed to get rid of the stack usage. Only one minor problem.. It doesn't boot up on my harmony encore anymore, what can cause that? When the yingyang has spun for to long and I turn off the console I think I see the titlescreen come on for a millisecond.

Brand: UNITED Model: UTV 2020X (B7) Guess those PAL versions are still 60Hz then and that I just found the shittiest TV in the world, happy it wasn't the cart or 2600, the TV was only 5$

My new crt TV doesn't seem to support 60Hz, so I put the PAL firmware on my harmony, but why does allmost every DPC game I boot up look crazy? medievel mayhem works but Stay frosty 2, space rocks, star castle arcade and others look crazy even if it says PAL in the filename, If the game starts with an atariage logo for example, there will be a second logo at the top of the screen and the screen slowly slowly stretches both upwards and down, anybody know my problem? Used eeloader_104e_PAL50.bin & hbios_105_PAL50.bin

Oh, I saw that in the saving cycles thread a long time ago and assumed that was how it worked

https://giant.gfycat.com/FixedGrippingGull.webm Looks like when you change room you jump directly to the new room from having allready drawn the former playfield and gone through all that rooms code on the same frame, make shure a drawscreen is called first. And you can make this faster by using then if instead of the first && like this.. if _Room=2 then if player1x>72 && player1x<85 && player1y<55 then _Room=46: player1y=85: _Bit5_Frozen{5}=0: goto DS46 bank5 then if _Room is not 2 it won't check if player1x>72 && player1x<85 && player1y<55 like it does now you could do that for all rooms.. __Roomchange if _Room=2 && player1x>72 && player1x<85 && player1y<55 then _Room=46: player1y=85: _Bit5_Frozen{5}=0: goto DS46 bank5 if _Room=4 && player1x>66 && player1x<86 && player1y<55 && player1y>45 then _Room=42: player1x=117: player1y=85: _Bit5_Frozen{5}=0: goto DS42 bank5 if _Room=5 && player1x>108 && player1x<118 && player1y<65 then _Room=39: player1y=84: _Bit5_Frozen{5}=0: goto DS39 bank4 if _Room=6 && player1x>44 && player1x<56 && player1y<71 then _Room=27: player1x=78: player1y=85: _Bit5_Frozen{5}=0: goto DS27 bank4 if _Room=7 && player1x>114 && player1x<134 && player1y<25 then _Room=37: player1y=18: _Bit5_Frozen{5}=0: goto DS37 bank4 if _Room=8 && player1x>62 && player1x<77 && player1y<62 && player1y>52 then _Room=40: player1x=21: player1y=85: _Bit5_Frozen{5}=0: goto DS40 bank4 if _Room=10 && player1x>80 && player1x<91 && player1y<63 && player1y>55 then _Room=31: player1x=77: player1y=77: _Bit5_Frozen{5}=0: goto DS31 bank4 if _Room=13 && player1x>46 && player1x<66 && player1y<46 && player1y>40 then _Room=37: player1y=84: _Bit5_Frozen{5}=0: goto DS37 bank4 if _Room=15 && player1x>87 && player1x<96 && player1y<77 && player1y>60 then _Room=25: player1x=78: _Bit5_Frozen{5}=0: goto DS25 bank4 if _Room=18 && player1x>99 && player1x<113 && player1y<47 && player1y>40 then _Room=38: player1y=84: _Bit5_Frozen{5}=0: goto DS38 bank4 if _Room=19 && player1x>51 && player1x<64 && player1y<63 then _Room=26: player1x=78: player1y=85: _Bit5_Frozen{5}=0: goto DS26 bank4 if _Room=24 && player1x>58 && player1x<78 && player1y<62 then _Room=32: player1x=46: player1y=85: _Bit5_Frozen{5}=0: goto DS32 bank4 if _Room=32 && player1x>88 && player1x<104 && player1y<31 then _Room=34: player1y=85: _Bit5_Frozen{5}=0: goto DS34 bank4 if _Room=35 && player1x>96 && player1x<106 && player1y<62 then _Room=36: player1y=85: _Bit5_Frozen{5}=0: goto DS36 bank4 if _Room=37 && player1x>124 && player1x<134 && player1y>28 then _Room=7: player1y=34: _Bit5_Frozen{5}=0: goto DS7 bank3 if _Room=41 && player1y<55 then _Room=56: player1x=25: player1y=84: _Bit5_Frozen{5}=0: goto DS56 bank5 if _Room=47 && player1x>32 && player1x<52 && player1y<47 then _Room=48: player1y=75: _Bit5_Frozen{5}=0: goto DS48 bank5 if _Room=51 && player1x>114 && player1x<134 && player1y<47 then _Room=50: player1y=75: _Bit5_Frozen{5}=0: goto DS50 bank5 if _Room=52 && player1x>71 && player1x<90 && player1y<47 then _Room=51: player1y=84: _Bit5_Frozen{5}=0: goto DS51 bank5 if _Room=59 && player1x>84 && player1x<101 && player1y<76 && player1y>59 then _Room=23: player1y=84: _Bit5_Frozen{5}=0: goto DS23 bank4 if _Room=54 && player1x>77 && player1x<90 && player1y<40 then _Room=64: player1y=84: _Bit5_Frozen{5}=0: goto DS64 bank5 if _Room=9 && player1x>49 && player1x<70 && player1y<24 then _Room=66: player1y=84: _Bit5_Frozen{5}=0: goto DS66 bank5 if _Enemy=14 then __Dontrunthat if _Room=36 && player1y<59 then _Ch1_Sound=8: _Ch1_Duration=1: _Ch1_Counter=0: goto __DragonBoss bank1 But would be even better if you just put if player1x>72 && player1x<85 && player1y<55 then _Room=46: player1y=85: _Bit5_Frozen{5}=0: goto DS46 bank5 at the beginning of DS2 and instead of jumping directly to DS46 just keep _Room=46 and que the new room until next frame (after a drawscreen) don't think this works? on _Room goto DS0 DS1 DS2 DS3 DS4 DS5 DS6 DS7 DS8 DS9 DS10 DS11 DS12 DS13 DS14 DS15 DS16 DS17 DS18 DS19 DS20 DS21 DS22 DS23 DS24 DS25 DS26 DS27 DS28 DS29 DS30 DS31 DS32 DS33 DS34 DS35 DS36 DS37 DS38 DS39 DS40 DS41 DS42 DS43 DS44 DS45 DS46 DS47 DS48 DS49 DS50 DS51 DS52 DS53 DS54 DS55 DS56 DS57 DS58 DS59 DS60 DS61 DS62 DS63 DS64 DS65 DS66 DS67 DS68 I would do something like this Mainloop (player movement, weapon logic and code that is used allways) on _Room goto 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 temp1=_Room-18 on temp1 goto 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 temp1=_Room-35 on temp1 goto 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 temp1=_Room-52 on temp1 goto 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 0 goto DS0 1 goto DS1 2 goto DS2 bank4 3 goto DS3 bank5 _draw drawscreen goto Mainloop --------------------------------------------------- and for example DS3 would look something like this DS3 (check if player is at position to change room) if it is, dont jump there just change _Room to that number (que it until next frame) (playfield and everything else related to this room) goto _draw bank3

Cool! If you want to try to continue working on the DPC+ version and have a starfield and stuff you can allways PM me about any problem you run into and I'm shure we can solve it quick

It's doing what it should do I was just wondering how you're using the same variable in your 8.8 type x & y variables dim p1x = player1x.w dim p1y = player1y.w Just w while I have to use both v & w dim _P1_L_R = player1x.v dim _P1_U_D = player1y.w So I'm wondering if I could also use just one variable in some way? Just making shure I'm not currently wasting nine variables if I don't have to?

DPC+ I'm trying to get the players to chase the ball object that you controll left and right ( temp6= _BALL_L_R -4 ) Or I'm doing that allready but I'm trying to save variables if I can? Yup, that's exactly what it's for, but player1-4 only moves upwards and player5-8 only moves down.. if player5x < temp6 then _P5_L_R = _P5_L_R + _robotspeed if player5x > temp6 then _P5_L_R = _P5_L_R - _robotspeed if player5y + l < 66 then _P5_U_D = _P5_U_D + _robotspeed else player5y = 66 So if player1y=94 and l=5, then the next time it will "snap" to 93 instead of move to 89 like this would if player1y > 93 then _P1_U_D=_P1_U_D - _robotspeed

Can you explain how this works? dim p0x = player0x.y dim p0y = player0y.y dim p0lo = y dim m0x = missile0x.x dim m0y = missile0y.x dim m0lo = x dim p1x = player1x.w dim p1y = player1y.w dim p1lo = w dim m1x = missile1x.v dim m1y = missile1y.v dim m1lo = v dim blx = ballx.u dim bly = bally.u dim bllo = u I've tried using the same variable for both x & y like you do with U V W X & Y but it allways results in jerky motion, don't think I understand how it works exactly? Can I do that? I am doing this now.. dim _P1_L_R = player1x.v dim _P1_U_D = player1y.w dim _robotspeed = l.var0 -------------------- if player1x < temp6 then _P1_L_R=_P1_L_R+ _robotspeed if player1x > temp6 then _P1_L_R=_P1_L_R- _robotspeed if player1y - l > 93 then _P1_U_D=_P1_U_D- _robotspeed else player1y = 93 ; makes the player stop at y-pos 93 no mather what speed it has

That seems to be only if you want to make shure your code works with updated versions of the kernel included in bB, I can finish the game with this one. Would someone with a harmony encore be so kind and test these three for me? They also have some more fixes I forgot in the last one. And report back which Nr. works or jitters the least? Rating them from worst to best. That would be awesome!

Yup, That's all I have to go by, but if overscan has 2398 cycles available, then 524 cycles in vblank seems like quite a lot (don't know what it's down to now tho?) BB.1.1d.reveng40? And I also don't know how many cycles the pushing and pulling takes? So I'm just using my sixth sense to know if I'm in the right ballpark. It would still generate a normal display from time to time, does that mean it's not overcycling by an obnoxious amount? When it didn't what happened was that the top of the screen moved down like a pixel and the top wall turned purple.

Question #2 Woops, I was shure it didn't overcycle anymore because stella didn't show a hint of it, and it used to show it allmost exactly like my TV.. Does it not show when vblank takes to long? Because I moved my pushes and pulls there. Tried it on real hardware today for the first time in a year (because of homelessness and all my stuff in storage) and it overcycled, but pretty evenly and jitterless, makes me think it's vblank? I could easily get rid of player9 and use those freed variables to get rid of the pushes and pulls, but I really like that thing and I would like to first make shure I'm using vblank and overscan in a balanced way and see if it's still to much code before I sacrifice something, Is there any emulation that will allow me to see any progress? Or else what can I do If I have no real hardware? Does this look like way to much for vblank first of all? vblank goto _vblank bank3 _vblank if !_NUSIZ1{3} && b{2} then goto __Done2 if missile0y>=180 || pfscorecolor=$BE then goto __Done2 if b{4} then goto __Done2 if player0y>230 then goto __Done3 stack 70 pull temp2 temp3 _tempspeed=0.10+_robotspeed temp7 = _error_accumulator_3 if _delta_x_3 > _delta_y_3 then goto _Skip_Chase1 _error_accumulator_3 = _error_accumulator_3 - _delta_x_3 if temp7 < _error_accumulator_3 then _error_accumulator_3 = _error_accumulator_3 + _delta_y_3 else goto _Skip_Chase2 _Skip_Chase1 if b{1} then _M0_L_R = _M0_L_R + _tempspeed else _M0_L_R = _M0_L_R - _tempspeed if _delta_x_3 < _delta_y_3 then goto _Skip_Chase2 _error_accumulator_3 = _error_accumulator_3 - _delta_y_3 if temp7 < _error_accumulator_3 then _error_accumulator_3 = _error_accumulator_3 + _delta_x_3 else goto __Done _Skip_Chase2 if b{0} then _M0_U_D = _M0_U_D + _tempspeed else _M0_U_D = _M0_U_D - _tempspeed __Done stack 72 push temp2 temp3 __Done2 asm lda _Points_Roll_Up beq No_Points_To_Add dec _Points_Roll_Up sed clc lda _sc3 adc #1 sta _sc3 lda _sc2 adc #0 sta _sc2 lda _sc1 adc #0 sta _sc1 cld No_Points_To_Add: end __Done3 if pfscorecolor=$40 then pfscorecolor=$4E : b{5}=1 if var2=251 then var2=250 if var1=251 then var1=250 return otherbank

Question #1 I'm having some problems understanding how the 160 pixel wide screen and the player1x variabel that can count all the way to 255 works together when getting player1 to enter or exit the side of the screen with masking.. I thought 0 would be for making it enter from the right side (but I'm using 160 now instead) and 153 to enter from the left.. for an eight pixel wide sprite. But for 153 to work right as starting position I have to do this when it gets to 161.. if player1x=161 then player1x=0, to get it to enter smoothly without teleporting a couple pixels somewhere in the middle of the screen, I also tried 248 as starting position to not have to roll the counter manually, and it works sometimes but sometimes teleports crazy. But when it comes back and I want to put it of the screen I have to use if player1x= 248 || player1x= 153 then player1y=200, It's as if it's sometimes 248 and sometimes 153, where does that inconsistancy come from? What numbers should I be using?

New demo. Hold pausebutton (firebutton on joystick2) while starting from the titlescreen to start with 099990 points New enemy Titlescreen Titlescreen goes to gameplay demo after awhile, still very dumb player Temporary titlescreen music (borrowed) Robotmissiles use bresenheim line algorithm to shoot straigt at the railslider Railslider death animation Minor sound and graphics changes Upper robots move behind rails Can get to boss from megablast Can pause anytime Correct hitboxes and hit-detection every frame instead of every other Doesn't overcycle!

I don't think I will feel inspired to make another batari Basic game after my first one, but it was really fun and easy to learn, and a great simple way to learn how to think about coding for the 2600, or coding at all as in my case. I'm really looking forward to try Spice C, and if the forum gets a Spice C section it will probably be a great place to learn C while making an awesome 2600 game.

I have a working PAL one (not the heavy kind), but with a huge hole in the shell, so would like to just replace that. so preferably a broken one or just a shell. But if you have a working one that would be ok to. Guessing that PAL and NTSC have the same shell? I need this desperately before the end of the month for an exhibition so let me know asap if you can help.

Is this faster than the regular way of using the stack? I pull and push values to temp2 and temp3 every frame of the main loop the normal way.. stack 70 pull temp2 temp3 (increase or decrease temp2 and temp3 values) and then stack 72 push temp2 temp3 I tried to pull like this instead asm ; A = location 0-255 LDA #<(STACKbegin+72) sta DF0LOW lda #$0f sta DF0HI lda DF0DATA ; A is the return value STA temp2 end ..and push like this asm ; Y = value LDY temp2 ; A = location 0-255 LDA #<(STACKbegin+72) sta DF0LOW lda #$0f sta DF0HI sty DF0WRITE end That seems to push and pull correct for temp2 but alot of other thing start to glitch, the players will teleport a couple pixels to the right, then back again etc. If this isn't faster I will keep the regular way, but it would still be nice to know what's wrong with it?

Seems like I don't have to? I have no idea how it works without setting the error accumulator and all the other stuff? _Chase.bas _NoChase.bas

I made an example of what I want to do, I have robots in my game that shoots missiles at you, but they can only shoot in six directions now and I would like if they shot in the exact direction you where when they fired the shot, I can do that but the problem is that the robots slowly speed up with 0.05 every one hundred points, and the missile automaticly speeds up to, the missilespeed is the robotspeed + 0.10 So it would just be for speed flexibility, and the smoothness ofcourse, subpixel bresenham movement seems impossible in my brain but I thought I should ask, what do you think? StraightLine.bas

Does this and other line algorithms require the data tables? I would really like to shoot in a straight line like i can do with this, but with smoother 8.8 type X & Y variables, is it possible?

Thanks for this and alot of other stuff I've used, I don't know if this can be helpful but I'll leave it here. simplesound2.bas