[TerminX]

Something between 4280 and 4284 is breaking yellow keycard locks, haven't had a chance to really diagnose it yet.

Edit: nm, found it.

[Fox]

For the sake of saving some memory, shouldn't the game not compile gamevars (not pre-defined) if they aren't used in the CON? Of course all unused gamevars should be removed from CONs as of now, but this optimization wouldn't hurt.

[Hendricks266]

I was already contemplating an optimization pass to cover

1. demoting per-actor and per-player gamevars to global when it can be determined their per-actor/player status is unused
2. automatically identifying whether individual gamevars need to be transmitted over the network or not

so unused variable removal would fit right in. Anything else you can think of?

[Fox]

I had like to have a new command to define gamevars that can specify the size. It's common to use a gamevar for a simply yes or no check, and 32-bits is a waste...

[TerminX]

Hendricks266, on 06 February 2014 - 11:45 AM, said:

2. automatically identifying whether individual gamevars need to be transmitted over the network or not

Negative on that one... clients will not be executing CON code in the same way the server does at all, so there's not much identification to be done. Clients will run display events but it's not logically going to work to just flag every variable accessed within a display event. People programming multiplayer mods will be expected to organize their game state data in such a way that small bits can be passed to the client as hints to guide the client's simulation of the server state.

Shit, it's almost like people will be expected to utilize actual programming techniques where EDuke32 doesn't hold your hand and just doing whatever you want will give poor results.

[Fox]

TerminX, on 06 February 2014 - 02:07 PM, said:

clients will not be executing CON code in the same way the server does at all, so there's not much identification to be done.

Please provide a pratical example, I want to understand how that will work.

[Jblade]

It doesn't sound much different from the sync days where it just required testing to get things to work properly. We'd play a game of the AMC TC, it would sync out at some point, we'd try and recreate it and then I'd go in and fix it. It's a pain but if you want to code multiplayer than you'll need someone else...and I imagine it's not worth working on till the new multiplayer is actually here (apart from common practices like keeping display variables seperate from gameplay stuff, .etc)

[Hendricks266]

TerminX, on 06 February 2014 - 02:07 PM, said:

Negative on that one... clients will not be executing CON code in the same way the server does at all, so there's not much identification to be done. Clients will run display events but it's not logically going to work to just flag every variable accessed within a display event. People programming multiplayer mods will be expected to organize their game state data in such a way that small bits can be passed to the client as hints to guide the client's simulation of the server state.

I insist you hear me out.

The identification would happen on the server side. The identification code for network transmission would work much like my idea for per-actor-->global demotion. By default, the transmit status of all gamevars would be false. Gamevars used in display events would be marked true. Then, any gamevar for which its first use in all delimited blocks discards the current value (like a get<struct> or setvar command) is marked false.

I assume the primary issue is keeping the size of packets as small as possible. To that end, gamevars would get a tracker system much like what the map structs have so that they are only transmitted when modified.

If the CON scripts have a fuckton of variables that never change (the ubiquitous make variables for every parameter passed to rotatesprite) then said constants would only be transmitted one time, when gamevars are initialized, even though they would be flagged as "transmit".

A secondary issue is that network transmission may not be sufficient for certain variables, such as weaponcount. However, addressing this issue is separate from automatic gamevar network transmission.

The only circumstance that I can see where my idea would be outright "negative" would be if client screen implementation was redesigned in such a way as to require all-new CON structure (requiring updates for ALL display mods to function over the network), such as an event where variables like weaponcount can be augmented whenever the client performs a "fake" game tic (basically a cut-down "onevent EVENT_GAME ifactor APLAYER { } endevent"), and therefore any and all existing gamevars would be useless to transmit over the network.

[Helixhorned]

Fox, on 06 February 2014 - 11:22 AM, said:

For the sake of saving some memory, shouldn't the game not compile gamevars (not pre-defined) if they aren't used in the CON? Of course all unused gamevars should be removed from CONs as of now, but this optimization wouldn't hurt.

Good idea with finding these. Starting with r4299, LunaCON adds two new warnings, -Wnever-used-gamevar and -Wnever-read-gamevar. They are not enabled by default: many CON mods in the wild contain a spamgenic amount of these gamevars. Also, they are not automatically removed from the code: memory-wise, what matters most are per-actor gamevars in C-CON. In LunaCON, they're implemented in a sparse fashion, meaning that they only use an amount of memory roughy proportional to the number of non-default values stored in it.

