OpenDrakan ~ A Drakan engine recreation

Anything to do with Drakan level editing and modifications, post it here! Also this is the place to tell us about your new levels and get player feedback.

Moderators: Mechanist, Arokhs Twin, yangez93

HeckFluff
Whelp
Posts: 24
Joined: Sat Oct 14, 2017 12:47 am
Location: England

Re: OpenDrakan ~ A Drakan engine recreation

Postby HeckFluff » Fri Apr 13, 2018 5:53 pm

With Bullet, you'll probably have some "fun" using its built-in character controller. Unless they've improved it, you'll probably want to build your own. Such a character controller could also be used for other simple physics, like those health potions, if you don't want them to rotate or have much interaction with dynamic rigid bodies.

UCyborg
Dragon
Posts: 350
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: OpenDrakan ~ A Drakan engine recreation

Postby UCyborg » Thu May 24, 2018 1:51 pm

I compiled Windows build of opendrakan and got some really funky results. The engine crashed in Engine.cpp, line 56:

mViewer->getCamera()->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(true);

I had to disable my secondary monitor to get past that line (OSG bug?). Then the level loaded (went with Wartok Canyons for the screenshot) and things got super weird, solid colored polygons everywhere! :shock:

Image

There's also this:

Error reading file C:\Windows\Fonts\arial.ttf: read error (Could not find plugin to read objects from file "C:\Windows\Fonts\arial.ttf".)

Got it when hitting one of the stats key (F1 or F2). Guess another dependency is needed?

I installed MSYS2, updated installation with pacman, installed needed software (CMake, MinGW, needed libraries) and instructed CMake to generate MinGW Makefiles. I used this guide as a reference to overcome some of the MSYS specific quirks, but other than that, it was only slightly more difficult than compiling it on fresh Ubuntu 18.04 installation.

Ubuntu repositories have the older OSG 3.4.0 while the newest is 3.6.0. I wasn't aware of the F1 and F2 keys when I tried it on Ubuntu, so didn't see that in action there.

Anyone has any thoughts regarding my observations?

BTW, shouldn't passing -DCMAKE_BUILD_TYPE=Release to CMake result in generated build files to pass the parameters telling compiler to optimize the final executable?

PS: Drakan now runs pretty smooth on Linux via WINE when using both dgVoodoo2 (with d3dcompiler_47.dll) and DXVK.

Image
Image
Image
Image
Image
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

Zalasus
Whelp
Posts: 11
Joined: Mon Jan 29, 2018 6:50 pm
Location: Germany

Re: OpenDrakan ~ A Drakan engine recreation

Postby Zalasus » Sat Jun 02, 2018 12:59 pm

I compiled Windows build of opendrakan and got some really funky results. The engine crashed in Engine.cpp, line 56:

mViewer->getCamera()->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(true);

I had to disable my secondary monitor to get past that line (OSG bug?). Then the level loaded (went with Wartok Canyons for the screenshot) and things got super weird, solid colored polygons everywhere! :shock:
That's a really funky result indeed. The fact that things are colored at all and Rynn has a pose means that shaders are working. I think this requires a deeper investigation. Thanks for pointing that out :D
Also, I admire your patience to compile the engine on Windows. I had given up on that rather quickly, but I guess I should try again sometime. Up until now, I wasn't sure whether the engine would run on Windows at all.

UPDATE: I added a commit recently that might address the problems you faced. See the issue on Github.

Got it when hitting one of the stats key (F1 or F2). Guess another dependency is needed?
The rendering stats (F1) are broken on Linux, too, and have been for quite some time. OSG's stats handler doesn't mix well with shaders it seems. Another thing that needs fixing.

BTW, shouldn't passing -DCMAKE_BUILD_TYPE=Release to CMake result in generated build files to pass the parameters telling compiler to optimize the final executable?
It should. However, until recently we were overriding that variable to "Debug" no matter whether the user set it or not. That is fixed now ;)

UCyborg
Dragon
Posts: 350
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: OpenDrakan ~ A Drakan engine recreation

Postby UCyborg » Tue Jun 05, 2018 12:40 am

All is well now! The engine actually creates 2 windows, one for each monitor, with the primary one in exclusive mode. Which looks kinda weird if you don't have 2 identical monitors, but I guess that can be tackled later when settings are added.

Also, I admire your patience to compile the engine on Windows. I had given up on that rather quickly, but I guess I should try again sometime. Up until now, I wasn't sure whether the engine would run on Windows at all.

Thanks, it was surprisingly smooth process. I would say cross-platform nature of the engine helps a lot.

I forgot to ZIP the shaders with the engine binaries last time, so it wouldn't work properly if someone else downloaded it and gave it a go. They're included now.
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

