P96 3.0.0 (and later) news and support - Page 13

samo79 · 20 November 2021, 23:54

Is overlay support planned someday in the future P96 dev release?
Dont know how many card currently support this under os3, however it will be a pretty interesting feature ... it was even high requested in the os4 version of P96 but unfortunely it never arrived

Thomas Richter · 21 November 2021, 09:17

It's not only planned, it is already in since a long time. On P96, this is called "PIP" "Picture in Picture", though it is actually an overlay. You find source code how to use it on supported cards here:

http://aminet.net/package/dev/src/P96PipDemo

samo79 · 21 November 2021, 11:23

Thats good to know, however do you know if this is fully supported even in ancient releases?
I mean atleast in the old P96 shipped with OS4 ... i ask because according to what the hollywood author always claims, the API availible still not enough for his needs

See this thread:

https://forums.hollywood-mal.com/vie...hp?f=10&t=1155

Thomas Richter · 21 November 2021, 11:48

Quote:

Originally Posted by samo79

Thats good to know, however do you know if this is fully supported even in ancient releases?

The interface exists since release 2.x, but may be not very well debugged. Last changes were made in 3.1.0 where the functionality was debugged for the S3Virge chipset.

Note, however, that overlay support requires chipset support, and the majority of chipsets you find in Amiga graphics cards do not support it. The PicassoIV (Cirrus GD5446) and the CVision3D (S3Virge) do have hardware support.

Quote:

Originally Posted by samo79

I mean atleast in the old P96 shipped with OS4 ... i ask because according to what the hollywood author always claims, the API availible still not enough for his needs.

I have no idea about Os 4, and I don't maintain this version.

trixster · 21 November 2021, 11:56

Any idea if Voodoo 3 or Radeon 9200 provide such support?

Thomas Richter · 21 November 2021, 12:42

Quote:

Originally Posted by trixster

Any idea if Voodoo 3 or Radeon 9200 provide such support?

No, I'm sorry, as I don't maintain their drivers. Hardware-wise it should be possible, I believe. Every halfway decent chip has overlay support. Please contact the vendor of the corresponding driver.

samo79 · 21 November 2021, 13:31

@Thomas Richter

If it was introduced since version 2, then it should be supported... atleast the latest library for OS4 PPC was:

Picasso96API.library 2.359

Since latest system updates P96 was then "unificated" with the graphics.library

@trixster

Not sure about Vodoo3 but Radeon 9200 as a card for sure provide full support for overlay ... for example MorphOS use it via Cybergraphics5 on Pegasos2/R100-R200 cards (Radeon 7000/92x0 series)

Thomas Richter · 21 November 2021, 16:20

Unfortunately, I cannot really tell you much about Os 4. The PIP support is, however, one of the dark corners of P96 and I hope that I provided with the sample programs and the wiki at iComp some information on how to use it. As the original code did not provide much information, it may be that Os 4 changed, removed or broke support for PIP.

Again, please contact your vendor, this is nothing I can check or influence on my side. I'm trying my best to have it supported from the 68K side.

samo79 · 21 November 2021, 17:33

Ok, at the moment I sent a message to the Hollywood author with the example pip code you created ... let's see if starting from this he could be able to implement the overlay on OS4 side... among other things he could at least be able to implement it on OS3 68k using the latest version of P96 :-)

tomcat666 · 03 December 2021, 07:55

There is a problem with 32 bit modes on 3.x P96 drivers. It seems even when the game wants to open a 32 bit full screen mode it cannot and it opens it in a window. This is most evident with the SDL games/utilities. If I use the 2.0 P96 libraries from aminet they open perfectly fine in full screen 32 bit resolution. If I use the 3.x libraries then they will open a tiny window on the workbench. For testing you can take Cave Story here which is free to download.

https://artishq.wordpress.com/2017/08/22/cave-story/

This happens with both the winuae RTG driver and the piStorm RTG driver. On 2.0 the game opens a full screen window with no problems.

Thomas Richter · 03 December 2021, 10:37

