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 outI compiled Windows build of opendrakan and got some really funky results. The engine crashed in Engine.cpp, line 56:
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!
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.Got it when hitting one of the stats key (F1 or F2). Guess another dependency is needed?
It should. However, until recently we were overriding that variable to "Debug" no matter whether the user set it or not. That is fixed nowBTW, 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?
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.
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 newsWunderbar! 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).
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.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.
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
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.
I already created an issue on GitHub for that, so feel free to comment. I would be very grateful
Something that just came to mind, Drakan has some weird bugs tied to frame-rate.
Oh, and UI scaling is a must feature.
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.
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.
All transforms deselected: 00 00 FF FF FF FF 00 00 00 00 00 00 FF FF FF FF
Rot. L: _________________ FF FF FF FF 00 00 00 00 00 00 FF FF FF FF 00 00
Rot. R: _________________ 00 00 00 00 FF FF FF FF FF FF 00 00 00 00 FF FF
Flip H: __________________ FF FF 00 00 00 00 FF FF 00 00 00 00 FF FF FF FF
Flip V: __________________ 00 00 FF FF FF FF 00 00 FF FF FF FF 00 00 00 00
Flip H+V: ________________ FF FF 00 00 00 00 FF FF FF FF FF FF 00 00 00 00
I tried making some sense of this, but I don't know anything about how the texturing is handled by the engine, so I was unable to reach any meaningful conclusion here.
MOV EBX,DWORD PTR DS:
MOV EBX,DWORD PTR DS:[EBX+1AC]
MOV EBX,DWORD PTR DS:[EBX+4E] ; In the struct that EBX now points to, the # of connected players is stored at [EBX+8]
MOV EBX,DWORD PTR DS:[EBX] ; EBX now contains the pointer to the server's struct (dedicated server = "fake" 1st player)
Users browsing this forum: No registered users and 1 guest