UCyborg
Dragon
Posts: 350
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: OpenDrakan ~ A Drakan engine recreation

Postby UCyborg » Sun Jun 10, 2018 4:07 pm

Wunderbar! The performance is a non-issue in this engine, even when ignoring visibility data and having a level with too much crap in it. The second most problematic level in that regard (Paradise) runs at 119 FPS with uncapped frame-rate in worst case scenario on my end, while the original engine chokes at about 10 FPS. Just Atlantis runs only at 3 FPS, which should climb back to normal rates after after adding fog (since everything is rendered ATM).

And another unimplemented feature in the Riot Engine; demo recording. There's one string in Dragon.rfl that says "Finished Demo Playback". There were supposed to be two more key commands available; in Dragon.rrc, the strings with ID 0x4004 and 0x4005 say: "Record Demo" and "Play Demo". I knew about the string in Dragon.rfl, but the latter two are new to me.

Oh, and the GameSpy authentication key is also read from Dragon.rrc: string 0x2142.
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

Zalasus
Whelp
Posts: 11
Joined: Mon Jan 29, 2018 6:50 pm
Location: Germany

Re: OpenDrakan ~ A Drakan engine recreation

Postby Zalasus » Sun Jun 10, 2018 10:30 pm

Wunderbar! The performance is a non-issue in this engine, even when ignoring visibility data and having a level with too much crap in it. The second most problematic level in that regard (Paradise) runs at 119 FPS with uncapped frame-rate in worst case scenario on my end, while the original engine chokes at about 10 FPS. Just Atlantis runs only at 3 FPS, which should climb back to normal rates after after adding fog (since everything is rendered ATM).
Wow, that's incredible, given that OpenDrakan is only single-threaded yet. I'm sure the visibility calculations and multi-threading become more important when I add more intensive calculations like shadow mapping, but your results are nontheless great news :)

And another unimplemented feature in the Riot Engine; demo recording. There's one string in Dragon.rfl that says "Finished Demo Playback". There were supposed to be two more key commands available; in Dragon.rrc, the strings with ID 0x4004 and 0x4005 say: "Record Demo" and "Play Demo". I knew about the string in Dragon.rfl, but the latter two are new to me.

Oh, and the GameSpy authentication key is also read from Dragon.rrc: string 0x2142.
I'm sure those features are easily implemented. Quick googling brought up a few examples how to capture frames with OSG and encode them with ffmpeg.

That particular GameSpy string is not found in my Dragon.rrc (the german version), but there are others that look like a key for something.

May I ask you how you know the strings from the file? In my version, most strings are XOR encrypted with a key I could not determine in it's entirety yet. So either you know more than I do, or you version simply is not encrypted. Would be glad to know since some of those strings are important for the UI. I already created an issue on GitHub for that, so feel free to comment. I would be very grateful :D

UCyborg
Dragon
Posts: 350
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: OpenDrakan ~ A Drakan engine recreation

Postby UCyborg » Mon Jun 11, 2018 12:48 am

Wow, that's incredible, given that OpenDrakan is only single-threaded yet. I'm sure the visibility calculations and multi-threading become more important when I add more intensive calculations like shadow mapping, but your results are nontheless great news :)

For the record, the CPU is AMD Phenom II X4 920, clocked at 3,00 GHz from stock 2,80 GHz, year 2009, not exactly the speed demon, but it's from the era when AMD was getting better.

As for GPU, NVIDIA GeForce GTX 750 Ti, year 2014, its selling point being power-efficiency rather than performance. Though GPU doesn't have much work to do when running OpenDrakan.

I'm sure those features are easily implemented. Quick googling brought up a few examples how to capture frames with OSG and encode them with ffmpeg.

They'd be nice indeed. But I think what Surreal actually meant with demo recording was Doom/Quake style demo recording, in which the engine just stores series of commands sent to the server from the client (in those engines, singleplayer mode runs a local server) in a very compact file. So you get "recording" which can be played-back in the engine in which it was created, or any engine that is compatible with the protocol. Quake Done Quickest speedrun compilation packed in Quake's PAK archive weights a little less than 14 MB and about a little less than 5 MB when zipped.

Of course, some developers of modern source ports then also add the ability to record the gameplay the "normal" way, that is recording the actual image, which is what you're referring to in your comment.

That particular GameSpy string is not found in my Dragon.rrc (the german version), but there are others that look like a key for something.

Oops, I made a typo, the actual string ID is 0x2412 and it says: zCt4De

May I ask you how you know the strings from the file?

Actually, for the GameSpy string, I suspected it must come from some file since the game seems to pull it out of nowhere. I first encountered it when debugging the server code that responds to queries.