There is rather a problem with these games. Try switching your workbench to a 32-bit mode first, then see what happens. The problem here is (potentially) that the 32-bit mode is not marked as comaptible to the workbench mode, i.e. the vga hardware cannot host both in memory at the same time. This happens because the aperture settings of the two modes are incompatible.

The "aperture" is the mapping between the CPU bus and the VGA bus, and a special cross switch may "rearrange" bits such that the little-endian VGA mode on the VGA bus looks like a big-endian VGA mode for the 68K.

Unfortunately, even under P96 2.0, while the software allows to keep incompatible VGA modes on the board, not everything works, and blits between incomaptible VGA modes just create nonsense, at least in some cases.

So, for the time being:
a) report this issue to the author/programmer and ensure that they please create the VGA memory buffer with OpenScreen/OpenScreenTagList, as they should. Allocating a bitmap will create an off-memory bitmap, and not a bitmap on the VGA board. This bimap will be brought onto the VGA memory as soon as it becomes visible, but for that the bitmap needs to be moved, and this confuses such applications which do not "lock" them correctly as they should.
b) as a workaround, place the workbench into a screen mode which has an aperture setting that is compatible to what the application requests. In the simplest case, just the same mode.

I'm working right now on workarounds concerning this, but this is mostly caused by incorrect usage of the API. In particular, the Amiga SDL ports are pretty lousy, and they would require a major makeover to fully conform to the specs. In particular, they get the bitmap address, and, after unlocking the bitmap, assume that it will stay in place. This has never been the case, and was never documented as such.

tomcat666 · 03 December 2021, 15:08

Quote:

Originally Posted by Thomas Richter

There is rather a problem with these games. Try switching your workbench to a 32-bit mode first, then see what happens.

I *do* have the WB in 32bit mode at all times on piStorm and on winuae, so it is compatible to the mode that the game sets...

You must know that both piStorm and winuae do not care about anything like aperture, etc. since they are all basically "virtual" modes that get stretched and converted to the current display mode of the hardware anyway

You can add any resolution in any depth and it will just work.

coldacid · 03 December 2021, 15:15

There are different 32-bit colour modes, though. BGRA and ARGB for example. Byte order matters.

tomcat666 · 03 December 2021, 15:47

Quote:

Originally Posted by coldacid

There are different 32-bit colour modes, though. BGRA and ARGB for example. Byte order matters.

Yes, but it is very hard to select them if they are not present in the preferences ScreenMode selector (they are present in some other programs in the selector like Shapeshifter for instance). piStorm for example supports all possible combinations of ARGB.
Anyway, any of these should not matter really for these newer drivers... there should be a way to ignore the contraints that Thomas mentioned. Both of these drivers can be set to any video mode regardless of what WB is using.

tomcat666 · 03 December 2021, 15:54

Quote:

Originally Posted by Thomas Richter

So, for the time being:
a) report this issue to the author/programmer and ensure that they please create the VGA memory buffer with OpenScreen/OpenScreenTagList, as they should. Allocating a bitmap will create an off-memory bitmap, and not a bitmap on the VGA board. This bimap will be brought onto the VGA memory as soon as it becomes visible, but for that the bitmap needs to be moved, and this confuses such applications which do not "lock" them correctly as they should.

Unfortunetly for a lot of programs it is not possible. Some of these can be recompiled and the SDL library (I think) can also be recompiled. So it might be fixable for SOME programs that use that. Not sure what is the possibility of that happening though.

Would it be possible to add another tool type on the monitor .info file like "Ignore Aperture" which would just ignore it and let ANY mode be set as the program requests regardless of what the restrictions might be (or not be in this case) ?

Best regards,
Tomaz

Thomas Richter · 03 December 2021, 17:36

Quote:

Originally Posted by tomcat666

Anyway, any of these should not matter really for these newer drivers...

But they may for the applications. Again, if the modes are realized by apperture settings, it makes a lot of difference.

Quote:

Originally Posted by tomcat666

there should be a way to ignore the contraints that Thomas mentioned. Both of these drivers can be set to any video mode regardless of what WB is using.

