[TerminX]

Using ifactorsound has about as close to no effect on performance as you can get; you would have to go out of your way to write exceedingly stupid code to ever get it to impact anything.

[Jblade]

Ok ok, I did have some problems with it when detecting a stereo ogg file so I was just checking to see.

[Micky C]

Is there a way of moving and rotating (by 90 degree increments) a large number of sectors without messing up the textures?

[supergoofy]

I've seen this: http://www.vogons.or...hp?f=24&t=52874

[Danukem]

I have a request: a command like rotatesprite16, but in which there is an xscale separate from yscale, allowing the drawing of sprites with dynamically changed xrepeat / yrepeat values.

[Hendricks266]

In the past I've gotten as far as trying to implement such a command but I could not decipher Ken's rotatesprite code in the software renderer.

[Danukem]

Hendricks266, on 19 March 2017 - 01:06 PM, said:

In the past I've gotten as far as trying to implement such a command but I could not decipher Ken's rotatesprite code in the software renderer.

Does that mean that you could implement such a command for the other renderers?

[Gambini]

I installed Windows 10 about a month ago. And since then, everytime i fire up mapster32 my keyboard layout is changed from spanish to english. This happens with both old and up to date snapshots and removing the mapster32.cfg doesn't fix it.

[Hendricks266]

This is what the behavior has been for years. I recently added switching whenever the window gains or loses focus, but it only works on Windows 7. Please add your opinion to this thread: https://forums.duke4...nput-requested/

[Danukem]

About sound CON commands. We have soundvar and stopsoundvar, but we don't have ifsoundvar or ifactorsoundvar, which makes for some ugly code when checking for sounds. We have to have a separate line of code to check for each individual sound number, since ifsound requires a hard number and won't take a var. Personally I think all of the "var" variants of command should be deprecated and vars should be made to work with all commands.

[Gambini]

Can skyboxes be scaled through def file?

If not, it´d be useful (and probably not that dificult) having the ability to scale them when defining them on the def file. I would love to have that because in my new Las Vegas map you get to see it from very different heights and there is no good tradeoff to adjust the horizon line so it looks right on both situations.

It could even be awesome and probably innovative, if you could scale it in all 3 different axis. x scale y scale z scale. This would allow modders to make short but big or long in one direction skyboxes.

Another thing is that i noticed that with the shadescale mode 2 voxels are still shaded the old open gl way. I already know this wont work on models for now, but what about Voxels?

Thanks for any time given to answer or address this.

[Hendricks266]

Gambini, on 24 March 2017 - 09:53 PM, said:

Can skyboxes be scaled through def file?

If not, it´d be useful (and probably not that dificult) having the ability to scale them when defining them on the def file. I would love to have that because in my new Las Vegas map you get to see it from very different heights and there is no good tradeoff to adjust the horizon line so it looks right on both situations.

It could even be awesome and probably innovative, if you could scale it in all 3 different axis. x scale y scale z scale. This would allow modders to make short but big or long in one direction skyboxes.

A skybox is what's called a cubemap. For example, Fox's skyboxes are built as 3D models, and he then rendered six images using special perspective and position settings. It is supposed to be the final result of what you see in-game. Any kind of modification to them at that point threatens to break the perspective illusion.

What you probably want is the ability to define your own 3D model to use as a skybox instead of a cube. I can't promise anything.

Gambini, on 24 March 2017 - 09:53 PM, said:

Another thing is that i noticed that with the shadescale mode 2 voxels are still shaded the old open gl way. I already know this wont work on models for now, but what about Voxels?

Thanks for pointing this out.

See my previous reply about applying tileshades to model skins. The system needs an internal revamp that I cannot prioritize at the moment. Please keep me informed of your release timeline.

[Gambini]

I understand what a skybox is, i have my own set of skyboxes for the mod but the cube is too small for what i need. I won´t add models as you say, although i can see how taht could be useful for others, so go ahead with it!

What i mean is: the cube where skybox textures are drawn is too small for my needs. It sure works great on small maps, but here we have three huge ass maps for which the cube is way too small.

So the idea is that you add a def parameter to scale the cube of a skybox when it´s defined, like this:

skybox {
   tile 84 pal 0
   scale 2
   top   "VEG_TOP.PNG" nocompress nodownsize
   down  "VEG_BTM.PNG" nocompress nodownsize
   front "VEG_NRT.PNG" nocompress nodownsize
   right "VEG_WST.PNG" nocompress nodownsize
   back  "VEG_EAST.PNG" nocompress nodownsize
   left  "VEG_SOUT.PNG" nocompress nodownsize
}

and with this:

Quote

It could even be awesome and probably innovative, if you could scale it in all 3 different axis. x scale y scale z scale. This would allow modders to make short but big or long in one direction skyboxes.

I mean something like this:

skybox {
   tile 84 pal 0
   xscale 1
   yscale 1
   zscale 2
   top   "VEG_TOP.PNG" nocompress nodownsize
   down  "VEG_BTM.PNG" nocompress nodownsize
   front "VEG_NRT.PNG" nocompress nodownsize
   right "VEG_WST.PNG" nocompress nodownsize
   back  "VEG_EAST.PNG" nocompress nodownsize
   left  "VEG_SOUT.PNG" nocompress nodownsize
}

So instead of a cube, you end up with a prisma of the given proportions. It is obvious that each texture face should be made to match its size, so it doesnt look stretched.

