OlafS25 Quote:

as I understand it the API is stormmesa library and only lowlevel stuff is warp3d so it not affects compatiblity. The problem more is warp3d on 4.X, is it still compatible to anything on 68k? I think both are different already

StormMesa is the most complete but older OpenGL API. There is MiniGL using a subset of OpenGL and it is possible to use Warp3D directly. Warp3D v5 is mostly compatible with earlier Warp3D. As I recall, the multitexturing was added and 10 new functions.

SetTextureBlend(), SetTextureBlendTags(), SecondaryColorPointer(), FogCoordPointer(), InterleavedArray(), ClearBuffers(), SetParameter(), PinTexture(), SetDrawRegionTexture()

http://thellier.free.fr/Wazp3D.htm

Wazp3D added the missing Warp3D v5 functions and functionality. As I recall, Alain patched some missing functionality in the official Warp3D that was causing crashes too. The CV64/3D Virge driver is not even updated to v4 while some driver library functions are not implemented in hardware that could be. The 68k code is a complete mess with libraries compiled using different compilers and different targets with no documentation or history about it. The Avenger libraries have the big memory trashing bug that will write across memory with an incorrectly calculated stride. The 3dfx/Avenger drivers are compiled for the 68040 likely using GCC which is incompatible with a 6888x and makes a mess do to the missing FINT/FINTRZ instructions which are in hardware on the 6888x and 68060 (the unofficial Warp3D likely works with a 6888x now). The Warp3D libraries really need separate compiles for 68030+6888x, 68040 and 68060, at least using GCC. The Permedia driver had color problems due to floating point rounding issues of color values which one user reported I fixed (I also tracked down and helped fix an unitialized FPU problem causing color problems for VBCC compiles and is now solved with a VBCC update and recompile). The Warp3D.library itself should work on a 68020+6888x but looks like it was compiled by some old compiler like EGCS which was replaced by GCC since the code generation was so bad. I would be embarrassed to claim ownership of Warp3D left in the bug ridden, non-updated, horribly optimized and unsupported state. PPC Warp3D was not much better though. Debugging is so difficult on PPC that bugs were not found and fixed but rather kludges were added as replacements.

https://wiki.amigaos.net/wiki/UserDoc:Warp3D#Configuration Quote:

Application Profiles Over time, the addition of new features and correction of bugs has resulted in a situation where compatibility with older titles has been affected. For example, in version 4 of Warp3D, an update to the Permedia2 driver added a new blending mode. While this was required for MiniGL titles such as Heretic 2, it resulted the famous "engine trail" bug in WipeOut 2097. Although the feature could be turned on and off through the use of an environment variable, there was no way to have a single configuration suitable for all. To address this problem, a feature has been added to selected drivers in Warp3D 5 that allows the driver configuration to be overridden on a per application basis. This works through the use of appropriately named subdirectories within the driver's own environment directory. The general path to these settings is ENV:Warp3D///. Thus, when the application "ShootEmUpFTW" running on a Radeon 9250 allocates the 3D resources, the driver checks to see whether any of the driver's environment settings in the ENV:Warp3D/RadeonR200/ directory have also been set in the ENV:Warp3D/RadeonR200/ShootEmUpFTW/ directory. Any that have will override those in the main ENV:Warp3D/RadeonR200/ directory. This ensures that only those settings requiring customisation need be defined, rather than duplicating all of the settings.

Also, I heard rumors that indirect rendering was removed from Warp3D v5 because of bugs and lack of performance. Indirect rendering works well on the 68k with the queue code optimized and has the major advantage of multitasking better than direct rendering. Responsiveness is improved with code under locks optimized too. Sadly, PPC bug fixes were not worth a 68k compile even though 68k debugging likely could have fixed some of the remaining PPC bugs. Road blocks for the 68k Amiga to encourage "upgrading" to PPC was priority Amiga1 though. A 68k Amiga update may have been interesting a decade ago but surely is not worth it today as the few remaining users spend thousands of dollars to keep their 30-40 year old museum piece 68k Amiga computers running, almost as much as the price of PPC AmigaNOne systems. PiStorms have the same problem of being attached to an aging I/O dongle with as much computing as possible moved from the 68k Amiga to ARM as possible. This is 68k Amiga replacement not development. If you like ARM/Linux then using ARM/Linux without the ancient Amiga dongle is more efficient and cheaper. If you want powerful and affordable 68k Amiga hardware for the masses, then update the silicon!

