Page 1 of 1

Graphics.h Issues / Questions

Posted: Mon Feb 21, 2022 10:32 am
by RobertK
I will use this thread for various questions and issues regardings graphics.h. I have made another test program named megatoll.c for my first two issues:

1. On the Philips VG5000 and the Robotron Z9001 (Low-Res, not KRT), the draw() function does not work properly.


2. The definition of drawb() goes like this:

void drawb(int tlx, int tly, int width, int height)

After doing...

xMax=getmaxx();
yMax=getmaxy();

...to query the maximum x,y coordinates, I would like to draw a screen border. Shall I use...

drawb(0,0,xMax,yMax);
or
drawb(0,0,xMax+1,yMax+1);
?

The latter would seem to make more sense because the parameters are named "width" and "height".
But it seems to me that this is implemented inconsistently among the platforms. Currently I'm doing drawb(0,0,xMax,yMax), because on most platforms drawb(0,0,xMax+1,yMax+1) would draw the right and bottom border outside the visible screen area.
However, on many platforms, the remaining lines that are drawn using draw(..,..,xMax,..) or draw(..,..,..,yMax) end outside the screen border.

Here is the bottom right corner of my test program on two platforms.
On the Z1013 KRT it looks like this, like on most other platforms:
Megatoll_Z1013_KRT.jpg
While on the Z9001 KRT, it looks good:
Megatoll_Z9001_KRT.jpg

Re: Graphics.h Issues / Questions

Posted: Mon Feb 21, 2022 11:00 am
by dom
I think this is due to a difference in the narrow/wide graphics implementation (z1013 is narrow, z9001 is wide)

There must be some code that attempts to avoid wrapping around after 256 pixels which is causing the discrepancy.

Re: Graphics.h Issues / Questions

Posted: Tue Feb 22, 2022 9:15 am
by RobertK
While we are in the GDR: please check why highres graphics on the KC85 only works correctly on the /2 and /3 models. On the models /4 and /5, the screen gets filled with vertical bars.

Code: Select all

zcc +kc -lndos -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -o megatoll_KC85_2-5 megatoll.c

Re: Graphics.h Issues / Questions

Posted: Tue Feb 22, 2022 8:17 pm
by dom
Okay, slowly getting through these issues.

Drawing a box: I agree making it the width of the box makes sense. This should now work for both narrow and wide platforms (different issues for each which made life fun)

Z9001, SMC777, FP1100: Lores draw should now work

VG5k: What an odd failure - I'm not seeing the "vertical" perspective lines is that the same as you?

KC: Yet to investigate

Re: Graphics.h Issues / Questions

Posted: Tue Feb 22, 2022 8:54 pm
by RobertK
dom wrote: Tue Feb 22, 2022 8:17 pm VG5k: What an odd failure - I'm not seeing the "vertical" perspective lines is that the same as you?
Exactly, only the horizontal lines appear.

Re: Graphics.h Issues / Questions

Posted: Wed Feb 23, 2022 11:09 am
by RobertK
Thanks for the updates!

drawb() is now consistently using width and height on all platforms, that's fine.

> Z9001, SMC777, FP1100: Lores draw should now work

All functional, except for:

Sony SMC-777: in Modes 8 and 9 no graphics primitives appear.
(Priority low for me, I currently don't need these modes)

A small correction to the Casio FP-1100 wiki page: Mode 1 has 640x200 graphics, not 640x100.

Attached is a modified megatoll.c package with batch files for all mentioned targets, I have removed the larger binaries and only included the smaller ones.

Re: Graphics.h Issues / Questions

Posted: Wed Feb 23, 2022 9:42 pm
by dom
Thanks for the smc777 info - that's now been fixed. VG5k should have been fixed in last nights build.

I've updated the wiki, just to let you know, if you've got an GitHub account you should be able to edit pages yourself.

So back to the DDR then....

Re: Graphics.h Issues / Questions

Posted: Thu Apr 28, 2022 6:27 pm
by RobertK
RobertK wrote: Tue Feb 22, 2022 9:15 am While we are in the GDR: please check why highres graphics on the KC85 only works correctly on the /2 and /3 models. On the models /4 and /5, the screen gets filled with vertical bars.

Code: Select all

zcc +kc -lndos -create-app -pragma-redirect:fputc_cons=fputc_cons_generic -o megatoll_KC85_2-5 megatoll.c
The folks at the Robotron forum have now found the reason.

The draw() function modifies the IX register. This must not be done on the KC85, because this register is used by interrupt routines.

As a workaround, the following push and pop statements can be set around the draw / undraw calls:

Code: Select all

      #asm
      push iy
      #endasm
        draw(...  / undraw(...
      #asm
      pop iy
      #endasm
With that added, Deepspace works on the /4 and /5 models as well. However, it slows down gameplay, there is a noticable pause every time the fuel bar is decreased. I didn't expect these two push and pop commands to be so demanding.

Anyway, I hope this helps to solve the actual problem.

Re: Graphics.h Issues / Questions

Posted: Thu Apr 28, 2022 9:41 pm
by dom
Apologies I've been very slack lately.

That wide draw routine is very naughty actually, it uses both of the index registers which it really shouldn't do. The best solution here will be to switch to the portable implementation.

I think the slowness might be due to an interrupt still occurring whilst the line is being drawn. With ix pointing to something different it may well cause the interrupt routine to do extra work. Try adding di/ei as well and see if that removes the pause.

Re: Graphics.h Issues / Questions

Posted: Fri Apr 29, 2022 9:34 pm
by RobertK
dom wrote: Thu Apr 28, 2022 9:41 pm Try adding di/ei as well and see if that removes the pause.
Like this? (I'm not really into ASM)

Code: Select all

#asm
di
push iy
ei
#endasm		
draw(...);
#asm
di
pop iy
ei
#endasm
That didn't help, the pause is still there.

Re: Graphics.h Issues / Questions

Posted: Fri Apr 29, 2022 9:37 pm
by jorgegv
RobertK wrote: Fri Apr 29, 2022 9:34 pm
dom wrote: Thu Apr 28, 2022 9:41 pm Try adding di/ei as well and see if that removes the pause.
Like this? (I'm not really into ASM)

Code: Select all

#asm
di
push iy
ei
#endasm		
draw(...);
#asm
di
pop iy
ei
#endasm
That didn't help, the pause is still there.
I believe he meant this:

Code: Select all

#asm
di
push iy
#endasm		
draw(...);
#asm
pop iy
ei
#endasm

Re: Graphics.h Issues / Questions

Posted: Fri Apr 29, 2022 9:46 pm
by RobertK
Ok, thanks! But that didn't help either, the pause is still there.

Re: Graphics.h Issues / Questions

Posted: Sat Apr 30, 2022 9:45 pm
by dom
I've switched +kc over to using the portable implementation of draw - with that the workaround you mentioned isn't needed and I'm not seeing a pause either - hopefully you can confirm the same.

Re: Graphics.h Issues / Questions

Posted: Sun May 01, 2022 10:41 am
by RobertK
Thanks, the problem is solved now! Now my game runs correctly and smoothly on all KC85/2-5 models.