The "How do I..." Thread

[D2JK]

I have a projectile that spawns blue sparks behind it, using A_SpawnItemEx and SXF_TRANSFERTRANSLATION (the untranslated spark sprites are yellow). Does it make sense that ZDoom is able to apply the translation correctly, while GzDoom isn't, leaving the sparks yellow? Should I report a bug, or is there something I should first try? The sprite is converted to "PNG (paletted)" in Slade.

[phantombeta]

Is the palette being used by the PNG the Doom palette? If not, I think that might be messing it up.

[edward850]

It logically has to be (in ZDoom anyway, GZDoom may not be doing any conversions, making translation impossible), but the problem is PNGs need to have their palettes translated, and even with the exact same colours the index is not guaranteed to come out the same way.

If you want to use translation, it is highly recommended that you use the doom sprite format, where you have a guarantee which colour indexes are used.

[Revanic]

First time posting here, I was wondering on how I would go about creating a new game with ZDoom? I already understand all the DECORATE stuff, but it seems I have no other choice but to modify the zdoom.pk3 for my own playerclass, mapinfo, and iwadinfo...

[phantombeta]

Uhh... No.
PK3 files are just renamed zips, so if you can edit one, you can make them without editing zdoom.pk3.
And you don't need IWADINFO. It's not required. That's just so ZDoom can find it automatically for the list. You can use any WAD with the -iwad parameter... Well, almost any. It needs to have a PLAYPAL/palette.

[edward850]

but it seems I have no other choice but to modify the zdoom.pk3

Absolutely never modify ZDoom.pk3.

[phantombeta]

I think ZDoom should check against a stored MD5 hash to make sure it isn't edited. If it is, don't let the game start, with the message "Do not edit the zdoom.pk3 file."

[Revanic]

Then a modding tutorial lied to me. Whoops. Alright then, look dumb now to look smart later I guess.

[Matt]

Can you post a link to this tutorial that tells you to mod zdoom.pk3? I think we need to call down the Spanish Inquisition on them.

[Revanic]

Well, more specifically it was a GZDoom modding tutorial. Though I would believe it would still apply to not actually modify the gzdoom.pk3 either. I also just realized it was posted on April 1st. Perhaps I am just [censored word]? ._.

www.lofibucket.com/articles/modding_doom.html

[Coincident]

I'm trying to pass a fixed point decimal from Decorate to an ACS call:

decorate

Code: Select all

		Pickup:
			TNT1 A 0 ACS_NamedExecuteAlways("testDecimal", 0, 121.5)
			Stop

ACS

Code: Select all

script "testDecimal" (int decimal) {
	printBold(f: decimal);
}

This prints 0.0000something


ACS

Code: Select all

script "testDecimal" (int decimal) {
	printBold(d: decimal);
}

This prints 121.

Is this behaviour normal? How do I pass a fixed point as argument to an ACS call?

[Revanic]

Ints don't like decimals. You'll have to use a fixed_t, I believe, instead. ZDoom handles fixed_t's as floats and only floats give you the decimal place. As for printing it, I have no idea since I haven't tried ACS yet. Hopefully I'm not wrong this time. xD

[cocka]

121.5

Try 7962624 instead.

[edward850]

Ints don't like decimals. You'll have to use a fixed_t, I believe, instead. ZDoom handles fixed_t's as floats and only floats give you the decimal place. As for printing it, I have no idea since I haven't tried ACS yet. Hopefully I'm not wrong this time. xD

Nothing in this post is correct.

Try 7962624 instead.

Nothing in this post is remotely helpful.

I'm trying to pass a fixed point decimal from Decorate to an ACS call

Decorate has to truncate the decimal to pass a valid result to ACS, which doesn't have floating point values. There is a very functional solution to this, though, which can be used simply by remembering the basic rules of fixed point integers.
In ZDoom, fixed point is 16.16, so 16 whole bits and 16 fractional. 1. is thus the 17th bit (1 << 16), making it an integer of 65536. Visually, this:

So this makes our magic number 65536. If we multiply any decimal (float/double) with this number, we get its 16.16 fixed point equivalent. Infact, you can just chuck that into decorate, like so:

Code: Select all

ACS_NamedExecuteAlways("testDecimal", 0, 121.5*65536)

This will pass the result of 7962624 to ACS, which you can then treat as a real fixed point number.

Code: Select all

script "testDecimal" (int decimal)
{
   printBold(f: decimal);
}

As you can see, nothing changes in the script you wrote up. The "f:" marker will tell PrintBold that, instead of treating the number as a literal integer, that it's a fixed point number and to print it like that instead.

[Coincident]

Yeah, soon after I posted I realized that my question was quite sily: especially because ACS_NamedExecute takes INTs for arguments, unlike other action functions...
So, I have to multiply x 65536 (shift << 16) every decimal I have in decorate, to be able to pass them as a proper fixed point int.

Once again, thanks edward for the thorough response.

PS - a small follow-up question: is it possible to have custom decorate functions?
I already had this is ACS, but I wanted the same for Decorate:

Code: Select all

function int toDecimal(int someInt) {
	return someInt * 65536;
}

The goal is to have "cleaner" code in decorate:

Code: Select all

Pickup:
         TNT1 A 0 ACS_NamedExecuteAlways("testDecimal", 0, toDecimal(121.5))
         Stop