amigakit Quote:

I have already said in a previous message here that a clean room reimplementation of the API that does not use the Warp3D name is acceptable. Anything else would need dialogue with the IP owners, A-EON Technology Ltd. Hopefully the proposed coder for this project does not have access to closed repositories that contain the Warp3D source code because that would not constitute a clean room implementation. The best scenario would be a free of charge Warp3D driver for all of the Pistorm users out there to enjoy. The Pistorm developers can engage with A-EON to make this a reality if they get in touch. A-EON is not interested in leveraging royalties or monetising this.

AmigaKit speaks for A-Eon clearly, almost like you own it and did not even need to communicate with them. Full disclosure of ownership? So A-Eon claims to own Warp3D, does not really want to development it as actions speak louder than words and realized they can not monetize such an outdated and buggy program but do not want competitors using it? PiSTorm is ok because AmigaKit sells it? Maybe you do not want conflicting libraries with the same name but similar version numbers? AmigaKit/A-Eon is very careful to avoid that right?

Karlos Quote:

It doesn't matter what it's called. You just plop it into Libs and rename it. It's not exactly rocket science.

Renaming does not solve the problem of multiple Warp3D libraries with the same name, different version numbers and different functions and functionality. Did all the professional developers leave the Amiga?

Last edited by matthey on 19-Jan-2025 at 11:05 PM.
Last edited by matthey on 19-Jan-2025 at 10:51 PM.

@matthey

Quote:

Responsiveness is improved with code under locks optimized too. Sadly, PPC bug fixes were not worth compiling even though 68k debugging likely could have fixed some of the PPC bugs.

Warp3d.library become irrelevant when Warp3D Nova was made, backwards compatibility is done using a wrapper that does not have the problems of the older drivers.

It became unnecessary to continue developing on the old API, that was no longer updated, like many things, once it was not economically viable support was stopped for older hardware, this is way CFE was not ben updated, this is why drivers that was promised is never released and so on.. things that are not updated or fixed, can’t be because its close source.

Last edited by NutsAboutAmiga on 19-Jan-2025 at 11:04 PM.
Last edited by NutsAboutAmiga on 19-Jan-2025 at 11:02 PM.
Last edited by NutsAboutAmiga on 19-Jan-2025 at 11:02 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@matthey

Quote:

Renaming does not solve the problem of multiple Warp3D libraries with the same name, different version numbers and different functions and functionality. Did all the professional developers leave the Amiga?

Are you being deliberately silly now? We are talking about a single file here. That you don't already have, that implements the full W3D 4.2 (or 4.3, I forget the last release) interface - or just the full v5, I mean that's also a publicly documented API - that is initially called something like "Emu68PistormCM43D.library" and you rename it "Warp3D.library" once it's in your libs directory. It has a library version number that starts at 4 (or 5), to match the original.

That's it. That's literally all that's involved. There's not even a Warp3DPPC.library being discussed here, just the 68K one. If you've got a bunch of additional Warp3D libraries installed already then that's your own stupid problem*

Christ, on a bike, did all the people with any braincells leave too?

You probably don't even need to come up with a name for the file. Warp3D is a trademark but I'm pretty sure warp3d.library isn't. Doesn't MorphOS already ship with a warp3d.library wrapper for it's own internal 3D?

People really do go the extra mile to make simple things difficult.

-edit-
* The only people that might be in trouble are those with PiStorm/CM4 and some existing PCI graphics card they want to use that already has a driver. I don't know how many people run a configuration like that but last time I worked on a Mediator the bus speed from CPU to VRAM was terrible (relative to the BVisionPPC) so moving away from their existing RTG/3D to a fully "on the Pi" solution is only going to be an upgrade.

Last edited by Karlos on 19-Jan-2025 at 11:24 PM.
Last edited by Karlos on 19-Jan-2025 at 11:19 PM.
Last edited by Karlos on 19-Jan-2025 at 11:18 PM.
Last edited by Karlos on 19-Jan-2025 at 11:03 PM.

