[TerminX]

Mapster32 for Wii was just a matter of fixing a couple of things that caused it to crash at startup (we've had EDuke32 on the Wii for several months). Porting EDuke32 to DOS would take significant effort.

[NightFright]

Issues with r3839:
- "Version Mismatch" for savegames saved with r3831 (that's the last version I tried before this one)
- Level stats not shown any more

[Micky C]

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

- "Version Mismatch" for savegames saved with r3831 (that's the last version I tried before this one)

Isn't it expected that savegames don't necessarily stay intact when playing them with different versions of eduke32?

[Mateos]

Well, I believe the save system isn't altered each 3 versions? So there shouldn't be any version mismatch issue that often :/

[Hendricks266]

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

- "Version Mismatch" for savegames saved with r3831 (that's the last version I tried before this one)

That's generally not an issue that needs reporting. In this case, BYTEVERSION had to be bumped because the DynamicSoundMap array had to be added to savegames.

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

- Level stats not shown any more

My bad.

[Fox]

Level stats or alternate HUD are the kinda of thing that I believe should be used as a CON mutator included by default instead of being hard-coded.

[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?