81 replies to this topic

[jrok]

Shawn Sr., on Mon Mar 30, 2009 1:19 PM, said:

OK, turns out there is still a pair of bugs. When I tested it on real hardware when playing the game the play area shakes up and down a little like some kinda scanline issue or something. It's really weird cause it doesn't happen at the start screen or when your between levels it only happens when the game is actually being played. This only happens on real hardware also. I can make a video if needed.

The other bug is sometimes when you loose a block, say when you have 2 blocks and you go down to 1 block due to not lining them up right the next row will give you your block back! I was able to make this happen in EMU, pic attached.

Anyone's help is greatly apprricated. Here is the BIN and BAS files.

bug.JPG

stacker16.bas.bin

stacker16.bas

Well, when I run the program in Z26 with the scanline count on... yeah, its definitely an issue with the number of scanlines, jumping between 264 and 262 every few frames. Some routine is taking too long to complete. Maybe you should try debugging in Stella, using the "breakif" command.

[Atarius Maximus]

jrok, on Mon Mar 30, 2009 12:06 PM, said:

Shawn Sr., on Mon Mar 30, 2009 1:19 PM, said:

OK, turns out there is still a pair of bugs. When I tested it on real hardware when playing the game the play area shakes up and down a little like some kinda scanline issue or something. It's really weird cause it doesn't happen at the start screen or when your between levels it only happens when the game is actually being played. This only happens on real hardware also. I can make a video if needed.

The other bug is sometimes when you loose a block, say when you have 2 blocks and you go down to 1 block due to not lining them up right the next row will give you your block back! I was able to make this happen in EMU, pic attached.

Anyone's help is greatly apprricated. Here is the BIN and BAS files.

bug.JPG

stacker16.bas.bin

stacker16.bas

Well, when I run the program in Z26 with the scanline count on... yeah, its definitely an issue with the number of scanlines, jumping between 264 and 262 every few frames. Some routine is taking too long to complete. Maybe you should try debugging in Stella, using the "breakif" command.

Moving a few routines to vblank may help.

Steve

[Shawn Sr.]

Atarius Maximus, on Mon Mar 30, 2009 3:51 PM, said:

Moving a few routines to vblank may help.

Steve

Any idea why the blocks are comming back when they shouldn't Steve?

[Atarius Maximus]

Shawn Sr., on Mon Mar 30, 2009 1:15 PM, said:

Atarius Maximus, on Mon Mar 30, 2009 3:51 PM, said:

Moving a few routines to vblank may help.

Steve

Any idea why the blocks are comming back when they shouldn't Steve?

Well, I haven't actually looked at the code that closely. I'll review it when I get some time and let you know if I can find the problem.

Thanks,

Steve

[jrok]

Atarius Maximus, on Mon Mar 30, 2009 2:51 PM, said:

jrok, on Mon Mar 30, 2009 12:06 PM, said:

Shawn Sr., on Mon Mar 30, 2009 1:19 PM, said:

OK, turns out there is still a pair of bugs. When I tested it on real hardware when playing the game the play area shakes up and down a little like some kinda scanline issue or something. It's really weird cause it doesn't happen at the start screen or when your between levels it only happens when the game is actually being played. This only happens on real hardware also. I can make a video if needed.

The other bug is sometimes when you loose a block, say when you have 2 blocks and you go down to 1 block due to not lining them up right the next row will give you your block back! I was able to make this happen in EMU, pic attached.

Anyone's help is greatly apprricated. Here is the BIN and BAS files.

bug.JPG

stacker16.bas.bin

stacker16.bas

Well, when I run the program in Z26 with the scanline count on... yeah, its definitely an issue with the number of scanlines, jumping between 264 and 262 every few frames. Some routine is taking too long to complete. Maybe you should try debugging in Stella, using the "breakif" command.

Moving a few routines to vblank may help.

Steve

I tried moving some things into the vblank, and at first I was getting a constant 266 scanlines, but whenever I added a block to the stack and had a piece "dropoff", the program added more scanlines until it finally destabilizes and crashes. Its hard to diagnose what's going on without commented code or named variables. Atari2600land: Would it be possible to go back and comment the code, and maybe even DIM all the variables you are using in the main loop?

[atari2600land]

