InkyBlackness news: v0.4.0 - Editor fully self-contained

[665b1f904be73dertseha]

° InkyBlackness
Progress! This is about two-thirds a technology update, one third content.
On the technology side, I now dropped the browser-support and the client/server concept. Both for some common and other various reasons. The more bigger change is having the UI completely done in the graphics window. So, no more text-mode combination and all is done now with the mouse.

During the winter I was also busy hacking various properties of the level object data. It's still not fully completed, yet the majority of the properties is covered. The editor shows the result of this information, by displaying various numbers for the objects. These may not make sense as of yet, next up I'm planning to add some meta data into the internal representation, so that the editor knows how to make them available to the user.

Here's the link to the release, again with a screenshot: https://github.com/inkyblackness/deck/releases/tag/v0.4.0
edit: Due to bugs in OpenGL initialization some might not be able to start the editor; Refer to this attempt at a bugfix release: https://github.com/inkyblackness/deck/releases/tag/v0.4.3

So, what is currently supported editing wise? Still only changes to the level tile map (heights, types, textures, ...) of the main archive (new game).

My (now not so secret) goal is to have something decent usable until our August meetup...

ps: The size of the font is hardcoded. I suspect if you have some higher resolution than HD, it'll be tricky

[665b1f904bffbfascinate4]

Hi, thanks for update, but I can't use it cause i have this problem. I am not good to use consoles on Windows. Did I do something wrong?

UPD: Sorry, forgot to say that, this command is not working for me.

[665b1f904c3d6dertseha]

Hi, thanks for update, but I can't use it cause i have this problem. I am not good to use consoles on Windows. Did I do something wrong?

Thank you for trying it out! It's not your fault it's not working, I didn't write proper documentation.
From the snippet I see you passed in the path to the ".res" file(s) directly - this is too much. the "--path" parameters need only to point to the one (or two) directories of all the ".res" files. So, if for example you had the CDROM under D:\ and the game installed under C:\sshock , the command would look like this:

Code: [Select]

shocked-client --path D:\cdrom\data --path c:\sshock\data
(the two "data" folders are where the .res files are located typically - double check)

If the installation is a combined one (no dedicated install medium), which is the case for the newer packages I believe, then only one "--path" parameter is necessary, pointing to the respective data directory.

The whole architecture is still in flux - When it's somewhat settled, I'm planning for more detailed documentation and/or video guides on youtube.

[edit]
I also just saw you're planning to work with the steam installation; This would most likely be the one-directory case, and I also highly recommend you make a backup first - possibly even working only on the backup. I haven't tested it with anything else than the vanilla CDROM.
The editor doesn't have UNDO - if you change something, that's final - and there's always the possibility of a bug breaking the whole installation.

Plus: thank you, Moderator, for adding the screenshot

[665b1f904c50ffascinate4]

Ok, I tried CD version (from Steam), but now it tells me this. And after that nothing happens.

[665b1f904c8b1dertseha]

Ok, I tried CD version (from Steam), but now it tells me this. And after that nothing happens.

Oi. Seems like my attempt for "compatibility through being unspecific" doesn't work on all graphics cards. I believe to know what the issue is, though I won't be able to verify this as I'm lacking test-hardware - In the worst case there might be a back-and-forth over some versions until it works.
Thank you for alpha testing - I'll release an update as soon as possible

For the technically interested: OpenGL shader compilation fails. With my previous dual-use of desktop OpenGL and WebGL I was able to keep the shader sources the same (and compatible) by not specifying the version of the shading language. My best guess now, supported by experience from another project, not all graphics card drivers like this. Since there's no more need for supporting WebGL, I can now specify the best fitting shader version for OpenGL 3.2 core.
Still, logging needs to become better - because if it's not the shader version, it's going to be tricky

[edit]
also, I should dig out that one blog post where it is explained how to get rid of build-machine specific information - Even the binaries know my username now

[665b1f904c9f2dertseha]

I've made a bugfix release, v0.4.2 . First post has been updated, here's the link again:
https://github.com/inkyblackness/deck/releases/tag/v0.4.2

fascinate4, may I ask you to try again, using these binaries?

[665b1f904cad8fascinate4]

Niiiice, it's working! Thank you 

[665b1f904cbe4WhyNott]

Doesn't seem to be working for me. A white window appears for a split second, and then the console returns to prompt.  I'm using the enhanced edition from gog, should I try downloading the classic version instead? 
[Przechwytywanie.PNG expired]

[665b1f904cdbbdertseha]

Thank you for trying it out as well!
It's again the OpenGL shader - this time the driver doesn't like deprecated stuff. I should be able to make another version later tonight.

[665b1f904cee9dertseha]

..aaand another release dished out. Main post updated, here's the new link for reference:
https://github.com/inkyblackness/deck/releases/tag/v0.4.3
May I ask you to try it out again, WhyNott?

[665b1f904cfc9WhyNott]

Aaaand... it works! Thanks a lot! Time to have some fun with it.
[Przechwytywanie.PNG expired]

[665b1f904d14ahank morgan]

Question for you if you can answer it for me?

The byte at offset 0xF in the object master record gives the z-coordinate for an object. But does that co-ordinate refer to the base of the object as a sprite pivot point or the centre or the top of the sprite Or is it possible there is a value somewhere for an object sprite that controls it's pivot point? For example what I've found in practise is that a normalised pivot vector for an email will not work for a corpse at the same time. One or the other will look wrong. The net effect I'm finding is that I think I'm calculating object positions correctly (accounting for level scales) but objects still float above ground. The exact same code will work perfectly of Underworld objects.

