Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
49 user(s) are online (28 user(s) are browsing Forums)

Members: 2
Guests: 47

Lio, sinisrus, more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 2 3 4 (5)


Re: DevilutionX - Diablo 1
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 942
@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(buffersize"%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


   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2776
@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.
   Report Go to top

Re: DevilutionX - Diablo 1
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 942
@kas1e

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

   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@LiveForIT
Oh right indeed, it was note from my first tests, that was the current code with workaround in end:

void GetPrefPath(char *buffersize_t size)
{
    
#ifdef __amigaos4__
    
snprintf(buffersize"%s""PROGDIR:");
    
#else
    
char *path SDL_GetPrefPath("diasurgical""devilution");
    if (
path == NULL) {
        
buffer[0] = '';
        return;
    }
    
snprintf(buffersize"%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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 942
@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).


   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2776
@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.
   Report Go to top

Re: DevilutionX - Diablo 1
Just can't stay away
Joined:
2009/5/1 17:57
From Czech Republic
Posts: 1106
@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?

_________________
Smoke me a kipper, I'll be back for breakfast!

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
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2006/11/20 16:26
From Norway
Posts: 2776
@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.
   Report Go to top

Re: DevilutionX - Diablo 1
Just popping in
Joined:
2006/11/27 20:35
From Poland
Posts: 146
In the 68k version, load / save already works. Maybe it's time for a new build for AOS 4?

   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2009/7/7 3:34
From Man Cave, Canada
Posts: 2362
@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
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

   Report Go to top

Re: DevilutionX - Diablo 1
Just popping in
Joined:
2010/10/14 17:05
Posts: 118
@328gts

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

   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2009/7/7 3:34
From Man Cave, Canada
Posts: 2362
@Nuder_Try

thanks that worked

@ DJBase

I'm getting 81 FPS with SDL2 version

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

   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2009/7/7 3:34
From Man Cave, Canada
Posts: 2362
@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
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 6074
@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!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: DevilutionX - Diablo 1
Home away from home
Joined:
2009/7/7 3:34
From Man Cave, Canada
Posts: 2362
@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
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga1000 & AmigaONE X1000 !
mancave-ramblings

   Report Go to top


« 1 2 3 4 (5)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project