Widescreen hack and some other fixes aka AiO Patch

Discuss Drakan: Order of the Flame with fellow players and post any technical problems here where an 'unofficial' support team will try and help you. Gameplay help questions can go here too.
UCyborg
Dragon
Posts: 433
Joined: Sun Jul 07, 2013 7:24 pm
Location: Slovenia

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

http://drakan.ru/445SP1.htm
viewtopic.php?f=4&t=2712&start=30 - see Drakon Rider's post

I forgot where opcode for stuck in block fix is, it just clears some flag in a specific code path (see Drakon Rider's posts).

The code cave for interval thing is at the end of Dragon.rfl code section. By default, it's only triggered when you load NoWhere level; intercepting a series of calls to some function and calls it 2 times with different parameters (a bunch of flags which probably only 1999 version of Tom Vykruta knows their meaning). That's all I know about those.

I updated the patch, now weapons can't be switched when mid-attack and when Rynn is stunned. Inventory also can't be open if Rynn is stunned (it is supposed to be used in the peaceful quiet spot, right?). Otherwise, you can cancel out the animation when Rynn falls over due to receiving significant amount of damage, so why have stun feature at all?

I also put the link to the previous version in the OP.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Thanks!

BTW, does this change also fix the "Rynn paralysis bug" - where pressing the inventory key in certain cases (eg. while Rynn is performing some animations) caused the inventory to not open anyway, but the controls still became unresponsive for a few seconds (about as long as it would normally take to open and immediately close the inventory)?
Or is that on unrelated one?

I was under the impression that the abovementioned bug was also caused by the engine failing to ignore the "inventory open/close" command in these cases where it should logically have no effect.

Unfortunately I don't remember any specifics about it, just that it tended to happen occasionally while I was trying to take a quick look at my inventory while running around like a headless chicken in multiplayer.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

That's unrelated bug I think. I don't remember experiencing inventory not opening, but from what I did experience, I think the issue is closing it at the wrong moment. Seems to have to do with animation handling or something; not releasing control to the player until animation was marked as finished. No idea how to fix, all I managed was to screw animations up. You can also make Rynn run while having inventory open, just tap forward key right after inventory key.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Hmm, I've downloaded the AiO patch source and tried compiling it.

After wasting several hours on getting Visual C++ 6.0 SP6 set up and running, already the first problem occurs: can't even open the damn files.

These files appear to have been saved in Linux (or some noncompliant Windows text editor), and so were all lacking the CRs from the CRLF EOLs.
Visual C++ took one look at that, determined that it's some incomprehensible gibberish, and didn't want any of it.
So I had to open each and every text file in Wordpad and save, to restore the missing CRs. Ok, so at least it opens now.

I hit "Build"... over 100 errors. Missing includes, since I didn't have the 2003 SDK.
Installed the 2003 SDK and added the missing includes... only 1 error left now, obviously due to missing the DirectX SDK.

Grabbed the DX6.1 SDK (presumably this is what Drakan was built with, too?). No errors now, just 4 warnings:
F:\DrakanAiOPatch\dllmain.c(1830) : warning C4047: 'function' : 'struct IDirectInputA *' differs in levels of indirection from 'struct IDirectInputA ** '
F:\DrakanAiOPatch\dllmain.c(1830) : warning C4024: 'PTR_DirectInputCreateA' : different types for formal and actual parameter 3
F:\DrakanAiOPatch\dllmain.c(1866) : warning C4047: 'function' : 'struct IDirectInputW *' differs in levels of indirection from 'struct IDirectInputW ** '
F:\DrakanAiOPatch\dllmain.c(1866) : warning C4024: 'PTR_DirectInputCreateW' : different types for formal and actual parameter 3
So... despite compiling "successfully" (???), the resulting dinput.dll is about 1KB larger than the one from the AiO patch 139 .zip - and of course completely, utterly fails to work.
When I try to run Drakan with it, all I get is "Unable to load the RFL!" (or whatever the exact wording was on that error message).

Any ideas, anyone?

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Got around implementing some small tweaks to the editing tools I had at the back of my mind:

  • Editing tools now remember 9 recently opened files (increased from 4 for Level Editor and from 6 for Modeler).
  • Level Editor: Memory warning that always showed when setting number of undo levels above 4 now only appears on machines with low amount of installed physical memory.
  • Level Editor: Default setting for undo levels has been increased to 20 (initial setting will still be 4 on machines with 64 MB or less memory).
  • Level Editor: Fixed the issue with message boxes related to undo setting popping up continuously if user closed the Level Properties dialog while undo number text box had keyboard focus.
  • Level Editor: Level Properties dialog now allows setting number of undo levels up to 1000 (previous maximum was 16).
  • Level Editor: Now remembers number of undo levels across sessions.
Download

Visual C++ 6.0 SP6

This one doesn't support inline assembly, you need Visual C++ 6.0 SP5 with Processor Pack.

These files appear to have been saved in Linux (or some noncompliant Windows text editor), and so were all lacking the CRs from the CRLF EOLs.

Use git to pull the code from the repo. Configure it properly first.

and of course completely, utterly fails to work

I don't push updated code to the repo immediately. So the revision that worked with files in AiO Patch 2.139 never saw GitHub. The current revision that works with 2.141 is up now. That message shows when Dragon.rfl fails to load, either missing or has different than expected checksum.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Wow, that was fast. Thanks for the help :)

Now the next issue is this:
I'd like to make some pretty significant additions to how some parts of the game work (in particular, add a simple text-chat-based voting system to the dedicated server).

I have a relatively solid idea of how to approach it from the coding standpoint, but there's another problem at play here.
It will do no good if I start changing Drakan.exe (or RFL) on my own, because then we won't be able to keep our changes in sync.

Ideally it would have to be done in such a way that it can be tacked on as an independent extension (maybe similarly to how your dinput.dll works?).
Any pointers you can give me as to how to approach this one?

BTW, I see that you insisted on one-upping my changes to the Editor :D

UCyborg wrote: initial setting will still be 4 on machines with 64 MB or less memory
Hmm, don't think there are any of those around anymore, outside of museums...

UCyborg wrote: Level Properties dialog now allows setting number of undo levels up to 1000
That was quite unwise, actually.

100 undo levels is already enough to strain a 32-bit application (the Editor) quite seriously when editing large maps.
In my testing, I got up to almost 1GB of allocated memory with 99 undo levels on a 512x512 map - but it only had one "layer of layers", and taken together they only occupied about 1/6th of the total available map area.

1000 undo levels is guaranteed to exceed the 2GB (or even 3GB) limit when working with maps of size 256x256 or bigger (or perhaps even less than that, depending on the number of layers, etc).

In any case, even my 99 undo levels are an absurdly, impractically large amount for typical Level Editor usage - especially since there's no such thing as "undo history" in it (and never will be).
I limited it to 99 for 2 reasons... one was that it kept the changes to the code to an absolute minimum, but the other reason was also because of the very real possibility of out-of-memory crashes.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

I'm actually insanely slow at putting these things together. I tend to obsess over small details.

I wasn't thinking straight when I put the 1000 limit for undo levels. I've read one of the Adobe programs has maximum limit at 1000. I didn't realize that memory usage may go up THAT fast as you've observed. When you think about it, besides the points you've already mentioned, memory fragmentation also comes to mind (who knows how good memory management works in there, plus the potential memory leaks) and let's not forget we can also work with much larger textures than it was originally allowed.

Forget yesterday's release happened, I've re-uploaded it. The limit is now at 50. Sounds saner to me than both 99 and 1000, all points considered. When you picked number 99, here's a hint: the error string is stored in the resource section of the executable, so it can be easily modified with Resource Hacker. 100 sounds nicer (I guess that's what you would have picked?). As for why I picked number 9 for file history list, the program does some in-place string manipulation so when the number of entry takes more than 1 character, code would have to be changed somehow to account for that.