In my version, most strings are XOR encrypted with a key I could not determine in it's entirety yet.

They're encrypted regardless of language it seems.

So either you know more than I do, or you version simply is not encrypted.

Just yesterday, I found the function in Drakan.exe in which the decryption takes place.

I already created an issue on GitHub for that, so feel free to comment. I would be very grateful :D

Already did! ;)
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

UCyborg
Dragon
Posts: 350
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: OpenDrakan ~ A Drakan engine recreation

Postby UCyborg » Tue Jun 19, 2018 5:01 pm

Something that just came to mind, Drakan has some weird bugs tied to frame-rate. Ideally, the new engine should be frame-rate independent. You don't want effects like flame on the Sword of Flame to just die when run on the shiny 144 Hz capable monitor.

Then we come to physics. Rynn can jump farther at higher frame rates. I guess the way it was meant to be played is how she jumps at 60 FPS. I also recall some odd behaviors when shooting NPCs with a bow with regular arrows. I didn't have debug messages on at the time, but it looked like the game behaved as if NPC was hit multiple times when hit once at particular spot, eg. the empty area between body and arms. I remember being able to gib a Scavenger at one point using a single arrow (with 10 damage) when he was still alive.

The most interesting bug related to frame-rate would be how much NPCs bleed. Things are consistently gorier at 20 FPS, although the same amount of blood can be observed under certain circumstances at saner frame rates. I wonder if the behavior you get at 20 FPS is the way it was meant to be.

Oh, and UI scaling is a must feature. Drakan's UI is practically useless at high resolution on a dense display. Size of lens flares are also dependent on the resolution.
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim

Zalasus
Whelp
Posts: 11
Joined: Mon Jan 29, 2018 6:50 pm
Location: Germany

Re: OpenDrakan ~ A Drakan engine recreation

Postby Zalasus » Tue Jun 19, 2018 10:20 pm

Something that just came to mind, Drakan has some weird bugs tied to frame-rate.

Ah yes, that old chestnut. Quite a few games had this issue back in the day. How you could program things to be dependent on FPS on purpose is beyond me, so this must have been due to the inexperienced Surreal programmers or simply due to them cutting corners.

At least that is something I don't have to worry about in OpenDrakan. Everything I have written up until now is synchronized with real time. The update hooks in the new engine provide absolute time and the time passed since the last update, so it should be no problem to write things properly. The gore and flame stuff is most likely due to some quirk in the particle system, but that's another thing I (or a contributor~ fingers crossed) will have to figure out someday.


Oh, and UI scaling is a must feature.

That's actually the thing I have been toying around with lately. What bothers me is the fact that the UI textures are relatively small. The main menu is a texture with a relevant area of maybe 380*460px in total, which will look either pixelated or soft when scaled up to fit a modern screen.

But even worse, the bitmap font used by Drakan has glyphs 17px high, which is definitely too small for any modern screen. The obvious solution is to ditch the bitmap font and use a vector font instead, but unless I can get my hands on the original font they used to make the bitmap, that would be really unauthentic.

What do you think? I thought I'd add an option to scale up the UI, but map it 1:1 to screen pixels by default. The latter would be called 100% scale and for anything above that you'd just have to live with a pixelated or fuzzy UI.

UCyborg
Dragon
Posts: 350
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: OpenDrakan ~ A Drakan engine recreation

Postby UCyborg » Wed Jun 20, 2018 12:56 am

What do you think? I thought I'd add an option to scale up the UI, but map it 1:1 to screen pixels by default. The latter would be called 100% scale and for anything above that you'd just have to live with a pixelated or fuzzy UI.

Sounds good. You can't do much else from the engine's standpoint anyway. Ideally, someone would make higher resolution textures for UI.

If I use 1280x720 as a base resolution and set dgVoodoo to upscale it to my monitor's native resolution 1920x1080, things are already fuzzy. Upscaling to 3840x2160 and letting the driver downscale it (NVIDIA Dynamic Super Resolution) smooths it out and it does look relatively good considering low-res nature of the original resources.

No idea how it would look on an actual 4K screen...

The obvious solution is to ditch the bitmap font and use a vector font instead, but unless I can get my hands on the original font they used to make the bitmap, that would be really unauthentic.

You're right. So for now, there are only 2 options; use original bitmap font which is pain to read, or another vector based font that isn't very Drakanish.
"Once a profound truth has been seen, it cannot be 'unseen'. There's no 'going back' to the person you were. Even if such a possibility did exist... why would you want to?" - Dave Sim


Return to “Drakan Level Editing and Game Mods”

Who is online

Users browsing this forum: No registered users and 1 guest

cron