Screen Viewable Area X,Y change possible?

[freshbrood]

Because the viewable screen starts at x0,y0 it means a sprite can smoothly go off screen right or down, but gets all janky and glitchy when going left or up off screen. 

 

Using BBasic (or plugging a bit of assembly patch into it) is it possible to have the starting x,y in the viewscreen changed to, maybe x55, y45 etc.. as the default starting top left viewable corner?

Is there a kernel possible? 

 

This would make programming when sprites get near the boundary edges much easier, and possibly save bloat trying to compensate for the off screen asymmetry. 

 

Or conversely would someone be able to show me some good .bas (or asm pluggable) samples that deal with sprite screen wrap around?

 

Thank you. 

Edited October 30 by freshbrood

[+Karl G]

In short, the coordinates can't really be changed. The X coordinates are hardware coordinates (the object's X positioning), and the Y coordinates are set to what is needed for that particular kernel (the Y coordinates are reversed in the Multisprite kernel, for example).

 

I'm not sure what you are looking for in terms of wrapping, but horizontally when a sprite goes past the right edge, it will start to wrap to the other side of the screen. This is hardware, and not a property of bB or what kernel you are using. If you don't want it to do this, you will need to change the X coordinate from the right edge to the left edge once it gets to this point. Some trial and error may be needed depending on the kernel you are using and the sprite's width, but e.g. using the standard kernel, the player object is fully visible on the left edge with the player object's X value being equal to 1, and it is fully visible on the right edge with the player object's X value is (161 - player_width_in_pixels).

 

As for the Y coordinate, this again depends on the kernel and may take some trial and error to get the numbers right for your sprite, but for the standard kernel, the objects will disappear off the top or bottom edge depending on the Y value of the object without wrapping, so if you desire you can have the object disappear off the top or bottom edges before appearing on the opposite edge. For the standard kernel and the player 0 object, the player is fully visible on the top of the screen when player0y = player0height + 2, and it is fully scrolled off the screen when player0y = 1. For the bottom of the screen, the player is fully visible on the bottom of the screen when player0y = 88, and it is fully scrolled off the screen when player0y = 88 + player0height + 2. These values may need to be tweaked by 1 for the player1 object due to the way the standard kernel implements its two-line kernel.

 

Anyway, I can likely provide a simple example if you give a better idea of specifically what kind of wrapping you are attempting to do.

[freshbrood]

Thank you for your explanation. I think I've addressed it well enough, I was just hoping there might be a better way so I could optimize and squeeze some more code space out. But I think you answered it well and confirmed my worst fear. 

 

On another note, is it possible to read an individual playfield row's color? I am trying to find as many "non variable" variables as possible (e.g. reading an individual of row's color could tell what level the program is on vs. using a stored number variable, etc..) 

 

Is there a hidden list of all the read only options in bbasic somewhere ? Or is RevEngines page as through as it gets?

[freshbrood]

But in short, I was just trying to get the widest arena practical with 2 constantly animating sprites that need to be perfectly symmetrical and behave exactly the same way either on the left or right edges as their sprites multiply by 2x and 4x in width. It's not been easy, but I think aside from a tolerable brief wrong facing sprite it's mostly complete. 

 

[+Karl G]

53 minutes ago, freshbrood said:

Thank you for your explanation. I think I've addressed it well enough, I was just hoping there might be a better way so I could optimize and squeeze some more code space out. But I think you answered it well and confirmed my worst fear. 

 

On another note, is it possible to read an individual playfield row's color? I am trying to find as many "non variable" variables as possible (e.g. reading an individual of row's color could tell what level the program is on vs. using a stored number variable, etc..) 

This is untested, but I think you could get the color of a row from assembly by putting the row number in temp1, and the color of the row would be placed in temp2. E.g.:

 

    temp1 = 0
    
    asm
    ldy temp1
    lda (pfcolortable),y
    sta temp2
end

 

[freshbrood]

Will try this, excellent, thanks. I think with a randomized playfield this could at least free up one variable if reading a particular row. I love tricks like this.