Regarding memory warning change, I just thought that's how it would have been done back then. That editor is technically museum piece of software. :) I also like keeping things compatible with retro systems.

The idea of independent DLL extensions is a good one and is actually already common approach when it comes to multiple people patching the same game with different things. The old GTA games for example use Miles Sound System, the latter has the feature that it loads any DLL with an .asi extension. So the idea of general purpose ASI loader was born. For Drakan, you place ASI loader DLL in the game folder, call it dinput.dll, place AiO Patch's dinput.dll to scripts folder, rename it to something else, eg. DrakanAiOPatch.asi, add your own DLL with .asi extension in there too and voila! ASI loader can also load ASI files from game's root folder, depending on its configuration.

I haven't tried this yet for Drakan, but it should work.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

UCyborg wrote: memory fragmentation also comes to mind (who knows how good memory management works in there, plus the potential memory leaks)
In my testing with 99 undo levels, I haven't observed any problems: after the initial buildup, the memory usage remained quite steady, even when I would deliberately undo several times in a row then perform some other operations to refill the undo queue.
I then performed some significant, rough landscaping on a 256x256 map, and everything worked OK as well; again, no signs of memory leaks or other trouble.

UCyborg wrote: and let's not forget we can also work with much larger textures than it was originally allowed.
Interesting - since I expected that the texture data for each face is stored in memory by reference, not "by value"?
But good point; I haven't tried testing it with larger size textures. I just used the regular landscape textures from the Mountain/Tropical Common TD's.