Fox, on 06 February 2014 - 12:35 PM, said:

I had like to have a new command to define gamevars that can specify the size. It's common to use a gamevar for a simply yes or no check, and 32-bits is a waste...

For the occasional global gamevar, you shouldn't feel bad using a 32-bit int even if it's only used in a boolean sense; the memory "waste" is negligibe. Again, if you want an array of booleans, using a CON gamearray (or per-something gamevar) is suboptimal. However, there's a simple trick: just consolidate up to 32 variables into one by using bit-wise operations. Like this:

gamevar tmp 0 0
gamevar actorprop 0 2  // various per-actor boolean properties

define APROP_ISAPIG 1
define APROP_CANFLY 2
define APROP_VERYDANGEROUS 4

useractor PIGCOP // ...
    getactorvar[THISACTOR].actorprop tmp
    orvar tmp APROP_ISAPIG
    ifvare sprite[THISACTOR].pal 21
        orvar tmp APROP_CANFLY
    setactorvar[THISACTOR].actorprop tmp
enda

(Untested, but you get the idea...)

[Fox]

I already use that trick, but there are cases at which it is not possible. Also it's not just with booleans, for example there are gamevars to store an actor owner or tags which don't require 32-bits.

But I do realize now a problem with what I was asking, here is an example:

  getplayer[THISACTOR].random_club_frame shade
  andvar shade 2047
  sin shade shade
  mulvar shade -1
  addvar shade 16384
  divvar shade 1024

This is the code I use to make the Shrinker / Expander crystal glowing... while at first I would assume shade is a gamevar that would only require 8-bits, on practice I use it for some calculation that overcome that limit for the sake of not using temporary variables. So the limit on gamevars should be reinforced only at the end of the actor / event, and I am not sure how feasible that is.

[TerminX]

Hendricks266, on 06 February 2014 - 04:55 PM, said:

The only circumstance that I can see where my idea would be outright "negative" would be if client screen implementation was redesigned in such a way as to require all-new CON structure (requiring updates for ALL display mods to function over the network), such as an event where variables like weaponcount can be augmented whenever the client performs a "fake" game tic (basically a cut-down "onevent EVENT_GAME ifactor APLAYER { } endevent"), and therefore any and all existing gamevars would be useless to transmit over the network.

This is pretty much the case. Nearly every mod will require updates to be usable with EDuke32 multiplayer... it just is what it is. None of them are programmed with any of the restrictions in mind that apply to a client/server setup where updates are actually transmitted, instead of events simply being expected to occur in an identical fashion on all players. Some of the stuff CON lets you do is just not going to be compatible with this.

[Jblade]

Where do we get a lunatic build of mapster? The things on the synthesis only have the eduke32 exe and the normal SDK doesn't contain any kind of lunatic mapster.

[Fox]

So I noticed that now the bonus screen says "N/A" if there are none (or negative?) enemies left. Wouldn't it be better to fix the whole messed up kill count instead? I see, it's the Damn I'm Good skill.

[Jblade]

Just asking again, where do we get a mapster32 build with lunatic? The zips on the synthesis don't contain any mapster32 exes.

[Micky C]

There are separate lunatic zips in each synthesis folder. I don't blame you for missing it because quite frankly it's hard to navigate that thing with all those file names that are virtually identical but with slight differences.

[Jblade]

Micky C, on 12 February 2014 - 03:07 AM, said:

There are separate lunatic zips in each synthesis folder. I don't blame you for missing it because quite frankly it's hard to navigate that thing with all those file names that are virtually identical but with slight differences.

The only lunatic zips I see are 32bit and 64bit versions, with no mention of a mapster32 version. If there's a direct link I'd love to have it, since if this new additive/blending modes still work with CON than it'll be invaluable.

[Micky C]

You're right, there is no mapster32.

I have to say, the whole separated-out structure of the SVN is a real mess at the moment, there has to be a better way to organize/present it. There are loads of people on the megaton forums asking "where's mapster32?" since it's not included any more, and there's no indication there's a separate zip(s) on the eduke32 website.

[Nukey]

Separating mapster32 at all was a bad idea.

[The Commander]

Micky C, on 12 February 2014 - 03:51 AM, said:

You're right, there is no mapster32.

