The_Raven on 2/2/2008 at 07:45
Ah, yes. I dream of a day when someone will pick up TSSHP's torch and carry it across the finish line. One day, one day....
Firefreak on 2/2/2008 at 11:26
Taking it across the finish line will probably require to start from scratch.
TSSHP consists of two major parts:
- Resource file hacking
- The (render) engine
The engine served two purposes: To see if the resource was properly hacked and to act as a how-to for Jim (How to create a 3D engine).
Jim is the only one who knew how the TSSHP render engine works, and since he's been MIA for years now, a big chunk of code is a black box (Even I won't be able to properly identify my parts of the code). As we were in the process of refactoring the code (to C++ and changes to several engine mechanics) shortly before the project went on ice, the code is quite in a bogus state.
(Note that I'm not forgetting Bryans or any other contributors' work - The 3D engine is just the biggest part of the code)
So, what remains reusable is the document that describes the resource files (the essence of the file hacking part) - and this is where anything meant for success should start off.
About a year ago I even did so, by reimplementing the basics about resource file load (and save!) and continued some res file hacking (note the updates on the document on sourceforge...). Of course, sooner or later I needed some render engine to test if the resource loader works - and used Irrlicht. And behold, after about two weeks spare time I had a 3D renderer that was about two thirds capable of what TSSHP was.
Note that this is in no way meant to make Jims work bad - (comparing the use of a complete engine against the work of writing your own (software) renderer is not adequate) - What I want to address is how much of the TSSHP code is not reusable (ie obsolete), yet starting from scratch with the right tools and effort quickly can surpass it.
Why didn't I go puplic with this re-hack you may ask (Sort of TSSHP 2)? Two reasons:
1: We know the mixed (but mostly negative) response we have in here about new ports of SS1 ;) -- or, described in another way: I as well am excited at first, but real life issues keep nibbling away the free time available.
2: A framerate of 30fps with two GeForce 8800 Ultra (SLI) does not speak for a prosperous engine. I simply have no experience at using 3D engines.
I hope I didn't derail this thread -- This 'trivia' above is placed best everywhere SS1 (TSSHP) related, and nowhere.
Plus: sinjid01, the link gives me a 404 - even with the trailing slash removed...
DiegoCyborg on 2/2/2008 at 14:32
Quote Posted by "Firefreak"
2: A framerate of 30fps with two GeForce 8800 Ultra (SLI) does not speak for a prosperous engine. I simply have no experience at using 3D engines.
Haha that's bad! But don't worry. Culling techniques on Shock-type geometry is fairly simple. A quadtree frustum renderer should help a lot.
For the SS1 port I see only one solution - By porting the original sources to a modern rendering/audio system and of course to a real windows application. Sadly they either don't want to release the sources or they're MIA and nobody knows where. I always wondered if theres some leak or someone still hanging around here offering knowledge or sources. How else did they reverse-engineer the whole RES files stuff TSSHP? Surely not by hex-editing and try&error programming. RES files are packed binaries. No way to figure out anything.
Kolya on 2/2/2008 at 16:16
Quote Posted by DiegoCyborg
I always wondered if theres some leak or someone still hanging around here offering knowledge or sources. How else did they reverse-engineer the whole RES files stuff TSSHP? Surely not by hex-editing and try&error programming. RES files are packed binaries. No way to figure out anything.
Yeah that's how TSSHP came to live, some mysterious looking guy offered the source files in a back alley in a leather briefcase. All I want to know is how come
YOU know all that?! :o
DiegoCyborg on 2/2/2008 at 17:04
Because I'm programming for over 12 years now and I hacked a lot around binaries and I simply don't know how the guys should have done it. Only way coming to my mind is diassembling the original engine and trying to figure things out that way (thats simply too hardcore for most human beings). I don't think of that "back alley guy" :D but there must be official specifications out there.
ZylonBane on 2/2/2008 at 17:42
Quote Posted by DiegoCyborg
Because I'm programming for
only 12 years now
Fixed that for you.
DiegoCyborg on 2/2/2008 at 17:52
If you're a programmer, then what do you think about it? I don't want to start silly flamewars here. I'm just interested in how they did it :rolleyes:
Al_B on 2/2/2008 at 20:48
Quote Posted by DiegoCyborg
If you're a programmer, then what do you think about it? I don't want to start silly flamewars here. I'm just interested in how they did it :rolleyes:
I was never directly involved with the ttshp guys (although I did exchange emails with Jim for a while, mostly about UW2 and 3D model stuff).
For my own part, it consisted of lots of trial and error; hacking bits and seeing what changed; many, many game crashes; trying different algorithms and getting frustrated; waking up at 2am with a new idea... The satisfaction of parts clicking into place...
That's why and how these things get done.
Firefreak on 2/2/2008 at 22:44
Quote Posted by DiegoCyborg
Haha that's bad! But don't worry. Culling techniques on Shock-type geometry is fairly simple. A quadtree frustum renderer should help a lot.
Yes... err.. I thought that as well :confused: ;) (My sarcastic way of telling I don't have any clue of 3D stuff other than some very basics about vertices and triangles. - Which underlines my above reason about my bad engine)
Quote Posted by DiegoCyborg
How else did they reverse-engineer the whole RES files stuff TSSHP? Surely not by hex-editing and try&error programming. RES files are packed binaries. No way to figure out anything.
Sooner or later it breaks down to basic types (integer and strings), which often come in sequence of similar values, at which point you identify structure boundaries. Then you look for references, either within the resource files (voice log text referring to audio chunk) or within the game (position within the world) and so forth. It is a lot of trying and guessing - followed by the satisfactory feeling of having hacked something successfully.
A quick search in my email archive didn't bring something up, but I think Jim once wrote something similar to "Sometimes I feel like looking at the Matrix code - I don't see the code anymore" (shortly after Matrix (the movie) was out ;) )
The most difficult part would have been determining the basic chunk/subchunk structure the res files are built of, combined with the compression algorithms (both for chunks and bitmaps). Next is identifying the chunk types (monsters, doors, trash, ...) - And then it's mostly tedious experimenting work - You have about 10 bytes of which you know they describe a door for example. Now what means what?...
How exactly the first steps at hacking the res files were done I can't tell - probably only Glen or Jim (or Joerg Fischer, the guy who made the first bitmap extractor) could answer that. I joined when most of the subchunk types already had been determined.
Oh, I forgot: Many things from the res files are still not decoded, so if any of you stumbles upon some new information that is not covered in TSSHPs unofficial specs document, drop me (or the tsshp-hackers list) a line :)
Displacer on 3/2/2008 at 01:31
One of the big problems is the .exe is bound to a dos extender. Disassembling it is not a problem, you just unbind the extender leaving you with the pure 32 bit code. The problem arises when trying to load it into a debugger. The extender is basically a 16 bit front end for the 32 bit code, so you would initially load it into a 16 bit debugger, which of course would not show the 32 bit code correctly. The 32 bit portion (which is the actual program) if separated from the extender will not run correctly or load into a 32 bit debugger. I think watcom's debugger (WD) can handle dos extended programs, but I've never tried it.
I did a quick disassemble of the 32 bit portion, its originally written in C, and looks like it would be a bastard to figure out...
