[Hendricks266]

Dynamicsoundremap, screentext, qstrdim, rotatespritea, orientation flag 2048, and other recent CON changes should be documented now.

NightFright, on 01 June 2013 - 03:25 AM, said:

- Level stats not shown any more

Fixed.

[Fox]

You wrote something about xdim-1 and ydim-1. But I am quite sure these values are already subtracted by one (i.e. at resolution 800x600 they will equal 799 and 599 respectively).

[Helixhorned]

Fox, on 03 June 2013 - 07:34 AM, said:

You wrote something about xdim-1 and ydim-1. But I am quite sure these values are already subtracted by one (i.e. at resolution 800x600 they will equal 799 and 599 respectively).

Nope, they are not. See setgamemode() in engine.c.

[Fox]

Well, that's something that changed recently.

[Helixhorned]

Helixhorned, on 03 June 2013 - 07:44 AM, said:

Nope, they are not. See setgamemode() in engine.c.

I should mention that this is orthogonal to the question of whether xdim or xdim-1 is the right value to provide to rotatesprite and friends to denote the right border (analogously, the lower border for ydim). The answer to this one is that it doesn't matter for the classic renderer. In dorotatesprite(), we have:

    // bound clipping rectangle to screen
    if (cx1 < 0) cx1 = 0;
    if (cy1 < 0) cy1 = 0;
    if (cx2 > xres-1) cx2 = xres-1;
    if (cy2 > yres-1) cy2 = yres-1;

(xres is the same as xdim as far as I can see). So even if the "correct" way is to pass xdim-1 (because the bounds denote a both-side inclusive range of pixel center coordinates), passing xdim does the same and saves a few keystrokes.

However, in the Polymodes' rotatesprite, polymost_rotatesprite(), it seems that we don't clamp the bounds to the screen size, producing slightly different results for xdim-1 and xdim. This is irritating and IMO we should take over the behavior from classic.

Fox, on 03 June 2013 - 08:23 AM, said:

Well, that's something that changed recently.

The way I see it is that nothing has changed on the implementation side, but that Hendricks merely edited the wiki to promote the most "proper" practice.

[Fox]

So from now on I shouldn't worry about crossing the four x-y limits?

[Mateos]

If you cross them they will be changed to the max (xres-1 or y-res-1) if you're above or at 0 if you're under 0 from what I read?

So you can but kindof useless as they will be autochanged.

[Hendricks266]

Mateos, on 04 June 2013 - 03:37 AM, said:

If you cross them they will be changed to the max (xres-1 or y-res-1) if you're above or at 0 if you're under 0 from what I read?

Currently only 8-bit classic fixes it but the OpenGL renderers should fix it too, so I guess as soon as that happens I'll revert the wiki and you can ignore it.

[Jblade]

I'd like to make a request about the projectile structure stuff; is there any way you guys can add a new projectile bitfield that doesn't do anything, but can be used by us to set our own stuff via CON code? Sorta like the workslike flag except it's more to set a bunch of flags for projectiles ourselves. I know this can be done in say event_game or egs but having a way to do it straight when defining the projectile would be pretty handy.

[Hendricks266]

Any reason you can't do it yourself? A global gamevar would work like setprojectile and a per-actor gamevar would work like setthisprojectile.

[Jblade]

Hendricks266, on 08 June 2013 - 01:02 PM, said:

Any reason you can't do it yourself? A global gamevar would work like setprojectile and a per-actor gamevar would work like setthisprojectile.

It would be convinient and would mean not having to add case-specific stuff to every projectile. Instead of having to detect for every projectile, I can just search for a set flag. I don't see it as anymore lazy than adding in support for tiles angled the wrong way (when mirroring the side angles in a paint program would achieve exactly the same result)

[Hendricks266]

However, in this case, it would be adding an extra arbitrary amount of memory (why stop at one?) that does nothing unless used. Helix's recent addition of negative actions is simply defining purposes for values that were previously undefined without any overhead.

[Jblade]

It still would be handy to have rather than having to add lots of projectiles to event egs, but if you're worried about the memory problems than that's understandable.

[Helixhorned]

Actually, projectile_t has six bytes of "filler" at the end to pad it to 64 bytes. They are thankfully not exposed to CON, so we can definitely pack a user member into there. Any suggestions for a good name?

[TerminX]

Well, my suggestion is something bluntly obvious like "userdata", but others may have different ideas.

[Jblade]

yeah my vote goes to userdata or userflags

[Fox]

Just call it filler.

[Helixhorned]

Alright, userdata it is then.

r3866 said:

CON: add projectile member .userdata and predefined label PROJ_USERDATA.

It is a 32-bit signed integer. No version bump necessary, although CON code
accessing this new member will not work with earlier revisions (obviously).

[Hendricks266]

Duke4 needs a Dopefish smiley so I can use it right now. In the meantime,

[Fox]

Is it possible to add an option to create the alpha channel of a texture from a separate B&W image?

[Plagman]

It doesn't make sense to add a feature for something that you can offline; it would just add bloat to the game code. There would be no runtime performance benefit either.

[Fox]

It has the advantage of working on the invisible parts of the texture.

[Plagman]

I don't know what you mean by that. Can you clarify?

[DavoX]

I know this has been brought up a million times but I wanted to check on it's progress... will it ever be possible to make sloped floor and/or alligned sprites? (within mapster32 without con) I saw some post from Hendricks that shows sloped or diagonal letters, maybe it's something related?

[Gambini]

What Hendricks showed was on-screen rotation and zoom.

[DavoX]

Ok my bad. So will it be available for mapster32?

[Fox]

Plagman, on 11 June 2013 - 07:37 PM, said:

I don't know what you mean by that. Can you clarify?

Some parts of the texture are invisible, i.e. 0% opacity. And that part might be displayed if, for example, you are using the texture as a wall.

[Plagman]

So what? What is the problem you're having exactly?

[Jblade]

Just wanted to say that the userdata thing works brilliantly; I've saved space and it's made things much simplier when it comes to adding new damage types. Before if I wanted to change what kind of attack a projectile does I would of had to of added tons of case specific code but now I can just change a flag and itll handle it from there (I should of done this from the start but of course I've been improving as I go along and coding systems rather than constantly making case specific stuff is one of those things I never really thought about doing until the last couple of years)

[The Lone Duker]

I'm using an xbox 360 controller on eduke I have every button set up like the xbox version the problem is the right stick I try to look left but it delays a little