DevilutionX - Diablo 1

Unfortunately, the save game load not work.

@kas1e
Thanks it works really well.
I tried the SDL 1 version

@mufa
Quote:
Probably they still didn't implement it? Is it works on win32, or/and on 68k? I read on morphzone where they tried WOS version, that save/load didn't work for them too.

@White
Quote:

Why not SDL2 ?:) It's better handled by the game (sdl2 is the original, and sdl1 was added as some fallback if I understand things right, with limited functionality in some parts)

@kas1e
I use winuae amigaos4.1 Final Edition update1
sdl 2 seems not to work, the music is heard but the screen remains black.
I think it's normal, (I think)
here the full screen SDL 1 version, and also in the window.

https://www.youtube.com/watch?v=G-Jo02QvYDg

@White
Ah, winuae.. It can be any kind of issues of course. But of course, it's not normal that you have a black screen in the sdl2 version.

@white
Perhaps related to lack of Compositing in WinUAE: give a try to my aminet patchcompositetags

This version will work?
https://www.gog.com/game/diablo

@kas1e
I'm aware of this, but it works and I'm happy, thanks!
The SDL 2 version with PatchCompositeTags now also works.
I have no real hardware, but amiga has always remained in my heart

@thellier
Thanks for the tips and your patch now works SDL 2

https://www.youtube.com/watch?v=veCLQoNvC1s

@walkero

Works, yes.

Playing a bit now but feels a bit slow for a 1.8 GHz Machine. Got 80 FPS @ 100% CPU Load with SDL2 and 40 FPS @ 40% CPU Load with SDL1.

I guess thats SDL why it performs so slow? I mean its playable but just thinking, the Original was designed for a Pentium 60.

@DJBase
I am sure it's not SDL guilty, as our SDL matured enough and it almost all "native" inside. Some things do pretty decent FPS. Currently what is left from SDL its name of functions, with amigaos4 native stuff inside :)

I think it can be anything else. Need to check how much it gives on current PC hardware, then on sam460, on pegasos2, to check how much it gives on real 68060, on a vampire, on morphos (the run WOS version), etc, etc. I somehow think it just codes of that rewrite done as it has done.

But to add, for both version I didn't use 8-bit screens, I use 16 and 32 bits, maybe that a bit reduce speed. But still, it can't drop by fps that much because of it.

Not sure if we need to worry and spend our time on it, maybe once loading/save will be implemented... But then 80 fps more than enough.

If you have time, check on other hardware (and on PC too, they probably provide win32 binaries), so we will know truth.

Well, seems that -f flag does not work on Windows version but "Save Game" does...

@DJBase
I.e. loading/saving works on win32 version? Mean it's our endian agnostic fixes didn't deal with that. Need to ask Marlon on main repo tickets, or maybe he somewhere else on facebook or something..

@kas1e

>Need to check how much it gives on current PC hardware, >then on sam460, on pegasos2, to check how much it gives on >real 68060, on a vampire, on morphos (the run WOS ?>version), etc, etc. I somehow think it just codes of that >rewrite done as it has done.


On a1k.org are some benchmarks for the Vampire:

54fps for the Vampire

https://www.a1k.org/forum/index.php?th ... /#lg=post-1344642&slide=0

@benny
How fast vampires's cpu ? 200-300-400 mhz ?

I read that on x5000 ppls have about 140 fps with SDL2 version. If Vampire are about 400mhz it can be fine then.

@kas1e

85Mhz

@benny

I see in code of that port, it is ifdefs about a vampire, so maybe something there. Also, they use an 8bit screen, while I set 16/32, so probably that as well.

@all
Is there anyone who can test it on different PCs, so we can know how much they have as well? Not that it's important, just interesting :)

@kas1e

Both binaries have serial debug on, I think it slows down at least the SDL1 version because there are mouse events logged.

Regarding SDL2, what happens if texture format is changed to ARGB8888? See this line:

https://github.com/diasurgical/devilut ... ceX/miniwin/misc.cpp#L169

ARGB8888 the only one supported by renderer so using that should avoid one conversion step. If I understand correctly:

1) engine uses 8-bit surface to draw
2) which is then converted to 24-bit texture by engine
3) which is converted to 32-bit texture by SDL2
4) which is uploaded to VRAM (with or without DMA)

Finally there is a frame limiter: https://github.com/diasurgical/devilut ... 3b855/SourceX/dx.cpp#L257

Not sure if it's activating or not.

@Capehill
Oh, I build it with pure SDL (not GL4ES ones) of course, and those ones for tests were kept with debug output enabled, so of course it slow things down! That expects jerky movement in the SDL1 version in window mode.

@kas1e

1.0.0 has been released, and there seems to be a windows (and linux and mac) binary too: https://github.com/diasurgical/devilutionX/releases

So -f should be supported now.