UCyborg wrote:I also like keeping things compatible with retro systems.
Normally I'd be inclined to agree, but let's be realistic about this:
Noone is going to be running it on Win98 anymore, since there is no reason to do that (even on a VM) - as it runs OK on modern systems.
Then there is the problem that W98 doesn't support pretty much any modern USB device ever made, to say nothing of the other hardware (especially graphics hardware!).
Good luck putting a W98 system on the network too, what with no compatible and up-to-date AV/firewall software being available anymore for that OS.

Then there is another, far more trivial cause, at least as far as I'm concerned... the Community Patch installer isn't compatible with Win98/Me, due to the version of Inno Setup that it uses.

Which is actually for the best, since it avoids the potential problems that would be caused by people trying the (dangerous, pointless and outright foolish) approach of running Drakan in a Win98 or WinME VM.
Before you say that it's an irrelevant corner case... at least 1 or 2 people (newcomers) in our Discord chat have put forward exactly that idea; IIRC one even already tried that and complained it didn't work.
And no, they weren't the kind of people that have the technical know-how required to be able to actually make that work. In one of these cases, it was just the opposite in fact (couldn't even extract the contents of a .ZIP to the correct target folder).

So the way I see it is... if someone absolutely insists on running the Community Patched version of Drakan on a toaster for whatever reason and has the skills to accomplish that, then the Inno Setup Win98/ME incompatibility becomes a moot point anyway.
But for everyone else - I really don't want them to be attempting unwise things and then complaining that it doesn't work as intended.

UCyborg wrote: When you picked number 99, here's a hint: the error string is stored in the resource section of the executable, so it can be easily modified with Resource Hacker.
Nah, I just went for the quick and sure-fire approach of modifying the string with a hex editor. Which is why 99 and not 100.
I didn't do what you describe, because the Editor is already a very brittle piece of software, and as such I prefer to avoid making any changes that could potentially worsen things even further.

My initial thought was to set it to 255 or 250 (that was before I did the memory usage testing), but this would be more involved since the opcodes would have to be rearranged; setting it to 99 required only changing the argument in a single opcode.

I like to keep my changes to the absolute minimum that accomplish the task at hand.

Now this is an example from a different field - but a few times I've tried to improve some crap Chinese electronic device, only to end up making so many changes that very little (or nothing!) remained of the original device.
In the end it was invariably such a waste of time and resources that I would have been better off just leaving it as-is, or binning it right away and buying a proper quality product from a non-Chinese manufacturer.

So yeah... as much as the Editor could use a total rewriting, I'm sure as hell not one to even begin to attempt that.

Just fixing the (badly broken) .BMP import/conversion code will be quite a job in and of itself.


-------------------------------------------------------------------------------

Totally unrelated to the above:

This is something that I've only noticed around AiO build 135 or 136, but it's possible that it happened earlier and I just failed to notice.
Lens Flare Effects don't work. Again...

