Messages

Hi
I will try to write a "direct" assembler program and recreate the situation.
Is there anything "special" done to the coordinates? I mean - you must translate from x,y to y,x and from absolut to relative...

Ill report any findings...  .

Malban

PS.
A "macro" from the screenshot, is this the result of zero being active an drawn nonetheless?

Time to experiment :-)

[that]

Hm.

Originally I thought it might be like you said, I DID in fact test inserting a  "call MoveSprite(0,0)" which did NOT help.

I tried your  "call MoveSprite(1,1)" and this does work. Do you check for "0,0" and optimize that call out?
Also: I remember having written about "a delay" (Malban == Chris Salomon :-)) But I don't think that is the "fault".

If only that would be the case than I guess adding some other sort of delay, like:

Code Select Expand

call IntensitySprite(50)
call IntensitySprite(51)
call IntensitySprite(52)
call IntensitySprite(53)

Would also do the trick - which it doesn't (unless some under the hood optimization is going on).
The reasoning behind the delay after the "Reset0Ref" is, that the actual enabling of the ~Zero line in the BIOS function is done without a wait loop.
The "worst" thing that can happen is that you position/draw the next object to early and the zero point was not reached yet.
So only some kind of offsetting would happen - not a complete wrong "picture".

Another thing that can be troublesome after WaitRecal/Reset0Ref is that the VIA_CNTL is set to "wrong" values.
The above functions set the register to $CC
(%110x110x = $cc means ZERO enabled, and BLANK enabled)

With that value no drawing of any kind is possible.

To be able to output anything to vectrex again you must set the Via register to: $CE again.
(%110x111x = $ce means ZERO disabled, and BLANK enabled)

One way to "enable" drawing again is to either to do it "manually"

Code Select Expand

      LDA     #$CE            ;Blank low, zero high?
      STA     <VIA_cntl

Or to do a "Moveto_d" (e.g. with 0,0 as positioning) as this function sets the VIA_cntl register to exactly that value.

But since (see screenshots) something is indeed output to vertex (and the lines have lengths other than zero) - this can't be the fault either.

I am at a loss why the display list reacts as it does, and why a "call MoveSprite(1, 1)" really helps.

Perhaps we can somehow have a peek at the actually generated assembler display list code?

Regards
Malban

Hi,

I have only recently begun fiddling with Vectrex32 and the most simple program I can imagine does not realy behave the way I expect it.

Code Select Expand

' test

textSize = {40, 5}
instructions = {{-50, 90, "DISPLAY VECTORLIST"}}
VectorList={_
        {MoveTo, +$20, -$40}, _
        {DrawTo, +$20, +$00}, _
        {DrawTo, +$00, +$40}, _
        {DrawTo, -$20, +$00}, _
        {DrawTo, -$20, -$40}, _
        {DrawTo, +$20, +$00}, _
        {DrawTo, -$20, +$00}, _
        {DrawTo, +$20, -$40}}

call IntensitySprite(50)

call TextSizeSprite(textSize)
call TextListSprite(instructions)

// NOT OK
call ScaleSprite(25)
vListSprite=LinesSprite(VectorList)

while true
    controls = WaitForFrame(JoystickNone, JoystickNone, JoystickNone)
endwhile

The display I get (see first attachment image)


A very simple solution is to display the vectorlist BEFOR the text:

Code Select Expand

' test

textSize = {40, 5}
instructions = {{-50, 90, "DISPLAY VECTORLIST"}}
VectorList={_
        {MoveTo, +$20, -$40}, _
        {DrawTo, +$20, +$00}, _
        {DrawTo, +$00, +$40}, _
        {DrawTo, -$20, +$00}, _
        {DrawTo, -$20, -$40}, _
        {DrawTo, +$20, +$00}, _
        {DrawTo, -$20, +$00}, _
        {DrawTo, +$20, -$40}}

call IntensitySprite(50)

// OK
call ScaleSprite(25)
vListSprite=LinesSprite(VectorList)

call TextSizeSprite(textSize)
call TextListSprite(instructions)


while true
    controls = WaitForFrame(JoystickNone, JoystickNone, JoystickNone)
endwhile


This works fine... (see second attachment image).

But why is that?
The behaviour is not what I expected and I haven't found any clue about it either.

Malban