P96 3.0.0 (and later) news and support

[Thomas Richter]

Originally Posted by pcotter

Sorry if this question is in the wrong thread but as the Native driver is interconnected with P96 i would like to know if Ftext is necessary still when using Native?

It never was necessary. Text() is replaced and covered by P96 and can render text from and into fast memory. In fact, I would not recommend any patches on top of P96 since it may impact stability. Note that Text() has to support many options such as bolding text, setting it to italics, rendering byte-packed or proportional fonts, and supporting color fonts. Installing a patch on top increase the probability of breaking some of these options.

[Thomas Richter]

Originally Posted by gdonner

It's interesting that a prototype of DKB's Inferno card did/does(?) exist--see link below to an old post from the legendary Skipper Smith talking about his Wildfire--but both the Amiga Hardware Database and The Big Book of Amiga Hardware ambiguously list CyberGraphX drivers (v3 and v4) for it. Obviously those drivers were planned, rather than actually written:

The problem is less the graphics chip for which a driver exists, but to understand how the card is mapped and how to access its registers. This is usually the job of the "card" driver. Thus, it would take some documentation to get support for it.

[pcotter]

Anyone noticed the mouse pointer changing color with MUI Bubble Help pop-ups?
I noticed mainly with IBrowse moving the mouse over the Fastlinks that the mouse sometimes changes color. But any MUI application that supports the Bubble Help can be used to test.
MUI 3.8
PI96 v3.3.3
32bit depth BRGB Workbench
3.9 BB2
---
Edit, deleting and recreating pallete.prefs seems to have fixed the issue.

[Thomas Richter]

That does not seem to be related to P96 at all. MUI will use whatever pens MUI seems fit, P96 will just use for sprite colors whatever is requested. Note one caveat, though: The hardware sprite of most RTG cards only offer two independent colors. The third color then inverts the background color which may look a bit strange. If you want to avoid this problem, use a softsprite.

[spotUP]

Hello Thomas.
When playing music with hippoplayer on my 800x600 256 color p96 wb and doing other things at the same time, telneting or browsing with ibrowse the music slows down when the screen updates. This doesn’t happen with AGA screens.

Do you have any tips for the hippo dev how to avoid this?

[pcotter]

Hi Thomas,
I understand that. But i come from rtg.lib 40.4029 directly to pi96 3.3.3 where with the old lib it was not an issue :-)

[Thomas Richter]

P96 provides its own ObtainBestPen() implementation to make it aware of true and high-color modes, however, I checked its implementation and there is absolutely no difference between the version in 3.3.3 and in 2.4.6. Thus, whatever you observed, it is not due to a change in P96.

[Thomas Richter]

Originally Posted by spoUP

Hello Thomas.
When playing music with hippoplayer on my 800x600 256 color p96 wb and doing other things at the same time, telneting or browsing with ibrowse the music slows down when the screen updates. This doesn’t happen with AGA screens.

Do you have any tips for the hippo dev how to avoid this?

This is so unspecific that I cannot really say much. I do not know how HippoPlayer obtains its time base, but you should understand that the typical graphics.library vertical blank interrupt is not suitable for that if graphics cards operate. Thus, if it attempts to use that, it will not work reliable.

Also, you did not say which graphics card you use, some really block the entire bus while they are busy, in which case NOBLITTER=YES in the monitor icon will avoid the issue, but will slow down the graphics card to a crawl as the CPU has to do everything.

[pcotter]

Originally Posted by Thomas Richter

P96 provides its own ObtainBestPen() implementation to make it aware of true and high-color modes, however, I checked its implementation and there is absolutely no difference between the version in 3.3.3 and in 2.4.6. Thus, whatever you observed, it is not due to a change in P96.

I believe you no questions about it but that does not stop the issue using rtg.lib 43.505 :-)
As I wrote before, redoing pallete.prefs seems to solve it for me.
[ Show youtube player ]

[spotUP]

Thanks for the reply Thomas. I am using an FPGA Replay, the gfxcard is in the FPGA. It works but it’s not super fast. I’ll try to get one of the replay developers to chip in some knowledge here.

[Thomas Richter]

Originally Posted by pcotter

I believe you no questions about it but that does not stop the issue using rtg.lib 43.505 :-)
As I wrote before, redoing pallete.prefs seems to solve it for me.
[ Show youtube player ]

There is really no issue, except in earlier releases in a sense. One of the issues of earlier releases was that if a color change was made to the sprite color registers (17 to 19), then the corresponding hardware sprite or software sprite was not recolored on a direct color screen. What you see here is thus just the natural consequence of some program allocating a pen that corresponds to an Amiga sprite color register. Frankly, this looks more like an issue for the Os team where intuition should allocate (or reserve) the pens belonging to the sprite. P96 only emulates what the Amiga hardware would do - if you write into the sprite hardware registers, the sprite colors change.

Or, to put it in a different way, if a program changed the sprite colors intentionally on earlier revisions, it may have happened that the sprite did not change as it should. P96 cannot know whether a color change is intended as a sprite color change, or is just a consequence of a pen allocation. If the sprite colors are un-allocated, the sprite register color change will change the pen, and the sprite.

[Thomas Richter]

Originally Posted by spoUP

Thanks for the reply Thomas. I am using an FPGA Replay, the gfxcard is in the FPGA. It works but it’s not super fast. I’ll try to get one of the replay developers to chip in some knowledge here.

