Graphics.h Issues / Questions
Graphics.h Issues / Questions
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: While on the Z9001 KRT, it looks good:
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: While on the Z9001 KRT, it looks good:
You do not have the required permissions to view the files attached to this post.
Re: Graphics.h Issues / Questions
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.
There must be some code that attempts to avoid wrapping around after 256 pixels which is causing the discrepancy.
Re: Graphics.h Issues / Questions
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
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
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
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.
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.
Re: Graphics.h Issues / Questions
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....
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
The folks at the Robotron forum have now found the reason.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 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
Anyway, I hope this helps to solve the actual problem.
Re: Graphics.h Issues / Questions
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.
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
Like this? (I'm not really into ASM)
Code: Select all
#asm
di
push iy
ei
#endasm
draw(...);
#asm
di
pop iy
ei
#endasm
Re: Graphics.h Issues / Questions
I believe he meant this:RobertK wrote: ↑Fri Apr 29, 2022 9:34 pmLike this? (I'm not really into ASM)
That didn't help, the pause is still there.Code: Select all
#asm di push iy ei #endasm draw(...); #asm di pop iy ei #endasm
Code: Select all
#asm
di
push iy
#endasm
draw(...);
#asm
pop iy
ei
#endasm
Re: Graphics.h Issues / Questions
Ok, thanks! But that didn't help either, the pause is still there.
Re: Graphics.h Issues / Questions
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
Thanks, the problem is solved now! Now my game runs correctly and smoothly on all KC85/2-5 models.