In one of the earlier builds, you fixed the LFEs to work even without dgVoodoo; I remember that because I tested it at the time and reported it works OK.

However since then, it seems that something happened that broke the LFEs.
Now they still work OK with dgVoodoo - but without it, strange and wonderful things happen.

When I have antialiasing forced to "on" in the Radeon Settings, the LFEs just don't appear, and there are no other negative effects.
But when I turn off the AA and anisotropic filtering, THIS happens...

Below is a screenshot of the location near the Poison Rune, while one of the lightning bolts happened to hit off-screen - and it was offscreen by a huge amount!
This kind of visual corruption affects the screen for exactly 1 frame when the lightning bolt hits, even if the entirety of the bolt is offscreen (eg. looking in the opposite direction from the Rune), as long as they're within the draw distance from the player.

Also, just to make things clear - the LFEs (the colored "circles" at the ends of lightning bolts) don't show up without dgVoodoo in any case, regardless of the AA settings in the graphics card control panel.
It's just that the corruption depicted doesn't happen for some odd reason when AA is set to forced.

(Not sure why the image is shifted downwards here. I took this screenshot with printscreen, but that works OK in all other cases. I'm pretty sure I didn't accidentally move it later when pasting it into Paint, either.)
Broken LFEs.png
Broken LFEs.png (344.11 KiB) Viewed 48067 times

I did some testing on this, and it seems to be related to upgrading the graphics card drivers:

With AiO patch update 5/21/2018 + older drivers, LFEs worked perfectly fine.
Same AiO version + new drivers = LFEs don't work without dgVoodoo, but there's no corruption, with or without antialiasing being forced via Radeon Settings.
AiO build 139 + new drivers = results as described above (visual corruption when AA not forced ON, no LFEs in any case).
(NOTE: this does not imply the graphical corruption problem began with 139. I don't have all the older versions archived. It's just that I can 100% confirm it for this particular release.)

I tried at least 2 different versions of the new Radeon drivers in the past few weeks, and both exhibit the same issue. Currently I'm on 18.4.1.


-------------------------------------------------------------------------------

EDIT: I've fixed the problem in the Editor that caused imported alpha maps to become scrambled in a very unusual way.

For reference, here's the changed code:
Alpha map import corruption fix.png
Alpha map import corruption fix.png (30.92 KiB) Viewed 48053 times
I'm currently working on some other fixes related to .BMP file import, so I'm not releasing the modified .EXE at this point yet.
In any case, I'll put the updated editor executable in the next Community Patch release :D

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

OK, when it comes to big textures, from what I remember when I did some experimenting a year ago, the spikes in memory usage were significant only when viewing them in databases. By significant, I mean multiple tens of megabytes which could quickly climb to a few hundred. I guess it depends also on the workflow. I will trust you on your experience with 99 undo levels. I put it to 100. I'll stop messing with this now.

At least for the patches I did, they're simple enough that you can't break compatibility with old systems. I agree it is counter-productive when it starts to take serious effort. I have to say though I never thought I'd see the .exe that is still targeted at and runs on Windows 9x systems while at the same time referencing d3d11.dll and dxgi.dll (Direct3D 11 Runtime and DirectX Graphics Infrastructure DLLs). I'm talking about Myth II: Soulblighter. Bungie gave its source code to some group of people, which disbanded back in 2003, but another group picked it up and maintains it to this day. VEG also mentions in his changelog for his Need for Speed III: Modern Patch adding separate Glide3x thrash driver for using on the real 3dfx Voodoo hardware. Amazing attention to details.

Which is actually for the best, since it avoids the potential problems that would be caused by people trying the (dangerous, pointless and outright foolish) approach of running Drakan in a Win98 or WinME VM.
Before you say that it's an irrelevant corner case... at least 1 or 2 people (newcomers) in our Discord chat have put forward exactly that idea; IIRC one even already tried that and complained it didn't work.

Ah, this is the kind of people that believe old games will run best on the operating system of the time in which they were developed. But when you have at least one person behind the game with the technical know-how, there's no fear that it won't run well and even better on modern systems. If issues related to sloppy coding are fixed, there shouldn't be any issues and newer hardware is only faster. Not to mention other helpful software we have today like dgVoodoo, DxWnd, Creative ALchemy, DDrawCompat, etc.

