[DavoX]

Paul B, on 28 May 2013 - 03:08 PM, said:

Sorry Hendricks266, I don’t agree with you. Of course the mobile computing has dramatically improved but I believe mobile computing serves a small and limited purpose. For instance, my smart phone I use to check my e-mail but you will never see me button mash to create an e-mail and send it from my phone its a waste of time. I do not believe desktop applications such as map editors should migrate to portable miniature devices just to keep up to a trend. I also believe this mobile trend is a fad and I’ll be glad when the focus comes back to PC. In my opinion it’s a waste of freakin’ resources and time to fulfill what purpose? So that 2 or 3 people who can't sit in front of their computer can lay on their bed and map edit with a stylus? I am not on board with this idea as this software will never be a good fit for mobile computing and it’s a waste of time pursuing. Unless you plan on turning Eduke into a flash player based game and redoing the entire mapster interface into a drag and drop system.

Just a thought, maybe you could incorporate Mapster to work with Siri voice recognition. Then we could pump out Duke Nukem maps with dictation on mobile devices. Now that would be kick ass!

"Siri build sector by X, Y & Z coordinates! use floor tile 773 and wall tile 878". That could actually make things faster instead of using touch, keyboard and mouse functions to some degree.

Paul he's obviously making fun of my post. I guess you didn't turn on your sarcasm detector

[Hendricks266]

DavoX, on 28 May 2013 - 05:54 PM, said:

Paul he's obviously making fun of my post. I guess you didn't turn on your sarcasm detector

Me? I'm completely serious about Mapster32 Wii.

http://svn.eduke32.c...er32_meta_1.xml
http://svn.eduke32.c...er32_meta_2.xml

[DavoX]

Oh the wii... what a pain the ass it was developing for that console. I hope I never see one again in my life

(was using the torque 3d engine, which might've had a part in it being bad)

[Paul B]

DavoX, on 28 May 2013 - 06:29 PM, said:

Oh the wii... what a pain the ass it was developing for that console. I hope I never see one again in my life

(was using the torque 3d engine, which might've had a part in it being bad)

Even playing games on the Wii can be a painful process lol Watch out for my flying remote the wrist strap is for noobs.

[Inspector Lagomorf]

 Hendricks266, on 28 May 2013 - 06:11 PM, said:

Me? I'm completely serious about Mapster32 Wii.

http://svn.eduke32.c...er32_meta_1.xml
http://svn.eduke32.c...er32_meta_2.xml

So eDuke DOS was an April Fool's joke but Mapster32 Wii isn't?

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