@Hans

I think you've been doing a good job in that regard too. Part of my daily routine is just to check in here to see what new port kas1e is working on and read about his progress.

@Hans

No, I DON'T think it's bad. I just think it's a very difficult task and would take a "team" of coders and a large chunk of time to port the engine and the interface to OS4. It isn't a one-man job at all and I think it would be a pity to port the engine and not port the dev interface. In my opinion, the dev interface is the easier of the two pieces to port.

It's just tiring to see non-coders always asking questions like, "Why don't we have Crysis for the Amiga?" or as in this case, "Hey, Godot is cool, let's just spend a week or two porting it over to OS4 since it's open source and we have the source code!". I know I'm exaggerating, but you get the gist.

I'm just trying to educate them as to why these types of projects aren't taken lightly and why they take so much time and resources and why the outcomes aren't always optimal when compared to the system that the software was natively developed for. I'm not annoyed with you but with non-coders who don't understand that these ports don't happen overnight.

I really respect your work. You've fought an uphill battle for years and exceeded the expectations of many people so please don't ever take my comments as criticism of your work. You deserve a medal in light of the closed source road blocks you've had to navigate in updating the 3D subsystem of OS4.

We can argue the speed of the X1000 and X5000 CPUs till the cows come home. For most applications, I will agree that the CPUs in those systems are "good enough". But they certainly aren't my first choice for any heavy lifting or modern gaming. I hope that OS4 survives and gains a more capable CPU soon as all the PPC variants seem to have died off or have become so scarce and expensive that they simply aren't practical.

Porting the engine would be a great first step, but ultimately I think the goal in porting the engine would be to get people interested in coding for OS4 again by showing off the games. When folks find out that the games were developed on a PC and transferred to OS4, their first response will be, heck, why not just get a PC and be done with it.

@Hans

I guessed you missed the point about Godot being a cross-platform game engine/game development system? That's the whole point of having a cross-platform game development system and engine....to create games for various systems regardless of the hardware and OS that the dev prefers. That's why I keep talking about devs using it for cross-platform development. Why do you keep talking about it?

And of course the engine needs to be ported to OS4 if anyone is going to use it to play Godot developed OS4 games just as the engine was ported to Windows, iOS, Android, and Linux. Why are you so good at re-stating the obvious? The developer interface also needs to be ported to OS4 with all the dependencies that I mentioned earlier unless you expect PC devs to create Godot based games for OS4 on their PCs and move them over, so what's your problem? And I don't see any PC developers who will be doing this as most of them don't even know what an Amiga is, let alone want to develop games for an Amiga for free in their spare time on their Wintel boxes.

As for your statement, "As for performance and/or missing hardware features, the Godot engine has a GLES2 backend and targets mobile devices too." I never said that any missing functionality or performance hits would be tied to OS4's precious GLES, so stop acting so butt-hurt about my comments. None of my comments have attacked your work. I specifically mentioned anemic embedded CPUs and the lack of muti-core/threading capabilities. Engine performance will be less than optimal even if it ever gets ported to OS4 due to this "anemia". Game build times will also suffer greatly. OS4 sound handling code needs to be written and added to the engine and the developer interface as well if you want sound with those games. I didn't even mention the SSL/TLS functionality that would be missing in any network enabled games since SSL/TLS support is so outdated on OS4.

And don't forget about LIBUDEV. The game engine needs this to enumerate things like USB joysticks and mice for in-game play. This also hasn't been ported to OS4 and it's unlikely that it ever will be ported, so custom code would need to be written to accommodate USB devices under OS4.

So let the porting of this "toy" begin! Actually Godot is no toy. It's more comparable to the Unreal 4 engine or Unity. Here's a video showcasing it with comparisons to Unreal and Unity. https://www.youtube.com/watch?v=IPCv6F-IgXU

Or this video which showcases version 3.1 which was released on the 19th. https://www.youtube.com/watch?v=P6nQ3E-Cyfk This is not your Amos Pro and a simple text editor.

It also supports C# so there's another large chunk of missing functionality if the dev interface and engine ever get ported to OS4 since there's no Mono support for OS4.

So in this developers opinion, it's more likely that we'll see a port of the Unreal Engine to OS4 before we see a Godot port, and the chance of that happening is 0%. Unless you're talking about a very early Godot version that is feature and performance crippled.

@Hans

Yes, obviously the slow downs on Godot if ported to OS4 wouldn't be due to the discrete desktop GPUs used in the X1000 or X5000. But there'd be a huge performance drop in comparison to current systems due to the X1000 and X5000 using outdated, EOL'd CPUs that were designed for embedded systems needing high single-threaded performance. As I said earlier, an X5000 performs on par with desktop Wintel systems from around 2003-2005 in terms of features and CPU horsepower. I don't know of any devs who would want to step that far back in time/performance to develop games for current platforms let alone drop what they're doing on current systems and adopt a dead (or on life support) platform to develop games for the same dead platform, except maybe kas1e.

