ScumSoft

Thanks for all the feedback. 1) The collision routine needs more checks in it to determine proper rebound velocities, right now the values are hard coded and reverse upon impact. The idea was to bounce you into a safe area and give the player half a second of invulnerability to avoid constant collision. However this backfired and ends up sucking the player into the objects and enemies. I think I have a fix for it, I'll get this working completely like it should in the next release. 2) This shouldn't happen, the bat is supposed to fly in from off the screen however I overlooked which player object I used for the water drop and it's the same as the bat. Which is why the bat spawns out of a droplet. I'll make the needed adjustments so the bat enters the screen properly to chase the player. 3) Touching the ground should never cause damage and the player should always bounce. I need to address comment #1 and see if that solves this issue as well. 4) I wanted to stick with a chicken theme, but this is what I ended up with. I think it works better to be an alien hunting gold eggs instead. A chicken flying into a cave seems like an odd story to explain, so I redesigned the player to accommodate the levels but tried to retain a chicken feeling. 5) I might change it back depending on how the new collisions end up working. Staying alive longer was the goal since I added many new dangers, but if more people agree that a 1hit KO would be a better gameplay mechanic, I'll revert right away. 6) Right now it's set to 255 and halves on each hit. If collisions work properly that should be 8 impacts before you respawn. 7) The game isn't overly long if you know exactly what to do, however once I finish the game it should a bit longer to complete 100%. But I will retain the ability for a short play through with the penalty of a lower score There should never be any unavoidable hits, the life meter was added so the player doesn't die when touching the walls. I might make enemies kill you in one hit, if that would be a good balance. But only more testing will tell. A design flaw on my end, I have a short period of non-collision after you collide to allow travel away from the collision. I wanted to avoid clipping through the playfield, however the period is too short and you rebound into the wall on next check. The collision code currently checks which direction you were traveling and reverses upon impact, however it's not behaving as intended and will be #1 on my TODO list. The bat is an entrance guard and keeper of the second egg, in order to collect his egg you must burn it with the torch. This will show it who's boss and he will then sit quietly. However once you've collected a certain amount of eggs, the other bat will start chasing you upon return. The only method is to avoid this one since you cannot fight it. If there are major changes to the gameplay I'll leave the older ones for contrast, but I would recommend playing the final products rather than the prototypes. There isn't enough space left for multiple game mechanics, everything left is being occupied by the pitfall minigame. A nice thought though. The torch should always be at the ship until you use it on the bat...so if it disappears then there is a logic error somewhere I'll need to track down. As for the last question, I have no clue. All pits are marked by curved walls and all ground should be seen clearly. This was an issue in 2.0 where the ground was one playfield off and hidden behind the score. I've elevated the ground above the playfield to adjust for this, but going along with the collision code fixes, hitting the ground should not cause any damage in the next release. Thanks for all the feedback and testing. I'll get the next update out once the pitfall minigame is completed.

Yeah the collision code is something I'm still trying to get working right. As far as moving twice as fast Horizontally, the values are the same for both but this is also something I've noted that will be ironed out in the next release test, as well as a fully working Adventure world like it should be. I was internally testing the game at 10 lives and thought this might be a bit to easy, so I halved it before posting. Would gaining a life per egg you collect be an acceptable compromise? Thanks for helping test as always, I need the feedback to improve certain gameplay mechanics.

Game updated to RC3 beta, all feedback on the changes welcome.

Actually it did, sorry I forgot to get back to you on that one

