[LeoD]

New nedmalloc version available:

Quote

v1.10 beta 3 17th July 2012:

[master 5f26c1a] Due to a bug introduced in sha 7a9dd5c (17th April 2010), nedmalloc has never allocated more than a single mspace when using the system pool. This effectively had disabled concurrency for any allocation > THREADCACHEMAX (8Kb) which no doubt made nedmalloc v1.10 betas 1 and 2 appear no faster than system allocators. My thanks to the eagle eyes of Gavin Lambert for spotting this.

[Mark]

Thanks. For us non-technical types, do we gain something noticable from it?

[LeoD]

Marked, on 19 July 2012 - 10:35 AM, said:

Thanks. For us non-technical types, do we gain something noticable from it?

If you're on a modern OS: most likely not.
WinXP/Linux 2.4 : maybe.
I'm not a technical type in terms of C programming but I wouldn't expect the game to run any faster except maybe for loading times and avoiding loading-related jerks if your PC is at its limits.

[LeoD]

Typing DNSHOWMAP always gives the message: "SHOW MAP: ON", never "OFF".


EDIT - Debian Wheezy 64bit compiler warnings:

source/sdlmusic.c: In function ‘MUSIC_Init’:
source/sdlmusic.c:157:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

src/driver_sdl.c: In function ‘fillData’:
src/driver_sdl.c:101:8: warning: pointer of type ‘void *’ used in arithmetic [-Wpointer-arith]

src/sdlayer.c: In function ‘getvalidmodes’:
src/sdlayer.c:957:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]


make LTO=1 :

engine.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters

obj/xdelta3.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters

[Fox]

How is the plan to control the animations before the level starts (like The Birth episode) or after you finish (like when you kill a boss) going in?

Right now I am forced to use some ugly hack that essentially freezes the game by setting all statnums to zero, unless I don't know a better way to do so?

[Hendricks266]

LeoD, on 20 July 2012 - 10:48 AM, said:

EDIT - Debian Wheezy 64bit compiler warnings:

For future reference, if you edit a six-day old post there will not be any attention drawn to it, and for those of us who use the "Go to first unread post" button it may not be seen at all. It's OK to have two posts in a row in a thread. If you have something new to add and time has passed, you can use discretion and make a new post.

I cannot fix these warnings myself because I do not have a Linux environment under which to test.

Fox, on 26 July 2012 - 04:31 PM, said:

How is the plan to control the animations before the level starts (like The Birth episode) or after you finish (like when you kill a boss) going in?

I don't have the code in front of me but I believe that actor code does not run when certain GAME_MODE / gm values are set, and it differs on single player vs multiplayer.

[Fox]

First of all, I have a question: how I am supposed to check if the ID of an player is valid? Something like sprite[].statnum MAXSTATUS but for a player...

Also I had like to request an orientation bit for "texture repeat", which would have the following effect:

[Hendricks266]

...You want us to add a flag to enable a bug that does not exist in the first place? I can understand aiming for accuracy in Resurgence, but this is going off the deep end.

Give us an example of an actual good reason to add this and then we'll think about it.

[Danukem]

Fox, on 27 July 2012 - 10:07 PM, said:

First of all, I have a question: how I am supposed to check if the ID of an player is valid? Something like sprite[].statnum MAXSTATUS but for a player...

Are you talking about the player ID, or the sprite ID of the player sprite? If you are talking about the player ID, then it will always be 0 in a single player game, and it will never be greater than the maximum number of players in a multiplayer game.

[Fox]

Hendricks266, on 28 July 2012 - 01:36 AM, said:

...You want us to add a flag to enable a bug that does not exist in the first place? I can understand aiming for accuracy in Resurgence, but this is going off the deep end.

Give us an example of an actual good reason to add this and then we'll think about it.

