A Powerslave / Exhumed Map and Game FAQ

[Corvin]

I think those guys only came to push the Powerslave map editing link.
Have they got back to you yet?


Whats this patch you made now?
I don't totally understand its purpose. Not that it might be useful however.

JonoF is still working on his PS/EX Build Editor you know? as the one linked in my previous post is a WIP.

[-=CHE@TER=-]

I think those guys only came to push the Powerslave map editing link.
Have they got back to you yet?

Nope. And since I can't find their contacts (e-mails) anywhere I wonder how I can bring their attention here. I will try to PM them if they didn't turn off forum e-mail notification for that.

Whats this patch you made now?
I don't totally understand its purpose. Not that it might be useful however.

As already mentioned in Powerslave map edition link above - Exhumed/PowerSlave are tag-driven game.
For example:
- In Duke Nukem 3D you run BUILD.EXE and insert sprite #1680 (LIZTROOP) and that's all - you just create an enemy for level.
- In Exhumed/PowerSlave you run BUILD.EXE and insert any sprite you want but you MUST set sprite lotag to 100 to be able to spawn Anubis Zombie. So if you want WYSIWYG you'll need to insert appropriate sprite (for example #2311 for Anubis Zombie) AND set it lotag to 100. It's very tiring, suffice it to say that most (if not all) of the original game maps have some misplaced sprites for lotags (for example: Blood Bowl with lotag of Extra Life). And it's very confusing. Because the game didn't care about sprite number but did care about lotag - when you start any level the game checks all sprites and replacing them (deletes and insert new - proper one) if their lotags matches with certain ones.

I did my tool to automate this process - you set up an ini file with TILE_NUM => LOTAG correspondence. After that you don't need to waste your time setting lotags for enemies, weapons, power-ups, etc. You just need to insert appropriate sprite as in Duke Nukem 3D and run my tool on the map after to automatically sets all lotags to their proper values (tile number in ini file will point to correct lotag value).

JonoF is still working on his PS/EX Build Editor you know? as the one linked in my previous post is a WIP.

It's great, but this will not help with lotags since it's game-specific thing.

[oasiz]

Sorry, missed this as I'm kinda busy at the moment with a lot of stuff :p
I'll let Methy know about this as well.

This sounds really cool, thanks for the heads up!
Should definitely give this a try soon. I won't be able to do anything super complicated since Ion Maiden dev is currently keeping me very busy (doing levels for that) and I'm in the middle of moving to saudi arabia for work, which has it's own things to keep me busy with
I'll try to get back here later today for a proper look

you can catch me with maxkyh @ // on google mail domain.

[-=CHE@TER=-]

oasiz thanks for reply!
I will drop you a mail with link to the tool since gmail didn't allow to send executable files in attachments.
I understand that you're busy right now, so it's alright to write back as you have some free time for that. Take it easy.

Also there is two important question to discuss.

1) First and very important one - I fill in some values in ini file for tile-numbers. Like this:

Code: Select all

[877]
title=speed loader
lotag=6
hitag=6
xrepeat=76
yrepeat=68

Speed loader has only one tile number - 877.
But monsters has a lot of sprite animation frames and the developers use any sprite they want in original levels.
My suggestion is to use first monster sprite in ini file. So you will insert it faster without need to dig in to the later ones.
With one exception for Anubis Zombie - I suggest use first one 2057 as Anubis With Drum and later one 2311 as regular Anubis Zombie.
But if you have any other thoughts about this - please tell me. I want to know what will be more convenient for mappers.
Because of that I didn't fill in monsters sprites and leave it to you guys - so you can fill it as you want.
So we can make a final ini file which will be released with the tool on public.
And that's the important part - final ini file that we release to public probably will be used without any changes by other people so we need to properly decide on things since it will be hard to change them later. In short - we need to develop some kind of standard for future use.

2) And second one - by now my tool can fix (replace) only 4 values from sprite properties: lotag, hitag, xrepeat (width), yrepeat (height). Note that property "title" used only to generate NAMES.H file. And if you omit any of them my tool didn't replace it. For example:

Code: Select all

[877]
title=speed loader
lotag=6
hitag=6

Properties xrepeat and yrepeat will not be changed.
So my question: did you need any other sprite properties to use with such tool? As palette indexes for example (because I see some keys in the original maps have palette 1 (blue) and I don't know if it mandatory property for work or not)?

Thanks!

[oasiz]

Thanks, got the mail and let methy know as well.
Currently for IM we're using mapster32 scripts so I think a lot of this could be automated with proper use of m32 scripts.
i.e. I have setups where I press a hotkey and it will automatically set repeats and height off from gound based on the sprite's picnum (i.e. a pushbutton), setting tags would be super easy to implement as well (or any picnum changes). This would expose everything practically in plaintext, however you'd have to use mapster32, requiring a chain to be implemented.

Your proposed monster sprite setup sounds sensible, NAMES.H labels aid mappers there, just like with duke you had STAYPUT variants visible that way inside the editor's texture view.
As for palette, etc.. I don't see any real need. Must be leftovers?

As for why m32 proposal is nice, you could quite easily run this process during "save" and potentially do even more "quality of life stuff" such as the sector flip effect linking during that time (one that relies on sector numbers).
These fake teleportation effects (player dimension changers as I like to call them) are one of the most tedious things to pull off currently when mapping for the game.
Effects could use those visually distinct orbs and here is where I'd use different colors to indicate effect types (i.e. visual effect vs. game play)
There is no clear standard here but one could be established as a "good mapping practice"

If I have some time in the near future, I could do some examples on this.
I'm no coder but m32 is fairly simple and super powerful for a mapper once you know how it works.

[oasiz]

FYI, this same happens in JonoF's editor as well, more of a bug in the game itself. (Used mapster here in shot)
This for example was manually fudged to match the tracks in-game, a very fun process, can recommend!
Which is also why there are some spots with lazy alignments.

It seems that the late V6 format still has some issues with relative floor textures when used on slopes.
You will end up with shifted textures when using relative bits here and there (IIRC not all rotations worked correctly either)
Good to a custom editor! Although I would highly recommend having some support included for mapster in the future as it's much more superior as a mapping tool due to the extensive hotkeys that have been added + scripting possibilities. They might seem similar in the surface but I almost exclusively use mouse + keys to move around and never use arrows these days.. Can't go back once you learn them

Anyway, if there is interest.. some compensation might help here.
So far slope artifacts are:
- Full visibility will be applied (doesn't diminish shade depending on distance)
- Relative floor texture alignment isn't always correct
- Angles can't be too steep or some number seems to overflow and the texture mapping goes haywire
- Firstwall/"hinge" must slope upwards as collision is only counted properly for uphill (Re-positioning Z and reversing firstwall direction will easily help here)

Thanks for the work so far!

[-=CHE@TER=-]

oasiz, thanks for the detailed reply!
I will see what can I do, because my initial idea was only about tags fixing and this is a bit more.
About EDuke32 and scripts. I tried EDuke32 some time ago and it was so slow on my system compared to JonoF's Duke Nukem 3D Port which I still using that I never used EDuke32 after. Well actually I tried it once again few years ago but additional to slowdowns there are was broken midi music (didn't work at all - I even tried some oldier builds), so I completely decide not to work with it anymore.
I'll try to look into it again and scripting system too, but can't promise anything.
Also if you have a separate tool - you can use it under real retrogaming system in pure DOS or you can use any Build port (not that there is much of them) you want not restricted by one engine only.
But I hear you so I will think about it.
Thanks!

[Corvin]

JonoF said for his last editor download, to not use the tables.dat file that's included. It is known to cause the sky box to have issues when its present in the game folder.

[jonof]

Hi all. I finally registered an account.

Further to what Corvin wrote, if you're using the tweaked JFBuild-based editor I prepared, for the time being it's best to keep it separate from your real Powerslave directory (with a copy of the game data) and copy your map to test it. I've observed using old tables.dat with the newer engine causes, specifically in TekWar, the NPCs to go mental, and of course the parallaxing is wrong, so I imagine doing the reverse (new tables, old engine) would give similarly undefined behaviour in Powerslave too. As such, I'm going to embed the data that's read from tables.dat into the executable so it doesn't rely on the file anymore, which will mean you can put the editor back with the game again. I'll post a link to that when it's done.

Jonathon

[-=CHE@TER=-]

Hello, jonof and welcome!
If this will help you - here is reversed code from the Exhumed / PowerSlave for loading "TABLES.DAT" file.
I don't know if the same code used in some other older Build games like TekWar or not.
You probably can detect tables file format by it's size (this one - 11904; Duke3D - 8448, etc.) to understand how to load it.
Hope it helps.

Code: Select all

void loadtables(void) {
long i, fil;
  if (tablesloaded == 0) {
    initksqrt();
    reciptable[0] = 0x7FFFFFFF;
    for (i = 1; i < 1024; i++) {
      reciptable[i] = 0x40000000 / i;
    }
    fil = kopen4load("TABLES.DAT", 0);
    if (fil != -1) {
      kread(fil, sintable, 2048*2);
      /* NOTE: skipped something */
      klseek(fil, 4096, SEEK_CUR);
      /* NOTE: only 640 instead of 640*2 as in Duke3D */
      kread(fil, radarang, 640);
      kread(fil, textfont, 1024);
      kread(fil, smalltextfont, 1024);
      kread(fil, britable, 1024);
      kclose(fil);
      /* (2048*2) + 4096 + 640 + 1024 + 1024 + 1024 = 11904
         11904 bytes - TABLES.DAT size in EX/PS */
    }
    tablesloaded = 1;
  }
}

Here is also reversed code for "PALETTE.DAT" file for Exhumed / PowerSlave:

Code: Select all

void loadpalette(void) {
long i, j, fil;

  if (paletteloaded != 0) return;
  if ((fil = kopen4load("palette.dat", 0)) == -1) return;

  numpalookups = (kfilelength(fil) - 768) / 128;
  if ((numpalookups % 2) == 0) {
    /* no transluc */
    numpalookups /= 2;
  } else {
    /* allocate memory for transluc buffer */
    numpalookups = (numpalookups - 255) / 2;
    if (!translucloaded) {
      transluc = malloc(65536);
      if (transluc) {
        fixtransluscence(transluc);
        translucloaded = 1;
      } else if (cachesize >= 262144) {
        /* if malloc failed - try to allocate in cache */
        cachesize -= 65536;
        initcache(pic, cachesize);
        transluc = cachesize + pic;
        fixtransluscence(transluc);
        translucloaded = 1;
      }
    }
  }

  /*
    41600 - PALETTE.DAT size

    numpalookups = (41600 - 768) / 128 = 319
    // (319 % 2) != 0 - transluc present
    numpalookups = (319 - 255) / 2 = 32
    numpalookups = 32

    int i, sz;
    sz = 0;
    for (i = 0; i < 255; i++) { sz += 255 - i; }
    printf("%d", sz); // sz == 32640

    total size from code:
    768 + (32 * 256) + 32640 = 41600
    matched with file size
  */

  kread(fil, &palette, 768);

  /* allocate memory for palookup buffer */
  palookup[0] = malloc(numpalookups * 256);
  if (!palookup[0]) {
    /* if malloc failed - try to allocate in cache */
    cachesize -= numpalookups * 256;
    initcache(pic, cachesize);
    palookup[0] = cachesize + pic;
  }
  globalpal = 0;
  globalpalwritten = palookup[0];
  setpalookupaddress(globalpalwritten);
  kread(fil, palookup[globalpal], numpalookups * 256);

  if (translucloaded == 1) {
    for (i = 0; i < 255; i++) {
      kread(fil, &transluc[257 * i + 1], 255 - i);
      for (j = i + 1; j < 256; j++) {
        transluc[256 * j + i] = transluc[256 * i + j];
      }
    }
    for (j = 0; j < 256; j++) {
      transluc[257 * j] = j;
    }
  }
  kclose(fil);
  paletteloaded = 1;
}