I'm not sure what might be causing the crashes for you, most everything seem to compile fine on my end. Would you mind attaching a .bas which doesn't compile so I could have a look? The playfield bouncing is caused by older DPCplus.arm versions, get the latest from the package I attached (can't find where Batari originally posted the file right now) it is the same one Batari posted which fixed this problem. I think I've read somewhere here where it was being talked about bB.v11d causing compile issues and that using bB.v11c resolved them for now. So try what I've attached below, bB.v11c + updated DPCplus.arm + custom2.bin update. No Visual Batari included, just replace your existing Atari2600\bB folder with the contents of this one. [edit]by the by, the bBWin7_64bit.zip was upto date when it was posted, however all the new releases are newer than that one and x64 compatible, from bB.v11B onwards I believe. Atari2600_2011_08_08_144525.zip

Windowed mode since I need to flip back and forth between source code and the debugger.

I've got notepad++ all setup just fine, works great with bB. Thanks though.

Thanks for checking into it. It's gotten to the point now where I cannot use this IDE any longer to finish my game, it's become to large although it works almost perfect for smaller games. I'll try and get it setup to compile from Notepad++ for now.

It can be easily reproduced on my end, it starts to occur right after a compile or failed compile. The file I attached will do it every time, although I won't rule out it being caused on my end, just that it only seems to do this on large projects. Try to compile the file then goto bank3 and press enter to start a new line, it will jump the screen up till the cursor is at the bottom of the screen. [edit] Note that what I attached isn't meant to compile, just show off the problem. BugTest.bas

I'm getting this bug now in Visual Batari that whenever I press enter the screen jumps up a page so that the carriage return is at the bottom of the screen. However the bug seems to go away once I switch my font, then it will start again after a while. My game is above 5k lines now, so might it have something to do with this?

Yes, however you have to set their sizes before they appear. missile0height = missile1height = ballheight =

Your issues are syntax problems which cause it to error out on legit lines, tracking them down would be hard.

I don't think you can at the moment, I would just define a blank playfield and do a drawscreen after calling it. This would blank the playfield.

I tested it on my Harmony(NTSC) and the screen drops down a scanline whenever there is to be a new graphic load for the building in the back, and goes back up one scanline when there isn't one being shown. I saw no screen roll that would indicate deviating from 262 scanlines. Are you perhaps taking too much time in Vblank that would offset it by a scanline?

Neat, I'll enjoy looking this over. Thanks! [edit] I took some time and formatted the text, so now it compiles and looks proper in Notepad++ halo2600_2011_08_01_143732.zip

Got your compiler setup properly?

Welcome! have you taken a look at the Stella source?

I don't know what you mean. For example, if it was temp6 = ((player0y-3)/4)-1 instead, you couldn't do what jwierer did. He lucked out because the number I was subtracting turned out to be 4, but at one time, the number was something else. What I meant was that you can always break down something complex and make it simple for the 6502. ((player0y-3)/4)-1 is the same as: rem divide ((a-b)/4) - 1 asm lda temp1 ;Load any value 0-255 in A sec ;Set carry sbc temp2 ;Subtract any value 0-255 lsr ;Divide by 2 lsr ;Divide by 4 clc ;Clear carry sbc #1 ;Subtract 1 from result sta temp3 ;Store result end This is just a straight forward method, I am sure math tricks can be used to do the same in less cycles.

You can always do something simple like that. There are no existing cases where this math cannot be applied on the 2600 asm lda player0y ;[0]+3 lsr ;[3]+2 lsr ;[5]+2 sec ;[7]+2 sbc #2 ;[9]+2 sta temp6 ;[11]+3 14-cycles for routine end You would be trying to optimize this routine, which is already pretty much as optimized as you can get.

Needs the latest stella 3.4.1 to run.

Yeah this might also help others who are having trouble getting everything sorted out and working. Latest bB + visual batari build as of 7/29/2011 One thing that wasn't included in batari's update was the updated DPCplus.arm, which caused the playfield bounce to return. I've added it and everything in this build should be the latest. Try this folder and see if everything works for you guys.

There is only 123 bytes of ROM space left in bank 1 after the update, so move everything critical for startup into bank2 like I mentioned in the PM Philsan, I personally use bank5 for startup code. All the new features might be what is taking up the extra space. I've been making some major changes to EggVenture, and now with these new features I need to go and remove all my amazing collision detection code in favor of this new method it should be much nicer. Thanks for the update! Will let you know what I encounter. [edit] Hmmm, something seems to be off. It's setting to 261 scanlines per frame, and the graphics are majorly skewed. I setup a fresh install of this, so I'm not sure if this is caused by something else or not. [edit2] Okay looks like this is required now before it will work properly. set kernel_options collision(playfield,player1)

Thanks for looking into it for us.

I think it's in this line of code from statement.c else if ((fixpoint1 == && (fixpoint2 == 0)) { // should handle 8.8=number w/o point or int var printf(" LDA #0\n"); printf(" STA "); printfrac(statement[2]); printf(" LDA "); printimmed(statement[4]); printf("%s\n",statement[4]); Comparing the compiled statement, this is the only area I think that defines the LDA STA and another LDA after it. So I think that it thinks we are addressing a Fixed point VAR.

Sorry, my project is in development and I cannot share the source at this time. However I believe I have tracked down what is going on. Here is a code snippet: ; ***************************************************** ; * BANK 5 ; ***************************************************** bank 5 temp1 = temp1 Start_Restart gosub titledrawscreen if proMode then P0lives = 5 else P0lives = 10 if P0_lockinput <> 0 then P0_lockinput = P0_lockinput - 1 if P0_lockinput = 0 && joy0fire then goto Intro_Animate proMode = SWCHB{6} goto Start_Restart Intro_Animate When it errors out it does something like this: .L0680 ; if proMode then P0lives = 5 else P0lives = 10 BIT Bool1 BPL .skipL0680 .condpart222 LDA #5 STA P0lives jmp .skipelse21 .skipL0680 LDA #10 STA P0lives STA C: ;<- It adds a extra store here to C: .skipelse21 However add a space right after the assignment where the parsing error happens and it fixes the problem: Start_Restart gosub titledrawscreen if proMode then P0lives = 5 else P0lives = 10 if P0_lockinput <> 0 then P0_lockinput = P0_lockinput - 1 if P0_lockinput = 0 && joy0fire then goto Intro_Animate proMode = SWCHB{6} goto Start_Restart Thus compiles to: .L0680 ; if proMode then P0lives = 5 else P0lives = 10 BIT Bool1 BPL .skipL0680 .condpart222 LDA #5 STA P0lives jmp .skipelse21 .skipL0680 LDA #10 STA P0lives ;<- No C: after this line, this is how it should be .skipelse21 . ; Hope this has enough info in it, if not I can try to conjure up some more.