There simply isn't enough demand for new games on OS4 to motivate anyone to port the Godot engine and Scons over to OS4. Again, it would be much easier to modify a current version of Godot running on a Wintel box or Mac to produce OS4 binaries than undertake the effort to port Scons AND Godot to OS4. And Scons is the one dependency that is definite. In my life as a developer I've found the FAQs for such projects to be totally inadequate and fail to mention the plethora of other dependencies required for a complete build.

After looking at the Linux build dependencies which would most closely mirror what would be needed for an OS4 build, there are quite a few more dependencies that would need to be addressed. These are:

Audio Handling
Freetype (for the editor)
OpenSSL (for HTTPS and TLS)
Optional - libudev (build with udev=yes)
Optional - yasm (for WebM SIMD optimizations)

The audio code would require a lot of work whereas the other dependencies already exist for OS4 or can be left out of an OS4 build as they are optional. But all this doesn't even matter because as I mentioned earlier, there's nothing to motivate anyone to even begin porting such a large amount of code to OS4. The Godot source archive is 96MB after unzipping the archive from Github. That's isn't a small project.

Updating the export engine of the Linux or Windows version of Godot to produce OS4 binaries would probably be easier than going for a full OS4 port. I'm not trying to be negative. I'm just being objective and pointing out how much work is needed to port current software to legacy systems. It is no easy task and takes a LOT of time. Such ports are also almost always inferior too. Either the hardware can't handle the new features, so said features are left out of the port or perform very poorly if left in, or the features/dependencies haven't even been developed for the legacy system which yields the same result.....a working albeit a crippled port.

@noXLar

The "ES" stands for Embedded Systems. It's a pared down version of OpenGL for phones, tablets, etc. and other devices that may not have the ability to support a full OpenGL implementation or they are "weak" in comparison to systems with dicrete GPU's.

Here are some of the differences between OpenGL 3.3 and OpenGL ES 2.0. ES lacks the following:

- lack of geometry shader support
- no min/max blending (there may be an extension for this)
- no Quad List primitive
- more restricted texture formats (especially regarding floating point)
- glGetTexImage is not available
- there is no Transform Feedback, same for several other advanced features

If the game you are developing in Godot targets the least capable hardware, then yes, OpenGL ES would provide the in-game graphics. Theoretically it would be possible to have Godot to use GLES (or MiniGL) for the developer interface but it would limit many of the things you'd want to do as a developer and make testing painful if the target system used OpenGL instead of GLES.

Typical game developers want the beefiest hardware they can afford in terms of CPU and GPU horsepower so that they can target the full range of systems for their games as well as speed up development cycles. Unfortunately, Amigas don't fall into the beefy category anymore and haven't since about 1991. Even the most current X5000 has rough feature parity with Wintel systems from about the year 2003-2005. I don't know of any developers, game devs or otherwise, who would seek out such outdated hardware for current game development unless they are masochists.

A couple years ago I took my A1200 out of storage where it had lain unused for over 10 years to update the PLPlot scientific plotting library. http://aminet.net/package/gfx/show/plplot68k-5.0.1

My A1200 has a 68030 running at 50 Mhz and I stuck to period tools (SAS C 6.58) but used a CF drive to speed things up. That was a painful experience and one that I won't repeat.

Now I use AmiDev C++, a cross-compiler, on my Windows system to code and debug and I drop the resulting executables into a shared folder under WinUAE for testing.

Over at the AmigaWorld discussion about Godot, Hans pointed out that it might be possible to port Godot to OS4 and use MiniGL or GLES for the interface. But even if it were ported I can't imagine too many developers who would want to use an X5000 or an X1000 for development. It would be terribly slow and you would still need to have a PC standing by to test any games you develop that use OpenGL 2.1 or higher. It would be much easier from the developer's standpoint to conduct development on a fast PC and target the X5000 or X1000. This would require someone to figure out how to get Godot to produce OS4 compatible binaries which probably isn't all that difficult if it's using a good cross-compiler, but I'm not certain about that.

@noXLar

Godot requires SCONS to build properly which doesn't exist on OS4. SCONS is similar to CMAKE but it relies on python, not to mention that the build process also requires a recent version of GCC. Someone would also need to write the OS4 GUI specifics for the user interface which is no easy task in and of itself. Godot also requires OpenGL 2.1 which is missing on OS4. OS4 has MiniGL which is just a sub-set of OpenGL, not a complete point release. It might be possible to cross-compile this on a Linux box but then you're left with the GUI and OpenGL issues mentioned earlier.