Hopefully this will be enough remarked. if not, just tell me and i'll do some more. I have a question: What is vblank, and how do i move stuff into it (and why would i?)

Attached Files

•  stacker16remarked.bas   9.21K   59 downloads

[Atarius Maximus]

atari2600land, on Mon Mar 30, 2009 2:50 PM, said:

Hopefully this will be enough remarked. if not, just tell me and i'll do some more. I have a question: What is vblank, and how do i move stuff into it (and why would i?)

Here's a good explanation of using vblank in bB: http://www.atariage.com/forums/index.php?s...0&hl=cycles

[Omegamatrix]

atari2600land, on Mon Mar 30, 2009 1:50 PM, said:

Hopefully this will be enough remarked. if not, just tell me and i'll do some more. I have a question: What is vblank, and how do i move stuff into it (and why would i?)

The TV screen is drawn with an electron beam line by line. It goes across the screen, steps down the line and continues. It's doing it so fast your eyes just brain just blends it into one image. The beam draws a line and then is turned off while it jumps back to the left edge of the screen to start another scanline. That period is known as horizontal blanking (Hblank). Line by line is drawn until the beam reaches the bottom right edge of the screen. It then does an overscan period before jumping back to the top of the screen before starting to draw the picture all over again. During this time (Vblank) the electron beam needs to be truned off as it retraces to the top of the screen.

[Shawn Sr.]

Here is stacker in ASM form (thanks to Omegamatrix)

if anyone is a disassembly guru that wouldn't mind looking to help smack these 2 final bugs:

1) the scanline count jumping
2) block(s) coming back after loosing them


Cheers,

Shawn

Edited by Shawn Sr., Sat Apr 4, 2009 10:45 PM.

[Omegamatrix]

I've speed up a couple of the routines, and with some suggestions from Nukey the scanline is now stable at 262 during gameplay. However there are still some bugs in the scanline count going from the game screen to the title screen. There are also bugs in the reset button, and of course the blocks appearing when they shouldn't. Also this version fixes a bug I introduced myself by screwing up Vsync.

I've outlined these in more detail at the top of this latest disassembly. Please have a look there. Also there are many potentials for easy fixes. Lots of rom space (over 1,024 bytes free), lots of unused time in Vblank, etc...


I really have to take a step back from this though if I'm going to survive the next month of school. Someone else will have to carry the torch from here. If not I will look some more at it in about a month.


 Stack16_rev3c_.zip   12.62K   58 downloads

Edited by Omegamatrix, Sun Apr 5, 2009 2:12 PM.

[GroovyBee]

Erm... Dumb question. Is it not easier to modify the batari basic source file and recompile?

[Omegamatrix]

GroovyBee, on Sun Apr 5, 2009 1:15 PM, said:

Erm... Dumb question. Is it not easier to modify the batari basic source file and recompile?

Not a dumb question at all. Yes it would be easier to modify the BB file, and actually it'd be more preferable for ease of use. The key is getting BB to compile in a way that saves cycles and rom. When Shawn asked for help I took a look at the rom to see what it was compiling as, and I found lots areas that could be simplified saving cycles and space. For example:

;old code

;	lda	$DC				  ; 3
;	and	#$F7				 ; 2
;	sta	$DC				  ; 3
;	lda	$DC				  ; 3
;	and	#$EF				 ; 2
;	sta	$DC				  ; 3
;	lda	$DC				  ; 3
;	and	#$DF				 ; 2
;	sta	$DC				  ; 3
;	lda	$DC				  ; 3
;	ora	#$02				 ; 2
;	sta	$DC				  ; 3
;	lda	$DC				  ; 3
;	ora	#$04				 ; 2
;	sta	$DC				  ; 3
;	lda	$DC				  ; 3
;	and	#$7F				 ; 2
;	sta	$DC				  ; 3
;	lda	$DC				  ; 3
;	and	#$BF				 ; 2
;	sta	$DC				  ; 3   wastes many bytes and cycles

;new code:
	LDA   $DC
	AND   #$07
	ORA   #$06
	STA   $DC

