Odyssey 1.23: AOS4 source code on GitHub

@Hans
Quote:

But with that you on your own :) You surely will need to ajust compiling of main.cpp accordingly as well as you may have issues somewhere else too not only with Cairo.

It's always better when anyone who even trying to do anything with have same setups.

With cairo at least you can simple change in in CMAKE/AddGlobalCompilerFlags.cmake in 2 places that:

-I/usr/local/amiga/ppc-amigaos/SDK/local/common/include/cairo

On

-I/whereyour_SDK_are/local/common/include/cairo

But maybe with softlink it will be better (so no need to ajust anything later about).

@kas1e

I have built this using the instructions. This was using a new install of Cygnix and using also the same paths as in the HOW_TO_BUILD_AMIGAOS4.txt document.

The only change i made was for the initial 'make' line to try and speed it up. I used "make -f Makefile owb -j$(nproc)" instead of "make -f Makefile owb -j4" which uses the number of threads available on my CPU instead of using a set number (in this case 4).

Thanks for everything you've done to get this in place.

@derfs
So all good then.

Now let's see if anyone will fix some bugs we have. The necessary one now is that new one when we switch to new gcc and patches to some conf files trashed. Then will be good to deal with crash in BlockFree of javascript when we exit from browser (happens on debug kernel all the time with 0xcccccccc). And issues with mediaplayer cause crashes/glitches will be nice to be deal with too.

@derfs

Great that you can confirm his instructions work.

I've got broken AHI headers, so I still got GetInterface()/DropInterface() errors with my last build. Probably have the old SDK's headers after all.

Fixing that now...

EDIT: Adtools really should be updated to install the latest SDK by default, as kas1e suggested back in 2018. Sure, it's not hard to update manually, but it's a pointless waste of people's time. Everybody should be using the latest SDK (which is actually old too; it's from 2015).

EDIT2: Just checked my adtools sources, and it downloads the old SDK, but saves it as SDK_53.30.lha. Had me fooled.

Hans

@Hans
Yes, as i wrote in how_to_build 53.30 is must, as well as in my article on os4coding.net about installing adtool on cygwin that you need to fix SDK to download real 53.30 when build it.

