Welcome, Guest. Please login or register.

Author Topic: Layers.library V45 on the aminet  (Read 64625 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #29 from previous page: September 16, 2014, 03:17:06 PM »
Quote from: Heiroglyph;773167
Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.



I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.

yes i remember it was technical issues of course. im not sure if this article is fully up to date, it must have been written by jason.

one issue not privilidgeing vbcc is of course that it is a native 68k compiler (afaik) and aros heavily depends on automatized cross compiling on servers to have actual nightlies ready at hand for testing by everybody. though since people are adding their preffered platforms to compile on i imagine vbcc could also be accepted if it was doable. what concerns missing features like different asm inline syntax (if i understand it right), we have here matthey who is helping with vbcc and vasm for input on that matter.
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #30 on: September 16, 2014, 04:35:55 PM »
Quote from: OlafS3;773175
That is great :-)


@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.


who? magorium? i doubt he needs my help, anyway he didnt asked for any so..
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #31 on: September 17, 2014, 10:06:42 AM »
Quote from: matthey;773214
Vbcc can cross compile from x86 or PPC which is generally all that is needed for fast cross compiling to 68k. AROS is using GCC specific functionality which is a problem. Vbcc has good C99 compatibility now (new unreleased version) and Frank Wille's vlink supports the AROS 68k ELF format. Frank Wille and the AROS developers need to hammer out the necessary changes to get it to work. There isn't a lot of motivation with GCC 68k code generation quality improving lately though.


okay, another informed opinion that gcc 68k backend improved. im sure matt bases it on own experience. of course if someone found solution to modify aros source to compile with vbcc or to extend vbcc with the necessary gcc functionality it would be also fine, but yet again this must be out of own motivation. hard to believe there will be significant amount of interest let alone money to rely on.
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #32 on: September 17, 2014, 10:25:39 AM »
Quote from: Karlos;773220
Not exactly. This work pre dated OS4. I never released it at the time because in fixing a few bugs (and doubtless introducing new ones) I broke compatibility with a few applications. Most notably some of the better demos. I wrote entire suites of tests and can honestly say the driver honoured the API but there exists a corpus of software that relied on some obscure undocumented and likely accidental side effects of the original code. And while the improved performance in synthetic tests was nice, the gains were marginal in most games because the bottlenecks where elsewhere (esp. on ppc).

And that's the moral of this story. Optimising the %&$#?@!%&$#?@!%&$#?@!%&$#?@! out of a single small area often leaves you with little to show for it other than more bugs than you started with. None of the fixes to the v4 drawing calls mattered for existing software except to my projects, and they were still broken / unimplemented in the other drivers, so my software was left running on P2 when voodoo was fast becoming the norm. MiniGL went from v3 api calls to v5 (OS4 only) rendering those fixes irrelevant for most applications.

I had marginally faster minigl 1.5 / heretic 2 / glquake and a lot of wrecked elude demos.




I'd be happy to release it, but it isn't up to me. Warp3D belongs to Hyperion and is now part of OS4. It's also deprecated so they may be ok with it. Either way, I'd have to ask.


you have had access to the sources and been working on a w3d driver predating os4? wow!
now: dont understand me wrong, ï dont expect wonders and also im not making demands. i was actually rather commenting on a general attitude to keep features for os4 even though they could be ported to 68k, or even opening them altogether, even if it was just for educational reasons or for code preservation. this might been legitimate as long as there have been slightest chance for securing an own commercial niche. but it seems for os4 such a chance if ever must have exist only at the very beginning.

now, this attitude seems to change now a little. at least when it comes to contributors, such as in case of the topic here, olsens roadshow or os4 mui maintainers. probably it is plain impossible to prevent such a notion, whoever would like to do it, as soon as it gains own dynamic. i wonder if some day at least the sources of improvements will be published, even if the original ones will remain locked off.
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #33 on: October 03, 2014, 11:59:06 AM »
i cant test as i dont know the issue, have never used birdie and above all have only a touch device with me that doesnt cope well with winuae. sorry.
 

Offline wawrzon

Re: Layers.library V45 on the aminet
« Reply #34 on: October 04, 2014, 04:01:23 PM »
Quote from: Thomas Richter;774462
I didn't even get the program working in first place. It seems to require some MUI classes, but those are installed here. It just crashes on start, probably failing a dependency check of some obscure library. I guess if the author wasn't keeping care enough to write proper tests for dependencies and returning an error instead of crashing, I wonder why I should care so much to make it working... (-;

Ok. Half a dozend missing libraries later... The program runs right into a hit when I try to load it from the workbench, calling through a6 = NULL for still some missing code - I don't know what is wrong there.

It does work from the Shell, though, and then I don't actually notice a problem with it. I can minimize the window just fine, close it, open it, and I don't get a hit or a problem. Thus, hard to say what goes wrong, but given the overall stability of the program as I experienced it I wouldn't be surprised if something is wrong here....


amitradecenter? years ago as i tried it it caused read hits.