Also lot of time the BB code was taking unnecessary branches that slowed down the code (ie the result hadn't changed, but the code kept testing it over and over). Branching directly to where it would end up saved many cycles.

[atari2600land]

I added a whole bunch of drawscreens to the code and ended up having the scanline count steady @ 262. Next up: tackling the blocks.

Attached Files

•  stacker16b2.bas.bin   4K   120 downloads
•  stacker16b2.bas   8.42K   68 downloads

[Omegamatrix]

I just checked the newest build from Atari2600Land is completely stable. There are no issues with the reset or going from the game screen to the title screen. The response is much better also.


Looking forward to seeing the final release. It's going to be a goodie.

[MausGames]

You can save yourself a lot of time and trouble by always adding:

set debug cyclescore

You can put it at the beginning of your program from the start, and REM it when you're not using it. It still seems like you haven't learned quite a few of the basics and are trying to fudge and copy/paste your way through making things, you might consider reading the documentation from top to bottom at least once.

edit: Are you supposed to be able to add 3-4 layers at once? The newest version plays a lot better, but I don't like the sound effects.

Edited by MausGames, Sun Apr 5, 2009 5:02 PM.

[yuppicide]

Here's the problems I see with the latest version:

- Piece moves WAY too slow. If I weren't testing this out for you, I'd have been bored to death and quit already.

- Piece does not get faster each level. It should. That is how the arcade is. So, I understand how level 1 seems all the same speed, then level 2 is faster, etc. I like that. But within the same level it should get a tad faster I think.

- I can press fire really quick and get almost to the top of the game without even trying.

- Let's say I have the following.. 3 blocks, 3 blocks, 3 blocks, 2 blocks, 1 block, but somehow on the next level I've got 2 blocks stacked on top of one. This is not possible. Is this what you talked about blocks coming back? I made it to level 3 just now, had 3 blocks, then eventually 2 blocks, then 1 block, then 2 blocks, then 2 blocks, then went to drop another 2 blocker on top and it made me lose.

Edited by yuppicide, Sun Apr 5, 2009 9:07 PM.

[atari2600land]

yuppicide, on Sun Apr 5, 2009 8:02 PM, said:

- Let's say I have the following.. 3 blocks, 3 blocks, 3 blocks, 2 blocks, 1 block, but somehow on the next level I've got 2 blocks stacked on top of one. This is not possible. Is this what you talked about blocks coming back? I made it to level 3 just now, had 3 blocks, then eventually 2 blocks, then 1 block, then 2 blocks, then 2 blocks, then went to drop another 2 blocker on top and it made me lose.

This is a known problem and is being looked at.
I will increase the speed of the blocks.

[yuppicide]

Eitherway I like your way as well. They're both good. To be more true to the arcade or not is the question. It's what people want. But that's just my opinion.

[yuppicide]

I kept thinking about this for a few days now closer to a week. I totally forgot about this thread that I was trying to tell if a pfpixel was on or off. You can use the PFREAD function to help with your falling pieces! So much easier than I was making it out to be!

http://www.randomterrain.com/atari-2600-me...nds.html#pfread

[yuppicide]

I dug up the thread I had originally started regarding PFREAD if you wanna see.. that could help you makes the pieces fall:

HERE

[Gateway]

Got my game STACKER in the mail today!

Thanks to Shawn, Chris, and LAI games

Label and game look great! However, I think I found a minor "bug" in the game?

I played a few rounds today right after I opened up the package. It seems that every other game, after I lose all my "lives" the game goes back to the title screen. This is expected, but then if I play again and lose another life, it returns back to the title screen and resets the number of lives to full..

Again, this is a minor thing, but wondered if anybody else who has gotten the game already has noticed this?

On the plus side, I noticed this final bin version has vertical "lines" on the grapics of each block and the side rails. A cool feature! I wonder is this done using the missles or another technique used on the playfield blocks?

Overall, a nice game!

[cvga]

I saw a Lighthouse game over the weekend that looks similar to Stacker. It's also by LAI Games. Maybe Shawn has another release up his sleeve?

[Propane13]

I'm kind of curious what the final product looked like (cart and screenshot).
How many were sold? All 50?

-John

[Impaler_26]

I found a few pics of the cart and box:

[Random Terrain]

Impaler_26, on Tue Dec 14, 2010 10:53 AM, said:

I found a few pics of the cart and box . . .

Wow, I didn't know they got it finished and polished enough to put on a cart.