"Ignoring constraints" is not a very helpful idea. Just to let you know again where the problem is: If two bitplanes using different apertures are on the VGA memory at the same time, then the current P96 version does not fully support blitting from one bitmap to another bitmap. Just "ignoring facts" is not a very helpful strategy.

The "right strategy" is to include support code to allow such blits such that two incompatible bitmaps can be held on board. This will be possible again with the 3.2.0 that is currently in the making, but I'm in the middle of testing, and as such, this will take a while to complete. As said, new support code is required in the low level blitting support is required for that.

tomcat666 · 03 December 2021, 17:43

Quote:

Originally Posted by Thomas Richter

But they may for the applications. Again, if the modes are realized by apperture settings, it makes a lot of difference.

"Ignoring constraints" is not a very helpful idea. Just to let you know again where the problem is: If two bitplanes using different apertures are on the VGA memory at the same time, then the current P96 version does not fully support blitting from one bitmap to another bitmap. Just "ignoring facts" is not a very helpful strategy.

The "right strategy" is to include support code to allow such blits such that two incompatible bitmaps can be held on board. This will be possible again with the 3.2.0 that is currently in the making, but I'm in the middle of testing, and as such, this will take a while to complete. As said, new support code is required in the low level blitting support is required for that.

Thank you for explaining. So that it works is purely by coincidence in 2.0 driver ?

Thomas Richter · 03 December 2021, 17:52

More or less. It depends on the type of blitting operations that are triggered by the application. Thus, if an application runs and the workbench continues to blit underneath, "interesting things" could happen.

demolition · 05 December 2021, 18:22

Where can one purchase P96? The icomp wiki says it can be found in the shop, but it is not listed under https://icomp.de/shop-icomp/en/shop.html#filter=*

fryguy · 05 December 2021, 18:34

Quote:

Originally Posted by demolition

Where can one purchase P96? The icomp wiki says it can be found in the shop, but it is not listed under https://icomp.de/shop-icomp/en/shop.html#filter=*

You need to login to see it in the shop.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
P96: What's the right way to do X?	Warty	Coders. General	2	21 December 2020 00:00
Providing 2 fire button support / cd32 joypad support	amigapd	request.Other	0	13 July 2015 17:20
Portaudio support (was: WinUAE support for ASIO drivers)	Amiga1992	support.WinUAE	57	28 March 2009 21:15
Classic WB P96	Anubis	project.ClassicWB	5	08 May 2006 14:30
amiga-news.de: Collected software-news	Paul	News	0	14 November 2004 15:50

20 November 2021, 23:54	#241
samo79 Registered User Join Date: Nov 2018 Location: Italy Posts: 158	Is overlay support planned someday in the future P96 dev release? Dont know how many card currently support this under os3, however it will be a pretty interesting feature ... it was even high requested in the os4 version of P96 but unfortunely it never arrived

21 November 2021, 09:17	#242
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,216	It's not only planned, it is already in since a long time. On P96, this is called "PIP" "Picture in Picture", though it is actually an overlay. You find source code how to use it on supported cards here: http://aminet.net/package/dev/src/P96PipDemo

21 November 2021, 11:23	#243
samo79 Registered User Join Date: Nov 2018 Location: Italy Posts: 158	Thats good to know, however do you know if this is fully supported even in ancient releases? I mean atleast in the old P96 shipped with OS4 ... i ask because according to what the hollywood author always claims, the API availible still not enough for his needs See this thread: https://forums.hollywood-mal.com/vie...hp?f=10&t=1155

21 November 2021, 11:56	#245
trixster Guru Meditating Join Date: Jun 2014 Location: England Posts: 2,337	Any idea if Voodoo 3 or Radeon 9200 provide such support?

21 November 2021, 13:31	#247
samo79 Registered User Join Date: Nov 2018 Location: Italy Posts: 158	@Thomas Richter If it was introduced since version 2, then it should be supported... atleast the latest library for OS4 PPC was: Picasso96API.library 2.359 Since latest system updates P96 was then "unificated" with the graphics.library @trixster Not sure about Vodoo3 but Radeon 9200 as a card for sure provide full support for overlay ... for example MorphOS use it via Cybergraphics5 on Pegasos2/R100-R200 cards (Radeon 7000/92x0 series)

