@flash

You better hang on to your PegII as it will most likely outperform the A1222+ by a wide margin.

OK,I couldn't help myself when I saw the comment about the qemu effort being a EULA breach. Someone is in full retard mode to make such claims. That's as absurd as claiming that VMWare or VirtualBox breach the EULAs for Windows, Linux or whatever OS a user chooses to run under them as a client. I get so tired of every thread being polluted by the anti piracy clown patrol. Rant over. Never go full retard.

@elfpipe

I can't imagine having to fix the toolchain I'm using to port a GUI library to another OS. That was a huge effort and you should be commended. I've been following your progress for months and your work is quite impressive. You've opened the door to a large number of modern applications that can now be ported to OS4.

@LiveForIt

2nd line has a typo if you haven't already caught it

@rjd324

Why not just use git or subversion?

@rjd324

why not use sprintf()?

Amazing progress! This will open up a whole new world of software for OS4 users. Keep up the great work!

@alfkil

I wish I could help with this one but it's outside the scope of my abilities.

@trgswe

It's doubtful that Tornado will ever get ported to any modern platform. It was written in assembly to maximize the anemic-by-today's standards PC hardware equipped with a VGA framebuffer. The developers needed to eek out every last bit of performance possible because this was in the days before GPU accelerators. CPUs at release time averaged 33 MIPS (486-33Mhz) or less. The assembly code bangs the PC hardware directly, such as accessing VGA registers and memory. It would be easier to just do a complete re-write of Tornado from the ground up in a modern language with modern CPUs/GPUs in mind because modern operating systems don't allow code to directly access the hardware. So essentially there's no way to port this assembly code to a modern OS. Porting Tornado in C/C++ or another higher level language is a huge undertaking and I doubt there's enough interest in such a port to even motivate any coders to take it on.

@kas1e

I suspect that you're correct because alfkil's compiler switches have 64-bit CPU references when the target is 32-bit:

"-DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_PPC -DV8_TARGET_ARCH_PPC_LE -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DV8_31BIT_SMIS_ON_64BIT_ARCH"

I know this is way too easy to be a solution, but it would be interesting to see what kind of errors get thrown if he removed the following compiler switch on his next build attempt:

"-DV8_31BIT_SMIS_ON_64BIT_ARCH"

@alfkil

I'm not 100% positive but you may need to add -fPIC to your compiler invocation. The PIC stands for position independent code (PIC) and refers to the generated machine code which is memory address agnostic, i.e. does not make any assumptions about where it gets loaded into RAM. Sounds like you've mixed some relocatable object code with non-relocatable.

@alfkil

This might be of help.

https://t6847kimo.github.io/blog/2019/ ... ma-in-variadic-macro.html

@LiveForIt

No, they're not the same. The wrapper you linked is for Windows based machines only. It isn't cross-platform. At a minimum the wrapper you linked requires a Windows XP based machine and a SSE2-capable processor. The one I linked over at sourceforge, though quite old (2003), is cross-platform and written specifically for non-Windows platforms and it builds on MacOS, BEOS, SGI and Linux.

"DirectX OpenGL Wrapper emulates API calls thru OpenGL commands and other platform specific commands in order to run DirectX 8 applications running on other platforms than Windows"

@LiveForIt

A working DirectX to OpenGL wrapper would open up a lot of new games for OS4.

The one found here works on several platforms including ReactOS, MacOS and SGI and supports up to DirectX version 8.

https://sourceforge.net/projects/dxglwrap/

I'd probably attempt a port of this wrapper to OS4 but I no longer own my PegII. I sold it back 2010 and I develop almost exclusively for Windows these days because that pays the bills.

@utri007

LOL! Yes, I can't think of single person who feels like an Amiga is their "go to" system for gaming. Most computers users these days don't even know what an Amiga is. Funny story is that my ex-wife assumed that I had a Spanish girlfriend because I used to spend so much time over at Amiga.org and other Amiga web sites. Even after I showed her that they were computer sites and not online dating sites, she didn't believe me....hence the reason she's my EX-wife!

@LiveForIt

