Trismegistus con mit cum Ex

#21
(2010-12-11, 08:47 PM)dmpdesign link Wrote:Looks really good, would love to have it working.

It works fine for me, so someone is going to have to work for that (an enticing screenshot is about all I have to offer at this point)

EDITED: I sort of wonder if maybe the download didn't make it up in one piece, or maybe I left something out. Other than that the only thing I can think of which might be different on your PCs is the system locale. But that shouldn't be a problem, even if the shift_jis codepage is not installed, which I reckon is almost by default, because browsers always offer it as an encoding. Graphics drivers maybe... if not some memory bug with random effects.
Reply

#22
(2010-12-11, 01:47 PM)Holy Diver link Wrote:Here is an HD screenshot for everyone who is not having luck with this Razz

I think this is actually a pretty nice vantage point. I will save my game here and maybe try to improve upon the quality this way and that over time. The plants in the distance are kinda disembodied for instance and other stuff. I kinda wonder if it might be an effective technique to try to do a higher quality render when the player is not moving. While they are moving everything is a blur anyway. Though I'm not sure at this point where you'd gain the extra cycles from, and if the framerate dropped considerably animated stuff would suffer, though technically I suppose you could skimp on anything that's moving, because it will also be naturally blurry (edited: though that would probably call for a special screenshot extension; so to do best quality for animated stuff also for the shot... nothing fancy in this screenshot though; ie. ~2 posts up)
Reply

#23
Can you upload the version with the logging so I can try to troubleshoot my problem?
- Todd DuFore (DMPDesign)
Site Founder
Reply

#24
(2010-12-12, 04:37 AM)dmpdesign link Wrote:Can you upload the version with the logging so I can try to troubleshoot my problem?

I'd rather pass it to you over messenger or email if necessary. Just on principle don't wanna a debug build being confused for anything helpful. If I'm visible on Live messenger for more than two minutes I'm available (regardless whatever it says my status is... it has a mind of its own)

I'll need about 5 minutes to prepare it.
Reply

#25
Here is a kit you can try at your leisure based on tonight's debug session.

I think the last launcher I had given you was no good in the logs dept, but it shouldn't matter.

Anyway the debug launcher/dll in this archive should work, and should generate a clog.txt file for some previously unlogged territory between the remote thread that hooks the .ini API and the point at which Som would normally load Ex (instead of various DirectX libraries etc)

The bug, whatever it is anyway, seems to reside within that space.

My clog.txt looks like this...

Code:
Redirecting std::wclog to clog.txt
Initializing off back of launcher
Installing API hooks courtesy Easyhook library...
API hooks installed (presumably)
Exiting DllMain entrypoint
GetPrivateProfileIntA(C:\Users\Michael\Saved Games\SoM\Trismegistus\Trismegistus.ini)
GetPrivateProfileIntA(C:\Users\Michael\Saved Games\SoM\Trismegistus\Trismegistus.ini)
DeleteObject: hdi object is 2F054E94(Bitmap)
Initializing virtual memory state...
Virtual Memory Page mapped at (thread lost)
SomEx initialized
Direct3D9 initialized
Software Device Library RGB9Rast_1.dll loaded succefully
DirectDraw initialized
...

Llog.txt...

Code:
Redirecting std::wclog to llog.txt
Creating subprocess thread main
Subprocess thread main created
OverwriteString()
OverwriteString()
OverwriteString()
OverwriteString()
OverwriteString()
OverwriteString()
OverwriteString()
OverwriteString()
Injecting SomEx.dll in order to perform early hooking
Sending code: c0000001...
Awaiting answer...
Answer received (a0000001)
Sending code: c0000002...
Awaiting answer...
Answer received (a0000002)
Sending code: c0000000...
Awaiting answer...
Answer received (a0000000)
Resuming subprocess thread main
Exited subprocess thread main

Please let me know how yours goes.

PS: Will try to remember to remove this attachment before too long.