21 November 2021, 16:20	#248
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,216	Unfortunately, I cannot really tell you much about Os 4. The PIP support is, however, one of the dark corners of P96 and I hope that I provided with the sample programs and the wiki at iComp some information on how to use it. As the original code did not provide much information, it may be that Os 4 changed, removed or broke support for PIP. Again, please contact your vendor, this is nothing I can check or influence on my side. I'm trying my best to have it supported from the 68K side.

21 November 2021, 17:33	#249
samo79 Registered User Join Date: Nov 2018 Location: Italy Posts: 158	Ok, at the moment I sent a message to the Hollywood author with the example pip code you created ... let's see if starting from this he could be able to implement the overlay on OS4 side... among other things he could at least be able to implement it on OS3 68k using the latest version of P96 :-)

03 December 2021, 07:55	#250
tomcat666 Retro Freak Join Date: Nov 2001 Location: Slovenia Age: 51 Posts: 1,647	There is a problem with 32 bit modes on 3.x P96 drivers. It seems even when the game wants to open a 32 bit full screen mode it cannot and it opens it in a window. This is most evident with the SDL games/utilities. If I use the 2.0 P96 libraries from aminet they open perfectly fine in full screen 32 bit resolution. If I use the 3.x libraries then they will open a tiny window on the workbench. For testing you can take Cave Story here which is free to download. https://artishq.wordpress.com/2017/08/22/cave-story/ This happens with both the winuae RTG driver and the piStorm RTG driver. On 2.0 the game opens a full screen window with no problems.

03 December 2021, 10:37	#251
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,216	There is rather a problem with these games. Try switching your workbench to a 32-bit mode first, then see what happens. The problem here is (potentially) that the 32-bit mode is not marked as comaptible to the workbench mode, i.e. the vga hardware cannot host both in memory at the same time. This happens because the aperture settings of the two modes are incompatible. The "aperture" is the mapping between the CPU bus and the VGA bus, and a special cross switch may "rearrange" bits such that the little-endian VGA mode on the VGA bus looks like a big-endian VGA mode for the 68K. Unfortunately, even under P96 2.0, while the software allows to keep incompatible VGA modes on the board, not everything works, and blits between incomaptible VGA modes just create nonsense, at least in some cases. So, for the time being: a) report this issue to the author/programmer and ensure that they please create the VGA memory buffer with OpenScreen/OpenScreenTagList, as they should. Allocating a bitmap will create an off-memory bitmap, and not a bitmap on the VGA board. This bimap will be brought onto the VGA memory as soon as it becomes visible, but for that the bitmap needs to be moved, and this confuses such applications which do not "lock" them correctly as they should. b) as a workaround, place the workbench into a screen mode which has an aperture setting that is compatible to what the application requests. In the simplest case, just the same mode. I'm working right now on workarounds concerning this, but this is mostly caused by incorrect usage of the API. In particular, the Amiga SDL ports are pretty lousy, and they would require a major makeover to fully conform to the specs. In particular, they get the bitmap address, and, after unlocking the bitmap, assume that it will stay in place. This has never been the case, and was never documented as such.

03 December 2021, 15:15	#253
coldacid WinUAE 4000/40, V4SA Join Date: Apr 2020 Location: East of Oshawa Posts: 538	There are different 32-bit colour modes, though. BGRA and ARGB for example. Byte order matters.

03 December 2021, 17:52	#258
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,216	More or less. It depends on the type of blitting operations that are triggered by the application. Thus, if an application runs and the workbench continues to blit underneath, "interesting things" could happen.

05 December 2021, 18:22	#259
demolition Unregistered User Join Date: Sep 2012 Location: Copenhagen / DK Age: 43 Posts: 4,190	Where can one purchase P96? The icomp wiki says it can be found in the shop, but it is not listed under https://icomp.de/shop-icomp/en/shop.html#filter=*

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)