Hi MSX users!
During the development of my "experiments in 3D" (E3D) I've found a problem I don't know how to overcome it:

R800 is faster to prepare vdp-commands than VDP to execute them so
cpu is always slow down waiting VDP to become ready to accept the next
command.
I think using V9990 could solve the problem
Apart from this "radical" solution I consider demos like "Ray Tracing Demo":
at the beginning there is a 2 color - full screen - 3D rotating "ANARCHY" text
which makes me think that VDP could make better than what I obtain with my code.
Even at the beginning of the game FIREHAWK there is a very fast - 2 colors intro
showing the name of the game... I always thougth it is done with a very
fast box filling routine.
Do you have any idea to solve/avoid this problem?

Hope to hear from you soon
Thanks in advance for your attention

MicroTech

I can't say I remember either of the demo-parts you're describing, but if I had to do a fast 2color animation I would consider using screen 2 or sprites, whichever fits best... Maybe that's how those demos were done?

I believe that the rotating Anarchy thing is screen 0!

Ofcourse the v9990 is faster, but you probably still can calculate some things faster then the v9990 can excute them. Depending on the size ofcourse.

a way to work around is not to wait to VDP be free...

you can do this:

                         ERASE or SWAP bitmap's screen
                         ERASE buffer    (buffer can be a simply stack).

renderLOOP:    if needs to render more THEN
                            if IS_FREE-SPACE_IN_BUFFER then
                                CALL mathscalcs (3d to 2d screen work and cock to raw)
                                CALL add_result_to_buffer
                           ENDIF
                        ELSE
                            ' ok, no needs to calculate more, but still the vdp drawing the scene.
                             GOTO LOOP2
                        ENDIF
                        ...
                        if VDP_IS_FREE then
                             takes the next thing from the buffer and send it to VDP
                        END IF
                        GOTO renderLOOP

LOOP2:            if VDP_IS_FREE and is_anything_to_render then
                             takes the next thing from the buffer and send it to VDP
                        END IF
                        ...
                        CASE SELECT things_to_do
                        case thing1
                                   like, keyboard, control reading.
                        case thing2
                                   like, sound playing.
                        case thing3
                                   like, enemies IA.
                        case thing255
                                   ok, no more things in this frame. WAIT to the next frame, and restart all.
                        END CASE
                        things_to_do = things_to_do + 1

                        GOTO LOOP2

a way to gain speed, is to push/pop in the buffer, the raw values that will go in the command's registers and NOT just FROM X,Y TO X1, Y1, color.

So, what happens?, surely when you already calculated all the math to render ALL, the vdp is still drawing the half of the screen. But, while the vdp does the rest, you can do other things not related with the rendering, dividing it in small tasks...

At the end, can be that the VDP finishes before or after than all tasks were made. So, continue looping until all tasks were made.

Most full screen effects are made in character modes. For example the "MSX still alive" animation in Unknown Reality (SCREEN 0.80 aka TEXT2).

Effects that are made in bitmap modes use some kind of trick to reduce the amount of pixels written. For example, the "1992" zoom in The Source of Power is made by drawing only the parts that change between two frames (basically, adding some lines on the outer edges and removing them on the inner edges).

Quote:

I believe that the rotating Anarchy thing is screen 0!

!!!

Quote:

Most full screen effects are made in character modes. For example the "MSX still alive" animation in Unknown Reality (SCREEN 0.80 aka TEXT2).

I'm a bit astonished... All those GREAT effects are only "tricks"!
... that's incredible.


@ flyguille:
I think your suggestion is good, thanks.
The only disadvantage is, in my opinion, that you have to poll "here and there in the code"
to check if vdp is ready to get a new command.
V9990 could issue an interrupt when a command finishes.

@ msd:
Are you developing a G9K library?
If so can I ask you support if I have some problems?

MicroTech

Yes MicroTech. I'm developing a G9K library. Ask all you want :-)

Check for the latest version on
www.teambomba.net/gfx9klib.html

Quote:

