P96 implementation of CyberGraphx ScalePixelArray() function does glitches and should be fixed.

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Please understand that you need to create an account to be able to post, guest posting was disabled as an anti spam measure.

    Hello, I'm a OS3 developper, doing game ports and maybe I'll do a video player.

    I installed the very last version of P96 (from yesterday) and there's always the same issue with CybergraphX API ScalePixelArray() function that scales a 24b or 32b RGB bitmap.

    Actually the scale is very OK horizontally, but just "treat one line per source bitmap line" vertically... (see screenshot)


    I think the issue is in P96 and not the .card drivers files because I installed this version of P96 on my A4000 zz9000, my A1200 pistorm, and my linux FS-UAE, and the 3 implementations have the issue.


    As I tend to use that function very often since 27 years, all my old demos and programs have the issue.

    The old Cybergraphics4 cybervision implementation of ScalePixelArray(), was using bilinear filtering on GPU, and so I was wondering if some blit function in the P96 driver developer API would redirect this one to a hardware blit. The piStorm and zz9000 card drivers are opensource and have other issues, so I'm also looking these codes to see what could be improved.


    I have done a test case archive with sources and executable, that is a simple use case of ScalePixelArray() with a resizable window, if that may help.

    Thank you.

    Wow - that's what I call a bug report. Thanks a lot!


    Since we're in the process of developing a blitter for Indivision ECS V4, would you mind describing how exactly the blitter could support here? So far, we'll cover moving windows (including off-screen) and supporting text placement, but scaling is something that requires some trickery on the Amiga blitter. Maybe I'm using the term wrong, but your example picture does look like simple up-scaling.


    Jens

    Hello, thanks for the answer.

    I was using the word "blitting" in the general way of treating bitmaps with a GPU and not the CPU, not refering to the Amiga blitter . In the P96 driver card api this is also called blitter. So I may reformulate "Can a P96 card driver implement something such a way ScalePixelArray() uses a GPU instead of the CPU. "

    > your example picture does look like simple up-scaling.

    Maybe there is also a misunderstanding: "this simple upscaling" is done by P96 implementation of cybergraphics ScalePixelArray(), not my code. I understand the code that does the scaling is either with the picasso code or each drivers code, but as far as I serarched, it is in P96, isn't it ?

    ... and of course an implementation of ScalePixelArray() could be simple "nearset color" upscaling or bilinear filtering accoring to the software/hardware capabilities... but "not with holes in it". It has "holes". That why I'm reporting something. Really a simple upscaling with no holes would be very very ok.

    Understood - I'm using "blitter" as a general term for 2D-acceleration, and I specifically referred to the Amiga blitter because I know that Amiga democoders like to show off their skills with zoom/rotation effects that are not easy to solve with a normal blitter.


    I'm not a programmer. Like not at all. All I can do is write some test routines, and I have enough coding knowledge to deal with 8-bit machines and MCUs - mainly because I use a logic analyzer as a debug tool. Anything higher-level, and I need help :-) So I'm the wrong person to ask about specific P96 functions. So when I say "we'll look into it and provide a fix as soon as we have one" - it means that I'm not involved in the details :-)


    Jens

    Thor was quick analyzing this. Quote:


    ------

    Well well, this is more complicated than it seems, and it is actually *not* an issue on real hardware, but rather a driver bug (really!). I cannot reproduce with the GBA PII++, actually...


    What happens here is that the function uses the graphics card blitter to replicate one line into multiple lines by setting the source to the line to be replicated, and the destination to the area where the replications are supposed to go. In order to replicate the source, the "source modulo" is set to zero such that the blitter keeps taking the source from the same line, copying it multiple times to the destinaton. Thus, the driver must be aware of the situation that the source modulo is actually zero, indicating that there is no vertical advance in the source line, and that the height is greater than zero, indicating that the source shall be copied multiple times.


    What likely happens is that the driver finds the source modulo to be zero, then says "oops, I cannot support this", but instead of calling the fall-back function in P96 (which would support it) it does nothing, and then creates the artefacts you see leaving the target blank. Actually, you can check by setting the tooltype NOBLITTER=Yes, the program should then work.


    I assume that the makers of these cards just copied the buggy implementation from UAE instead of following the specs, or looking at the reference driver...


    So, net result: Please fix the drivers. There is really no defect here in P96.

    ------


    Jens

    The problem is, VideoCore driver for PiStorm/Emu68 **does not** use blitter yet, which means these functions are handled entirely by P96, the corresponding fields in BoardInfo are not set in the InitCard at all.

    Hello again. I'm at my job just UAE here.

    I tested NOBLITTER=Yes in the tooltypes on the "generic" UAE driver, and bug is still here.


    and I watched the source of the pistrom VC4 driver at

    https://github.com/michalsc/Emu68-tools/blob/master/VideoCore.card/src/main.c

    ... and it says:

    bi->Flags |= BIF_GRANTDIRECTACCESS | BIF_FLICKERFIXER | BIF_HARDWARESPRITE; // | BIF_BLITTER;

    ... and all the BlitXXXX functions just below are let to NULL.


    ... so it looks like to me that the P96 internal P96 copy is used for the rendering on the Videocore driver.


    Thor said:

    > I cannot reproduce with the GBA PII++, actually...

    Yes, but could it be that this implementation doesn't use the callback ?

    Quote from Jens

    Hmmmumble mumble "don't use buggy UAE driver as reference...

    This is all fine but I was not looking at UAE driver at all. And yes, I was looking at reference driver and was reading the documentation. And at the very moment my VideoCore driver is not using acceleration at all.


    Regards,

    Michal (Emu68)

    Quote from victorien

    I tested NOBLITTER=Yes in the tooltypes on the "generic" UAE driver, and bug is still here.

    Thor says that this is impossible - he tried it with that setting, and it works. Make sure you're clicking on "save", make sure it's really the correct icon, reboot.


    Jens

    While firing out eMails to different persons (not just Thor) to have all drivers fixed that are (supposedly) based on the UAE driver, Thor did some more digging and found the reason why it worked at his place and not on your machine(s). He writes (translation by me):


    The problem isn't even the implementation itself, but optimization that went a little over board: This optimization takes a short cut without comparing if the modulo-values are actually identical. This seems to be a very old defect of P96. It did not show here because I was working on a different construction site [that was hiding the bug - added by me].


    Short: Will be fixed in the next version of P96, which will also have a Matrox driver for OpenPCI-compatible PCI daughterboards.


    Jens