Who's Online |
60 user(s) are online ( 43 user(s) are browsing Forums)
Members: 0
Guests: 60
more...
|
|
Headlines |
-
gifanimdt.lha - datatype/anim
Sep 22, 2023
-
giflib-extras.lha - development/library/graphics
Sep 22, 2023
-
dtconvert.lha - utility/filetool
Sep 22, 2023
-
libx264.lha - development/library/misc
Sep 20, 2023
-
amissl-sdk.lha - development/misc
Sep 20, 2023
-
mce.lha - game/utility
Sep 20, 2023
-
amissl.lha - library/misc
Sep 20, 2023
-
mediathek.lha - network/misc
Sep 19, 2023
-
libwebp.lha - development/library/graphics
Sep 17, 2023
-
reminiscence.lha - game/adventure
Sep 17, 2023
|
|
|
|
|
Re: how to make a shell window be active after boot by default ?
|
|
Home away from home 
|
@joerg
Thanks! That did the trick, in my case 6 + were enough.
|
|
|
|
|
|
how to make a shell window be active after boot by default ?
|
|
Home away from home
|
@All
Have some user-kind issue annoy me a little bit : on the boot i load up lot of stuff automatically : dopus4, shell window, amidock, xdock, lots of commodities, etc.
So, once boot in progress, i see the workbench showed up it's face, then dopus4 and shell window runs, then amidock, xdock, commodities start to load up. And once everything loads up, i want my shell window to be active by default, without me needs to touch mouse when i want to type something in the shell window after boot.
Is there anything i can do in the system by saying it something like "once all loads up, make shell window to be active one" ?
ps. The shell window running from user-startup script, as the last entry in. All the other stuff, runs from the WBStartup.
|
|
|
|
|
|
Re: gcc 9 and 10
|
|
Home away from home
|
@Oliver Max did change new binutils a bit, so .rodata do have it's own segment now and marked as "R", so it looks like this now: test_dyn:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x01000034 0x01000034 0x000c0 0x000c0 R 0x4
INTERP 0x0000f4 0x010000f4 0x010000f4 0x00011 0x00011 R 0x1
[Requesting program interpreter: /usr/lib/ld.so.1]
LOAD 0x000000 0x01000000 0x01000000 0x050b0 0x050b0 R E 0x10000
LOAD 0x015000 0x01005000 0x01005000 0x000a5 0x000a5 R 0x10000
LOAD 0x0150b0 0x010150b0 0x010150b0 0x000d8 0x00130 RW 0x10000
DYNAMIC 0x0150c0 0x010150c0 0x010150c0 0x000b8 0x000b8 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .hash .dynsym .dynstr .rela.bss .rela.plt .text .plt .__newlib_version
03 .rodata
04 .ctors .dtors .dynamic .data .got .sbss .bss
05 .dynamic
libf.so:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x10000000 0x10000000 0x02034 0x02034 R E 0x10000
LOAD 0x012000 0x10002000 0x10002000 0x00031 0x00031 R 0x10000
LOAD 0x012034 0x10012034 0x10012034 0x000f8 0x000f8 RW 0x10000
DYNAMIC 0x012074 0x10012074 0x10012074 0x000a8 0x000a8 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .hash .dynsym .dynstr .rela.dyn .rela.got2 .rela.plt .text .plt
01 .rodata
02 .ctors .dtors .got2 .dynamic .data .got
03 .dynamic
And while it looks good, when i run the test case it simple crashes in libf.so:ctor() with "symbol unavailable". The differences which we have now in compare with adtools's binutils is __newlib_version in adtools were in the same area where .rodata was, but in our current case currently we keep it in the one where .text and .plt are. But can it be cause of crash ?
Edited by kas1e on 2023/9/18 10:43:39
|
|
|
|
|
|
Re: New EGL_Wrap library is OUT!!! with support GLEW and shaders...
|
|
Home away from home
|
@Huno I just unpacked new archive to my WORK: , going to directory with Examples, and start checking them by dbl-click on them : after run of any example, I do have in ENV: created a lot of LIBGL_*, and when exit from example they are still in ENV: For sake of tests I tried different examples, and in all cases the same happens. Checked also Doom3 : this one also have the same issue : lot's lib LIBGL_* created in ENV:, which disappear only after reboot. Quote:
Did you use the installation provided with the packaging?
I was under impression that just simple running of test cases with statically build egl_wrap into, shouldn't cause any issues and created those LIBGL_* in the ENV ? I mean, why it's doing this at all ? Maybe some old code left in library still ?
|
|
|
|
|
|
Re: New EGL_Wrap library is OUT!!! with support GLEW and shaders...
|
|
Home away from home
|
@Huno
I tested the demos coming with EGL Wrap, and find out, that they do create "LIBGL_*" envs in the ENV: directory and after exit from test apps, didn't delete them.
Of course after reboot they gone, but it still mean, that if anyone will run any EGL_Wrap stuff, then, he will be forced to have again the same problem as we discuss before : EGL_Wrap's LIBGL_* in the ENV:, and reboot will be need it.
I also checked the new prefs : yes, this one create LIBGL_* envs in the Env-Archive/EGL_Wrap/ directory, but still, strangely, all the test cases included in the release of EGL_wrap, do create LIBGL_* in the main ENV: directory , and after exit didn't clean them :( While it is expected they do not create any LIBGL_* in env, but instead use the ones from env:EGL_Wrap, right ?
If so, then looks like bug which need to be fixed or by deleting all env:LIBGL_* after any EGL_Wrap app exit, or, which should be better imho is to not create in ENV: any LIBGL_* but instead use only ones from env:EGL_Wrap ?
|
|
|
|
|
|
Re: New EGL_Wrap library is OUT!!! with support GLEW and shaders...
|
|
Home away from home
|
@Huno
Cool, thanks for explain
Downloaded, will play with :)
Btw, if i will update EGL wrapper in the current doom3 , it will automatically work ? Or, there needs for new version of doom3 to take advantages of new egl_wrap ?
|
|
|
|
|
|
Re: New EGL_Wrap library is OUT!!! with support GLEW and shaders...
|
|
Home away from home
|
@Huno Cool ! The only problem i have right from the reading a readme is : Quote:
Other games using the GL4es library can take advantage of my Prefs GUI, use a GL4es part on GUI and enjoy!!
Is it mean, that it will globally change envarcs of gl4es ? I mean, all my gl4es ports are tweaked to be as i need them to be (and that include internal change of LIBGL_* envarcs), so if somebody do play with your new prefs GUI for GL4ES, permanently save gl4es options, and then we may have issues with some stuff when report bugs will be a cause of different LIBGL_* envs .. Or i miss the point, and your prefs will change only GL4ES envs for games compiled with EGL_wrap library in special ENV:EGL/ directory and not global LIBGL_* envs, so old GL4ES without usage of EGL_Wrap will still be ok ?
Edited by kas1e on 2023/9/17 12:16:54
|
|
|
|
|
|
Re: have you seen this?
|
|
Home away from home
|
@Joerg
Interesting, my more or less modern notebook and the webgl version for, manage “just” 300–400 fps in first level.
|
|
|
|
|
|
Re: have you seen this?
|
|
Home away from home
|
@geennaam Quote:
Afteral, the pc version manages >2000fps.
With same RadeonRX ? Then our one should have 500 at least :)
|
|
|
|
|
|
Re: have you seen this?
|
Posted on: 9/14 12:03
#10
|
Home away from home
|
@Huno Quote:
I don't think it's beneficial for other systems because it remains native to AOS4 and what's more it's very proprietary, especially for the egl_wrap part. My library will be available this weekend and you can have fun with it and do benchmarks if you wish, more than 4 years of development and additions of all kinds to have an all-in-one library (which continues to be improved)
Will be very interesting to test, that for sure :) Btw, the new version will help to gain some more fps in doom3 as well ?
|
|
|
|
|
|
Re: have you seen this?
|
Posted on: 9/14 11:53
#11
|
Home away from home
|
@Huno Quote:
When I am in egl_wrapper I go directly via ogles2 with proprietary internal shaders
As so, that explain it then. It just means not original gl4es, but a modified .. Maybe worth to update original gl4es with such changes as well ? All other gl4es builds can benefits from then
|
|
|
|
|
|
Re: have you seen this?
|
Posted on: 9/14 11:35
#12
|
Home away from home
|
@Huno Did i understand right what you say , that when you compile with GL4ES you have 30 FPS, but when you compile with EGL_Wrapper on top of GL4ES you have 90 FPS ? Quote:
because the version compiled at the very beginning of the thread runs at 30fps with gl4es I run at 90fps with egl_wrap in wrapper GL
The only reason why it can be faster with your additional layers, is that you hardcore change GL4ES for your own use, so to reduce functionality or something in favor of better speed, that correct ? Quote:
My legacy build use Glew by choice
What i mean, that Glew it's additional layer on top of all other layers. And this can make things behave different. If you say, that pure GL4ES build with Legacy code give 30 FPS, and your build with GL4ES integrated with EGL_Wrap and Glew give 90 FPS, it only means that or you don't go Legacy route in the game, or, that you change the GL4ES itself for your own use via customizing internal shaders gl4es build or/and via reducing functionality/quality. I mean, if you use something, and have 30 fps, and then add on top of it 2 more layers, and it gives you 90 fps, then it means that our you change gl4es, or you go another code-route for handle GL in the game.
|
|
|
|
|
|
Re: have you seen this?
|
Posted on: 9/14 10:58
#13
|
Home away from home
|
@Huno
Can't download from wetransfer sadly, but why there need for glew and egl_wrap in there ? I mean, why not just gl4es ? More layers can cause issues as well, for legacy build there no needs not for glew, not for egl
|
|
|
|
|
|
Re: have you seen this?
|
|
Home away from home
|
@Huno Quote:
When we use gl4es we are lower than with glew + egl_wrap, as you say a simple game but what you forgot… is that it is a game coded for Windows or Linux initially, our system requires some additional optimizations and we would surely have to rewrite some parts of the game to be able to gain a few frames per second. Then we use wrappers, which is a little more greedy too so there are still some lost images. Natively (shaders) we are at the top and the game is running at full speed.
I can understand it with Doom3, but not with Wipeout which works even on old classic amigas and radeon9250 on 60 FPS with no problems. Re-written code can acts worse of corse, but not _that_ bad.. Also, if we check MorphOS's thread, with this WipeOUT rewrite they do have: Quote:
between 100-60 fps (closed spaces vs wider scenery) on fullscreen 1280x1024 @ 24bit on a PMAC 1.4GHz 256MB Vram 9800Pro AGP 2x. It's ultra smooth, to say the least, amazing! Old version resulted to system freeze after quitting but latest one is bug free.
So i not sure how with RadeonRX geennaam had 30-50 fps.. Quote:
On version pure shaders i have 140fps on my X5000
Did geennnaam test some other version, and not the correct one with shaders where you had 140 fps ?
|
|
|
|
|
|
Re: gcc 9 and 10
|
|
Home away from home
|
@Oliver
While you at it (thanks a bunch!) can you please also check if adding of fini/init arrays support by Alfkil expected to be working ? When we tryied some time ago to build new binutils with it's support, it was still forced to dtors/ctors, and reading comments of the commit to elf.library where alfkil add it, it were marked as "untested", so we not sure if it should works or not :)
|
|
|
|
|
|
Re: have you seen this?
|
|
Home away from home
|
@All
Can anybody explain what going on wrong there, and why is such a low fps with such a simple game we do have now ?
Is it because we compiled it now with not pure gl4es, but glew+egl_wrap going some other than casual gl4es route ?
And how issues with alignment disappear magically ?:)
|
|
|
|
|
|
Re: have you seen this?
|
|
Home away from home
|
@geennaam
Something very wrong somewhere. It was 60 fps always even old warpos version of wipeout over novabridge. Over gl4es it should be MUCH faster. Seems some debug libraries used somewhere, or something involved are cause of massive slowness.
@Sinan
Seems you use something which together with fixing textures for you add very big overhead in terms of speed. Are you use some other libraries ftom sonewhere or debug versions of libraries ?
|
|
|
|
|
|
Re: have you seen this?
|
Posted on: 9/12 10:27
#19
|
Home away from home
|
@smarksugs
Emulation can easily deal with alignment issues by default.. But again, maybe G3/G4 and os4 kernel for peg2 are same forgiving for as x1000's cpu. I can check that all on all x1000,x5000,sam460,peg2 and winuae
|
|
|
|
|
|
Re: have you seen this?
|
|
Home away from home
|
@smarkusg
You test on real g3/g4 or emulated ones ? And with what os ?
And yes, fixing it on kernel level will make it slower in compare with original code fixes, but not sure if -that- slow to be noticed.
@Sinan
If textures works fine on x1000, then yes, if no, then no
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TuneNet forum
Unsatisfactory Software forum