I have to say, the whole separated-out structure of the SVN is a real mess at the moment, there has to be a better way to organize/present it. There are loads of people on the megaton forums asking "where's mapster32?" since it's not included any more, and there's no indication there's a separate zip(s) on the eduke32 website.

Nukey, on 12 February 2014 - 09:05 AM, said:

Separating mapster32 at all was a bad idea.

[TerminX]

Nukey, on 12 February 2014 - 09:05 AM, said:

Separating mapster32 at all was a bad idea.

My original intention was to separate out all of the sample data that 99.999% of users never use... I don't necessarily think separating out mapster32.exe itself was a good idea either.

[Nukey]

The original intention makes sense, but I think having them in a separate sample folder was good enough.

[MetHy]

The one thing that got everybody to make maps for Duke3D back in the days was that the level editor was in the folder of the game...

[Nukey]

Exactly

[Hendricks266]

The samples folder 7-zipped is 55.9 KB. With my next SVN push, eduke32-sdk packages will be gone and reintegrated into the main download. The net download size for someone who wants both will be smaller because 7-zip will compress out the redundant engine and libraries (SDL, FLAC, etc).

If the lack of a package containing only eduke32.exe actually bothers any users in practice, we can see about making that available too. Really though, if file size is a concern, it's not that hard to set up your own synthesis.

Packages will still be separated based on architecture (32-bit/64-bit) and release/debug. That will keep the file size mostly down.

[The Commander]

"simple" people just want a download with eduke and mapster in one zip, they are not going to go to the lengths of learning how to compile it themselves just for that.

[Nukey]

I think most people in general prefer it that way. When I have a hundred things to do and upgrading a program is one of them, the last thing I want to do is track down two separate halves of it.

[Helixhorned]

Hendricks266, on 11 February 2014 - 11:43 AM, said:

Or not, because I still intend to implement .alpha in classic as an analog of the OpenGL alpha.

Well, then you'd either have to
* calculate the 128 blending tables at startup, which takes a couple of seconds even in the release build (it's 2²³ engine.nearcolor() calls, after all), or
* package the extended PALETTE.DAT as part of EDuke32.

Both options have their problems. The central one I see with hard-coding the functionality is that you take away resources from modders. With blending tables 0 + 1..128 taken, there are only 127 more left. What if a mod author wishes to implement 255 levels of blending, but using a different formula than the usual alpha translucency? Keeping the core functionality availble but giving modders its full potential seems to be most in line with the modding spirit of EDuke32.
Besides, when using .alpha, you already commit yourself to having custom scripting code. In that setting, having the few lines of additional code for the alpha -> blend+cstat translation is a non-issue.

Micky C, on 12 February 2014 - 03:51 AM, said:

You're right, there is no mapster32.

Oops, riiiiiight. I omitted it from the Lunatic package earlier since I didn't want anyone creating map-text maps yet. Starting with r4330, the synthesis package contains Lunatic Mapster32, but without the ability to save TROR maps.

[Hendricks266]

Helixhorned, on 12 February 2014 - 02:34 PM, said:

Well, then you'd either have to
* calculate the 128 blending tables at startup, which takes a couple of seconds even in the release build (it's 2²³ engine.nearcolor() calls, after all), or
* package the extended PALETTE.DAT as part of EDuke32.

It would be completely independent of .blend. That way, users could define those any way they want and have the same range of functionality with 8-bit assets in all the renderers.

The how of it is undecided. I generally use the Wii as my worst-case scenario. 256 colors * 256 colors * 128 degrees of translucence = 8 MiB! That's not acceptable.

Since palettes only use 0-63 anyway, we could limit alpha to intervals of 4. 2 MiB isn't as bad, but it still requires more investigation.

Perhaps the transitions could use some form of RLE...

[Micky C]

If eduke32 is going to calculate the tables at startup, maybe the player can be given the choice as to whether they want the improved translucency or classic? Then if a modder wants to use them, they can then just include it with the mod since it'll probably be a fraction of the mod's size anyway.

But can I request that the last day or two of posts in this thread be moved to the eduke32 thread? This thread has been seriously off-topic lately.

[Fox]

Since we are talking about palettes and tables, what about making it possible for a mod author to include their own palettes or lookups without relying on some obsolete PALETTE.DAT editing? Akin to how we use tilefromtexture now instead of EDITART.