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.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
Visual C++ 6.0 SP6
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.
and of course completely, utterly fails to work
Hmm, don't think there are any of those around anymore, outside of museums...initial setting will still be 4 on machines with 64 MB or less memory
That was quite unwise, actually.Level Properties dialog now allows setting number of undo levels up to 1000
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.memory fragmentation also comes to mind (who knows how good memory management works in there, plus the potential memory leaks)
Interesting - since I expected that the texture data for each face is stored in memory by reference, not "by value"?and let's not forget we can also work with much larger textures than it was originally allowed.
Normally I'd be inclined to agree, but let's be realistic about this:I also like keeping things compatible with retro systems.
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.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.
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 yeah... as much as the Editor could use a total rewriting, I'm sure as hell not one to even begin to attempt that.
Wait, did you mess with the Editor .exe again? Oops, now we have 2 different versions with different changesI put it to 100.
So what does that tell you? Their tech just wasn't feasible for the job anymore?
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.I haven't changed the code that deals with those ever since it was put in there.
Strange, because I seem to recall them working back then, with AA set to forced 4xEQ. But don't quote me on thatAt 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
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.
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 8 bit conversion though.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.
Users browsing this forum: Bing [Bot] and 3 guests