It's an interesting alternative to the Unreal 4 Engine or the Unity Engine but you're not likely to ever see any of these engines ported to such an ancient and lacking OS as OS4. Too much water under the bridge.

Some folks at AWorld discussed porting it last month here: https://amigaworld.net/modules/newbb/v ... topic_id=42428&forum=2&19

@ChrisH

Yeah, it looks like most of the python gui's out there are Mac/Linux/Windows native or rely heavily on wxidgets or QT. I think Kas1e did a QT port to OS4 so it may be worth taking a look at pyQT4. https://www.riverbankcomputing.com/software/pyqt/download

I'd prefer something wxwidgets-based because it's more lightweight in terms of code and system requirements/resources but I don't think it's been ported to OS4.

Another lightweight GUI is FLTK and it has been ported to OS4. See this: http://www.soft3dev.net/pages/fltk.php

and the pyFLTK page: http://pyfltk.sourceforge.net/

@ChrisH

PyGUI

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

@Daytona675x

I don't think he's being pushy. I think he's just so excited to be making progress that he doesn't want to slow down. That's understandable given a platform where the progress has historically been measured in years....

@ChrisH

The Tabor hasn't been released as per A-Eon, the audio, NIC, and FPU problems haven't been sorted out. The boards have been available for 2 years now but Trevor won't sell them until the drivers are finished and the FPU issues are resolved. I guess he doesn't want a repeat of what happened with the X1000, and I don't blame him. He lost a lot of prospective customers over that.

The TimberWolf debacle has everything to do with Hyperion. It was headed by Hyperion's 2 chief programmers, the Frieden brothers. They even posted their progress reports from Hyperion's official blog site. TimberWolf

I'm unwilling to modify my beliefs because I'm unable to ignore the facts.

And unfortunately, Hyperion was bankrupt and the official records state so.

But believe what you will. You don't seem to be one who can be swayed by anything factual and you have an economic stake in this with you being the author of PortableE for the Amiga. I'm nothing more than a disgruntled former customer who won't make the mistake of buying anything associated with Hyperion again. Neither my ego nor my wallet rely on the success or failure of Hyperion.

@Spectre660

Someone bailed them out and it wasn't Amiga INC.

Quote:

So either Ben has a rich aunt from Nigeria or A-Eon helped them out. And despite the denials of bankruptcy, you don't get listed as bankrupt by accident as was implied.

A-Eon is the only company that would have had any interest in this "restructuring" which in my country is colloquially termed a "bail out".

@Spectre660

Here's a thread from 2010 discussing the failed port of Open Office. There are more threads going back even further if you choose to look for them: Open Office

And afterward, in 2012, A-Eon announced an effort to port LibreOffice which has also amounted to nothing: LibreOffice At this point even A-Eon recognized that Hyperion had once again failed to deliver and attempted to step in and rectify the situation.

Here are some Hyperion claims regarding SMP from back in 2011. Again, there are other references dating further back in time if you choose to Google them: SMP

and this one:

SMP

In those days Hyperion was claiming it would take less than 2 years for an SMP version of OS4 to be completed.

And here is a blog update from Hyperion back in 2013 about SMP progress, or rather the lack of it: SMP

As for a web browser, Timber Wolf (FireFox) was a disaster: TimberWolf

A bug riddled mess was delivered and most OS4 users can't or won't use it due to the bugs.

Hyperion and A-Eon are now a joint venture since A-Eon bailed Hyperion out of its financial mess. So laying the blame on A-Eon for the lack of driver support is the same as blaming Hyperion.

As for "being worked on", that's all that Hyperion seems to be able to offer.....

@orgin

Quote:

Bit to be desired? That's a serious understatement. X1000 users have been waiting nearly 10 years for audio and NIC drivers. Hyperion promised a web browser, office suite and an SMP version of OS4 10 years ago as well. It's been 2 years and no audio or NIC drivers for the Tabor, nor FPU support. Hyperion hasn't delivered on any of their promises in 10 years and based on your assessment why would one believe that they now have the resources and the resolve to deliver anything related to OS 3.1?

I suspect that anything they release for 68K Amigas will simply be patches and fixes already available on the net bundled up with Hyperion's name affixed to the box. So no thanks.

I'm sure it'll be released simultaneously along with an SMP version of OS4 and an office suite....and those audio and NIC drivers for every existing piece of A-Eon hardware.

@Dandy

No worries. Probably just a glitch in your browser cache.

@Dandy

Hmmm...the graphics show up just fine for me in the first post. They were created at 1024x768x256. Your browser must not be working properly as I can see them well in Chrome and Edge.

