Images/PNG Grab

[RUNSABER]

Granted there are only so many of us to help each other, I decided to tackle this problem alone until the headaches just couldnt do it any more justice.

Could someone please explain the Png grab, how it works and why it makes it difficult to define proper offsets for PNG images? For example..

PNGS are supposed to be set to 0 offsets for both the X and Y planes of your image. For some reason, even with this hardcoded via DDF, it is either not fully accurate or a hassle either way. This leads me to abandon the need for PNGs and convert them into Doom paletted sprites. Not a pretty alternative, but I'd rather deal with black than finicky transparency. Perhaps a future ability to enable and control the alpha of a sprite and NOT just the translucency of that sprite will be available. This can make it hard to properly line up sprites that overlap each other. In this case, a flare to "beautify" the Imp fireball.



Is there another way to have one thing or sprite use multiple sprites at once without having to use spawn states or actions? I've seen DECORATE use actor specials that allows a main sprite and an additional sprite on top of it. Maybe its my inability to get these new features for 3DGE under control, but they are indeed not user-friendly for modders. It should be something even a newbie starting out could know and not require a load of testing to get it right... I can understand spending 1 hour coding definitions, but I shouldnt spend no more than 10 minutes trying to get PNGs up and going...



A past issue rearing its head, heres to hoping these alpha transparencies see some kind of attention in the next final build. This could be bad coding, or crappy PNG once again. It appears when multiple images share a close proximity or space, they clip each other out and cause artifacts. None of this stuff is major, I can get away with ALL of it by not using PNGs at all. Though that honestly takes the satisfaction of using 3DGE for its simplicity out of the window. I would like to make my special effects work for minimal CPU pull. Sorry to bombard with this help quest as there are more important things under the hood that need to be fixed. Its just that Ive had more time to play around and put something together in this engine. What always turns me off is the lacking ease of tasks that should be rather simple to replicate in this engine.

Lastly, here are my definitions. In order to spawn the flare sprite, I define it as a harmless attack that is called a second before the Imp's Combo Attack. This spawns the flare on TOP of the fireball (which should be directly on center with it) without clipping away the fireball sprite itself. Attacks don't seem to clip whereas anything defined as a 'thing' is. Or maybe both. I don't know.

Code: Select all

//***********
//**ATTACKS**
//***********

[IMP_FIREBALL]
ATTACKTYPE=PROJECTILE;
HEIGHT=8;
RADIUS=6;
DAMAGE.VAL=3;
DAMAGE.MAX=24;
DAMAGE.OBITUARY="OB_Imp";
ATTACK_HEIGHT=32;
SPEED=12;
FAST=2;
ATTACK_SPECIAL=FACE_TARGET;
PROJECTILE_SPECIAL=NOBLOCKMAP,MISSILE,DROPOFF,NOGRAVITY;
LAUNCH_SOUND=FIRSHT;
TRANSLUCENCY=90%;
DLIGHT.TYPE=QUADRATIC;
DLIGHT.INTENSITY=100;
DLIGHT.COLOUR=#b83c1c;
PUFF=ROCKET_TRAIL;


STATES(IDLE)=BAL2:A:2:BRIGHT:SMOKING,
             BAL2:B:2:BRIGHT:SMOKING;

STATES(DEATH)=BAL1:a:0:BRIGHT:DLIGHT_SET(100),
              BAL1:a:0:BRIGHT:DLIGHT_FADE(0),
              BAL1:a:0:BRIGHT:TRANS_FADE(0%),
              BAL1:a:0:BRIGHT:KILLSOUND,
              BAL1:b:3:BRIGHT:PLAYSOUND(FIRXPL),
              BAL1:c:3:normal:NOTHING,
			  BAL1:d:3:normal:NOTHING,
			  BAL1:e:3:normal:NOTHING,
			  BAL1:f:3:normal:NOTHING,
              #REMOVE;

[FIREBALL_FLARE]
ATTACKTYPE=PROJECTILE;
HEIGHT=8;
RADIUS=6;
DAMAGE.VAL=0;
DAMAGE.MAX=0;
ATTACK_HEIGHT=32;
SPEED=12;
FAST=2;
ATTACK_SPECIAL=FORCE_AIM;
PROJECTILE_SPECIAL=NOBLOCKMAP,MISSILE,DROPOFF,NOGRAVITY;
TRANSLUCENCY=70%;
SPRITE_SCALE=0.2;


STATES(IDLE)=YFLR:A:-1:BRIGHT:NOTHING;

STATES(DEATH)=NULL:A:0:NORMAL:TRANS_FADE(0),
              #REMOVE;

DDF IMAGE DEFINITION

Code: Select all

[SPR:YFLRA0]
IMAGE_DATA=LUMP:PNG:"YFLRA0.PNG";
X_OFFSET=0;
Y_OFFSET=0;
SPECIAL=FORCE_CLAMP;
FIX_TRANS=BLACKEN;

If there isnt a clear-cut solution at this time, I will gladly do without these things until a stable release and proper tutorial and documentation explains how grabbing actually works.... Thank you!

[CeeJay]

The images will be set X=0 Y=0 aslong as the image itself doesn't use embedded coordinates (you need to make sure of this as to avoid conflicts). I haven't really used or tested the PNG Grab feature, I stick to the old fashioned way of defining the images and their proporties in IMAGES.DDF.

If it's a projectile you need give it the same Y offset as the actual image but half. If the projectile is in a 64x64 image, it would X=0 Y=32.

That's about as much help as I can provide I think.

EDIT: ATTACKS don't clip while THINGS do. No idea why. When this is an issue I try to work around it.

[Corbachu]

The problem here is this, in DDFIMAGE:

[SPR:YFLRA0]
IMAGE_DATA=LUMP:PNG:"YFLRA0.PNG";
X_OFFSET=0;
Y_OFFSET=0;
SPECIAL=FORCE_CLAMP;
FIX_TRANS=BLACKEN;

For grAb, you don't specify offsets at ALL in Images.DDF -- even if the expected offset is 0,0 in grAb. If you use the OFFSET system via DDF, it will redefine these to 3DGE's standard 0,0 coordinates, which are completely different and useless for images that use grAb.

Rule of thumb -- for grAb, don't use X_OFFSET or Y_OFFSET in Images and let the grAb struct do the rest =)

[CeeJay]

I've had some issues myself. It just doesn't seem to work properly. I'm using PNG images for an enemy with embedded offsets and without any entries in IMAGES.DDF but 3DGE appears to be doing something wrong. It's not centered but it not the correct offset either.

Does 3DGE assume the graphic is a HUD sprite (weapons), graphic (centered) or world sprite (enemy, items, etc)?

[Corbachu]

What would make it easier for 3DGE to assume these kinds of things is to have your projects in either a PAK, PK3, or PK7 in the right namespaces. That way it helps you (and the engine) figure this sort of thing out.

For instance, grAb structs are working fine for me (and the images in question are built-in graphics), the console interface reports as such:

Got grAb struct: -569/-324
WIDTH = 1024 (1024)
HEIGHT = 512 (512)
BPP = 3
WIDTH = 1024 (1024)
HEIGHT = 1024 (1024)
BPP = 3

You should see something similar in yours -- the struct offsets at the very top should be the offset you are aiming for. If it is not what you have it in SLADE, then something
is indeed wrong. Check back on that for me.