ps. Btw, i think that will be cool add to UAE source, some little piece of code, which will read options like "name_of_window="xxxx" And for example, we can write for every game name_of_window=slamtilt (For example), and window will have SlamTilt word (what is very nice in end for visual jerking :) )

I tryed also put that .no_centralized_system dummy file, but that make no difference .. (i have for icons: S:glUAE_LA only).

I mostly think about speed on EUAE side. From the OS4 side EUAE itself brings in a half of second, so there is no problems related to your scripts of course :)

All in all, thanks for help :) I already done 5 games by this way, and they all works fine. Cool.

Strange that you not use WHDLoad for yourself , because its totally different by speed. For example, for running SuperStardustAGA from ADF/DMS even with 800% of floppy speed, up to 2-3 minuts to reall start to play in game. But with whdload i think its no more than 30 seconds (that include loading of intro, menu, and later game itself).

ps. Tryed also to run many games at the same time, just run SlamTiltAGA, then SuperStardustAGA. And gluae handle all fine. Check that screenshot of gluae in action on my setup :)

Ok, i managed to work that whdload stuff ! For now it looks at last as i want: i just go by filler to any directory, then "open wb window", then have SlamTilitAGA icon, press on it twice, and have req: execute of file. Ok, and just black window brings, and after 15 seconds i have fully loaded and playable SlamTilitAGA.

The only think which will be cool to do its somehow remove that header from window mode (where typed name of window, winuae 0.8.28). Just to have plain window wihtout thinking that its uae.

And what i want to ask: If i unpack all my games on my work SFS parition, and if, all that S/DEVS/C also on the SFS parition, did it mean, that e-uae will read it faster, or, it will just emulate it like it old FFS or kind ?

Why i ask about, i just want speedup loading of those whdload demos/games as fast as possible. Or its fully referers to emulation speed for now ?

Ps. related to centralized system looks like it will not helps, because running of the game binary, are done in the startup-sequnce, so for all the new game/demo new startup-sequnce. What mean in any case new i need create S: dir, so then no problems create also DEVS and C :)

But still in interest: it is possible by some binary on os3.1, run icon from shell ? I mean:
amiga shell:> some_binary blbalalb.info

and then os3 will read all the tooltypes from info, and do exectaly the same, what happenes when user do double-click on that .info ?

Btw, can i setup by your glUAE running of all my whdload games by dbl-click ? (without need to start from hardfile, and press double-click on it ?) Right now i reading your docs related to glUAE, but just want to be sure that is possible :) Will be cool just dbl click on icon, and have window or full-screen game which runs very fast because of whdload.

And if it can works, will it works with latest e-uae with gui ?

(i think need add some kind of options to switch gui off in some scripts)

Yep, that is what i use for KidChaos and Aladdin (in the first post i put also these 2 320x256 configs).

KidChaos in that case works very smooth and feels fast and nice, but Aladdin are not. Right now, i tryed all what you point + i also set music to Mono, and that what i have:

Aladdin AGA video on e-uae 320x256/mono on peg2/1ghz.

It more or less playable for now, but you can see how music slows a bit, and graphics itself too. Imho there is just 1ghz is not enough for. Even 1.2ghz i think will emulate Aladdin with current settings just fine/fast/smooth (imho).

Maybe you have any other ideas about how speedup it ? Maybe some nasty flags for the chipset settings, or maybe add/reduce RAM or kind .. (just to give euae more power to emulate only necessary stuff).

This is interesting, since this was something I used earlier for creating script applications within a drawer. Somewhere along the upgrades of 3.5 and 3.9 though, this stopped working, Workbench would treat an icon of a drawer as a drawer type icon, even when it was set as type "project". I assumed this was an "bugfix", but it has annoyed me. Seeing that this is possible in OS4 makes me wonder though, maybe it wasnt an intended "fix".

It might be more system friendly to write-protect the AppDir directory by clearing the "write bit" with the C:protect command or Dopus4 protect button. That way the system will be able to copy the ENVARC:AppDir (although empty) directory to ENV: at boot time instead of encountering an invalid link. Just be sure to delete the AppDir files before write-protecting it.

Well, the mechanism is there, it's not that hard if
you think about it, the server needs a -->DIRECTORY<--
called ENVAR:AppDir to be able to create the cache files
inside it, if the server can't find a directory of
that name on bootup then the server process simply exits
politely.

If you havn't started a program even once in 6 months,
it's probably safe to say that you don't use it anymore.

As far as entries with a bad path, they get flushed at
every amiga day number that is a modulus of 31.

I read it, it's rather pointed and uninformed,

plus, I really can't believe you would be so reckless
as to create scripts to manupilate the path cache
and upload it to the public already,

I will take a moment to mention a couple of things
for what it's worth, I usually don't get involved
on these forums, but this is an exception,
whether it's of any use or not, I really don't care.

The APPDIR: server runs at a priority of -99
it does not affect normal operations, it operates
asyncronously from the load process, so it does not
cause any waits for the loader process, load events are sent as messages to the server for it to service
when not much else is happening,

besides, it only logs
the path of applications when their data changes,
not every time they are loadsegged.

The reason there are some extraneous files in the cache
is because something other than ramlib LoadSeg()'ed them,
this may be as simple as running the 'version' command
over it, but whatever loaded it, it gets added to the
cache when it's not loaded by ramlib.

The "hex" comment on the files in the cache are a quick 32 bit
hashing value of the path string inside, the other
number is the week number the last time it was used,
this is so the APPDIR server can automatically flush
dead entries after 6 months of no access, so dead
entries won't build up.

I should take this opportunity to also mention that if
the cache is disabled, you're going to need a large
bucket of luck getting any of the pre-configured
software to work.

None of the new URL: device settings will work,
a bunch of extras on the CD won't either,
nor will future automated update software work or
anything that may use an installer script looking for
the path of your application with; $(appdir/<application>)

Nevertheless, I understand it's your machine and you
can cripple it anyway you see fit.

Looks like none of the beta testers ever turn
the Assign-Mount switch off.

Title bar now fixed for a later update.....

Good grief, why exactly would you want to disable APPDIR:
it would have to be the single most usefull DOS feature
since PROGDIR: and CURRDIR: were created.