The PLPLOT screens are user selectable so if you choose to use a higher resolution or if you have an RTG card you can use higher resolutions if you so desire. My A1200 only has an old Rosewill monitor attached that can't go any higher than 1280x960. That's why I posted pics at 1024x768. I also do not have 24-bit color capability on my Amiga 1200 so Example 8 is using 256 dithered colors, hence the lack of smoothness. The array used to generate the example was also quite small, around 128x128 if I remember correctly. Using a 24 bit display and a much larger array would yield a smooth graph.

Here are the links to the images I created on my A1200 in the first post in case you're still having trouble seeing them.

http://www.lidarwidgets.com/samples/plplot/example01.jpg
http://www.lidarwidgets.com/samples/plplot/example08.jpg
http://www.lidarwidgets.com/samples/plplot/example09.jpg
http://www.lidarwidgets.com/samples/plplot/example16.jpg
http://www.lidarwidgets.com/samples/plplot/example16-1.jpg

And yes, PLPLOT can display images like the one you posted. The images I posted are merely the result of the example programs as they were written with no changes and no bells or whistles. You can see more examples here: PLPLOT Demo Plots

And please remember, I didn't write PLPLOT. PLPLOT is an opensource effort with hundreds of programmers and users making code contributions. I merely compiled the 5.0.1 library for classic Amigas, compiled the examples and posted some of the pics created by the examples. If you want to know more about PLPLOT, please go to their web site here PLPLOT Home

@Dandy

I just uploaded some plots created by the example programs on my A1200 using the High GFX driver.

@Dandy

Yes, Aminet is back online and I have uploaded the 5.0.1 archive and README. You can get it here: http://aminet.net/gfx/show/plplot68k-5.0.1.lha
The Readme is here: http://aminet.net/package/gfx/show/plplot68k-5.0.1

The PLPLOT homepage is here in case you're looking for documentation and more : http://plplot.sourceforge.net/

PLPLOT is actually a programmer's plotting library with bindings for C/C++, Fortran, Python and a few other languages. It makes it quite easy for novice programmers to write their own plotting applications. The example programs can be easily modified and re-compiled to suit your needs if you have a compiler.

The current version of PLPLOT is 5.12 for non-Amiga systems. I may take a stab one of these days at updating the Amiga version to 5.12 but right now I'm quite happy with 5.0.1 as it does everything I need it to do. And it's much more advanced than the version 2.6 that has been on Aminet for years. The maintainers of PLPLOT have also migrated to a CMAKE environment which makes updating this Amiga version to 5.12 somewhat more difficult as I don't think there's a CMAKE tool for classic Amigas.

After a 24 year hiatus I decided to drag my A1200 out of storage and brush up on classic Amiga development. I hope to do more development once I get my hands on the standalone Vampire. I normally develop LIDAR applications for Windows and OSX using XCode and Visual Studio. As a refresher I thought it would be a good exercise to compile PLPLOT 5.0.1 for classic Amigas since it was the last version that supported the classics and the latest version on Aminet is 2.6. I was successful at compiling the library and building all the examples but not without some pain. Finding a "make" utility to process the included make file was troublesome but I finally found the correct one on Fred Fish Disk #69. The GNU make utility on Aminet may also work but I haven't tried it. You also have to link against the reqtools.library which is found on Aminet. The make file also needed some heavy editing but now everything builds fine using SAS C 6.58. I will upload the entire archive once Aminet is back online. Seems to be down at the moment. Below are some plot examples using the High Graphics Screen Mode Driver and 256 colors. The library supports other modes as well and screen mode selection is menu driven. I will include all the binaries and PLPLOT link time library in the archive for those who want to use it.


Aminet link to archive: http://aminet.net/gfx/show/plplot68k-5.0.1.lha

Readme link: http://aminet.net/package/gfx/show/plplot68k-5.0.1

To run the examples, extract the archive to your favorite hard disk such as DH1:
Then open a shell and create the following assign without quotes: "assign plplot: DH1:plplot"

Navigate to plplot/tmp and then run any of the examples such as X01c thru X19c.

Here are some High GFX plots created from the examples on my A1200:

@LiveForIt

I never said anything about open source. But since you mentioned it I'll point out that there are also quite a few closed source projects on git, svn, etc and some of them are also Amiga projects....closed source or open sourced, it doesn't matter. An inactive project is an inactive project.

And as a C/C++ programmer who spends most of his time porting Linux apps to Windows I do understand the nature of porting from one OS to another and I use SVN and git all the time. But inviting OS4 programmers to hang out at a Facebook page does nothing. Until there's an incentive (i.e. money and a consumer demand) for a programmer to pick up his keyboard and start coding again, these projects are gonna sit until hell freezes over.

Asking a bunch of programmers who have bills to pay to join a "virtual programmer's commune" on Facebook isn't going to get a damn thing done, open or closed source.