Diadem of Maunstraut

[Holy_Diver]

I can't tell for certain, but I think the TL (don't know what that means -- maybe TnL) mode maybe disables hardware fog. The other mode definitely looks smoother, but I didn't hunt around for a nice open area to check the horizon curvature.

I did notice that the non-TL mode seems to come to a crawl with 16bit colour, because it's emulating it I would guess. The TL mode probably emulates it as well (on my hardware) but seems to perform better so any slowdown isn't noticed. I mention this because I think I discovered SoM looks much better in 16bit colour. It just looks more lofi, which is kinda how I take my KF 8)

[dmpdesign]

Well, I used true color on most of my custom textures, so if you ever play my game youll want to run it in 32 bit mode hehe...else it really looks retarded in some areas.

[Holy_Diver]

Actually I think modern drivers just map the 32bit colour to 16bit colour, so it won't look as retarded as you think. It actually just gives it a sort of interesting texture. You should try it. Most all lcd screens on the market can't do anything close to 32bit colour anyway (yeah, one step forward, and two steps back)

[Hguols]

I guess to answer that question, I set the fog on DoM to 0.  That would mean there is no fog.

The fog effects looked bad with a short draw because of the "sudden draw" look of it.  Turning the fog off and a black background created more of a realistic darkness effect.  

Trismegistus takes advantage of SoM fog features.  The "sudden draw" is a little less noticeable in Trismegistus because that game has a higher draw distance.

The draw in Diadem of Maunstraut is very short, but it beats the alternative.  Enemy spawning is based on draw distance, and enemy projectiles have virtually NO collision detection.  Not to mention, I didn't want to have to walk a good ways just to run into that same enemy again.

This has to do with me being a collector in games; I farm enemies for drops in virtually all games that, well, have enemy drops.  Does that mean I'm OCD?

[Holy_Diver]

Mystery Solved>>

What about projectile collision detection though? They seem to collide against everything for me.... even other projectiles!

[Holy_Diver]

PS: If anyone sees this^

That is sort of interesting that the baddies spawn from behind the shadow horizon. I thought the draw distance in DoM is ok for that dark claustrophobic feel... but if you were just trying to get the respawn rate up, I wonder if you can't make certain equipment shorten the clip distance (ie. respawn) ...which would in effect (or side effect) increase the encounter rate for exp and drops.

I kinda feel the respawn rate for DoM is a bit much. It took a while to find out the healing tree fruit transports you though, so maybe I was doing double duty backtrack wise. Still doesn't seem right to have stuff popping backup just because you looked over your shoulder

[Hguols]

I too liked the overwhelming darkness feel that the low draw gives as well, but respawn rate seems to truly be dictated by draw distance.  It was a happy compromise, I thought.

As for the projectile collision detection, it certainly does depend on the projectile fired.  Even with that short a draw, I can get an arrow through the wall from a Soror Ionesco....   not to mention, most projectile from lower levels will hit the character's feet.

SoM collision detection seems to be wacky in general from system to system.  Some move object commands will be off on different computers....  

I think you falling through the floor (which is something I have yet to experience) is a decent example.  I think me getting shot through the walls (which is something you have yet to experience) is another decent example.

[dmpdesign]

Object movement is definately weird on different computers, if not broken on some...and it drives me insane!

I have two parts in my game that have a continuous moving object, one is a mill wheel, the other is a stream of light coming from a lighthouse.

On one PC they move nearly ok (though the object movement timer really doesnt work right in SOM) on another pc they get stuck halfway through the cycle and sit for about 10 seconds then whip around really quick for a few cycles.

Maybe it is processor speed related?  The fast the computer I run on the worse this gets.

Maybe you guys who know the ins and outs of SOM can help me with this when I get my game to testing phase.

[Hguols]

The problem you mentioned seems fairly cosmetic....

On John's decked out demo, he's got these events to move the player across a chasm....  works like a charm on one PC, another PC it throws the player in to the depths.

Why?  It really does appear that some SoM parameters are different from PC to PC.

....but why?  Once again, I don't know.  John doesn't either.

[Holy_Diver]

I can tell you the collision detection is probably a function of the frame rate. It sounds like collision is handled by time based simulation rather than trajectory tracing/intersection routines. So if the frame rate is low, then the simulation will be very likely to pass thru things undetected. Usually these things are done outside the framerate because they actually need to be finer grained. But either way, I doubt there is any other factor here other than cpu time. So increasing the priority of your SoM game might also help alleviate this.

For the animations, the situation is also similar. If if it's slowing down and speeding up, it is probably not a realtime animation (in sync with the system rtc) ...though if your system has a messed up rtc that might also explain it (say perhaps if SoM is using some legacy timing routines) ...but most likely what is happening, is the animation is just not synchronized, so when things are speeding up and slowing down, it might reflect the load other processes are having on your system. Again giving SoM (the runtime game exe) a higher priority would help aleve this.
 
It's possible SoM runs these simulations in separate processes which could also help explain why they seem to fluctuate independent of the game proper. In which case you might have to adjust the priority of those processes independently.

Lastly the cpu load might not be properly pipelined in accordance with the graphics hardware api calls, in which case your graphics could be causing a bottleneck which would cause these things to chug. If they do run in a separate process, you probably don't have to worry about that (outside of general performance concerns) but if they don't, it's possible the software could not foresee all possible iterations of DX, which could now be throwing a wrench into the works. Not to mention who knows the how DXs backwards compatible runtimes work, or the quality of their implementation (because really Microsoft probably cares little to see that old games continue to work... unlike OpenGL, each new version of DX is a completely new beast)

So pretty much you can chalk all of this up most likely to simplistic design thinking on SoM's part, shady backwards compatibility philosophy on behalf of DX, and perhaps most importantly, how much of a priority SoM (and any subprocesses) is getting on your system.

Anyway, I haven't tried some of the other scenarios (windmill animations and other tricks & hacks) on my machine, but everything seems to run well for me. Projectiles all work as you'd expect, which suggests the collision routines are very generalized. Striking type attacks do go thru walls, and the enemies on the other side seem to be attacking at me... but that is more of an AI thing... but if I fire a spell at an enemies spell, the two actually cancel out... so my collision processing seems to be fairly fine grained to say the least. I doubt having a too powerful machine is a problem. But I don't want to speculate too far.