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.
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
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.
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
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.)
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:
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