Gambit37 wrote:The only way I could see this being fixed is to create four images and foor doors that all operate at the same time. Two images are simply the left side and right side of the door. The other two are just sliver image of the 'depth' of the door and are offset to appear next to the edge of the straight door image. With careful layering (ie, the slivers are rendered behind the actual door images), you could fudge the effect.
I'd set up a more complicated door triggering mechanism, where each set of doors require an instance of some sort of "door trigger" object to control them. It's not as troublesome as it sounds, because I'm sure
spawn_door can be hacked so this is transparent in DDM or in the Lua file. Then, I'd
dsb_qswap the associated door from a door with a "closed" image to a door with an "opening" image as needed. The upside is that the dungeon mechanics are cleaner and you only need one door. The downside is that it takes a fair bit of Lua coding. (adding the associated downside that this fix is DSB-only)
Anyway, as if the previous concerns aren't enough, I'll throw in my own thoughts--
On the topic of doors, I have a sinking feeling the rather "clunky" animation used by DSB (and RTC) for an opening door just won't fly. You know what I mean, clank clank clank and it goes up in large steps. It looks fine with the original DM graphics (or lo-res custom graphics), because it gives that authentic DM feel. However, even in a highly detailed 640x480 dungeon, it would start to look a little, shall we say, dated.
Right now, DSB's Lua functions expect a 640x480 screen. All coordinates pertaining to drawing, clickzones and the like expect one. If the resolution is increased, suddenly all that code breaks. Granted, you'd probably to write new code to support some of the new features of a high resolution dungeon anyway, but I'm sure at least
some of the base code would still be usable. The quick, but not necessarily good, solution (and I don't particularly like it) would be to just define "virtual pixels" and let DSB assume it's on a 640x480 screen regardless of the actual screen size. If you're running at 1280x960, this isn't too bad; your main problem is that you lose very fine control over where things are positioned. However, if you're running at something like 800x600, where there's no integer ratio between a real pixel and a "virtual pixel," precise positioning would become more or less a game of chance.
Running at extreme resolution might be slow. This could be anywhere from "kinda" slow to "really really" slow, but pushing that many pixels using software rendering is not going to be very quick. DSB's backend is software rendering via DirectX 7, and though I do use a triple buffer and a few other optimizations, modern video cards are optimized for 3D and will be very little help in these modes. An increasing number of games, even though they're in 2D, will use OpenGL to draw their screens. It's typically much faster and smoother than using software rendering, and you get scaling, blending, rotation and smoothing "for free." This would be the eventual solution, but making this conversion is a rather monumental task in itself.
Gambit37 wrote:I'll split this discussion off to a new thread as iit's off topic, but should it go in DSB forum or somewhere more generic as it applies to RTC too?
I left it here because I wouldn't know where to move it if we wanted to move it. There is no generic "clone development" forum, except for the "Other Clones," but it seemed silly to have a post in there that applies to clones that have their own forums. I also added some DSB-specific stuff, so I think it's ok here.
Or, hey, let's just make it global announcement and have it show up on
every forum.
/mophus.png)