Quote: I believe that the rotating Anarchy thing is screen 0! !!! Quote: Most full screen effects are made in character modes. For example the "MSX still alive" animation in Unknown Reality (SCREEN 0.80 aka TEXT2). I'm a bit astonished... All those GREAT effects are only "tricks"! ... that's incredible. @ flyguille: I think your suggestion is good, thanks. The only disadvantage is, in my opinion, that you have to poll "here and there in the code" to check if vdp is ready to get a new command. V9990 could issue an interrupt when a command finishes. @ msd: Are you developing a G9K library? If so can I ask you support if I have some problems? MicroTech

Just is one test of 2 o 3 assembler's commands inside a loop or 2...

just remember Savage's words:

If it looks good on MSX, it's a trick!

Quote:

Just is one test of 2 o 3 assembler's commands inside a loop or 2...

Not so easy because polygons require many single horizontal lines... anyway
I think I will use your solution.

Quote:

just remember Savage's words: If it looks good on MSX, it's a trick!

Sad but true...

Anyway to evaluate real code performance I was thinking to use TurboR system timer.
To read its value I think to use the following routine:

STL equ     0E6H
STH equ     0E7H

.comment %
    System Timer

    IN
    OUT HL = system timer value
%
STGet@::

    ld c,STL
    ld a,i
    ex af,af'       ; save interrupt enable flag and disable ints
    jp po,?1
    di
?1:
    ; this must be the quickest possible
    in a,(STH)
    in l,(c)
    in h,(c)

    ex af,af'       ; restore interrupt if previously enabled
    jp po,?2
    ei
?2:

    ; now evaluate results
    ld a,l
    cp h
    jr nz,?3

    ; (STL) not changed
    ex af,af'
    ld h,a
    ret

?3:
    ; presume H = L + 1
    ; check if L = 0FFh, so H = 0
    inc l
    jr nz,?4

    ; L was 0FFh
    ex af,af'
    ld h,a
    inc h
    ld l,0
    ret

?4:
    ; L was not 0FFh
    ld l,h
    ex af,af'
    ld h,a
    ret

Any suggestion?
MicroTech

YES

STL equ     0E6H
STH equ     0E7H

.comment %
    System Timer

    IN
    OUT HL = system timer value
%
STGet@::

    ld c,STL
    ld a,i
    ex af,af'       ; save interrupt enable flag and disable ints
                             ; jp po,?1 REMOVED (if it is disable, and you disables again, nothing happens, and the "JP po," is a waste of time. 
    di
?1:
    ; this must be the quickest possible
    in a,(STH)
    in l,(c)
    in h,(c)

    ex af,af'       ; restore interrupt if previously enabled
    jp po,?2
    ei
?2:

    ; now evaluate results
    ld a,l
    cp h
    jr nz,?3

    ; (STL) not changed
    ex af,af'
    ld h,a
    ret

?3:
    ; presume H = L + 1
    ; check if L = 0FFh, so H = 0
    inc l
    jr nz,?4

    ; L was 0FFh
    ex af,af'
    ld h,a
    inc h
    ld l,0
    ret

?4:
    ; L was not 0FFh
    ld l,h
    ex af,af'
    ld h,a
    ret

[/quote]

ah, it is for v9990 ?

you can to explain a bit it?

Why are you using the high-byte of the timer? Do you really need it?

System timer is TurboR specific: it's a 16bit real time counter which increments approximately every 3,911 microseconds.
It is mapped on I/O ports 0E7h (high 8 bits) and 0E6h (low 8 bits).
Reading both I/O ports is not an atomic operation so to be sure that value read is coherent I read m.s.b. one time (let's call it MSB) and l.s.b. 2 times (let's call them LSB0 and LSB1).

If (LSB0 = LSB1)
{
system counter didn't change so output value is MSB:LSB
}
else if (LSB0 = 0FFh)
{
LSB1 must be 0 and MSB must be incremented by 1: output value is (MSB+1):LSB0
}
else
{
LSB0 <> 0FFh, output value is MSB:LSB1
}


About "jp po":
I simply avoid to disable interrupts if they are already disabled, it can be a waste of time but, for personal experience, I try to avoid useless instructions.

MicroTech

Quote:

Why are you using the high-byte of the timer? Do you really need it?

I need to evaluate how much time is required for drawing a frame: actually I would like to reach a rate of 20 fps so each frame must be drawn in 50ms.
With high-byte of timer I can evaluate up to 255ms.

MicroTech