DevilutionX - Diablo 1

	Bottom Previous Topic Next Topic
Register To Post

« 1 2 3 4 (5) 6 7 »

Capehill

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 10:30 #81

Just can't stay away

@kas1e

It seems that our SDL_GetPrefPath doesn't try to create the directory under ENV:. If that was fixed then this PROGDIR: workaround could be removed.

It's also true that in this case


char *path = "PROGDIR:";

snprintf(buffer, size, "%s", path);

free(path);

we shouldn't free the memory because we didn't allocate it with malloc. I think if you call this function twice, it will crash.

SDL_GetPrefPath is different because user is expected to free the memory returned by it: https://wiki.libsdl.org/SDL_GetPrefPath

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 11:06 #82

Home away from home

@Capehill

Quote:

It seems that our SDL_GetPrefPath doesn't try to create the directory under ENV:. If that was fixed then this PROGDIR: workaround could be removed.

Is it worth to create bugreport ?

Join us to improve dopus5!
AmigaOS4 on youtube

LiveForIt

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 12:10 #83

Home away from home

@kas1e

"PROGDIR:" is not allocated everytime you run the function, it allocated when the program starts, so you should not try to free "PROGDIR:".

Compile your code with -Wwrite-strings option and you should get a warning about your mistake from GCC.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Capehill

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 12:38 #84

Just can't stay away

@kas1e

Not needed, there is a branch for testing: https://github.com/AmigaPorts/SDL/tree/fix-getprefpath

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 18:38 #85

Home away from home

@LiveForIT
Oh right indeed, it was note from my first tests, that was the current code with workaround in end:


void GetPrefPath(char *buffer, size_t size)

{

    #ifdef __amigaos4__

    snprintf(buffer, size, "%s", "PROGDIR:");

    #else

    char *path = SDL_GetPrefPath("diasurgical", "devilution");

    if (path == NULL) {

        buffer[0] = '\0';

        return;

    }

    snprintf(buffer, size, "%s", path);

    SDL_free(path);

    #endif

}

@Capehill

Tested, seems it works, but not sure if it ok for amigaos4 and diablo in general. I mean, it will put the saves and the .ini (config) file to the "env:diasurgical/devilution" , which mean it all will die after reboot.

So, it should be at least in the prefs/env-archive if go that way, because SDL_getprefpath is "This is meant to be where the application can write personal files (Preferences and save games, etc.) that are specific to the application.", so something which survive reboot.

But again, is it worth for exactly Diablo to remove workaround ? Imho it better to have .ini file in the root of game somewhere ? It also somehow strange that with removed workaround it start to save to the env "single_0.sv.tmp" file on exit, instead of pure "single_0.sv", like, it didn't do something with removed workaround. As well as it stop to find some font file from unpacked data file. Recompiled with workaround back , and all works.

Join us to improve dopus5!
AmigaOS4 on youtube

Capehill

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 19:04 #86

Just can't stay away

@kas1e

Good point. I could change SDL_GetPrefPath() to use ENVARC: rather.

There is also SDL_GetBasePath(), which gets you the PROGDIR: path (and you have to free the string after use).

LiveForIt

Re: DevilutionX - Diablo 1

Posted on: 2020/1/12 23:44 #87

Home away from home

@Capehill

«ENVARC:» is bad idea because it uses RAM.
«ENVARC:» is bad becouse some times you might need to reinstall AmigaOS, then config is lost.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

trixie

Re: DevilutionX - Diablo 1

Posted on: 2020/1/13 7:21 #88

Amigans Defender

@LiveForIt

Application Library's PrefsObjects system uses ENV(ARC): by default, so it's pretty common to store configs there.

Quote:

«ENVARC:» is bad becouse some times you might need to reinstall AmigaOS, then config is lost.

That is a rather weak argument. Sensible people will make a backup before reinstalling the system or reformatting/repartitioning their disk. And surely it is easier to backup the entire ENVARC: than scuttle through all sorts of arcane places looking for stored configurations?

The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/13 11:27 #89

Home away from home

@liveforit
facepalm! ENVARC it's good idea, because:

@trixie
Quote:

Application Library's PrefsObjects system uses ENV(ARC): by default, so it's pretty common to store configs there

Of course! AmigaOS always use ENVs for store configs. Just lately it somehow wasn't considered, but ENVs in the first place were mean like "home directory" to store configs and stuff since beginning, just some prefer to use "S:" back in past for keys (for some reasons, dunno why). Even in our wiki we have:

Quote:

ENVARC:
ENVARC: is the name assigned to the directory SYS:Prefs/Env-Archive. ENVARC: always contains a Sys directory, in which each of the Preferences editors stores the .prefs file created when you save a setting with its Save gadget. Custom default icons created in IconEdit are also saved here. (Named settings saved with the Save As menu item in an Editor are stored by default in the Prefs/Presets drawer.)

Other Workbench programs that allow you to save configuration settings, such as MultiView, also place their files in ENVARC:

The contents of ENVARC: are copied to ENV: at boot time.

ENV:
ENV: is a cache that holds the working copy of ENVARC:. Since ENV:'s contents are memory-resident, accesses to its contents do not have to read the system disk. ENV: is an Assign, into which the contents of ENVARC: are copied when booting. Preferences settings activated with Save or Use gadgets are stored in ENV:. Global environment variables are also stored here, as small files.

In OS3.x and earlier, ENV: was assigned to a directory RAM:Env/, but in OS4, ENV: is a handler with its own storage, only accessible to the user through the ENV: assign.