"The first thing to do figure out how many of these functions are missing, google the function names, see if you find library it needs."

Yes, I did that already. The D3D source code for Carnivores 2 DOES compile without errors and it runs too. The error message that is presented after running the D3D binary is presented in a dialog box and it is being thrown at run time when the binary tries to initialize 3D audio output.

The point I tried to make about the archives at github is that in many cases the game(s) source code there isn't the final release code and is in most cases the sources are bug riddled and incomplete. Carnivores 2 is a prime example with it's D3D audio. Also, when trying to generate a binary that uses software rendering for audio and video, the sources for Carnivores 2 software video rendering engine is incomplete. Whoever uploaded the sources didn't upload the latest nor complete code base, so until that happens it'll never get ported to OS4 unless someone wants to write OS4 specific software video rendering for this game from scratch.

And yes, OS4 has 3D hardware accelerated graphics, sort of. OpenGL/OpenGL ES support is spotty and incomplete and is a work-in-progress, not to mention that even the best GPU cards for OS4 were produced about 8 years ago. And don't even get me started on how far behind NG Amigas are in terms of raw CPU horsepower. Even the best NG Amiga CPU performs on par with x86 processors from around 2004.....that's a 17 year gap in performance.

@utri007

Yes, several of the games have already been ported to both OS3 and OS4. Thanks for the link to the archives BTW. Looking at the source code for many of these games was quite an enjoyable trip down memory lane, at least for Windows/DOS programmers. Unfortunately, both classic and NG Amigas have a lot of catching up to do in regard to graphics libraries, cross-platform toolkits and build tools. Programming for classic and NG Amigas is like taking a time machine back to the year 1998.

Another problem is simply a lack of raw CPU and GPU horsepower on classic and NG Amigas. In some cases, libraries such as QT have been ported to OS4, but the CPU/GPU overhead is so high that the performance suffers. Many developers already know this so they won't even attempt to port some games knowing that they will run so slowly that there's no point in even trying. SDL based games run poorly on all Amigas due to a lack of CPU/GPU horsepower.

My opinion, FWIW, is that NG Amigas will have to make the leap to modern processors and OS4 will have to undergo a complete re-write to survive, but that's not likely to happen as long as Ben Hermans is still breathing. The MOS team figured this out years ago as did Apple, but for some reason, the average Amiga users out there have put their heads into the sand and think the way forward is to pay higher and higher prices for slower and slower hardware and almost no OS development.

A OS4 re-write is needed to enable multi-processor support at a minimum. Again, that won't happen as long as Ben is breathing. AROS x86 SMP is promising though.

@utri007

Even though most of these games were written in C/C++, many of them depend on libraries that don't exist for the Amiga or are poorly supported under OS4, if at all. Just for kicks, I decided to see how difficult it would be to compile the sources using Visual Studio under Windows for Carnivores 2 and Postal. Postal was a breeze to compile since its only dependency is SDL2. Postal has already been ported to OS4, which isn't surprising because SDL2 was ported to OS4 years ago. The Postal debug binary ran perfectly after compilation. Carnivores 2 was a different story. I was able to get it to compile a D3D binary on Windows with only some minor edits to the code, but upon running the binary I get a dialog box that says "Can't find procedure Audio_UploadGeometry". Compiling a version that supports software video rendering (a requirement for OS4 since there is no D3D compatibility layer) threw over 200 errors. At that point I didn't even attempt to track down the cause because even if I was able to get the source to compile under Visual Studio, there's no way it will ever compile for OS4 until someone smarter than me writes OS4-specific code to handle the video output as well as Amiga-specific keyboard and joystick controls. The current software rendering is also Windows-specific. You need to get the idea out of your head that just because a game or app was written in C/C++ that it's easy to port it between different platforms. It isn't, especially for platforms that have been dead for years and where any real development ceased 2+ decades ago.

@Hans

Look no further. There's now a softcore design for Xilinx boards.

https://openpowerfoundation.org/the-ne ... power-foundation-journey/

Very interesting development. This opens the door to FPGA systems that could run OS4.

https://www.nextplatform.com/2019/08/2 ... wer-chip-instruction-set/