INTYBASIC 1.2 problems

[+nanochess]

About new features, what about a way to copy to a from the backtab ram a rectangle of tiles from and to an array in rom or ram?

 

You mean, a block-copy? I thought IntyBASIC had a statement for this... Oscar?

 

Updated: In reading the IntyBASIC manual, it seems that the SCREEN statement does this. You give it a label to your array, an offset, and the block dimensions in columns and rows.

 

I haven't verified, so can someone confirm?

 

-dZ.

Yes, the SCREEN statement does a block copy from ROM to BACKTAB.

 

Currently there isn't a reverse way, but always you can use loops, PEEK and 16-bits array.

[carlsson]

Do the screen cards in ROM still need to be arranged as 20 cards per row even if you're copying a smaller rectangle to screen? I was playing with that last weekend (sorry, no source code available right now) and found that if my ROM cards consisted of e.g. 9 columns and 4 rows, the SCREEN function would print the first 9 columns, then offset the ROM source by 11 or so before printing the next row. I solved this by adding zero byte cards to pad out the source data, and then the function worked as I had thought it would. At least I didn't find any documentation that is how it would work, and perhaps there are situations where you have a full screen of cards defined but only need to copy a smaller window out of it, so the current behavior would be desired.

[+nanochess]

Do the screen cards in ROM still need to be arranged as 20 cards per row even if you're copying a smaller rectangle to screen? I was playing with that last weekend (sorry, no source code available right now) and found that if my ROM cards consisted of e.g. 9 columns and 4 rows, the SCREEN function would print the first 9 columns, then offset the ROM source by 11 or so before printing the next row. I solved this by adding zero byte cards to pad out the source data, and then the function worked as I had thought it would. At least I didn't find any documentation that is how it would work, and perhaps there are situations where you have a full screen of cards defined but only need to copy a smaller window out of it, so the current behavior would be desired.

 

The newest version of IntyBASIC now allows to copy blocks from lesser than 20 columns , the SCREEN statement gets an extra argument where you can give info of your source width.

[carlsson]

Ok, I'm already using version 1.2.3 so in that case I was just missing the argument. I did however check the documentation and tried all options it mentioned. Later on I will try again and post a code sample if I can't get it to work.

[+Tarzilla]

I think what people might be referring to is a different, more specific command than SCREEN, lets call it BLOCKCOPY for now so we don't get confused by more parameters to SCREEN

 

