Here is something I've worked on the last couple nights. You can get your paws on it by downloading the latest SomEx.dll which will be available soon over in the DirectX9 thread (wish I had a link at my fingertips)
It squeezes into 640x480 (assuming you end up with the same font maybe ... no worries, the font can be standardized) but can also come in two columns and double wide mode depending on your resolution / preferences. The double wide mode probably won't be accessible in the first release.
I really need to add some stuff to the ini file for customizing things. And there's a lot more memory to sift thru than I expected (which is probably a good thing because it means Som uses the heap little if at all) so just paging thru all the memory is really too cumbersome, so I need to add some features like jump to and find.
Oh BTW this is a realtime memory inspector. You can see Som's memory while you play. So like if you see a number changing while you're turning, then it stops changing when you stop turning, and so on, then you've found the memory where Som stores the player's turn angle. This will really revolutionize Som. We just need to map out all the memory like Game Genie people do for games... so you can have infinite HP for example.
I think maybe I see the clock, but I could be wrong. Hopefully that would allow me to fix the clock reset bug for example. Another important piece of memory would be the current map number. That would let us get started doing things like adding a better background to each map (one that sits still for example)
Of course there are other benefits like setting up events that let you detect what the player has equipped. So anyway, I advise everyone to take this quite seriously.
That said it's still not super useful for every day use until I can add some features. I can already find some memory pretty easy by building a search into the code. But that's not super practical. I also want to build some notation into the inspector so like if it's known what some memory is it will print that on the line above. There will most likely be two addresses for everything, one for som_db.exe and one for the game exe (som_rt.exe) but hopefully they will overlap enough to build a mapping, but the ini file will have to let you specify both just in case... especially for new memory.
I spent a lot of time setting up a way to input what address you wanted to look at, but it wasn't practical to do with dinput in the end, so I will have to rethink it a little in terms of more traditional window input. If you use the traditional Som key layout it's pretty simple, but I can imagine if you wanted to map the movement keys to WASD that would make trouble for typing in hexadecimal addresses (which would need A/D) for example.
I wish it worked with the pause extension but it doesn't because the pause extension literally pauses everything. It would take a bit of work to pause the game but still have access to the overlay etc, but I think that might eventually happen. Especially if we start using the overlay for other types of stuff (like printing out stats about the game while you work with your map)
I think Todd really wants a falling damage extension. So first person to find the memory that stores the player's position in space gets a cookie (I think the HP parameter will be pretty easy to pin down... in fact I hope all the other player related stuff is nearby)
This is pretty neat. The bulk of the memory wasn't exactly where I expected to find it, but then I've never done this sort of thing before. The memory inspector may need to be a lot more sophisticated to make it useful. Or it may be that all of Som's uninitialized memory is all in one place (section 13) ...it seems like most stuff is stored in static records maybe even byte identical to the files in the PARAMS folder.
I can see the main player stats and the player's spatial orientation. I can also see all of the enemies I think. So maybe already I can do some interesting stuff like display the monsters HP/MP over its head and even display damage numbers as they happen, both for diagnostics and if you wanted to integrate something like that into your game. I can definitely see all of the magic spells / could change their characteristics on the fly I reckon. I can see numbers for the players swing and magic I think... probably just the gauges come to think of it. There might be a way to use that to fix the no magic equipped gauge bug.
And of course there is enough there to work out a fall damage extension. It might be better to set the calculated damage in a counter so an event can decide whether to deal the damage or not or how to generally proceed. I also want to work out a way to describe formulas in the extension file so you can do it that way.
It's actually easiest to detect the player and monsters because you can see the numbers churning when they move around. Finding all of the less obvious stuff is going to require some sleuthing and clever map setups. I hope some of you really get into that.
The way I have this setup right now is kind of centric to my keyboard, which is not really standard. The keys can be remapped however, and eventually we can work out a better arrangement maybe to suit a standard full size keyboard. Basically backspace opens/closes the overlay, but you can open it with any button that it uses also. I'm surprised backspace doesn't have the same function as the esc key in Som. I'm seriously considering disabling the Enter key from Som's pov so it can be used exclusively for Ex stuff. You can use the spacebar to do everything enter does afaik (at least with the patched exe files)
Then from there each F key (like F1) not already used by Som brings up different information. Originally I was going to have the function keys switch between different layouts with different functions, but now I think they will all just go up on the screen and the F keys will just be toggles. The Ex.ini file will let you setup the layouts you like and tie F keys together so if you press one others get out of the way. Eventually I'd like to replace Som's clunky F1 and F2 keys because they don't always even work, and can't be accessed outside of som_db.exe. Might as well do the same for "god" mode etc. I'd like to integrate a mouse eventually. The backslash/pipe key acts like a tab key for input and moving to different fields on screen. And enter presumably commits the input data. I'm considering also making you use numlock to choose which set of arrows you'd like to not use with Som. And another key to kill all keyboard input to Som... which if you're using a joypad anyway you might just leave on permanently. Only prob is most of the keys I like for that are beside keys you use to play with. Maybe it should be an odd sequence like ctrl+alt+del (but not that one!!)
EDITED: Oh yeah, more about keys. The plus/minus and brackets keys are also reserved for use, but I'm not sure how exactly. Atm +/- scrolls the first column of memory and [/] moves the second. Might use the arrow keys or something to choose what function you want to manipulate.
Hmm...not gonna hijack the thread but...it would be possible to load an enemy with a player magic profile which makes their magic attacks go after enemies. Though it would really be jacked up
I've always thought monsters in games should fight/eat each other when the player is not around. I mean really, these killer creatures have an absolute armistice until a player shows up, then scramble for the chance to be the one that gets to kill the player
This thread is the right place to talk about this kind of stuff as far as I'm concerned. I think the enemy data is pretty well laid bare. There are definitely some possibilities. Does monster melee hit other monsters? I'm not sure, testing that might be difficult to setup.
I think it might be possible to even add monsters on the fly. So summoning might be easier than controlling them. If they just did spectacular magic attacks and disappeared that might be pretty simple.
BTW: I'm thinking about holding back on the D3D9 release for a day or two because the build is a little out of order because last night I got a wild hair about supporting 16bpp mode because it dawned on me there was no way to truly support 16bpp under Aero but it could be replicated as a visual effect. To be honest I love Som in 16bpp mode. It only seems interesting to me when it's in 16bpp honestly. In 32bpp it seems really drab and washed out and dead. In 16bpp it's incredibly lush and has a painterly effect and the constant peeling caused by the fog makes everything (including the shadows) seem to be alive. That said I've had a lot of complications. First attempt was to just add a line of code to the pixel shader basically remove the 32bpp colour information from the pixels (large ranges of colours get collapsed into one) which looks better to me, but D3D9 applies the fog after the pixel shader, so A) it's 32bpp, and B) you don't get that awesome peeling effect, and all the surfaces seem dead (static never changing) ...so I could do my own fog with a vertex shader but the way Som works that would be a nightmare to manage and I prefer to implement things in a way that is agnostic to Som (so any game could be hooked up to the Direct X code in theory) ...so now I'm trying to render to a 16bpp texture then just plaster it over the screen in the end (which is also a good time to apply other effects) but for some reason just switching the render target over to the texture isn't good enough (worse I can't imagine why) and I'm kind of at a loss to think of something to try / am beginning to think this trouble I'm having may not supposed to be happening. But I won't give up, and I expect to get it done in the next few days, schedule permitting.
I was fortunately able to track the bug down to the pixel shader I'd hastily thrown together to do the fullscreen blit with no frills. I'd declared a texcoord semantic with float instead of float2 and that made it act like a 1D texture (for some reason turned on its side) even though the tex2D intrinsic was used.
It looks really good. Maybe cleaner than the original. It was a little sluggish at first until I thought to force the sampler to a point filter. Now it plays without missing a beat at 1920x1200. My computers are all miniature, decent for games, but not awesome by any means. So this is not bad.
The only thing keeping me from serving it up immediately is I should add some stuff to make sure it's only used when the game is actually in 16bpp mode. And the text is not being drawn for some reason I don't understand. My guess is the GDI based text routines are not compatible with render targets which are never supported in off device memory afaik. In fact I think the text routines are not generally serviceable with D3D9. I don't know how it implements it, but it suggests if you must use them to render them to system memory then transport that to video memory to be composited with your picture.
Fortunately I think I have all the necessary text routines already hooked, and can use the same interfaces I used to setup the green overlay text to draw the game text (with higher quality (than the green) of course) in a hardware friendly way... in fact I have a feeling the results would be nearly identical if not better so, which makes me wonder why the drivers wouldn't just handle this stuff transparently. But you can do it a bit more efficiently if you do it yourself, so maybe it's a good idea to not give software developers a crutch.
Ultimately it's not a good idea to apply the fullscreen blit after the menus have been drawn, but it will be good enough for now until I can figure something else out. If I integrated other effects into the blit you probably only want them effecting the game / not the menus and stuff. It will be interesting to work out the timing for that when the time comes.
Yes the green text made it thru just fine, so everything should work out eventually. I think I will provide an option to leave out the sliver of shadow in the text, because that's really not worth the performance penalty. And modern text rendering can be very intensive. I actually have a feeling I'm seeing better performance than ever. It's smooth as silk frame rate wise anyway.
Well, i know that enemy spells definately hit enemies and damage them... During a test a monster took out the other, attacking me but hitting a monster that was in front of me.
Will there be any increased direct draw for SoM in your update? I cant stand how you can be walking around and seeing chunks out of walls / corners etc. Any bonus lighting / shadow effects would be great...
Lastly i've a problem with my text in SoM, it used to flicker from gray to white when i had dd enabled, then strangely it turned entirely gray, so now the text is hard to read.
I'm not sure what you mean by "direct draw" or chunks out of walls etc. If you mean the geometry disappearing, Som does that. It's pretty common in many games. I don't know if I see it a lot in my projects or not. I know I do with the water sheet objects. If objects did not come with Som, then it's very possible there is something wrong with those files. If the object did come with Som, then there is probably something wrong with Som (would not be the first thing)
If increasing the draw distance helps at all, I could develop some extensions to prevent the disappearances either by hiding them in fog or overriding Som's Direct3D settings. There might also be a way to trick Som into thinking it has a wider frustum. Also if you enable "map optimization" when outputting your map, Som makes some assumptions like when you're in a tunnel you can't see things outside of it, which can be bad if your piece is not a true tunnel for example.
For lighting I do intend to try to get around Som's four light limit for objects. It may or may not work. But basically I would just always keep the lights on once Som sets them up (Som only keeps 4 on at a time) ...and since we know where the player is relative to the lights now I could still turn lights off that are too far away to be seen (according to maximum draw distance)
If you wanted to start doing interesting things with lights you'd have to output your map without lighting, then use that extension as a start. Then your map would have the same lights as the objects/monsters (which are really not consistent anyway -- I also plan to do a calibration extension to try to improve that) and you could turn the lights off/on dynamically, but you would lose Som's baked in shadow calculations (like how a column by a candle will cast a shadow on the room)
But if you want to totally revolutionize Som's lighting that would be the way to start. Then you could start adding shadows and stuff by some other means.
PS: If you literally "disabled DirectDraw" (and that means what it sounds) I'm surprised Som would even work. That might mean it has some yet undiscovered means of rendering itself which I'm totally unaware of. If so it would be statically linked into the exe and there'd be virtually no way of getting at it. Like a 3rd party software renderer with no dll associated. Though it probably just forces Windows to use software renderering to implement DirectDraw/3d.
Text is working / looks good. The STORE ITEMS menu is DD is lightning fast now, so it was the text rendering that was dragging that down and less so my non-caching text translation code (re-translates every frame even though the text stays the same)
That menu is the biggest killer therefore I have a feeling the menus in general will be silky smooth now. In the past they've always staggered horribly for me making the input really unresponsive/unpredictable also.
UPDATE: The key/pad input in the menus is still a little hit/miss for me. I'm pretty sure it's something inherent in Som that makes it that way. I'm sure one day it will be fixed if so. It's still fast, just clumsy as ever (which is not as aggravating when it's fast)
Offtopic anecdote: while I was debugging Som it would crash with a beep and some odd exit codes. I noticed some Japanese (?????????) in the debugger output. The Japanese translates to "general purpose 'counter' management". I'm surprised I had not noticed it in the exe file before. So anyway, the word 'counter' is in katakana so "counter" seems like a reasonable translation. I don't know if John realized that's what it said or not, but he never mentioned the katakana in arguing for the translation. And also it demonstrates that a lot of the untranslated text in the exe was intended for debugger output, which is an odd rarely used debugger feature. The error it self doesn't actually mean anything other than presumably Som was doing something in the counter block... probably just running debugger tests looking for odd behavior. The reason for the crash seems to be because one of my counters was 65535 (max counter) which might look like a runaway counter, but the odd thing is Som would only complain about this when converting from 32bpp to 16bpp mode. I don't know if it was because the debugger was attached or if because som_db.exe was in use, but it should not effect som_rt.exe based executables. It was a pain to go into the map editor to fix it.
PS: I don't know if the Japanese will print to the forums or not. I think I have the 16/32bpp switching down well enough for a release sometime later today.
