Graphics.h Issues / Questions

Bug reports (if you don't/won't have a Github account)
Post Reply
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Graphics.h Issues / Questions

Post 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
You do not have the required permissions to view the files attached to this post.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Graphics.h Issues / Questions

Post 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.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post 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
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Graphics.h Issues / Questions

Post 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
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post 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.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post 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.
You do not have the required permissions to view the files attached to this post.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Graphics.h Issues / Questions

Post 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....
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post 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.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Graphics.h Issues / Questions

Post 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.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post 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.
User avatar
jorgegv
Well known member
Posts: 287
Joined: Wed Nov 18, 2020 5:08 pm

Re: Graphics.h Issues / Questions

Post 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
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post by RobertK »

Ok, thanks! But that didn't help either, the pause is still there.
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Graphics.h Issues / Questions

Post 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.
User avatar
RobertK
Well known member
Posts: 347
Joined: Mon Feb 26, 2018 12:58 pm

Re: Graphics.h Issues / Questions

Post by RobertK »

Thanks, the problem is solved now! Now my game runs correctly and smoothly on all KC85/2-5 models.
Post Reply