Now available IntyBASIC compiler v0.8 ! :)

[catsfolly]

Thanks! It's pretty bare-bones at the moment, but I have some ideas, and when those run dry, I'll be posting updates on the forums for feedback. It seems to have worked well for GOSUB.

 

D'oh! This is exactly the problem! I was overflowing into memory of other arrays. Changing those 4s to 3s has fixed the problem. Thanks! I'm too used to C-syntax of for (i = 0; i < 4; i++)

 

Is there any way to stop sprites from doing that funky stutter when they near x = 0 and instead just gracefully go off-screen?

IF e_type(0) <> 0 THEN temp1 = e_frame(0): SPRITE 4, e_x(0) + $300 - offset_x, e_y(0) + $100, enemy_sprites(temp1) + enemy_colors(temp1) ELSE SPRITE 4, 0, 0, 0

 

Add the part in red above...

[Cybearg]

IF e_type(0) <> 0 THEN temp1 = e_frame(0): SPRITE 4, e_x(0) + $300 - offset_x, e_y(0) + $100, enemy_sprites(temp1) + enemy_colors(temp1) ELSE SPRITE 4, 0, 0, 0

 

Add the part in red above...

Ah, of course. Thank you!

 

I guess when I saw the stutter, I assumed it was that sort of weird effect I would get on the 2600 as well when you let something go too far to one side of the screen and it would freak out.

Edited October 8, 2014 by Cybearg

[Cybearg]

Warning: questions incoming!

 

1. How do I arrange data to be scrolled in for a very large playfield? I mean this both in the sense of how the data should be arranged (having more than 20 16-bit values in a "row" of screen data causes things to get all messed up) and how it should be scrolled in (since the SCREEN function apparently only works with offsets of 0-200, which means a playfield 10 screens long, which seems a bit short. Considering it takes about 45 seconds to scroll through a whole screen (at what I consider to be a pretty slow scroll speed), that would limit levels to being about 7 and a half minutes long. What if I wanted them to be longer, like 20 screens long?

 

2. How do I scroll in the cards smoothly and discreetly? At the moment, you can see the new card being written in on the far right. I'm probably just making a silly mistake, but here's the specific code for it:

scroll_screen: PROCEDURE
	temp1 = (counter AND 15)
	IF temp1 = 0 THEN IF offset_x<=0 THEN offset_d=2:offset_x=7: GOSUB scroll_objects: GOSUB load_tiles ELSE offset_x=offset_x-1: GOSUB scroll_objects

	SCROLL offset_x,0,offset_d
	offset_d = 0
END

...

load_tiles: PROCEDURE
	SCREEN screen0B, level_offset, 19, 1, 12
	level_offset = level_offset + 1
END

3. I'm still having some odd sprite jittering issues at times. If you play the game (attached below), you may notice that enemies occasionally will jerk around, but I have no idea why. Any ideas?

main.bas

scrolling.bin

[+nanochess]

Warning: questions incoming!

 

1. How do I arrange data to be scrolled in for a very large playfield? I mean this both in the sense of how the data should be arranged (having more than 20 16-bit values in a "row" of screen data causes things to get all messed up) and how it should be scrolled in (since the SCREEN function apparently only works with offsets of 0-200, which means a playfield 10 screens long, which seems a bit short. Considering it takes about 45 seconds to scroll through a whole screen (at what I consider to be a pretty slow scroll speed), that would limit levels to being about 7 and a half minutes long. What if I wanted them to be longer, like 20 screens long?

 

2. How do I scroll in the cards smoothly and discreetly? At the moment, you can see the new card being written in on the far right. I'm probably just making a silly mistake, but here's the specific code for it:

scroll_screen: PROCEDURE
	temp1 = (counter AND 15)
	IF temp1 = 0 THEN IF offset_x<=0 THEN offset_d=2:offset_x=7: GOSUB scroll_objects: GOSUB load_tiles ELSE offset_x=offset_x-1: GOSUB scroll_objects

	SCROLL offset_x,0,offset_d
	offset_d = 0
END

...

load_tiles: PROCEDURE
	SCREEN screen0B, level_offset, 19, 1, 12
	level_offset = level_offset + 1
END

3. I'm still having some odd sprite jittering issues at times. If you play the game (attached below), you may notice that enemies occasionally will jerk around, but I have no idea why. Any ideas?

 

For point 1, you could have several screens for reference, now is more easy because of ON GOTO statement in IntyBASIC v0.9

 

You could choose the one you want keeping a counter for advance or something.

 

For point 2, the right way to update the screen is AFTER the WAIT statement, check my sample scroll.bas (scrolling to right).

 

Remember this: SCROLL saves data for update in next frame, when the next video frame comes the interruption routine does the scroll (WAIT), then you can update the column without any trouble.

 

For point 3, you should update the sprites with SPRITE statements after the SCROLL and before the WAIT, so you've the right values already in buffer when the next video frame comes.

 

So a tiny pseudo-example:

' ... calculate here new offsets for scroll ...
' Following statement saves data for doing scroll in next frame
SCROLL offset_x,0,offset_d
' Following statements save data for updating sprites in next frame
SPRITE 0,...
SPRITE 1,...
SPRITE 2,...
SPRITE 3,...
' Waits for frame and does the update to avoid jerky movement.
WAIT
' Time to update the column in screen
IF [need_to_update_column] THEN GOSUB load_tiles

[+nanochess]

BTW, now it's available IntyBASIC v0.9

 

http://atariage.com/forums/topic/230642-intybasic-compiler-v09-recharged-;/

[Cybearg]

For point 1...

Ah, okay. So one must have individual screens for each, then switch which screen data is being read from. I guess it's about the same size-wise--it just requires more logic to tie it all together.

 

Though why does the SCREEN statement allow offsets of 0-199 if it can only really bring in one screen (0 to 19) at a time? What's the use case for those larger indexes?

 

EDIT: Got it, thanks tons, nano! It was indeed just a matter of moving some things around.

 

1. I moved GOSUB update_enemies to AFTER GOSUB scroll_screen. I don't think this necessarily did anything, but it didn't hurt anything. I can't remember why it wasn't there in the first place. :/

 

2. I moved GOSUB set_enemies and GOSUB load_tiles to just after the WAIT, set to fire based on a flag bit toggled when offset_x = 7. Together, these fixed both the enemy weirdness AND tiles popping in with one fell swoop!

scrolling_fixed.bin

Edited October 11, 2014 by Cybearg

[+nanochess]

Ah, okay. So one must have individual screens for each, then switch which screen data is being read from. I guess it's about the same size-wise--it just requires more logic to tie it all together.

 

More or less

 

Though why does the SCREEN statement allow offsets of 0-199 if it can only really bring in one screen (0 to 19) at a time? What's the use case for those larger indexes?

 

It's because you can copy any rectangle, for example, you could have a big enemy in four animation frames in offsets 0, 10, 120 and 130 (size 6x6), and blit it with SCREEN to screen.

 

 

EDIT: Got it, thanks tons, nano! It was indeed just a matter of moving some things around.

 

1. I moved GOSUB update_enemies to AFTER GOSUB scroll_screen. I don't think this necessarily did anything, but it didn't hurt anything. I can't remember why it wasn't there in the first place. :/

 

2. I moved GOSUB set_enemies and GOSUB load_tiles to just after the WAIT, set to fire based on a flag bit toggled when offset_x = 7. Together, these fixed both the enemy weirdness AND tiles popping in with one fell swoop!

I'm glad to be of help