AFAIK, no virtualizer exists with support for 3D acceleration for Windows 9x guests. Even running games on a virtual machine with a newer OS leaves A LOT to be desired IMHO (performance-wise and the lack of seamless integration with host system). There are PC emulators that emulate Voodoo 2 card, which is again, really slow.

And no, they weren't the kind of people that have the technical know-how required to be able to actually make that work. In one of these cases, it was just the opposite in fact (couldn't even extract the contents of a .ZIP to the correct target folder).

Yup, Win9x in 2018 is only for enthusiasts. Your CP installer works if you install KernelEx and set installer's .exe to Windows XP compatibility mode. But since the people you mention were running a VM, that fact alone wouldn't get them far.

So yeah... as much as the Editor could use a total rewriting, I'm sure as hell not one to even begin to attempt that.

Me neither. It's crazy how much it takes to put these things together. If only Drakan was based on some more popular engine. It seems games inheriting their technology from Quake are better off when it comes to available tools for modding. Supposedly Riot Engine's layer technology has its advantages, if we are to believe Surreal's devs. But, before Surreal was no more, they were in the making of a new game (This Is Vegas) based on Unreal Engine 3. So what does that tell you? Their tech just wasn't feasible for the job anymore?


Lens flares are also broken on my laptop with Radeon R2 with newer drivers. I have no idea which drivers I had at the time I made this observation, I just know they were from 2018 and installed from Windows Update. The other drivers I used on it were from 2016, but when I still had those, the lens flare patch wasn't a thing yet. I haven't changed the code that deals with those ever since it was put in there. Perhaps AMD's drivers are being shaky? There were some unrelated issues back in December 2017, which were fixed, but those made quite an impact.

Edit: cool about the upcoming editor fixes! BTW, I have the habit of reordering the code so when I'm done there's no NOPs in between, unless the function is really really big and there's a great risk of missing CALLs and JMPS that have to be adjusted when the code is moved. Especially if you're modifying a DLL where in such scenario you'd also have to edit the relocation table with RelocEdit or similar utility. I think I even did the latter for cases when the function I modified was small. And if I find the code that must be skipped and the function is really too big to bother moving things around, I just put a JMP at the point where the code is skipped instead of leaving a series of NOPs there.

When there's no space I put JMP to a code cave at the end of the executable (though there's not much space left in Level Editor.exe, but new sections can be added if needed). One notable exception were fixes dealing with responding to queries send by the client to get server information, where I put them in the reclaimed space since I deleted a bunch of duplicate code and changed it to call a common routine which was already in place. I align code caves at 4 byte boundary (so the starting address always ends with 0,4,8,C) and put INT3s or NOPs in between, depending on how it's done on with the nearby code. Only later it occurred to me compilers align code at 16 byte boundaries, but screw it, at least it saves a bit of space and keeps them somewhat organized at the end of the executable section. Then I change the VirtualSize member of executable code section header (.text) in EXE header to point at the first unused (zero byte) at the end of .text section when you add VirtualSize to the address where the executable section. This one doesn't really change anything in practice, just the compiler that made those .exes makes it this way, but what can be observed from outside is if EXE checksum is correct. So I check the checksum with Process Hacker's Inspect executable option (or PE Viewer in its start menu folder) and put the number in the EXE header's Checksum member, so the program says the checksum is correct. OllyDbg does a good job of decoding those structures at the start of the EXE.

These are the conventions I follow that come to mind.
Last edited by UCyborg on Sat Aug 18, 2018 6:20 pm, edited 1 time in total.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

UCyborg wrote:I put it to 100.
Wait, did you mess with the Editor .exe again? Oops, now we have 2 different versions with different changes :(
(I based my fixes on the Editor .exe from AiO 143)

UCyborg wrote: So what does that tell you? Their tech just wasn't feasible for the job anymore?
:)