I can live with the first idea, but the 2nd would be the bananas!

Quote

See my previous reply about applying tileshades to model skins. The system needs an internal revamp that I cannot prioritize at the moment. Please keep me informed of your release timeline.

The sooner the better, we are about two months away.

[Hendricks266]

Gambini, on 25 March 2017 - 10:26 AM, said:

What i mean is: the cube where skybox textures are drawn is too small for my needs. It sure works great on small maps, but here we have three huge ass maps for which the cube is way too small.

So you're saying that your level geometry is clipping into the skybox?

Gambini, on 25 March 2017 - 10:26 AM, said:

So instead of a cube, you end up with a prisma of the given proportions.

Plagman can correct me if I'm wrong, but this is anathema to the idea of a cubemap. As I said, the proper way to approach this would be letting the user define their own 3D models to use as a skybox, so you could use whatever shape you wanted (rectangular prism, cylinder, sphere, etc).

Gambini, on 25 March 2017 - 10:26 AM, said:

The sooner the better, we are about two months away.

OK.

BTW, you only need "nocompress nodownsize" once per skybox.

skybox {
   tile 84 pal 0 nocompress nodownsize
   top   "VEG_TOP.PNG"
   down  "VEG_BTM.PNG"
   front "VEG_NRT.PNG"
   right "VEG_WST.PNG"
   back  "VEG_EAST.PNG"
   left  "VEG_SOUT.PNG"
}

[Gambini]

It doesn't clip but its proportional size is too small, it almost looks like it clips. Now i understand the usefulness of having models, i think that would be very useful.

Question: does the skbox´s position remain relative to the player view or to the map´s coordenates?

Quote

BTW, you only need "nocompress nodownsize" once per skybox.

noted.

[Mblackwell]

If your skybox appears too small for the map then that generally means you need a larger skybox projection (in other words the perspective is incorrect for the player's viewpoint/size). Changing the size or shape would still give you the same basic perspective projection.

As far as the position, the player's view is from the center of the cube and the cube/viewpoint never moves.

Here's a fun project to learn about cube maps with:
http://advsys.net/ken/kube/kube.htm

[tomo]

Hello i have a problem i think it's a known issue but im not sure, with the latest build running in polymost transparent textures have some kind of wierd alpha/transparency issue that makes the texture flicker and breaks the looks of many maps, it doesn't happen in software or polymer just polymost.

Thanks for your time.

[Hendricks266]

Thanks for the report, it's a known issue that is proving very difficult for us to address.

[Gambini]

Because of coding needs, we began to use up-to-date snapshots for our mod, and now i find there are tons of visual bugs in polymost, most of them are related to child sectors flickering. and so far one with a maskwall of which half of its face (split diagonally) flickers too:



The child, neighbour sectors visual flickering is very difficult to catch with screenshots. i did my best and only could capture one: (this didnt happen with the older build i was using, not at all):

[Gambini]

Ok, Trooper Dan suggested me to test with the debug versions and i found that it only occurs when running the 32bits no-debug build. It doesnt happen with the 64bits build, nor the 32bits debug build.

[Hendricks266]

I can't dig up the post right now, but I've spent hours looking at this bug, and my conclusion is that something has changed with the current generation of compiler versions, because with the right conditions I can trigger the same bugs in old SVN revisions dating back 7 or more years. Polymost's interface to OpenGL needs to be completely redesigned.

[Duke of Hazzard]

Gambini, on 27 April 2017 - 04:48 PM, said:

Because of coding needs, we began to use up-to-date snapshots for our mod, and now i find there are tons of visual bugs in polymost, most of them are related to child sectors flickering. and so far one with a maskwall of which half of its face (split diagonally) flickers too:

To my knowledge, Polymost has some bugs in vanilla, too, because I don't think they're caused by my hardware (lowly GT 740M laptop card).

Polymer doesn't run at 60 fps for me all the time, but I find it ultimately better as well as not requiring the high res content to look good.

[Tea Monster]

If it's anything to do with alpha/transparency, we had swapping PNG for targa files fix one issue for us, but that was a model, not a wall texture, and that was Polymer, not Polymost.

Might be worth a try though.

[Hendricks266]

Tea Monster, on 27 May 2017 - 12:04 PM, said:

If it's anything to do with alpha/transparency, we had swapping PNG for targa files fix one issue for us

Sounds like a PNG optimizer mangled "invisible" parts of your data channels.

[Mark]

IIRC it was a one time fix. Replacing others with TGA did nothing to fix the problem

[TerminX]

Would any of you have problems if I lowered MAXTILES down to a more reasonable number?

[Mark]

What is it at now?

[TerminX]

30720. If you had 30720 128x128 tiles you'd have 500 megs just in .art files.

[blizzart]

TerminX, on 11 July 2017 - 02:55 PM, said:

30720. If you had 30720 128x128 tiles you'd have 500 megs just in .art files.

I think AMC TC is using a huge number of tiles right now. You should ask James and his team before lowering anything, I guess.

If I will find the time some day and put all the textures, sprites and models into my Brute Force mod, it will end up using between 12000 and 16000 tiles.

[Hendricks266]

We need to make it dynamic, starting at the DOS MAXTILES (6144) and reallocating up to the current MAXTILES gradually. That's the real solution. Same with voxels. Same with everything really, just up to the point where it breaks Ken's hacks of stuffing multiple return values into one 32-bit integer.