SS1src: SS1 source code release

[6741b3e82b455Gawain]

There are some header files related to resource offsets. File header says they are created by RESTOOL.
I couldn't find RESTOOL in sources.

[6741b3e82b638Kolya]

https://player.twitch.tv/?channel=nothings2

Sean Barrett is going through the source right now.

[6741b3e82ba49dertseha]

https://player.twitch.tv/?channel=nothings2

Sean Barrett is going through the source right now.

Is just closing down. It was interesting and had funny details in it as well.
Though I don't think I'll stay up to 1:30AM so often

[6741b3e82bb7cKolya]

Yeah, I caught your message on discord too late. Fortunately the stream is still available. And here is Barrett's fork: https://github.com/nothings/shockmac/blob/master/README.md

[6741b3e82be44JosiahJack]

There are some header files related to resource offsets. File header says they are created by RESTOOL.
I couldn't find RESTOOL in sources.

Resource.m and other tools are found in /Libraries, e.g. Libraries/RES/Source/ for the source to what appears to be a command line utility for pack and unpack of the .RES files.

[6741b3e82bf3aGawain]

Didn't find it.
There is also comment about RESOURCE.DOC that isn't in the sources.

[6741b3e82c055Gawain]

It looks like the 3D graphics library was completely rewritten in C for the MAC port. The original was in ASM.

Descent seems to use the same (later version) graphics library.
For example Libraries/3D/Source/INTERP.C can be found in Descent sources

Edit:
Descent2 sources seem to have C port as well. Looks similar.

[6741b3e82c153Bert3]

Descent2 sources seem to have C port as well. Looks similar.

same filename but more less complete different content, or do i compare the wrong files?

[6741b3e82c272Gawain]

Functionality is mostly the same (opcode based rendering).

About SS rendering:
There is a big function pointer table with all the graphic calls. There seems to be concept of "devices", and even mentions about 24bit rendering.
Adding new rasterizer implementation (Immediate OpenGL) could be possible with that.
If more modern approach is wanted rendering needs to be rewritten I think.

[6741b3e82c3addertseha]

Asked about which resources the source port is going to use, Stephen said

It will look like the Mac version
all the Mac assets are higher resolution as well!

Which will make many happy I guess - though the answer to my question which file format they are using is still pending. (I'm not talking about endianess, it's about the general file formats) Because if that's changed as well, I need to get my tools ready, stat.

[6741b3e82c4f9voodoo47]

interesting - and a confirmation that we'll have work to do as some people will definitely want to play the pc cd version. no info on the renderer?

[6741b3e82c7b6nemyax]

If more modern approach is wanted rendering needs to be rewritten I think.

You'd just be writing to arrays instead of issuing (zillions of) draw calls. That shouldn't be much of a leap.

[6741b3e82ca63Gawain]

You'd just be writing to arrays instead of issuing (zillions of) draw calls. That shouldn't be much of a leap.

I have looked into the source code and it will be a lot of work.
Reimplementing the rasterizer phase (basically polygon tmap (and some non textured too) calls) is a lot less work.

Edit:
It think it may be possible emulate immediate mode by rewriting all of the index and vertex buffers every frame. But that propably won't have any benefits over immediate mode anyway, since you can use command buffers?

[6741b3e82cbd2Gawain]

I think UI rendering could be kept as it is (software).
But it might need some hacks to allow sensaround to work. I didn't look yet, but if it is just rendered on top of UI instead of inside UI canvas no hacks are needed.

More about 3D acceleration:
One of the problems with accelerated rasterizing is CLUT (color lookup table / palette).
That can of course be done with pixel shader.

Edit:
If I have understood correctly object picking still needs to use the software rendering. I don't think it uses physics engine (raycasting).

[6741b3e82ccf3voodoo47]

I wouldn't worry about sensaround too much, as mouselook pretty much obsoletes it. meaning, if it's something that won't work properly at first, then so be it.

[6741b3e82cdf9Gawain]

Yes, I agree, its not very useful when playing with old controls either. It however does have effect on enemy spawns as they won't spawn behind you if sensaround is active.
But using it like that feels little bit like cheating anyway.

[6741b3e82cf91icemann]

Annoying that we get stuck with Mac assets. Yes I know their higher rez and all that. But to use SS2 as an example, I don't use rebirth as I prefer the vanilla models, whilst I do use SHTUP as that improves everything texture wise while still retaining the original look.

I'd prefer the same with SS1. Let me pick in the options or something which to use. This I want in the source port.

[6741b3e82d130Gawain]

I'm not happy that they force to use the "higher resolution" assets. It should be optional.
They really aren't just high resolution versions of the assets, they are shopped assets and some of them are not faithful to originals.

I hope they can return/fix the smoothing code that DOS version uses on sprites. Mac doesn't smooth them and sprites actually look a lot worse (low resolution) in Mac. Sprites are rendered four times bigger in DOS with multisampling (not interpolated, but there is some color shading going on).

There is of course technical reason (time/money reasons) for using the Mac assets:
The resource code has been butchered (no compression, top level file format has been changed to use apple own format, data seems to be indentical however, it is basically just wrapped differently.
UI code has been changed to support higher resolution images. It looks like old code is kept there, so it can be restored (and made so that you can use dos or mac versions)

[6741b3e82d209icemann]

Good to see that I'm not the only one of the opinion on the assets.

[6741b3e82d303voodoo47]

using the mac assets with a port based on the mac source is probably the easiest way of getting it work, so no surprise really.

pretty sure it will be possible to get the source port to load the pc cd data as well - the question is how much effort will be required to make it work.

[6741b3e82d484dertseha]

Your friendly Discord report here:
In the source-code chat there are two people independently porting the mac code to Intel platform (more as a hobby as I see it, they fully realize that an "official" source port is pending). One (named "Interrupt") got the renderer to work yesterday and posted screenshots.

This also brought Stephen on the plan, who finally invited the one person onto the Discord server who is doing the official source port (named "Axemelon").

Open for questions, Axemelon answered the following:
* The source port uses the mac resources, which were ported into the DOS .res files -- should be good for InkyBlackness, this makes the editor & tools compatible.
* As for OS, they said: "Windows-only for now. For the near future, hopefully we can get it working on other platforms as well." and "It was already running in Linux at some point, there's no reason it won't run again "

[6741b3e82d563icemann]

Care to post these screenshots?

Good to hear that a porting over of the code to Windows is in progress.

[6741b3e82d6b7dertseha]

Screenshots, and the general endeavor, documented in separate topic.

I wanted to know how the release is progressing. Axemelon replied

I'm fixing some final issues and then I will be submitting the game for testing this week

When the source release itself will happen, and whether it will be parallel to the "binary" release, or staged, Axemelon couldn't say (directing to Stephen).

Back to you in the studio...

[6741b3e82d7bcdertseha]

This bump to notify I've split Interrupt's work into a separate topic.