_________________
Doing stupid things for fun...

NutsAboutAmiga Quote:

Warp3d.library become irrelevant when Warp3D Nova was made, backwards compatibility is done using a wrapper that does not have the problems of the older drivers.

I can see why the bug riddled and unmaintained Warp3D was abandoned.

NutsAboutAmiga Quote:

It became unnecessary to continue developing on the old API, that was no longer updated, like many things, once it was not economically viable support was stopped for older hardware, this is way CFE was not ben updated, this is why drivers that was promised is never released and so on.. things that are not updated or fixed, can’t be because its close source.

Nothing was ever economically viable for PPC AmigaNOne. The 68k Amiga market is likely thousands of times larger and even though the potential has not been realized due to lack of anywhere near competitive 68k hardware, it was still enough larger than the PPC market for Hyperion to stop PPC AmigaOS development and start 68k AmigaOS development. Proper development and bug testing is very difficult with such a small Amiga market, even with the larger 68k Amiga user base. I have experienced it. The Amiga market is not healthy.

Karlos Quote:

Are you being deliberately silly now? We are talking about a single file here. That you don't already have, that implements the full W3D 4.2 (or 4.3, I forget the last release) interface - or just the full v5, I ,mean that's also a publicly documented API - that is initially called something like "Emu68PistormCM43D.library" and you rename it "Warp3D.library" once it's in your libs directory. It has a library version number that starts at 4 (or 5), to match the original. That's it. That's literally all that's involved. There's not even a Warp3DPPC.library being discussed here, just the 68K one. If you've got a bunch of additional Warp3D libraries installed already then that's your own stupid problem.

An exact clone of a library is fine as long as all functions and features match. As soon as anything new is added and used by another program, you have a development fork. It does not matter if you bump the version number or not. Some programs will ask for something that is not available in the other fork and it gets worse when the other fork adds different features. Amiga version numbers work well only when there is one maintainer.

Karlos Quote:

You probably don't even need to come up with a name for the file. Warp3D is a trademark but I'm pretty sure warp3d.library isn't. Doesn't MorphOS already ship with a warp3d.library wrapper for it's own internal 3D?

Yes, MorphOS has their own Warp3D clone.

@Karlos

Quote:

Thinking about it, just call it Warp2D and be done. It's by far the most accurate name for what it is: lol:

Warp2D already exists, actually. It's a component in AmigaOS Enhancer, so can't use that one. But I take your point.

-- eliyahu

_________________
"Physical reality is consistent with universal laws. When the laws do not operate, there is no reality. All of this is unreal."

@matthey

Quote:

Yes, MorphOS has their own Warp3D clone.

And exactly what is the name of the wrapper library on disk?

Quote:

An exact clone of a library is fine as long as all functions and features match. As soon as anything new is added and used by another program, you have a development fork.