But ! If you update to the latest 53.30 SDK only now, you should recopy again Odyssey's SDK on top of it, because Odyssey's SDK have fixed cybergraphics includes, which i do not know if was in SDK 53.30 (i reported it on hyperion's forum and point out on errors, but do not know if they fits to 53.30).

@kas1e

Already done. I reapplied your SDK files after updating the SDK ones. I skipped your cross-compiler instructions because I already had a working cross-compiler. Didn't realize that SDK_53.30.lha on my machine was actually the old one.

Hans

@thread

Could a MD5 check be done on files ?

For example SDK 123MD5.zip could be in folder :
SDK/123MD5/123MD5.zip with also SDK/123MD5/123MD5.lha
(if one needs different compressed file on platform).

which then also has
SDK/123MD5/123MD5.zip.contents.txt

:D

@kas1e

... and I have built Odyssey! Posting this from my own compiled version. My build has a screwed up "Conf" directory. It created a new directory with a random looking name, and put WebpageIcons.db in there. After copying the
other conf files, it's working nicely.

EDIT: The conf file directory name is random. It creates a new directory with a weird name every run...

I have one more tweak to suggest for the instructions, but will do that from my Windows machine.

@asymetrix

An MD5 check could probably be done, but the adtools makefile really needs to be fixed to download the correct SDK.

Hans

@kas1e

Here's my final tweak to your instructions:
ppc-amigaos-g++.exe -mlongcall -D__USE_INLINE__ -std=gnu++0x \
-Wno-expansion-to-defined -Wall -W -Wno-parentheses -fno-exceptions \
-I/usr/local/amiga/ppc-amigaos/SDK/local/common/include/cairo \
-I../Base \
-I../Base/wtf \
-I../Source/WebKit/OrigynWebBrowser/Api/MorphOS \
-I../Source/JavaScriptCore \
-I../Source/WTF \
-I../Source/WebCore/platform \
-I../Source/JavaScriptCore/runtime/ \
-c ../Tools/OWBLauncher/MorphOS/main.cpp -O2 -o Tools/OwbLauncher/CMakeFiles/owb.dir/MorphOS/main.cpp.obj

All the paths have been changed to be relative to the build subdirectory, so you no longer have to put the Odyssey source code in /amiga/Odyssey/.

Hans

@Hans
Thanks, will ajust how_to_build

As for bug: yes, that is this one. And happens only with new gcc now , with the same 3d party libs and includes, but via gcc 4.4.3 i didn't have such issue. Let's continue about that bug in progress1.23 thread ? I post some info about already in it (see last post)

@all

Derfs and I can confirm that Odyssey is now quite easy to build. Simply follow kas1e's instructions. So if you're interested in helping out, doing so got a whole lot easier.

I know the biggest change we all want is a big update to WebKit. However, here are a few smaller improvements I think would be nice to see:
1. Tweak the build system so that it builds the entire browser in one go, so kas1e can delete the final main.cpp compile and link steps (needs someone who's familiar with CMake)
2. IIRC, the video player is a bit crashy...
3. Implement composited video support in the video player
4. WebGL is based on OpenGL ES 2, which we have. It would be awesome to have that working too

Hans

@Hans

Quote:

That one very easy, just i didn't do so because for me was always better to build last main.cpp and linking manually because of offten test, and that manual compile/link are very fast, in compare with running "make" again, and waiting all the checks for libs you not need to build.

Quote:

Mediaplayer files in BAL/Media/WebCore/MorphOS/ "BCMediaPlayerPrivateMorphOS.cpp_save" file is saved original from Morphos an "BCMediaPlayerPrivateMorphOS.cpp" is aos4-adapted version , which can be totally rewriten of course.

Quote:

That one surely good idea. Through, some thing may appear like video player is slow because of cairo, and maybe it will be much better to add compositing support to Cairo, and then whole Odyssey include video player will be faster.

Also, video player use acinerella which use ffmpeg.

Quote:

That one interesting too, and Deadwood back in past say me he build webgl for aros vesion of 1.25 version (through it was buggy because of bugs in aros 3d subsystem which he wasn't in interst to fix then), so that surely possible. Through, we don't know how it all rendered in WebKit, very possible we may hit the wall with DMA. Through have it working even without DMA will be intersting.

To add, the thing which for real want to be fixed also are crash on exit when we on debug.kernel. Happens in javascript's blockfree(), all the time, wtih 0xcccccccc. And probabaly can be a cause of some bugs everywhere.

Another good idea will be to check http://bugs.os4depot.net/?function=viewissues&softwareid=15 , and check all the non-fixed suggestions, etc. Maybe something worth to be adding as well.

@Hans

This makes me optimistic.

@LiveForIt
Just remember plz NO liveforit_odyssey or any other new version releases based on that repo. There should be one single odyssey for os4, and all patches and pull-requests should go there.

@kas1e

Yes, the biggest question regarding composited video and WebGL, is how it'll interact with the Cairo rendered stuff. The last thing we want is to render stuff on the GPU, and then have to copy it to RAM to be software rendered into the rest of the page.

We can probably create the equivalent of an overlay window for video playback, and hopefully that'll work well enough.

I'm not sure that compositing support can be added to Cairo, or how much that would help. Cairo does a lot more than compositing, so that would only cover some operations.

Ideally, we'd have everything rendered on the GPU, but that's quite a task. IIRC, Cairo's API design itself is a bit of a bottleneck for GPU rendering, at least as far as webpages is concerned. That's why browser engines are ditching it for something else.

I'm hoping that composited video/WebGL could be merged with the Cairo rendered stuff on the GPU somehow (e.g., handle rendering the video player's controls on top of the composited video on the GPU). Otherwise we'll take a performance hit with stuff being copied from VRAM to RAM.

Hans

@Hans
Quote:

Yes, that how it was done (and still?) on morphos. When you press "fullscreen" on youtube videos, there just overlay window opens and video plays as fast as it should.

But it also intersting to have it be fast played in the window of odyssey too of course :) I need to find out logs with all the talks we have about years ago, so maybe some bits of info which can help us can be refreshed.

We at least need to fix crashes in current mediaplayer to make it more stable for time being )

I noticed that mediaplayer offten loose sound when you move time slider, and no other sound after that possible at all in whole system. So it mean AHI die and we need to re-check ahi parts in BCMediaPlayerPrivateMorphOS.cpp