UCyborg wrote: I haven't changed the code that deals with those ever since it was put in there.
Well, then there's something else messing it up. Since when I fire up that update right after you fixed it, now the LFEs don't work, but the display remains uncorrupted (loading the exact same savegame) - no matter what I set in the Radeon Settings regarding AA/anisotropic.
But using the recent AiO builds, there's the crazy flashing corruption if I disable antialiasing, as I described.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Yes, it's 2.144 xD Don't worry, I don't do crazy changes anymore that would give you a headache if you compared them with hex editor that highlights differences. BTW, I edited the previous post with conventions I followed when editing EXEs or DLLs (or RFLs in Riot Engine's terminology) directly.

I'm a bit tired now and your observations regarding lens flares still confuse me. it's AMD specific issue, right? Even if I standed on my head, I couldn't get the two other computers with NVIDIA and Intel card to produce corruption with lens flares. At least the thing with AA making them disappear is universal.

The code cave that ensures the most optimal z-buffer format is selected is at the end of Drakan.exe, more specifically at the address 0x478540. The other change is in Dragon.rfl:

CPU Disasm
Address Hex dump Command Comments
687A3CFB |. 8BB5 60060000 MOV ESI,DWORD PTR SS:[EBP+660]
687A3D01 |. 4E DEC ESI
687A3D02 |. 3BC6 CMP EAX,ESI
687A3D04 |. 7D 02 JGE SHORT 687A3D08
687A3D06 |. 8BF0 MOV ESI,EAX
687A3D08 |> 8B8D 64060000 MOV ECX,DWORD PTR SS:[EBP+664]
687A3D0E |. 49 DEC ECX
687A3D0F |. 8D43 0A LEA EAX,[EBX+0A]
687A3D12 |. 3BC1 CMP EAX,ECX
687A3D14 |. 894424 10 MOV DWORD PTR SS:[ESP+10],EAX
687A3D18 |. 7C 04 JL SHORT 687A3D1E

Notice the DEC ESI and DEC ECX commands. Those are new. I really can't think of anything else regarding lens flares. The only other graphics related fixes are the black menu background bug (just removes some DirectDraw mipmap flag for certain textures before creating DirectDraw surface) and there's a fix for crash and missing ice effect on Arokh (which uses bump mapping), just changes code flow slightly by skipping part of it when it would cause access violation error.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

Ok, I've transferred my fixes to the new editor.exe from AiO 144.

I'll try to investigate the lens flares issue a bit more when I find some time, try it on different hardware and with different AiO builds.
And I still have an old computer with an nVidia card, but I would have to dust that one off (the rest are all AMDs).

UCyborg wrote: At least the thing with AA making them disappear is universal.
Strange, because I seem to recall them working back then, with AA set to forced 4xEQ. But don't quote me on that :)


EDIT:

It turns out that the "unsupported" 32-bit textures work perfectly fine in the Riot Engine! Both with alpha maps and without!
All that's needed is some way of importing them.

So here's what's currently on the agenda for the Level Editor:
  • Make 32-bit textures importable in RGBA format,
  • Make all textures exportable in RGBA format, regardless of their alpha map status in the databases.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

Strange, because I seem to recall them working back then, with AA set to forced 4xEQ. But don't quote me on that :)

Now I remember how it was. I only thought at one point anti-aliasing was a factor before the lens flare patch. Because for some reason, on Windows XP, lens flares sometimes worked, though rarely while they should never work, like it was the case on newer Windows versions with newer NVIDIA drivers.

Here's the full summary of changes for the lens flare patch:

  • Modified callback function in Drakan.exe at 0x43CFE0 to accept D24S8 and D24X8 depth buffer formats (it's called by Direct3D method IDirect3D::EnumZBufferFormats).
  • Added mask to 24-bit code for reading back depth values in Dragon.rfl:
CPU Disasm
Address Hex dump Command Comments
687A3D60 |> /BA FF000000 /MOV EDX,0FF
687A3D65 |. |D3E2 |SHL EDX,CL
687A3D67 |. |8B4C24 18 |MOV ECX,DWORD PTR SS:[ESP+18]
687A3D6B |. |83C1 08 |ADD ECX,8
687A3D6E |. |894C24 18 |MOV DWORD PTR SS:[ESP+18],ECX
687A3D72 |. |0BEA |OR EBP,EDX
687A3D74 |. |8B5424 14 |MOV EDX,DWORD PTR SS:[ESP+14]
687A3D78 |. |4A |DEC EDX
687A3D79 |. |895424 14 |MOV DWORD PTR SS:[ESP+14],EDX
687A3D7D |.^\75 E1 \JNZ SHORT 687A3D60
687A3D7F |. 81E5 FFFFFF00 AND EBP,00FFFFFF

The last instruction is the one, right after the loop, which should be shown nicely graphically in OllyDbg. Just in case Dragon.rfl doesn't load at its preferred address, you can open it directly in OllyDbg to locate the code sequence. Or just search for the "Lens Flare could not lock Z buffer" string to locate the function of interest.

  • The change I mentioned in the last post; it decrements width and height of the rectangle which is checked to see if lens flare is visible. It fixes the problem of accessing out-of-bounds memory.
  • Added 'poking' code to the surface data reader in Drakan.exe at 0x434CBC. This one's for compatibility with dgVoodoo's fast memory access.
You can read posts by Dege on VOGONS.

Anyway, the first version of AiO Patch featuring lens flare patch produces corruption with lens flares on AMD Radeon R2 with newer drivers, but with older ones from 2016, they simply don't appear. I didn't bother with anti-aliasing, it just makes things slow. Drakan performance on that laptop is already pretty retro PC like. Just changing driver changes things. No problems either way when using dgVoodoo.

It turns out that the "unsupported" 32-bit textures work perfectly fine in the Riot Engine! Both with alpha maps and without!
All that's needed is some way of importing them.

I messed with this a little in the past. I think I got editor to import them in 24-bit format. At least I remember some check for 16-bitness and skipping it made the texture/image I had appear in the database in 24-bit, at least that's what it said. Don't know if anything more would be needed on the editor side. I could see the texture in 2D view, but the 3D engine bailed out with an error about unsupported 24-bit texture. The textures simply weren't drawn.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

User avatar
Mechanist
Dragon
Posts: 303
Joined: Wed Mar 07, 2018 7:27 pm
Location: Poland

Re: Widescreen hack and some other fixes aka AiO Patch

Post by Mechanist »

UCyborg wrote: Sun Aug 19, 2018 1:38 pmI messed with this a little in the past. I think I got editor to import them in 24-bit format. At least I remember some check for 16-bitness and skipping it made the texture/image I had appear in the database in 24-bit, at least that's what it said. Don't know if anything more would be needed on the editor side. I could see the texture in 2D view, but the 3D engine bailed out with an error about unsupported 24-bit texture. The textures simply weren't drawn.
The Editor's 24-bit import code was partially broken (specifically, the byte-order-flipping routine, as I mentioned recently). However that seems to have only affected the 24 :arrow: 8 bit conversion though.

Importing ANY 32-bit BMPs is totally broken, the colors get all mangled up.
Same with importing 8-bit BMPs (does the damn thing ignore the BMP palette data, instead trying to use the loaded .PAL file :?:).

The way I want to do it is to ditch the broken-ass conversion code completely, and have it jump to a new code section containing totally new conversion code, which does things its own way, and puts the right data in the right places in memory.
Importing 24-bit BMPs will be passed through back to the original code, since it works fine for that particular use case.

I don't care about importing 8-bit BMPs; there is no good reason to ever do that in the first place - and even if it's absolutely required to use an existing 8-bit BMP for whatever reason, then it can be easily converted to 24-bit in a few clicks using MS Paint.
Fixing the existing broken code for 8-bit BMP import is hardly worth the time and effort; the same also applies to writing entirely new code for that specific purpose, too.

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

Re: Widescreen hack and some other fixes aka AiO Patch

Post by UCyborg »

I updated the archive; Drakan.exe now accepts 32-bit textures in addition to 8-bit and 16-bit flavors since they've been confirmed to work.
"When a human being takes his life in depression, this is a natural death of spiritual causes. The modern barbarity of 'saving' the suicidal is based on a hair-raising misapprehension of the nature of existence." - Peter Wessel Zapffe

Post Reply