Quote:

That is a rather weak argument.

Not only weak, but facepalm too, because it's like saying "hey, I have on my HDD some data somewhere, but it shouldn't be there, because I will reinstall the os" :) Like I do not know what and where will be when I do not know what and when will do :)

Join us to improve dopus5!
AmigaOS4 on youtube

LiveForIt

Re: DevilutionX - Diablo 1

Posted on: 2020/1/13 17:48 #90

Home away from home

@kas1e

There is also other advantages of using progdir: as you can have many installed version of the same program, etch has its own config file, so config is not mixed with etch program, you don't need to worry about wrong config file being loaded. for beta testers this can be useful. Imagine you have a incompatible .prefs maybe with new options need by one program but they do not exists in older version of the same program.

ENVARC: ENV: I consider system, its where the environment is, a tool or program is not the environment, it does not need to be there,

The part about ENVARC: being copied to ENV: if that done by handler or by a copy command in startup-sequence it make no difference, it takes RAM it does not need, after program exist not in use, there is no expunge system to remove .prefs from env: when they are not in use. so it basically a memory leak

another messed up issue is all the .info files in env:sys/ depending on size of your .info icons it take lot memory, I think this partly way AmigaOS4.1 classic has problems running on classic Amiga systems. Yes I know ELF files are large but they are tiny compared to all the space graphics needs.

Also backing up a program is easy, just copy drawer, don't need to worry what is in env: or envarc:, don't need to worry if there something in s: its in drawer, if its progdir:, admit it progdir: is cool, envarc: is not

Edited by LiveForIt on 2020/1/13 18:05:32

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

mufa

Re: DevilutionX - Diablo 1

Posted on: 2020/1/19 17:39 #91

Not too shy to talk

In the 68k version, load / save already works. Maybe it's time for a new build for AOS 4?

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/19 18:01 #92

Home away from home

@mufa
Is those changes about load/save on github ? I didn't see it there. Maybe that just some test 68k binary without putting source code online ? Or i just blind ? :)

EDIT: found, its in fix-save branch. Will build os4 binary then

Join us to improve dopus5!
AmigaOS4 on youtube

328gts

Re: DevilutionX - Diablo 1

Posted on: 2020/1/21 17:36 #93

Home away from home

@DJBase wrote:
"Currently nobody with an X1000 posted any FPS so far. I am not sure if my system is just f***** up or something"

Got it workign awesome full screen on my X1000 just now but how do I check FPS ???

@ all

anyone get save game working?

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

Nuder_Try

Re: DevilutionX - Diablo 1

Posted on: 2020/1/21 20:31 #94

Just popping in

@328gts

Run the game from shell with -f option. I asked the same question. :)

328gts

Re: DevilutionX - Diablo 1

Posted on: 2020/1/21 23:01 #95

Home away from home

@Nuder_Try

thanks that worked

@ DJBase

I'm getting 81 FPS with SDL2 version

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/22 10:38 #96

Home away from home

@328gts
The same as for DJBase then. Interesting how different there X1000 vs X5000. Usually its x1000 most of time faster when it come to some simple operations where graphics.library involved (because of DMA usage), but seems bottleneck there is not graphics operations but cpu/memory and stuff.

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/22 11:21 #97

Home away from home

@All
Tried to build that "save/load" branch, and it seriusly fucked.

It stop parse correctly diablo.ini : settings just like didn't taken in account. It also on running freezes most of time after intro stop, or may not freezes if i run in background snoopy for example. That mean some real memory trashing somewhere happens seems so.

Also sound most of time missing from intro too.

I may try to apply to previous working build the fixes Arhtur do for save/load, maybe that will fits well. Will check now.

EDIT: applied "save/load" changes on top of working previously version, and it is the same buggy now as with whole last build. Maybe it works on os3 because os3 more tolerant to bugs, but there surely something broken for now in save/load branch.

Edited by kas1e on 2020/1/22 11:43:43

Join us to improve dopus5!
AmigaOS4 on youtube

328gts

Re: DevilutionX - Diablo 1

Posted on: 2020/1/23 15:09 #98

Home away from home

@kas1e wrote:

Quote:

EDIT: applied "save/load" changes on top of working previously version, and it is the same buggy now as with whole last build. Maybe it works on os3 because os3 more tolerant to bugs, but there surely something broken for now in save/load branch.

you mean OS3 PPC right not 68k?

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

kas1e

Re: DevilutionX - Diablo 1

Posted on: 2020/1/23 15:32 #99

Home away from home

@328gts
Quote:

you mean OS3 PPC right not 68k?

I mean that mufa says in few posts above: "In the 68k version, load / save already works. Maybe it's time for a new build for AOS 4?". That mean that 68k version (not os3 ppc one) have working save/load. While 68k and ppc both big-endian, all should works the same everywhere. In practice as i say building save-load branch is unstable and crashy like omiga1200. I have a guess that if mufa says that 68k version work from the same code, then it only mean 68k more tolerate to bugs. Or, not all fixes about save/load in the repo at moment.

Join us to improve dopus5!
AmigaOS4 on youtube

328gts

Re: DevilutionX - Diablo 1

Posted on: 2020/1/23 18:55 #100

Home away from home

@kas1e

thanks for the explanation..I was only asking since if an OS3 version exists I'd like to try it on my 1200 with 060

_______________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

Register To Post	« 1 2 3 4 (5) 6 7 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )