Assidragon on 8/12/2005 at 23:27
Quote Posted by ToxicFrog
80x86 assembly, which is a cthonian abomination created for the sole purpose of driving coders insane
Quoted for truth. Found that out the hard way with SS2.
ToxicFrog on 9/12/2005 at 03:17
And yet, despite this, I persist in trying to write a keyboard remapper for SS1 that I'll never use.
[EDIT]
Dammit! I had the jump table right in front of me and then IDA crashed!
[EDIT]
The graph of function calls from the keyboard interrupt handler is a an abstract painting of the Lovecraftian horrors that lie in wait outside reality. Gaze upon it too long and it will peel away the thin layer of sanity that seperates your mind from Outside and leave you gibbering and empty.
It also takes 30 seconds of CPU time to render.
[EDIT]
Hang on, there aren't any function calls in the interrupt handler!
My diassembler is posessed by Cthulhu!
[EDIT]
The xref-to chart for N__fKB4() looks like a wireframe diagram of a steampunk airship seen side-on.
Perhaps I should go to sleep now.
Assidragon on 9/12/2005 at 15:12
Quote Posted by ToxicFrog
And yet, despite this, I persist in trying to write a keyboard remapper for SS1 that I'll never use.
...why do it then? :erm: :angel:
Quote Posted by ToxicFrog
Dammit! I had the jump table
right in front of me and then IDA crashed!
It does that often. Actually, mine does that
every goddamn time I try to make an programwide UML, after the loading process has completed. (No, it doesn't crash BEFORE the loading is done. Funky eh?)
Quote Posted by ToxicFrog
The graph of function calls from the keyboard interrupt handler is a an abstract painting of the Lovecraftian horrors that lie in wait outside reality. Gaze upon it too long and it will peel away the thin layer of sanity that seperates your mind from Outside and leave you gibbering and empty.
Oh I feel your pain. The precessor has roughly 40000 commands and just looking at the refs of one single command/variable makes you want to poke your own eyes out to save your sanity.
Quote Posted by ToxicFrog
It also takes 30 seconds of CPU time to render.
Not bad. How long does it take to load the program into IDA? o.O
Quote Posted by ToxicFrog
Hang on, there aren't any function calls in the interrupt handler!
My diassembler is posessed by Cthulhu!
...or SS1 is. I vote for the latter.
Quote Posted by ToxicFrog
The xref-to chart for N__fKB4() looks like a wireframe diagram of a steampunk airship seen side-on.
Perhaps I should go to sleep now.
That's not so bad. Looking at majority of the SS2 charts will remind you of a big black circle, so EVERY diagram will be so crowded you don't see anything else than a big black circle even if you magnify the thing like mad. :grr:
Edit: hey that's a great idea actually! Perhaps we could use UMLs in psychology tests: "what does this UML remind you of?" :joke:
ToxicFrog on 9/12/2005 at 15:24
Quote Posted by Assidragon
...why do it then? :erm: :angel:
Because it
must be done.
I honestly don't know why, but this program has to be written.
Quote:
It does that often. Actually, mine does that
every goddamn time I try to make an programwide UML, after the loading process has completed.
I found the problem - it was trying to show all (thousands!) of xrefs for the uint32_t I was cursoring over. Limiting it to 16 xrefs at a time fixed it.
Now if I only I could solve the problems where it doesn't remember any of my configuration, doesn't auto-analyze the program, and can't read its own save files.
Quote:
Not bad. How long does it take to load the program into IDA? o.O
About ten seconds. And then another 15 minutes to analyze it.
Quote:
...or SS1 is. I vote for the latter.
Or both.
Tej on 9/12/2005 at 17:36
Quote Posted by ToxicFrog
I would give my left mandible for the source code. ;.;
Now where would the challenge be in
that? ;)
Quote:
Z80 will help; I started out with 80x86 myself (bad idea!) and then 680x0. SS1, of courses, is 80x86 assembly, which is a cthonian abomination created for the sole purpose of driving coders insane. Being able to read it is a good skill to have, but learning the MC68K or Z80 first is a much better idea.
I've done some motorola programming a few years ago, at some under-graduate classes, we've even done some compiler and a built a small virtual machine for some other simple set of op codes. Anyway, know of any good tutorial for the x86 op codes and stuff?
Quote:
RES files, not WAD files. *bappity*
Yeah, I've been thinking Doom files. Sorry...
Quote:
However, as Shadowcat has pointed out, a lot of empty levels aren't all that much fun. Of course, if we can generate the map geometry automatically, we can also place the entities automatically;
I didn't say everything would be filled in instantly. But if someone would be doing a total conversion, as I know people have already tried, at least you can have your
world Citadel Station bootstrap itself. Of course you'd still need to write all the game logic, but we've already seen engines that let you float through the extracted game environment, but not much else. With an engine such as Source, you have your clipping, physics and triggering mechanisms already done. I'm guessing here, but do you think it would be so hard to implement the AI, the checkpoint/branching/inventory system?
Yeah, I later supposed that the sprites would not go well into Source, and that there might be problems such as with cell walls with zero thickness (I suppose that a brush in Hammer must have at least one unit in each dimension, but I'm not sure)... well, I don't know.
Quote:
There's a reason why, of all the "SS1 ported to engine X" projects, none of them have really gotten off the ground.
The laziness of those involved or the real life taking over? :)
Quote:
The xref-to chart for N__fKB4() looks like a wireframe diagram of a steampunk airship seen side-on.
Can we see any screenshots perhaps? :)
I'm sure that SHODAN is behind all this.
ToxicFrog on 9/12/2005 at 19:11
Quote Posted by Tej
I've done some motorola programming a few years ago, at some under-graduate classes, we've even done some compiler and a built a small virtual machine for some other simple set of op codes. Anyway, know of any good tutorial for the x86 op codes and stuff?
There is no such thing as a good tutorial for the 80x86. The closest you can come is a tutorial that doesn't immediately rip your soul out through your eye sockets and perform hideous abuses upon it.
No, I don't know of any.
That said, though, there's a decent instruction reference for the 486-and-earlier (
http://www.cs.tut.fi/~siponen/upros/intel/) here, which is sufficient for taking apart SS1. It only covers the instructions, though, not the incredibly perverse and arbitrary restrictions on MOV or the meanings of the flags or the like.
Quote:
Yeah, I've been thinking Doom files. Sorry...
Unclean! UNCLEAN!
Quote:
I didn't say everything would be filled in instantly. But if someone would be doing a total conversion, as I know people have already tried, at least you can have your
world Citadel Station bootstrap itself. Of course you'd still need to write all the game logic, but we've already seen engines that let you float through the extracted game environment, but not much else. With an engine such as Source, you have your clipping, physics and triggering mechanisms already done. I'm guessing here, but do you think it would be so hard to implement the AI, the checkpoint/branching/inventory system?
(1) What checkpoint/branching system?
(2) Inventory shouldn't be hard. Source is pretty flexible.
(3) AI is the hard part, but still doable, especially if the HL2 AIs can be adapted.
However, if I were to do something like that, I'd do it to TSSHP, which at this point is pretty much missing only physics and AI to be a playable game. Like I said, the underlying problem with porting SS1 to another engine
is not the code, it's finding the people to convert all the game resources!
Quote:
Yeah, I later supposed that the sprites would not go well into Source, and that there might be problems such as with cell walls with zero thickness
There's no such thing in SS1. Have you read the map format? The closest it comes is doorways and gratings (which are effectively a flat, two-dimensional clipping plane with a texture applied), but since those are entities, not world geometry, they'd have models associated with them in a modern engine.
Quote:
The laziness of those involved or the real life taking over? :)
Or perhaps the difficulty of finding people with the (1) knowledge (2) skills (3) tools and (4) time to create, essentially from scratch, models and textures for some 423 entities and animations for over 100 of those?
The overwhelming advantage that TSSHP has is that the hard part has already been done by LGS; all that's left is the code.
Tej on 9/12/2005 at 21:22
Quote Posted by ToxicFrog
That said, though, there's a decent instruction reference for the 486-and-earlier (
http://www.cs.tut.fi/~siponen/upros/intel/) here, which is sufficient for taking apart SS1. It only covers the instructions, though, not the incredibly perverse and arbitrary restrictions on MOV or the meanings of the flags or the like.
And, ehm, what's your opinion on (
http://developer.intel.com/design/Pentium4/documentation.htm#manuals) these thingies? :angel:
I'm... sooooory...
but I did enjoy the movie
Quote:
(1) What checkpoint/branching system?
You know... you fired a laser... there is a branch of "shield on" and another one for "shield off"... :erm:
Quote:
However, if I were to do something like that, I'd do it to TSSHP, which at this point is pretty much missing only physics and AI to be a playable game. Like I said, the underlying problem with porting SS1 to another engine
is not the code, it's finding the people to convert all the game resources!
I've actually gone and checked-out the CVS project and skimmed through files. Quite a lot of those, actually :) I am basically curious what could be done with it in its current state. No, I am not volunteering as I have absolutely no time to do that (and I'd even have to start importing it into Visual Studio .Net), but the curiosity is there.
Quote:
There's no such thing in SS1. Have you read the map format?
Emm, nope :o but I do know a thing or two, like it's cell-based, and cells have planes for walls, or so I assumed. Now, I went and tried to make a plane in Hammer, and of course it complained I'm trying to make an empty box. Hence, each brush in Source needs to have some volume.
Quote:
The closest it comes is doorways and gratings (which are effectively a flat, two-dimensional clipping plane with a texture applied), but since those are entities, not world geometry, they'd have models associated with them in a modern engine.
Right, makes sense.
Quote:
The overwhelming advantage that TSSHP has is that the hard part has already been done by LGS; all that's left is the code.
So, what are we waiting for? :joke:
ToxicFrog on 9/12/2005 at 21:55
I try to read it, but all I see is "lasciate ogne speranza, voi ch'entrate".
Quote:
You know... you fired a laser... there is a branch of "shield on" and another one for "shield off"...
That's just keeping track of story/mission/quest vars, something almost any game does to some extent. There's at least two ways you could handle that in Source, either internal gamestate variables or cvars. Not something worthy of seperate mention IMO.
Quote:
I've actually gone and checked-out the CVS project and skimmed through files. Quite a lot of those, actually :) I am basically curious what could be done with it in its current state. No, I am not volunteering as I have absolutely no time to do that (and I'd even have to start importing it into Visual Studio .Net), but the curiosity is there.
UNCLEAN! Burn him! BURN HIM!
Quote:
Emm, nope :o but I do know a thing or two, like it's cell-based, and cells have planes for walls, or so I assumed. Now, I went and tried to make a plane in Hammer, and of course it complained I'm trying to make an empty box. Hence, each brush in Source needs to have some volume.
You should grab the specs off the TSSHP site and read them sometime. Walls between cells aren't planes, they're solids - caused by an adjacent cell either being solid (or partially solid in a way that covers that face), or by being out of vertical alignment such that the ceiling of one cell is below the floor of the adjacent one.
If you have two cells in vertical alignment, and you can't make one of them sloped or diagonal-filled, but you need a wall between them, you have to either deploy a doorlike entity or a 3d model to serve as a wall -- but as stated above those are entities, not world geometry.
If you want an example of making a cell floor- or ceiling-sloped in order to create a wall between that and an adjacent vertically aligned cell, go examine some of the hallways in deck R.
Quote:
So, what are we waiting for? :joke:
Well, I'm waiting for some free time, and the completion of my other projects - ss1keymap, shockmap-2.x, res-4.x, and ss1edit. I might write some format-conversion tools to go with ss1edit while I'm at it, but that's up in the air at the moment.
Tej on 9/12/2005 at 22:26
Quote Posted by ToxicFrog
I try to read it, but all I see is "lasciate ogne speranza, voi ch'entrate".
Hmm, is that Italian? The link is to the Intel's manuals on IA-32 processors. Since my last post, I've been reading that first document (book), and actually learned about the segments in the memory. Interesting. Is that the source of the ugliness of the assembly code? Because it looks quite clean in the book... (yeah, yeah, we know all about that).
Quote:
That's just keeping track of story/mission/quest vars, something almost any game does to some extent. There's at least two ways you could handle that in Source, either internal gamestate variables or cvars. Not something worthy of seperate mention IMO.
Well, you're most probably right. I guess I am taking things too academically ;)
Quote:
UNCLEAN! Burn him! BURN HIM!
Nah, I don't think I'd burn at all. Not enough fat.
:eek:
Hm... ok, maybe I
would at least simmer... :erm:
Quote:
You should grab the specs off the TSSHP site and read them sometime.
Yeah, sure, just let me know where they stock time. I'd need some of it, you know :)
Quote:
If you have two cells in vertical alignment, and you can't make one of them sloped or diagonal-filled, but you need a wall between them, you have to either deploy a doorlike entity or a 3d model to serve as a wall -- but as stated above those are entities, not world geometry.
Ah, so it would be quite easily replaced buy a brush system. Nice.
Again, academically speaking, of course.
Quote:
Well, I'm waiting for some free time, and the completion of my other projects - ss1keymap, shockmap-2.x, res-4.x, and ss1edit.
Sounds like plenty of fun! :cool:
Quote:
I might write some format-conversion tools to go with ss1edit while I'm at it, but that's up in the air at the moment.
Nah, unless you want to convert them into a VRML, it wouldn't do until somebody is there to grab the thing and put it into some use other than creating an empty map.
ToxicFrog on 9/12/2005 at 22:56
Quote Posted by Tej
Hmm, is that Italian? The link is to the Intel's manuals on IA-32 processors. Since my last post, I've been reading that first document (book), and actually learned about the segments in the memory. Interesting. Is that the source of the ugliness of the assembly code? Because it looks quite clean in the book... (yeah, yeah, we know all about that).
I did read the link, so I know what it's a link to.
The quote is Italian, and means "abandon every hope, ye that enter". I'm sure you can place it now.
The underlying ugliness, is, well, an example.
Say you want to move data from register X to register Y:
MOV Y,X
However, because the designers of the x86 are actually hideous creatures from beyond the worlds we know, you can't actually do that! Instead, because Y can only recieve data from memory, you have to go:
MOV someMemoryLocation,X
MOV Y,someMemoryLocation
And so on. The x86 is
full of crap like that.
Quote:
Nah, I don't think I'd burn at all. Not enough fat.
:eek:
Hm... ok, maybe I
would at least simmer... :erm:p
With a big enough flamethrower, everything burns eventually.
Quote:
Yeah, sure, just let me know where they stock time. I'd need some of it, you know :)
Come on, it doesn't take that long to read. It's not even 60k.
Quote:
Sounds like plenty of fun! :cool:
Some of it is.
SS1keymap, involving as it does trips into the unrelenting hell of x86 disassembly and reverse engineering, is not.
Hate Intel. Hate hate hate hate hate hate.
Quote:
Nah, unless you want to convert them into a VRML, it wouldn't do until somebody is there to grab the thing and put it into some use other than creating an empty map.
I think you're missing the point. I'm talking about converting the game resources - textures and sounds, for example - into more portable formats like PNG and PCM, which can be easily viewed and edited,
and back again, thus paving the way for a SHTUP- or Marathon-style texture upgrade project and similar.
With a map editor, there's no reason to convert the maps. But few[?no] editors exist for the artwork formats it uses and I can't be arsed to write any; it's easier to write convertors and hand them over to an existing editor like the GIMP.