Huh? This has nothing to do with Resurgence (and I don't think Duke 64 render the bleeding of tiles like that).

I want it for drawing repeat patterns, which I eventually used for other projects like this:

[Micky C]

Can we put in spotlights that don't cast shadows yet? Is it in the works?

[Hendricks266]

Fox, on 28 July 2012 - 10:50 AM, said:

I want it for drawing repeat patterns, which I eventually used for other projects like this:

Ah, now that is a valid reason. Sorry about the confusion, the messed up pistol sprite threw me off. This would require engine code. IIRC, sprites are specifically coded to avoid the circular blending behavior.

[Plagman]

Rotatesprite already has a bit to set repeating, IIRC.

[Fox]

Which one?

[Reaper_Man]

Just gonna leave this here.

http://www.altdevblo...-native-client/
https://developers.g.../native-client/

[Fox]

I got an issue with a non-functioning SE in Eduke32. For some reason, the blue access card elevator in Spaceport map extracted from the Nintendo 64 ROM does not work, and it won't "teleport" you to the other point.

The map works fine with DOS version of Duke 3D. And if you copy the sectors on a new map it works just fine, meaning it has something to do with a superfluous component of the sector / wall structure (such as firstwall for example).

Attached File(s)

•  spaceport64.zip (31.95K)
  Number of downloads: 717

[Helixhorned]

Fox, on 04 August 2012 - 05:51 AM, said:

I got an issue with a non-functioning SE in Eduke32. For some reason, the blue access card elevator in Spaceport map extracted from the Nintendo 64 ROM does not work, and it won't "teleport" you to the other point.

The map works fine with DOS version of Duke 3D. And if you copy the sectors on a new map it works just fine, meaning it has something to do with a superfluous component of the sector / wall structure (such as firstwall for example).

This is one of those wacky cases where the behavior depends on the particular order of sprite indices (the most famous example probably being the order in which the cameras are cycled each time you "use" a viewscreen). Here's what happens: the warping elevator SE in sector 3 needs to determine when it can teleport the player and sprites contained in it to its matching sector. This is the case when no "hole" is visible from it any more. But the fake ceiling door, sector 178, is immediately adjacent to it! If its spawn-time code executes before the warp-elevator's one, the "door" will be closed and an engine function searching for the "next z step" fails. This is exactly what happens with the extracted map and EDuke32. Now, when you highlight the whole map from Mapster32 and copy it to a new one, currently the sprite index order is changed in general, and with this quasi-duplicated map, the SE17 runs first.^[*] So why does it work with the DOS or N64 version? I don't know for sure, but the two most natural possibilities are

• The order in which the two SEs run is reversed because of different order in which the code is run between EDuke32 and DOS/N64. I haven't compared the original DOS source with ours, but I'm leaning more to assume that they're functionally identical in this respect.
  
• That it works in DOS/N64 is coincidence. Currently, I have made EDuke32 terminate the the extracted level since, as noted above, the "find next z step" function fails, and moreover the resulting (invalid) sector index -1 was used to access the sector array, which is undefined behavior.

^[*]Side note: I screwed up with copy-pasting. Before r2965, some sector and wall members which are used for TROR functionality would get reset, regardless of whether the source or destination map had any TROR. Now, the bug still persists if the portion to be duplicated contains TROR, but I think its fix has to wait until the new map format.

[Fox]

Am I the only one who have a problem with hard-coded polymer lights in Eduke32? The developers are against using new art, but they are okay with these lights?

I know you can remove them through CON with some effort. But I believe they should come in a CON patch with HRP or something.

[Hendricks266]

It's not too hard for modders to account for it. I would have to say that it's better to include hardcoded lights because they are not really the addition of any other resources. SW's palswaps are stored in the source code. Plus, you would not have noobs whining why the Polymer checkbox only serves to make the game slower. On the other hand, it wouldn't cause the misinformed masses to think EDuke32=HRP and edit the Duke 3D Wikipedia article to say that xDuke and hDuke keep the original look of the game while EDuke32's updated graphics using OpenGL have high performance requirements that do not work on many computers.

[Fox]

Hendricks266, on 21 September 2012 - 04:01 PM, said:

I would have to say that it's better to include hardcoded lights because they are not really the addition of any other resources. SW's palswaps are stored in the source code.

They are. What are these RGB values based on? Who says that the Expander must emit orange light, and not red? Why the light of some explosions expand with the animation and others don't?

[necroslut]

The hardcoded lights should at the very least come with an option to switch them off. They're just way too big and as they shine through walls they give away secrets (the old "switch in the wall" trick), and fuck up countless of old of mods where tiles has been changed into something else, such as a green-glowing M16 or a switch without diods shining green/red.
I too find it a bit odd that while other features are rejected because it would harm compability, this thing seems to be fine with everyone.

[Fox]

I nocited that some actors run EVENT_ANIMATESPRITES in multiple instances (to make shadows, for example). If it was possible to control such feature, we could create effects such as mirrors in the floor, etc.

[Hendricks266]

What do you mean by control?

[Fox]

I don't know exactly how it could be done. Perhaps setting RETURN to 1 would force it to draw the sprite a second time?

[Hendricks266]

The issue with that would be that it would be easy to make an infinite recursion.

[Mblackwell]

Hendricks266, on 29 September 2012 - 04:55 PM, said:

The issue with that would be that it would be easy to make an infinite recursion.

The only way I could think of would be to add a new member that counts down if non-zero. Said member being the number of draws. ANIMATESPRITES would then let you check the value of this member to determine what you do with the extra draw (cancel it, alter it, etc).

It's really not a perfect solution however. And it definitely wouldn't really be useful in creating the effect you want (a mirror floor). The effect you want would be the ability to flip showviewunbiased (player's current view with y inverted) and then display it using DISPLAYROOMS and making the floor transparent. Currently not possible afaik however.

Really it's the kind of thing that should be done in the engine though.

[Fox]

Yeah, I guess if you could mirror horizontally or vertically (or even rotate) showview it would be possible to do any form of reflection.

Edit: I got a particular conflict... now we can change the current menu being displayed, so I can bypass the episode select screen. Buuut it became impossible to select a User Map. Would it be too much to ask to move the User Map option to the main menu?

[Hendricks266]

Fox, on 29 September 2012 - 05:59 PM, said:

Edit: I got a particular conflict... now we can change the current menu being displayed, so I can bypass the episode select screen.

Wait, how did you do that?

[Fox]

Primarily using this:

ifvare current_menu 100
  cmenu 110

[Hendricks266]

Where does that code go?