There is some scary low-level ahi code which i for sure badly port from morphos to os4.


Quote:

Dunno what much of "else" it do under the hood, but as i see it Cairo used for simplify rendering of 2D, and for that have different backends : software, accelerated, etc. Currently we use software, the slowest possible. I assume that if there will be compositing acceleration added, it will just speed everything up automatically, and even videos will plays smooth as it.

Hi, in the "big" CMAKE commandline there is:
..
-DENABLE_ACCESSIBILITY:BOOL=ON \
-DENABLE_BLOB:BOOL=ON \
-DENABLE_ACCESSIBILITY:BOOL=ON \
-DENABLE_BLOB:BOOL=ON \
..

twice, ¿typo?
just trying to compile following your steps.

Would make sense for you all guys if what needs to be done go to issues section of github, where we can add all the suggestions from os4depot, as Roman mentioned? That way all thing needed to be done will be in one place for everyone to find it, and keep this thread for discussion as well. Otherwise, necessary information will be scattered.

In my opinion, there are ways to watch online video on AmigaOS 4 using exernal scripts and ffmpeg, which works pretty well. I don't say that it is not necessary, but maybe having a newer version of webkit and some serious bugfixes is more crucial right now, what do you think?

In github there is projects section, where tasks can be created on what needs to be done. So, there can be visibility on what is on the pipeline and what is currently in WIP. That way people will know what needs to be done, to void duplicate work by being more transparent.

From my side, I will start working on a development environment based on docker, which will be able to compile Odyssey out of the box. I will surely need help from you, but first I will use Roman's guides.

@walkero
Quote:
That depends on how many bug reports there are on the old system. If it's a small number, then transferring them to GitHub would be useful. Otherwise, I'm not sure the effort would be worth it.

Quote:
IMHO, top priority should be for any bugs that crash the browser. That includes the video player bugs that can cause a crash.


@kas1e
Quote:
Have you tried using the cairo-gl backend? We have GL4ES etc., so we should be able to use it now. And, it would be our best bet to moving rendering to the GPU. Writing a new backend would take some time...

Hans

@Jabirulo
Quote:

Yeah surely typo, thanks

@walkero
Quote:

Updating of core is a big and hardwork, and i do not know up to which revision we can update with current source code base without too much rewrite. So don't hold the hopes.

But crashes should be fixed in current version, because they will make things only worse with or without updated core.

Quote:

Waste of time IMHO. Because you always will be in need to be in sync with odyssey's SDK files and with actual code. And your image always will be outdated.

Probably it only will be good to have some image with just installed adtools, and then let the developers download the repo from GitHub ourselves (and not the only odyssey's one, but anything else they need). But that not very much related to odyssey itself then.

If someone can't build it now with all the GitHub code and how-to, then contribute from those ppls is not welcome then as they will contribute a shit. No need to spend time on things that any adequate user (even not developer) can do already.


@HAns
Quote:

"moving rendering to the GPU" without DMA ?:)

From our tests with warp3dnova/ogles/gl4es , SDL2, DOSBOX, and compositing in all our projects, the current conclusion is that compositing always faster than gl4es/nova/ogles/minigl whatever. And that not even about DMA, but just probably because OpenGL is a more massive thing and need more to initialize just for some simple things. Also, have too many layers between not very helpful too. If there should be "rendering to the GPU", it should be then warp3dnova backend for Cairo, but then again no_dma.

Taking the same no-DMA situation, but on compositing, always faster from all the tests than non-DMA on OpenGL, which always hit 100% CPU and busy everything when uploading textures and whatever else it does internally.

Also, gl4es/ogles2 works not everywhere, while compositing everywhere.

In other words, IMHO, until GL things will not have DMA we out of luck. And that DMA thing may not happens ever if we will wait while Steven and co be done with it in the kernel to be able to use new functions for. And even then, all the users without RadeonHD/RX out of luck.

Yes, writing compositing backend will take time sure, but it will work everywhere. And we will not limit users without Radeon HD/RX cards. And in compare with "Wait when new kernel will properly support DMA, then wait when radeon drivers will support Dma, then wait when graphics.lirbary will be updated to support dma, then wait when os4 update will be released, then wait when aeon will release update" - in compare with that, writing of compositing backend to the cairo will be a best possible way. Or even not for cairo, but just for mediaplayer parts.