Yes, that unstoppable torrent of new features that are being added to the legacy Warp3D API. Gotcha. All that was added from 4 to 5 was a simplified vertex array model that uses a single pointer (which incidentally can also be mostly built on top of the v4 functionality though I'd recommend doing it separately as it might actually be cleaner) and support for multitexturing in HW.

Warp3D legacy is basically frozen in time and nobody is talking about "going nova" here. It would be better by far to just create a direct GL implementation for the video core later.

BTW your previous anlyses of the library bloat is somewhat off the mark. Do you know why the v4 libraries are so massive compared to the v3 ones? It's not due to the choice of compiler. It was the vertex array functions. The implementation was templated so that near identical code was duplicated across every combination of coordinate vertex format, colour format and texture state, resulting in a huge mass of additional code. This is what I was pointing out early in the thread to avoid. Check out the size of the OS4.1 Permedia 2 3D driver which is based on the 68K one for 3.x I implemented but was never released. The 68K version was a fraction of the size (IIRC still less than 100K) while implementing all the missing vertex drawing operations (lines, etc) and correcting a bunch of bugs. The 4.1 version then adds support for per application tweaks which deals with your problems caused by applications having dependencies on bugs of prior versions.

It's all solvable.

Last edited by Karlos on 19-Jan-2025 at 11:56 PM.
Last edited by Karlos on 19-Jan-2025 at 11:55 PM.

_________________
Doing stupid things for fun...

@eliyahu

The name is irrelevant but it's fun to think up a few as a distraction from the noise.

_________________
Doing stupid things for fun...

@amigakit

AmigaKit (or should I call you A-EonKit) for all the good you have done for the community you undermine it all with crap like this. You behave like multinational conglomerates do that buy up IP and shelve it to hoard it all to yourself and the community it would benefit gets nothing. You buy Warp3d.library to peddle your Enhancer crap and keep it locked up and do nothing for the Classic amiga market hoping you would force us to buy your hyper-expensive next-gen hardware. Then you want to peddle your next-gen 1200 thing and the A600gs with your AROS-based AmigaOS clone so why would you be incentivised to progress Warp3D.library for us already owning Mediators praying our Voodoo cards don't die? I mean you never progressed the community with the Radeon 9200 or Voodoo 4 driver for Warp3D. Library for classics it was left up to Elbox to come up with that which never happened. Then comes along this project and you bring the hammer down with some passive-aggressive ("no one talked to A-Eon about this") Sure you walked it back by saying you.... sorry A-Eon fully support a free warp3d.library for PiStorm, but why don't A-Eon just be a part of the community and give it your endorsement and YOU reach out to them and support it instead of monopolising the moment. We are all getting too old for this crap and so are our computers, the faster we get this the better our Amiga's will be.

_________________

@eliyahu

Quote:

eliyahu wrote: @Karlos Quote: Thinking about it, just call it Warp2D and be done. It's by far the most accurate name for what it is: lol: Warp2D already exists, actually. It's a component in AmigaOS Enhancer, so can't use that one. But I take your point. -- eliyahu

A-EON System 54 Enhancer doesn't have "the name" AmigaOS license.

There is no such thing as "AmigaOS Enhancer" when A-EON is not Amiga Corporation's licensee.

Last edited by Hammer on 20-Jan-2025 at 06:08 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Mediator would not be an issue, at least not currently. PCI Graphics Cards and PiStorm are at least currently not possible to work together (you are right about "principially" of course).

@MagicSN

Yeah, I'd not heard about such a configuration but you never know. People love to hack :D

_________________
Doing stupid things for fun...

@amigakit

I am willing to do a discussion on you on this. Actually a free of charge Warp3D Driver if you offer the needed conditions for it would be acceptable though it is not the solution I had in mind.

I suggest the discussion not to be done on here, but in a private phone call.

The needed conditions for making it an actual Warp3D Driver would be that you put the Driver NDK under MIT OpenSource licence (which I think is actually a good idea). The implementation of Videocore VI Support requires usage of the Broadcom Headers and an QPU V3D Assembly translator which are under MIT OpenSource Licence. Using them in a Closed Source Scenario is not possible at best my knowledge.

Also note that several people who pledged support made the requirement that it has to be OpenSource (but it has to be OpenSource anyways due to the BroadCom/Assembly-translator issue).

I would love it if you put Warp3D into OpenSource! (I assume though you do not want to).

Everything else should be discussed privately.

Have you thought what Hans-Joerg Frieden, Thomas Frieden and Sam Jordan would have thought of what you do here currently ? Yes, the people who actually CREATED Warp3D. I know all of them personally (though have been out of touch for quite a while).

I think this market is small enough and trying desperately to prevent PiStorm 3DHW Support from happening as you do is embarrassing. Not for me, for you. As a side note I know ALL the people who originally created Warp3D personally (though have been out of contact). My suspicion is that they would not like what you make with their hard work.

I have done severel commercial games for AmigaOS (of which also the hardware you sell profits) in the recent past, and am planning several more commercial titles. In a way, bite a hand that feeds you ?

Why do you attack me ? We need to COOPERATE in this market.

Best regards,
Steffen Haeuser
tirionareonwe@gmail.com

Wow! That escalated fast. Lighten up, people!

I see that the crowd-funding campaign is already funded. Good news for PiStorm users.

@MagicSN

Quote:

The needed conditions for making it an actual Warp3D Driver would be that you put the Driver NDK under MIT OpenSource licence (which I think is actually a good idea). The implementation of Videocore VI Support requires usage of the Broadcom Headers and an QPU V3D Assembly translator which are under MIT OpenSource Licence. Using them in a Closed Source Scenario is not possible at best my knowledge.

MIT licenses permit code use in closed-source projects.

Quote:

I think this market is small enough and trying desperately to prevent PiStorm 3DHW Support from happening as you do is embarrassing. Not for me, for you.

It looks like you missed some of what @amigakit said in this thread. Last I heard, Matthew was pretty positive about the PiStorm, and even sells them (link). He's definitely NOT interested in preventing 3DHW support on the PiStorm.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

Okay, then it would actually be an option to have a closed source Driver.

Still it probably would mean i would have to refund about half of the pledges as some people really made the condition that it is an opensource development. So other options might still be more attractive.

As I said I am willing to talk to Matthew on this.

Steffen

@MagicSN

I don't think there's any attacking going on, just some initial confusion. And while it may make people feel fuzzy and cooperative, for what it's worth I think you are already on the best possible implementation trajectory. You could make an actual Warp3DHW library implementation but I honestly don't think it's the best technical choice here for all the reasons I've already stated.

A monolithic driver will be simpler to implement, you aren't shackled by any internal design decisions made 20+ years ago, fewer moving parts to consider and being open source so that anyone else with the skill and inclination to contribute in the future can do so is a great foundation to start off on.

_________________
Doing stupid things for fun...

@MagicSN


Quote:

Why do you attack me ? We need to COOPERATE in this market.

You clearly have not read anything I have posted. Where on earth did you come up with this opinion ? Misinformation such as this just feeds a false narrative.

Quote:

I think this market is small enough and trying desperately to prevent PiStorm 3DHW Support from happening as you do is embarrassing.

Why would I do that? Both A-EON and AmigaKit are highly supportive of the Pistorm project. Simply take a few minutes to read what I have posted in this thread before rushing to type unsubstantiated opinions.

Quote:

I suggest the discussion not to be done on here, but in a private phone call.

A phone call is a good idea - but I would suggest this should have been done way before making a public announcement.

Last edited by amigakit on 20-Jan-2025 at 09:41 AM.

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@MagicSN

Quote:

Okay, then it would actually be an option to have a closed source Driver.

It's one of the most premising source code licenses, you could still keep it open.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@amigakit

There are already three other full library replacements for W3D in existence - QuarkTex, Wazp3D and the wrappers for MorphOS. How many of those had to consult with the IP holders before being released? You do seem oddly fixated on this one in particular.

You've already said a clean room reimplementation that doesn't use the trademark has no issues, so I'm not sure why this is still even a conversation.

Last edited by Karlos on 20-Jan-2025 at 09:37 AM.

_________________
Doing stupid things for fun...

@Karlos

As I have mentioned in this thread several times before, there is no need to replace the main warp3d.library as has been promised in this bounty. A conventional Warp3D driver can be written. A-EON can work through the technical details and offer support if contact is made.

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@Karlos

Quote:

@MagicSN I don't think there's any attacking going on, just some initial confusion. And while it may make people feel fuzzy and cooperative, for what it's worth I think you are already on the best possible implementation trajectory. You could make an actual Warp3DHW library implementation but I honestly don't think it's the best technical choice here for all the reasons I've already stated. A monolithic driver will be simpler to implement, you aren't shackled by any internal design decisions made 20+ years ago, fewer moving parts to consider and being open source so that anyone else with the skill and inclination to contribute in the future can do so is a great foundation to start off on.

My first thought when I read this was: "why not just write an actual Warp3D driver?" I've written two of them from scratch (for Southern Islands GPUs, and then the W3D_NovaBridge driver that makes Warp3D Nova backward compatible). The driver API is straightforward, and I didn't have any trouble with its design.

In both cases I bypassed the Picasso96 driver, because I put a render manager API in the 2D driver which let me allocate VRAM without having to play silly games with Picasso96/Cybergraphics. This eliminated the annoying need to lock the graphics system during Warp3D operations.

Hans

Last edited by Hans on 20-Jan-2025 at 09:46 AM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work