Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
50 user(s) are online (32 user(s) are browsing Forums)

Members: 1
Guests: 49

Beajar, more...

Headlines

Forum Index


Board index » All Posts (ferrels)




Re: No std::to_string(float) in GCC 11
Just popping in
Just popping in


@rjd324

why not use sprintf()?

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


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

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@alfkil

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

Go to top


Re: Open Source Games Available!
Just popping in
Just popping in


@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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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"

Go to top


Re: Qt 6 progress
Just popping in
Just popping in


@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.

Go to top


Re: Qt 6 progress
Just popping in
Just popping in



Go to top


Re: Lots of sources for comercial and arcade games 1980-2002
Just popping in
Just popping in


@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"

Go to top


Re: Lots of sources for comercial and arcade games 1980-2002
Just popping in
Just popping in


@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.

Go to top


Re: Lots of sources for comercial and arcade games 1980-2002
Just popping in
Just popping in


@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!

Go to top


Re: Lots of sources for comercial and arcade games 1980-2002
Just popping in
Just popping in


@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.

Go to top


Re: Lots of sources for comercial and arcade games 1980-2002
Just popping in
Just popping in


@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.

Go to top


Re: Lots of sources for comercial and arcade games 1980-2002
Just popping in
Just popping in


@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.

Go to top


Re: PPC Instruction Set Now Open Source
Just popping in
Just popping in


@Hans

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

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

Go to top


PPC Instruction Set Now Open Source
Just popping in
Just popping in


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/


Go to top


Re: Open Source cross-platform game engine
Just popping in
Just popping in


@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.

Go to top


Re: Open Source cross-platform game engine
Just popping in
Just popping in


@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.


Edited by ferrels on 2019/3/24 7:23:14
Edited by ferrels on 2019/3/24 7:26:26
Edited by ferrels on 2019/3/24 7:35:50
Edited by ferrels on 2019/3/24 7:56:55
Go to top


Re: Open Source cross-platform game engine
Just popping in
Just popping in


@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.




Edited by ferrels on 2019/3/24 5:29:55
Edited by ferrels on 2019/3/24 5:31:10
Edited by ferrels on 2019/3/24 5:33:39
Edited by ferrels on 2019/3/24 5:39:40
Edited by ferrels on 2019/3/24 6:12:53
Edited by ferrels on 2019/3/24 6:27:37
Edited by ferrels on 2019/3/24 6:38:39
Go to top


Re: Open Source cross-platform game engine
Just popping in
Just popping in


@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.


Edited by ferrels on 2019/3/23 18:27:52
Edited by ferrels on 2019/3/23 20:42:49
Go to top


Re: Open Source cross-platform game engine
Just popping in
Just popping in


@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.


Edited by ferrels on 2019/3/23 8:44:08
Go to top



TopTop
(1) 2 3 4 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project