Given the following image that is 3 screens wide (for demonstration, I'd do a single "sprite sheet" in practice.) This image has been sitting open on my computer for weeks, I've just been too busy to ask the question

[Click to Enlarge]

It was designed to work with IntyColor's new features, in this case produces a nice 3 screen wide landscape SCREEN_CARDS data

 

It works great if I copy the whole 8 cols x 12 rows (or SCROLL it as intended), but if I just want the stuff in the yellow box, I have to use 2 FOR loops as I don't believe SCREEN lets me be that specific.

 

How about

BLOCKCOPY SCREEN_CARDS StartCol, StartRow, StartWidth, StartHeight, DestinationRow, DestinationColumn.

BlockWidth=8
BlockHeight=8

AniLoop:
'Frame 1
BLOCKCOPY SCREEN_CARDS 12,4,BlockWidth,BlockHeight,12,4
Gosub Delay

'Frame 2
BLOCKCOPY SCREEN_CARDS 20+12,4,BlockWidth,BlockHeight,12,4
Gosub Delay

'Frame 3
BLOCKCOPY SCREEN_CARDS 40+12,4,BlockWidth,BlockHeight,12,4
Gosub Delay
Goto AniLoop

In this case I'm just grabbing 3 "frames" of a giant boss animation and blasting it to the same location on the visible screen. by changing the 12,4 I could coursely move the boss around (on 8x8 boundaries of course)

 

[+nanochess]

Ok. Then you should use:

 

 

AniLoop:
'Frame 1
SCREEN SCREEN_CARDS,4*60+12,4*20+12,BlockWidth,BlockHeight,60
Gosub Delay

'Frame 2
SCREEN SCREEN_CARDS,4*60+12+20,4*20+12,BlockWidth,BlockHeight,60
Gosub Delay

'Frame 3
SCREEN SCREEN_CARDS,4*60+12+40,4*20+12,BlockWidth,BlockHeight,60
Gosub Delay
Goto AniLoop

[+Tarzilla]

 

Ok. Then you should use:

AniLoop:
'Frame 1
SCREEN SCREEN_CARDS,4*60+12,4*20+12,BlockWidth,BlockHeight,60
Gosub Delay

'Frame 2
SCREEN SCREEN_CARDS,4*60+12+20,4*20+12,BlockWidth,BlockHeight,60
Gosub Delay

'Frame 3
SCREEN SCREEN_CARDS,4*60+12+40,4*20+12,BlockWidth,BlockHeight,60
Gosub Delay
Goto AniLoop

I understand that part, it grabs the 8x8 block from the "virtual" screen 2 and screen 3 and puts it in the exact same spot on the real screen. What I was trying to do is put the 8x8 block at a different spot on the real screen...

 

The concept is to use the SCREEN_CARDS data as a virtual sprite sheet, not just a copy of the screen to be displayed like we do with title screens or scrolling land. If I wanted the 8x8 block of cards that make the virtual boss sprite to move down or around as they animate, say if I wanted the 8x8 virtual Boss Sprite to move down one card each frame, I don't see how the current SCREEN command can do that.

In this example, I'd move the boss down 1 row each frame, then move it over 1 frame if it gets too low.

BlockWidth=8
BlockHeight=8
BossX=12
BossY=4
AniLoop:
'Frame 1
BLOCKCOPY SCREEN_CARDS 12,4,BlockWidth,BlockHeight,BossX,BossY
Gosub Delay
BossY=BossY+1:If BossY>12 then Bossy=1: BossX=BossX-1
'Frame 2
BLOCKCOPY SCREEN_CARDS 20+12,4,BlockWidth,BlockHeight,BossX,BossY
Gosub Delay
BossY=BossY+1:If BossY>12 then Bossy=1: BossX=BossX-1
'Frame 3
BLOCKCOPY SCREEN_CARDS 40+12,4,BlockWidth,BlockHeight,BossX,BossY
Gosub Delay
BossY=BossY+1:If BossY>12 then Bossy=1: BossX=BossX-1

Goto AniLoop

[artrag]

I use screen already. I was thinking to something able to copy a block e.g.2X8 from video ram to an array and vice versa.

 

Screen works fine for rom/ram to video ram, not for the reverse.

Edited September 18, 2015 by artrag

[Kiwi]

I believe he is talking about put_frame function. It is a function in Colecovision BIOS and I believe MSX have similar function. It takes an array of data and paste it on the screen. It also check the border and can slide in image from right and left without messing up the VRAM. I abuse this function to do metatile mapping and etc.

Something like BASIC syntax

put_frame source,x,y,width,height

could work.

[+nanochess]

@Tarzilla, I see you're having a hard time getting a grasp of source/destination offset.

 

I think this macro will make you to get it easier:

' Put everything in a single line 
DEF FN blockcopy(label, source_column, source_row, target_width, target_height,
                 target_column, target_row, source_main_width) =
     SCREEN label,(source_row)*(source_main_width)+(source_column)
                 ,(target_row)*20+(target_column),target_width,target_height,source_main_width

[+Tarzilla]

I believe he is talking about put_frame function. It is a function in Colecovision BIOS and I believe MSX have similar function. It takes an array of data and paste it on the screen. It also check the border and can slide in image from right and left without messing up the VRAM. I abuse this function to do metatile mapping and etc.

 

Something like BASIC syntax

 

put_frame source,x,y,width,height

 

could work.

Looks like it, I haven't got too far into the ColecoVision stuff but I think I might be confusing things by using a whole 20x12 screen cards (or bigger) in my example rather than just defining an standalone array of say 8x8 which is what I'd have to do with put_frame.

 

Mostly it is me trying to leverage the power of IntyColor to not have to manually create a bunch of smaller arrays,

[+Tarzilla]

@Tarzilla, I see you're having a hard time getting a grasp of source/destination offset.

 

I think this macro will make you to get it easier:

 

 

DEF FN blockcopy(label, source_column, source_row, target_width, target_height, target_column, target_row, source_main_width) = SCREEN label,(source_row)*(source_main_width)+(source_column),(target_row)*20+(target_column),target_width,target_height,source_main_width

Well, it is Friday...it has been a long week...though I blame your SCREEN command for having too many parameters

Thanks, my friend, that makes a bunch more sense.

 

I'll try it tonight.

Edited September 18, 2015 by Tarzilla

[artrag]

@Tarzilla, I see you're having a hard time getting a grasp of source/destination offset.

 

I think this macro will make you to get it easier:

' Put everything in a single line 
DEF FN blockcopy(label, source_column, source_row, target_width, target_height,
                 target_column, target_row, source_main_width) =
     SCREEN label,(source_row)*(source_main_width)+(source_column)
                 ,(target_row)*20+(target_column),target_width,target_height,source_main_width

In ordet to put on screen a software sprite you need also background restoration.

This in general needs the capability to get a MxN region on screen and save it in ram.

This is not covered by screen.

 

Add that to build a screen from meta tiles (say 4x2) it is much more intuitive to have something like

 

Put_box label,x,y,nx,ny

 

 

Where label is an array of nx*ny element arranged per lines

Edited September 19, 2015 by artrag

[+nanochess]

In ordet to put on screen a software sprite you need also background restoration.

This in general needs the capability to get a MxN region on screen and save it in ram.

This is not covered by screen.

 

Add that to bould a screen from meta tiles (say 4x2) it is much more intuitive to have something like

 

Put_box label,x,y,nx,ny

 

 

Where label is an array of nx*ny element arranged per lines

 

If you're moving a big element over, getting a region and restoring it would make flicker. (also it would use a lot of scarce Intellivision 16-bits RAM)

 

I would suggest the following method:

 

1. The screen where appears your big sprite is blitted with SCREEN.

2. Your boss is blitted with SCREEN.

3. When moving your boss, left or right: restore only one column, top or down: restore only one line. This would avoid flicker.

4. Go to step 2

[artrag]

 

If you're moving a big element over, getting a region and restoring it would make flicker. (also it would use a lot of scarce Intellivision 16-bits RAM)

 

I would suggest the following method:

 

1. The screen where appears your big sprite is blitted with SCREEN.

2. Your boss is blitted with SCREEN.

3. When moving your boss, left or right: restore only one column, top or down: restore only one line. This would avoid flicker.

4. Go to step 2

 

Ok, but if the background has been build by meta tiles, building the background region can be very clumsy

 

Probably also if you have multiple software sprites that overlap each other and you want to move one element per frame is a case where storing in ram the backgrounds can lead to a more efficient implementation of the logic of the sprite management (e.g. a caterpillar of 3x3 elements overlapping one or two tiles while creeping).

 

Anyway, as you said, in the end I can do a procedure with two FORs and rely on the compiler optimization.

Edited September 18, 2015 by artrag

[+nanochess]

 

Ok, but if the background has been build by meta tiles, building the background region can be very clumsy

 

Probably also if you have multiple software sprites that overlap each other and you want to move one element per frame is a case where storing in ram the backgrounds can lead to a more efficient implementation of the logic of the sprite management (e.g. a caterpillar of 3x3 elements overlapping one or two tiles while creeping).

 

Anyway, as you said, in the end I can do a procedure with two FORs and rely on the compiler optimization.

 

I would suggest an unrolled loop.

 

 

    DIM #save(4 * 4)
    ' Save screen
    #address = $0200+row*20+col
    FOR row = 0 TO 3
    #save(pointer) = PEEK(#address)
    #save(pointer + 1) = PEEK(#address+1)
    #save(pointer + 2) = PEEK(#address+2)
    #save(pointer + 3) = PEEK(#address+3)
    #address = #address + 20
    NEXT row
    ' Restore screen
    SCREEN #save,0,row*20+col,4,4,4

 

Just remember probably you don't have enough 16-bits variables in Intellivision, unless you use the --cc3 or --jlp option.

[artrag]

Oscar, I found that INTYBASIC.EXE may report to dos wrong exit codes after compilation.

 

There are cases where the ERRORLEVEL in the shell is 1 even if the compilation has worked perfectly (with no warning or errors, producing a valid ASM file that in turn, once assembled, gives a valid rom).

The problem is in intybasic, it is not a matter of scripts, even fixing intybuild and intytest, they cannot work properly.

 

I have seen the problem by calling intybasic directly on the command line and printing ERRORLEVEL.

 

It can seem a minor issue (well, it is) but it prevents the use of intybasic in make scripts.

 

I am trying to isolate the code that generate the issue, but the event seems appearing randomly.

Do the exit points in your compiler go all to the same section of code that is in charge of error reporting and of setting the exit code to dos ?

It could simplify the analysis of the issue on your side.

Edited September 19, 2015 by artrag

[+nanochess]

Oscar, I found that INTYBASIC.EXE may report to dos wrong exit codes after compilation.

 

There are cases where the ERRORLEVEL in the shell is 1 even if the compilation has worked perfectly (with no warning or errors, producing a valid ASM file that in turn, once assembled, gives a valid rom).

The problem is in intybasic, it is not a matter of scripts, even fixing intybuild and intytest, they cannot work properly.

 

I have seen the problem by calling intybasic directly on the command line and printing ERRORLEVEL.

 

It can seem a minor issue (well, it is) but it prevents the use of intybasic in make scripts.

 

I am trying to isolate the code that generate the issue, but the event seems appearing randomly.

Do the exit points in your compiler go all to the same section of code that is in charge of error reporting and of setting the exit code to dos ?

It could simplify the analysis of the issue on your side.

 

Thanks for reporting it. I'll check it this afternoon.

[+nanochess]

Oscar, I found that INTYBASIC.EXE may report to dos wrong exit codes after compilation.

 

There are cases where the ERRORLEVEL in the shell is 1 even if the compilation has worked perfectly (with no warning or errors, producing a valid ASM file that in turn, once assembled, gives a valid rom).

The problem is in intybasic, it is not a matter of scripts, even fixing intybuild and intytest, they cannot work properly.

 

I have seen the problem by calling intybasic directly on the command line and printing ERRORLEVEL.

 

It can seem a minor issue (well, it is) but it prevents the use of intybasic in make scripts.

 

I am trying to isolate the code that generate the issue, but the event seems appearing randomly.

Do the exit points in your compiler go all to the same section of code that is in charge of error reporting and of setting the exit code to dos ?

It could simplify the analysis of the issue on your side.

 

Found it, some warnings still were setting error code to 1.

 

Anyway if your program didn't generate warnings, the error code is properly returned as zero.

 

I'm going to update IntyBASIC next month or so.

[artrag]

Ok, thanks. I'll try to report if I find something else on exit codes.

 

I updated dzgorf with sprite multiplexing on bullets.

It looks fine (for me) but collisions are missing and multiplexing on bullets could interfere with COLX

 

BTW, is it possible to lower the volume of the music using the MML commands supported by PLAY ?

 

dzgorf.rom

[+DZ-Jay]

Ok, thanks. I'll try to report if I find something else on exit codes.

 

I updated dzgorf with sprite multiplexing on bullets.

It looks fine (for me) but collisions are missing and multiplexing on bullets could interfere with COLX

 

BTW, is it possible to lower the volume of the music using the MML commands supported by PLAY ?

 

 

Looks good, but honestly, the controls feel weird and counter-intuitive: pushing left moves rotates clockwise, and pushing right moves anti-clockwise.

 

I guess I'll have to get used to that.

 

-dZ.

[Kiwi]

The warp drive is looks interesting and seems to be very fun to play. I'm anxious to see how this game will come out.

 

The controls, I like how Gyruss control in this type of game. When you hold right, the ship goes to the right side of the screen and stop at 3°clock. When pressing left, the ship moves 180° and stops at 9°clock position. Pressing down will move the ship to the 6°clock position. And up will move it to the 12°clock position.

And with multiplexing collusion detection is pretty tricky. This is something I need to experiment completely to understand. Sprite information is written right after interrupt, and the collusion have to be done before the screen is drawn. I got this working with a project I'm working on. I have to make sure that the program doesn't take to long that interrupt occur before wait.

You can go into the epilogue to change the note volume. I recall someone was asking before.


example:

_piano_volume:	PROC
        DECLE 14,13,13,12,12,11,11,10
        DECLE 10,9,9,8,8,7,7,6
        DECLE 6,6,7,7,6,6,5,5
	ENDP

Edited September 20, 2015 by Kiwi

[+DZ-Jay]

The controls, I like how Gyruss control in this type of game. When you hold right, the ship goes to the right side of the screen and stop at 3°clock. When pressing left, the ship moves 180° and stops at 9°clock position. Pressing down will move the ship to the 6°clock position. And up will move it to the 12°clock position.

 

 

That's what I was expecting too. The good thing of doing it that way is that it matches perfectly the way the Intellivision disc is used: you roll your thumb on the disc and make the ship roll around the screen with it.

 

-dZ.

Edited September 20, 2015 by DZ-Jay

[pimpmaul69]

 

That's what I was expecting too. The good thing of doing it that way is that it matches perfectly the way the Intellivision disc is used: you roll your thumb on the disc and make the ship roll around the screen with it.

 

-dZ.

i love gyruss controls and the disc is definitely perfect for this

[intvnut]

It's funny... the clockwise / counter-clockwise control vs. move-toward-disc-position control is a similar problem to the Auto Racing control discussed in this thread.

 

Designing good control schemes is difficult!

 

It's interesting that I prefer the Gyruss controls for Gyruss, and the Real Steering controls for Auto Racing. For this game, I definitely lean to the Gyruss scheme.