PS the documentation looks like a great resource. Wish I had access to it 3 years ago...

[665b1f904d777dertseha]

Question for you if you can answer it for me?

I checked back with the code of TSSHP to clarify a suspicion. The coordinate in the object master record does specify the pivot point. To which pixel this pivot point connects to in a sprite is encoded in its bitmap header.
In object.c there's this function "try_render_sprite". Lines 2015-2018 appear to calculate the (offset to the) pivot point. Sprites are always flat facing, so cx would be horizontally, cy vertically. And the bmp->x1 / bmp->y1 fields are the first two fields called "Left" and "Top" in the "HotspotBox" of the Bitmap Header.
Make some cross checks - I can't remember whether the Right and Bottom fields specify sizes or absolute positions. I do believe to vaguely remember sprites to always have a hotspot box of 1x1 pixel in size, so it would suffice to go with the first two fields only - which is most likely why TSSHP also used only those two.

PS the documentation looks like a great resource. Wish I had access to it 3 years ago...

[665b1f904d92dhank morgan]

Only just got around to trying to implement that. Not sure if I missing something here. To give an example. In objart.res chunk 1350, image no 632 which is a corpse I'm decoding the following values in the bitmap header.

Code: [Select]

Bitmap header
Type  = 2
???  = 1
Width  = 70
Height  = 19
Width in bytes (you call this stride) = 70
log2width (width factor) = 6
log2height (height factor)  = 4
left= 0
top = 0
right = 0
bottom = 0

All the sprites in that chunk have the same left,top, right & bottom position values so that idea doesn't seem to work for me when displaying object sprites.

Those particular values are set for critter sprites so in all likelihood they are used to keep animation frames pinned to the same spot.

[665b1f904df07dertseha]

All the sprites in that chunk have the same left,top, right & bottom position values so that idea doesn't seem to work for me when displaying object sprites.

Those particular values are set for critter sprites so in all likelihood they are used to keep animation frames pinned to the same spot.

Hm. You are right, these values most likely will help only with animated sprites.
Have you tried copying the algorithm TSSHP was using? It did render both UW and SS levels. The mentioned code section does have an IF for anchoring sprites (lines 2024-2026 of object.c). To reduce confusion, I'm pasting the code here:

Code: [Select]

2015   if (bmp->x1 == 0) cx = 0.5 * bmp->width;  else cx = bmp->x1;
2016   if (bmp->y1 == 0) cy =       bmp->height; else cy = bmp->y1;
2017   cx *= scale;
2018   cy = (cy * scale) - 2.54 * prop->scale;
2019
2020   /*
2021    * Start populating the surface vertices, at the top left corner which is
2022    *  also the texture anchor point
2023    */
2024   tv.x = obj->view.x - cx;
2025   if (Option_underworld) tv.y = obj->view.y + scale * bmp->height;
2026   else tv.y = obj->view.y + cy;
As far as I can interpret that, for UW the top is the base value plus the (scaled) height of the bitmap (line 2025). For SS it's the base value plus the (scaled) height of the bitmap (line 2026, with cy coming from 2016) MINUS some extra value coming from the object properties (line 2018). That dubious factor of 2.54 seems to be some fudge, possibly putting the properties value to the scale TSSHP was using.

In short, are you respecting that extra offset value coming from the object properties (only present in SS)? This value is read in decode_ss_object_prop() and not even documented in the original ss_specs.txt . Sorry I didn't see that before; I still haven't started working on objprop.dat, so I didn't know about that value. You wrote the objects are floating above ground, so I assume this might be the missing offset.

On a sidenote, I just today managed to add the function for inserting new objects to the editor. With a default value of 0 for Z, items are rendered a bit "below" the floor. Looking at various objects in archive.dat, they are always placed a little higher as well.

[665b1f904e07chank morgan]

That's correct. Just edited the common object entry in objprop.dat and set the byte at offset 11d  to zero  and the corpse in the original game now floats in the same position in the air that I was calculating it to be based on the master object record position. I'll test a bit more tomorrow as I need to find out if this offset value is changing the world space position of the object or just a change to the pivot point of the sprite.

Thanks.

[665b1f904e378dertseha]

I'll test a bit more tomorrow as I need to find out if this offset value is changing the world space position of the object or just a change to the pivot point of the sprite.

Thanks.

Sure thing. Please report your findings, because then I can add it to the documentation.

[665b1f904e55chank morgan]

Ok. The value in the props file seems to control the vertical pivot of the sprite in relation to it's world position.  A value of zero will pivot the top (I think) of the sprite at the object position. Increasing the value will shift the sprite down. So I think the value is the number of pixels to shift down by.

It's interesting though..  Setting a value that is too high will crash DosBox. A sprite which has a high enough value to appear underneath the floor will still be visible so it appears the engine uses the object position to cull the object.  It's kind of an off-putting effect.

Changing the value effects sprites and critters but does not appear to affect wall aligned stuff like switches. If you kill a critter that has been shifted down then it's corpse will appear at the correct un-shifted location.

For my Unity based project I think it should be enough to use the offset value to change the vector used to control the sprite pivot but it's not working for me just yet.