Attached Files
.zip   SomEx_db.zip (Size: 921.57 KB / Downloads: 188)
Reply

#26
Here is a better rendition of the previous screenshot. I may do a better one with the do_antialias (good for screenshots, but not ready for play) extension, though I like the flame in this one. The flame animations are not normally synchronized afaik, but those two pedestals they seem to just happen to be so. Funny, twice when taking the screenshot the flame disappeared. I've never noticed it do that... though I suppose you might not notice unless things slowed down. Weird either way.

I took care of the major artifacts in the previous image by adding a lodbias setting to the images key. Only one level (-1) was necessary to fix the grass and the tree. The grass seems a little too sharp, but better than having disembodied portions. I think it may be possible to do multisampling (sub-pixel sampling) only for specific objects (versus fullscreen) which may be more practical than doing everything... you'd still incur the cost of a fullscreen copy (with D3D9 anyway) and allocating multiple depth buffers... but at least you would not be rendering everything 4 times or more (more or less) ... anyway, I think that's about the only thing that would really help the grass at a distance. Still I think the colorkey textures are pretty effective / in most cases the way to go for delicate filament like features.

Something like this might look nice in the Gamefaqs (gamespot) gallery if there's nowhere better to hang it. Just don't tell anyone it's the product of major league hacking Evil


PS: It's not a bad concept shot for Trismegistus either. The NPC in the background I think Tom never meant to be visible. He's not there anyway when you walk over to that side. He adds to the overall mysteriousness kinda, and in the screenshot anyway (if you let your imagination run wild) could even fill the shoes of the player character (from a 3rd person pov) almost being watched by "The all seeing Eye of Horus" Geno

EDITED: I notice a little speck under the tree leaves. Dunno if it's actually something, or a stray texel from the leaves. Photo edit it away and clone tool the cut across the tree top out, and you'd end up with something close to perfection (by Som standards)


Attached Files Thumbnail(s)
   
Reply

#27
nothing new, replaced the .dll and the .exe to no avail.
- Todd DuFore (DMPDesign)
Site Founder
Reply

#28
(2010-12-13, 03:57 AM)dmpdesign link Wrote:nothing new, replaced the .dll and the .exe to no avail.

Well the build was not meant to be a fix. I would like to know what your logs now look like. Please IM me asap if you can.
Reply

#29
attached


Attached Files
.txt   clog.txt (Size: 458 bytes / Downloads: 190)
.txt   llog.txt (Size: 594 bytes / Downloads: 194)
- Todd DuFore (DMPDesign)
Site Founder
Reply

#30
(2010-12-13, 06:36 AM)dmpdesign link Wrote:attached

Does the clog.txt file look right for you when you open it with Wordpad? The attached version seems mangled somehow. I can still make it out in a hex editor.

Anyway, it looks like everything is going normal, but Som itself is crashing before it even gets to reading its ini file.

SomEx goes on ahead and installs all the hooks first thing at this point, even though only the ini file read API needs to be hooked earlier than normal. So it's possible there are many other hooks being called before SomEx is properly initialized which might be causing trouble, because I hadn't even thought to look (because I haven't had any trouble)

So anyway, I will add some log stuff to the top of every hook and actually check to make sure the hooks install, though not installing shouldn't be fatal. If none of those log entries show up then there is something wrong with the hooking process itself. Which would probably be because of other something installed (or possibly not installed) on your computer.

UPDATE: I don't see anything that could possibly cause Som to crash before getting to the ini API (which doesn't show up in your clog.txt) so I'm pretty stumped. I'm attaching another SomEx.dll with some additional log information. I'm hoping there is just something stupid going on this might shed some light upon. However my guess is there is something installed on your computer that's getting in the way. So many things people install on their computers these days hook into every single process and muck around with stuff.... pretty much the same way SomEx mucks around with Som. Microsoft even provides an API for that.


Attached Files
.zip   SomEx_crashtest.zip (Size: 672.56 KB / Downloads: 175)
Reply





Users browsing this thread:
4 Guest(s)