Then, please check with the authors of the FPGA board. What seems quite likely is that the FGPA power is needed to emulate the hardware blitter, and not sufficient performance is left to emulate the CPU.

[mfilos]

Anyone else has any problems running iGame (latest version) under new P96 3.3.3 installation?
I had issues of running the application doing nothing. Then I put my CF into WinUAE and same thing happened...
Ok, next step was to load a backup of my system under 3.2.2 and previous version of P96 (3.3.2). iGame was running just fine!
I update P96 with latest 3.3.3, reboot and voila... iGame doesn't run
I update P96 with older 3.3.2, reboot and voila... iGame runs again

Tried updating and reverting files from both 3.3.2 and 3.3.3 archives and so far I came to the following findings:
- LIBS:Picasso96API.library doesn't create an issue if using latest
- LIBS:Picasso96/emulation.library doesn't create an issue if using latest
- LIBS:Picasso96/rtg.library... and there we have it. Version 43.399 from P96 3.3.2 archive works just fine. Version 43.505 from P96 3.3.3 archive doesn't work with iGame.

Rings any bell?

Attaching SnoopDOS logs from running iGame under rtg.library from 3.3.2 and 3.3.3.
Well, there are definitely changes in the logs.
Not saying ofc that something's wrong with P96 (might be a problem with iGame alas I contacted the dev of iGame as well to check it out).
I also tested other MUI applications like iBrowse, MCP that didn't create a problem while running.

[pcotter]

Originally Posted by mfilos

Anyone else has any problems running iGame (latest version) under new P96 3.3.3 installation?
I had issues of running the application doing nothing. Then I put my CF into WinUAE and same thing happened...
Ok, next step was to load a backup of my system under 3.2.2 and previous version of P96 (3.3.2). iGame was running just fine!
I update P96 with latest 3.3.3, reboot and voila... iGame doesn't run
I update P96 with older 3.3.2, reboot and voila... iGame runs again

Tried updating and reverting files from both 3.3.2 and 3.3.3 archives and so far I came to the following findings:
- LIBS:Picasso96API.library doesn't create an issue if using latest
- LIBS:Picasso96/emulation.library doesn't create an issue if using latest
- LIBS:Picasso96/rtg.library... and there we have it. Version 43.399 from P96 3.3.2 archive works just fine. Version 43.505 from P96 3.3.3 archive doesn't work with iGame.

Rings any bell?

Attaching SnoopDOS logs from running iGame under rtg.library from 3.3.2 and 3.3.3.
Well, there are definitely changes in the logs.
Not saying ofc that something's wrong with P96 (might be a problem with iGame alas I contacted the dev of iGame as well to check it out).
I also tested other MUI applications like iBrowse, MCP that didn't create a problem while running.

Hi,
What i found with rtg lib 43.505 is that guigfx.library seems not to be working. The game screenshots are not showing.
Setting "No GuiGfx" in IGame preferences makes it use MUI internals i think and the screenshots are displayed but not scaled.
Not sure this is a bug with the new P96 but with guigfx.library itself trying to hide bugs and incompatibilities as stated in the readme?
https://aminet.net/package/dev/misc/guigfxlib

[mfilos]

Thank God after a week I thought I was the only one around with the problem...
Disabling GuiGfx seems to fix the problem for me as well (no scaling but I can live with that and the new rtg.library).
I'll pass this info to the iGame dev as well.

[coldacid]

Yeah GuiGfx is wonky like that, which is why the option to disable it exists in iGame in the first place. It's a known issue, but one that's not likely to be resolved as long as we're using the library to do the image scaling. If someone can point to a MUI widget that can properly scale an image (i.e. maintain aspect ratio) within the bounds of the widget's frame that doesn't have this problem, that works with MUI as old as 3.8, I'm sure we could switch over to it.

[pcotter]

"Thank God after a week I thought I was the only one around with the problem..."
ahahaha! I know the feeling :-)

btw, i forgot to mention that only the screenshots in 8bit depth fails to load. 24bit still works.

[Thomas Richter]

Originally Posted by pcotter

Hi,
What i found with rtg lib 43.505 is that guigfx.library seems not to be working. The game screenshots are not showing.

Any chance of how to reproduce that? I cannot do that here. I just installed the latest (20.1) guigfx.library into LIBS:, then downloaded MCC_guigfx, installed its MUI class into libs:mui/, then downloaded iGame, started it, disabled the "Hide Screenshot" and "No GuiGFX" checkmarks, thus to ensure that it uses both guiGfx and shows the screenshot - and then when I start iGame, I do see a screenshot.


Do you have any minimally "non-working" configuration you can share?

Edit: I also got MUI5.0 now, installed it, and it still works. It just looks different. Note that the guigfx.library that comes from MUI is older (20.0) than the one that comes from aminet (20.1), though I doubt it makes much of a difference.

[mfilos]

Hi Thomas and thanks for looking up for it.

I tested that on a freshly installed OS3.2.2 with P96 3.3.3 with only guigfx.library (20.1) into LIBS and latest iGame installed (2.2.1) although I haven't installed the MCC_guigfx class of MUI as I use version 21.7 that is installed on MUI 5 that I use.
Having all these intsalled with no alteration... iGame doesn't start. If I disable from the prefs file the setting no_guigfx=1 then iGame starts just fine.

[Thomas Richter]

Well, if you do not install the MCC_guigfx class, how is this then supposed work? (-; Get it from Aminet, put it into LIBS:Mui/