DevilutionX - Diablo 1

@Capehill
Tested that new win32 version with "-f", it gives me 60fps on a modern PC. So it's VSYNC'ed. And I didn't find any options to disable it..

@kas1e

Yes, the engine asks for VSYNC and there is a bug in AmigaOS4 SDL2 because it didn't obey the request properly.

You can override VSYNC using https://wiki.libsdl.org/SDL_HINT_RENDE ... 29%7C%28CategoryHints%29:

setenv SDL_RENDER_VSYNC 1 to enable
setenv SDL_RENDER_VSYNC 0 to disable

@Capehill

Tried on win32: "set SDL_RENDER_VSYNC=0", and I have just 155 fps! That on ICore i5-7200U 2.71GHZ 2 core.

So.. Having 140 on our side, it's probably very very well.

@DJ-Base

So we know now, that its game has done that way, that even on modern PC it gives just 155 fps. Having 140 on our side is a pretty good result then.

In other words, all fine on our side :) Phew!

So we have 80 FPS on X1000 and 140 FPS on X5000

@DJBase
Taking into account that on modern enough PC it's 155, then have 140 on x5000 for sure fine.

But have 80 on X1000 feels like something strange. I expect it to have then at least 120-130. But maybe exactly in a case with that game, faster memory speed and some other crap make the differences.

Did you know if on other x1000 it gives the same 80 fps with sdl2 version (and with the same diablo.ini)?

But the main point there despite the bigger than expected difference between x1000 and x5000 is that the whole project didn't coded very well in terms of speed.

@All
So once load/save games will be done, that probably will be the same for release, and not now. I read on some forum that Artur sais that he now will concentrate on load/save things to make it works.

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

@kas1e

My i5-windows desktop gives way more FPS, ~1000. But it of course has drivers optimized by millions of dollars, multi-core and probably SDL also uses SIMD accelerations that help with bitmap conversions.

@Capehill
Wow, a strange difference too! My i5 its a notebook, but still good enough one.

@kas1e

When upscale is disabled (0) in diablo.ini and with frame limitter commented out in SDL2 version, FPS got to 190+.

It would be also interesting to test 8-bit screenmode. It should be possible at least with SDL1 but I didn't get that far in experiments.

@DJBase

How does one get the FPS?

@Nuder_Try
"-f" flag when running via the command line

@kas1e

Also getting about 80 FPS on an X1000

@Nuder_TRY
So for some reason x1000 pretty slower in compare with x5000 exactly in that test. Surprisingly, usually its about the same.

@kas1e

love to try on my X1000 too once I find my old Diablo CD somewhere in one of my mancaves

@kas1e

I have measured the display update parts on X5000 and roughly, surface conversion (CLUT -> ARGB) is 1 millisecond, then texture update and the rest take 4 milliseconds. Texture update is the slowest operation, it takes 3-4 milliseconds. Potentially future driver optimizations (DMA) will help here.

To clarify:

- 1 millisecond here: https://github.com/AmigaPorts/deviluti ... aster/SourceX/dx.cpp#L183

- 4 milliseconds here: https://github.com/AmigaPorts/deviluti ... aster/SourceX/dx.cpp#L247

All this talk about FPS. The original game was capped at 20-25 FPS. So having the game running at a stable 40 or 80 FPS shouldn't matter the least.

@kas1e if you have done any changes to make this work with OS4, please submit these changes in a PR so I can add it to the AmigaPorts repo. I am in talks with the official maintainers of DevilutionX to add our Amiga specific changes to the official repo, which means they will distribute official builds for AmigaOS 3.x, AmigaOS 4.x, WarpOS, MorphOS and AROS with every release.

Thank you

// Marlon Beijer
AmigaDev / AmigaPorts

@Marlon

Quote:

Imho for os4 its enough to build just SDL2 version, as really SDL2 version supported by DevolutionX better. So there changes i do (but which anyway fits also and in build SDL1 version).

1. In those files:

Source/diablo.h
SourceX/controls/devices/game_controller.h
SourceX/controls/devices/joystick.h
SourceX/storm/storm_dx.cpp


i add at top #include <cstdio>

(to avoid errors about non declared snprintf)

2. In the 3rdParty/Radon/Radon/source/key.cpp add at top:

#define _GLIBCXX_USE_C99_STDIO 1

(to make to_string() works)

3. evilutionx.dir/SourceX/dx.cpp have some bad for c++ stuff, on line 235, in the ifdef __amiga__ part : old_buffer = surface->pixels; , so need to add to build/cmakefiles/devolutionx.dir/flags.make : -fpermissive

4. in SourceX/dx.cpp i comment out all __AMIGA__ ifdefs (they to check if it 680800 / vamprire)

Also in SourceS/sdl_compat.h commeout out whole __AMIGA__ ifdef block.

Because if not, it bring errors on linking. Probably it can be just if __AMIGA__ and !__amigaos4__

5. In SourceX/storm/storm.cpp i had to modify GetPrefPath() to make all works with paths and stuff (that for SDL2 version, probabaly you didn't meet with it as build SDL1 version for os3):



And that all. I also had to change CMakeLists.txt a bit, but not sure if it worth mention as if all builds already for you then all fine.

Also if for automatic builds only SDL1 will be choicen (but better still SDL2 for os4), then there need some more changes (like, not use 8bit modes, because intro then broken visually).

@kas1e

80 FPS doesn't bother me, just the inability to save/load. :)

@kas1e


"char *path = "PROGDIR:"; "

should be:

"const char *path = "PROGDIR:"; "

"free(path); " try to free const string, that’s wrong.

unless you like to change

"char *path = "PROGDIR:"; "

to

"char *path = strdup("PROGDIR:"); "

but that does not make sense here.

@LiveForIt
Quote:

Its in your example with const will be "try to free const string", in my example it is not const.

But i think Marlon know how to add all correctly