[blizzart]

Hi folks,

after a lot of time I decided to get back to work on my EDuke-mod yesterday.

So I downloaded the latest 64bit builds of EDuke and put them into a copy of my mod folder. After firing up Mapster I noticed some issues. As my mod is one that uses 32bit textures and models, I noticed that all the textures in Mapster look pixalated.

See here:

I know this is a standard for Mapster and 32bit textures since ever. I fixed this years ago by changing gltexfiltermode in mapster32.cfg from 2 to 5, which showed me the textures in the way they are shown ingame.

See here:

By looking into the mapster32.cfg I saw, that gltexfiltermode was reset back to 2 automatically.

See here:


Second issue is the 2D-mode of Mapster. With an older build (r5056) sprites are colored:


while in the latest ones there are just white placeholders, which makes it impossible to see whether they are blocked or not:


I´ve tested this issues with builds back to the beginning of July 2015 (r5282) with the same result. The build, where everything works fine is r5056 from March.

Does anybody else has these issues and/or can somebody tell me how I can solve these problems?

Thank you in advance.

[The Mechanic]

blizzart, on 26 August 2015 - 03:24 AM, said:

Second issue is the 2D-mode of Mapster. With an older build (r5056) sprites are colored:
2d-mode-correct.jpg

while in the latest ones there are just white placeholders, which makes it impossible to see whether they are blocked or not:
2d-mode-incorrect.jpg

I´ve tested this issues with builds back to the beginning of July 2015 (r5282) with the same result. The build, where everything works fine is r5056 from March.

Does anybody else has these issues and/or can somebody tell me how I can solve these problems?

Thank you in advance.

I have this issue too. Could you do me a favour and check if r5265 works ? Reason I ask is that is the version I'm mainly using and that does the proper sprite colouring. The later version I use I built myself and I assumed was something to do with my setup and I was meaning to find out, but perhaps that now seems incorrect. Anyhow, if r5265 works for you then I'm guessing we may have the same issue.

TTFN,
Jon

PS : Sorry can't help re textures at this time.

[blizzart]

The Mechanic, on 26 August 2015 - 04:37 AM, said:

I have this issue too. Could you do me a favour and check if r5265 works ? Reason I ask is that is the version I'm mainly using and that does the proper sprite colouring. The later version I use I built myself and I assumed was something to do with my setup and I was meaning to find out, but perhaps that now seems incorrect. Anyhow, if r5265 works for you then I'm guessing we may have the same issue.

TTFN,
Jon

PS : Sorry can't help re textures at this time.

The 2D mode looks fine for me in r5265. But the problems with textures still remain.

[blizzart]

Just found this:

------------------------------------------------------------------------
r5282 | terminx | 2015-07-07 20:34:46 -0700 (Tue, 07 Jul 2015) | 10 lines

Mapster32 changes:

-2d mode sprite colors are now automatically generated from the sprite's 8-bit tile.
-Zooming in and out has been smoothed out.
-The 2d mode crosshair cursor is now 1px thick instead of 2.
-The left mouse button can now be used to select multiple wall points and sprites in 2d mode.
-Ctrl-x now skips corrupt maps instead of going into an infinite loop.
-'-L function in 3d mode works again.
-Sprites with a clipdist that has been changed from the default value of 32 will display a circular approximation of the distance in 2d mode. Note that the real clipping distance is actually closer to a square, but a circle looks much less confusing/stupid alongside the display of floor sprites.
-2d mode status bar has been made a few shades lighter.
-----------------------------------------------------------------------

Maybe this could be a reason for te 2D-mode problem???

[The Mechanic]

blizzart, on 26 August 2015 - 05:59 AM, said:

------------------------------------------------------------------------
r5282 | terminx | 2015-07-07 20:34:46 -0700 (Tue, 07 Jul 2015) | 10 lines

Mapster32 changes:

-2d mode sprite colors are now automatically generated from the sprite's 8-bit tile.

That could well be it, well spotted ! Had a think and can see the logic, it can be difficult trying to differentiate sprites in sprite-heavy constructions and this change could could in theory help. However in the attached two examples (from the lovely RedRock map) the new colouring doesn't help in the slightest and the third picture illustrates that there is little difference between dark and bright white tiles! In my opinion it is _way_ more important to know that the sprites really are blocking or not.

This breaking change really does need to be made optional (I hoped that was what r_usetileshades in mapster32.cfg was, but that is completely unrelated).

Whilst mooching around, I found some code that suggests that you used to be able to set the sprite colour via a script file ? It strikes me as this would be a better way since if someone were constructing a complex sprite structure they could define their own colours for the handful of sprites they'd be using and choose them such that they really stood out.

TTFN,
Jon

Attached thumbnail(s)

• 
• 
• 

[Helixhorned]

blizzart, on 26 August 2015 - 03:24 AM, said:

After firing up Mapster I noticed some issues. As my mod is one that uses 32bit textures and models, I noticed that all the textures in Mapster look pixalated.

In r5075, two cvars have been renamed:

• r_texturemode -> r_texfilter,
  
• r_textureanisotropy -> r_anisotropy.

[mono20]

blizzart, on 26 August 2015 - 05:59 AM, said:

------------------------------------------------------------------------
r5282 | terminx | 2015-07-07 20:34:46 -0700 (Tue, 07 Jul 2015) | 10 lines

Mapster32 changes:

-2d mode sprite colors are now automatically generated from the sprite's 8-bit tile.

I have trouble to get used to the new 2d mode sprite coloring in Mapster32. Most sprites are now represented by white or light gray icons which doesn't help for overview. To me the sprite's ingame color in this mode is less useful than information about the sprite type or whether it blocks or not. If some people prefer the new display I'd ask for a choice between both systems in the config.

Thanks in advance,
m20

[Micky C]

I agree, the old colour scheme was much better for mapping. It's hard to tell different sprites apart in the way you want.

[The Mechanic]

Micky C, on 21 October 2015 - 02:29 AM, said:

I agree, the old colour scheme was much better for mapping. It's hard to tell different sprites apart in the way you want.

I did a patch a while ago to bring back beloved old purple/green but couldn't get some of it consistent - changes to the code meant it wasn't as simple as adding a flag to run the old version, so I'm having a ponder. I missed a couple of things too.

Helixhorned made the valid argument that some sprites - SE, M, A etc - as well as switches have enforced blocking flag states regardless of how you set them in mapster. These could be left as white (which is new colour scheme - well, for SE,M etc although the background flashing to black so I cant read the black text is annoying). This has the big advantage of quickly being able to differentiate between "control" sprites and decoration. What do others think ? White for special sprites, or be totally consistent and use old green/purple system but maybe make it so that if you try to set/clear blocking flag on a sprite that will ignore it then mapster ignores your change (with suitable message)? I think the latter would certainly be better for new mappers, whilst the "white" version I think is more generally useful. Anyhow, what I say will carry little weight as I haven't released a map, I think those that have a proven map making track record should suggest how they'd prefer it.

I did try to run with the new system but only found it useful for looking at other peoples maps - (ah, so _there's_ the switch"). But when it comes to creating a map I found the new system unusable.

One other concern is also changes to wall colours, with blocking walls now flashing between reddish-purple and red when you go anywhere near them (mentioned in another thread)(haven't checked very latest builds). I'm hoping that is just a bug that has slipped in - I suspect it might be as some times newly created red walls appear white !

TTFN,
Jon

[Paul B]

Yea i'll weigh in too since I always try to run with the latest synthesis build. I too am not fond of the new coloring scheme in 2D mode, I find it difficult to tell if a wall \ sprite is blockable or what sprites are what? I definitely preferred the old way, I feel lost in the new color scheme but I thought it was just me and when I spoke to Terminx about the new look he gave me the impression that most people welcomed the new change.

[mono20]

I came to find the new sprite display useful in certain situations. When you have a cluster of sprites (i. e. letters) you can temporarily mark some of them adding a different palette for easier finding and editing in 2d. I still think it would be cool to be able to switch between the display modes in 2d, maybe by key if there's one left unassigned...

[Mark]

I only recently started using newer builds and I don't like the changes. But it might just be because I was used to the old ones for so long. I'll withhold any final conclusion until after I have used it for a while. It may turn out for the better.

[Kyanos]

I also just returned to mapster32 after a short exodus from mapping.

I'm not sure yet about the sprite colors if I like or dislike.

The purple blocking wall, flashing red when highlighted I do not like.

The sprite text info flashing black when highlighted I do not like.

These are my 2 cents on the subject. Nothing was a make or break deal for me, so I wouldn't have brought it up if this thread didn't already exist.


edit;

still have that problem where I pick a tile for a floor or wall (in 'v' mode) and sometimes, seemingly randomly, it sets it to the next tile number instead... I swear it was reported a while ago, at least a year now.

[Kyanos]

here it is

Micky C, on 03 March 2014 - 01:58 PM, said:

I'm also still getting the issue where if you choose a tile from the selection screen, sometimes it actually places the next tile up.

[TerminX]

Drek, on 29 October 2015 - 02:57 PM, said:

The sprite text info flashing black when highlighted I do not like.

That's a bug.

[The Mechanic]

TerminX, on 29 October 2015 - 06:17 PM, said:

That's a bug.

Can you also confirm the peculiar white walls is a bug ? This is repeatable and survives a map save/load and can only be gotton rid of by toggling the blocking bit twice. 'F8' does not reveal any obvious changes. The bug appeared about the same time that blocking walls started to flash red which I assume is also a bug ?

TTFN,
Jon

PS screenshots are using r5400 but earlier versions also exhibit the same behaviour.

Attached thumbnail(s)

• 
• 

[Paul B]

Release notes from r5430 & r5429 appear to indicate that the classic look of Mapster has been restored through the use of a customized setting. Any ideas how we can toggle this back to the original default color scheme ? I can't seem to make this work.
Thanks!

[Helixhorned]

Paul B, on 15 November 2015 - 06:16 AM, said:

Release notes from r5430 & r5429 appear to indicate that the classic look of Mapster has been restored through the use of a customized setting. Any ideas how we can toggle this back to the original default color scheme ?

It hasn't been restored, I just added a Mapster32 DEF command along with some tweaks that allow emulating that scheme. The file tiles.cfg, packaged in the synthesis zip, contains instructions. The important part is that the DEF gets loaded, e.g. by passing its file name as a positional argument to the mapster32 executable:

mapster32 my_own_mapster32.def

and that you uncomment the section marked "[OLD_COLOR_SCHEME]" with the hidden "All" tile group.

The necessity of specifying the DEF file is somewhat clunky. As an alternative, I thought about exposing editorcolors[] to m32script (allowing it to be altered from m32_autoexec.cfg), or simpliy making the editorcolor[] index -> actual color index mapping from 33 onwards hard-coded by default. The directions in tiles.cfg provide some pointers for exploration. For example, check out the "do set showpal 1" mode to see the loaded base palette and the editorcolors[] mapping.

One important change to the coloring scheme is that when an object is highlighted, color indexes are offset in the range [0 .. 4] with respect to the base one. Thus, you can't really use the last 16 (fullbright) colors, only the gradual "ramps" of the Duke3D palette.

[LeoD]

Another zombie bug

It has been reported recently, but I failed do dig up that post.

Some floor aligned sprites show up distorted in Mapster32's 2D mode when graphicsmode is set to 1 or 2:

I assume that only animated sprites are affected. Example map: Alien Controlpoint at x1152 / y29952.
Issue introduced by r1197.

[Paul B]

Helixhorned, on 15 November 2015 - 07:18 AM, said:

It hasn't been restored, I just added a Mapster32 DEF command along with some tweaks that allow emulating that scheme. The file tiles.cfg, packaged in the synthesis zip, contains instructions. The important part is that the DEF gets loaded, e.g. by passing its file name as a positional argument to the mapster32 executable:

mapster32 my_own_mapster32.def

I did manage to restore the color scheme (bright orange and purple blocking sprites) thanks to your advice, some sprites don't seem to inherit the color code (AI & Item Inventory sprites). At least now i know which of the majority of the sprites are block able and which aren't. Thank you for the provided update, as I can streamline the process to restore some functionality. However, it is still not quite the same as the original classic mode since the flashing of the selected sprite item is black and difficult to read when said sprite is selected. It might just be easier to continue using a previous synthesis for the time being until some of the kinks are worked out.

[Helixhorned]

Paul B, on 16 November 2015 - 06:35 AM, said:

I did manage to restore the color scheme (bright orange and purple blocking sprites) thanks to your advice, some sprites don't seem to inherit the color code (AI & Item Inventory sprites).

Yes, deliberately in the case of the packaged tiles.cfg. The "All" tile group comes after the few other ones that specify 2D colors: "Actors", "Effectors", "Items" and "Player". If a color has been assigned to a tile via this system, it will not be reassigned again (since r5430). Hence, if you move the "All" group to the top, you'll get orange/purple for all tiles.

Quote

However, it is still not quite the same as the original classic mode since the flashing of the selected sprite item is black and difficult to read when said sprite is selected.

That's not intended. It being black suggests that maybe editorcolors[] had not been set up properly. (Though you wouldn't have gotten the orange/purple then, either. Huh?)
Since r5433 you can also do this setup from m32_autoexec.cfg.

[Paul B]

I was In the middle of mapping when Mapster decided to crash. Please see the attached logs for the reference to the crash.

When in Mapster 2D mode from a fresh install folder with only the Duke.GRP file and the latest synthesis file my screen has a red hue in 2D grid mode. If I take a screenshot of the screen and look at the screenshot the coloring is perfect. However, both the output HDMI to my TV and VGA to my monitor show this red hue\haze in Mapster 2D grid mode only. 3D Mode looks fine. Out of curiosity i started up Build and it looks fine in 2D mode.

*** UPDATED *** EDuke Synthesis Release 4249 was the last published release where the 2D Grid looks normal and clear. Eduke Synthesis 4254 introduces this problem.

Sorry, I think this post is already related to what I posted here: https://forums.duke4...090#entry251090

Attached File(s)

•  mapster32.crash.log (5.01K)
  Number of downloads: 535
•  mapster32.log (1.82K)
  Number of downloads: 526

[zazo]

Paul B, on 15 November 2015 - 06:16 AM, said:

Release notes from r5430 & r5429 appear to indicate that the classic look of Mapster has been restored through the use of a customized setting. Any ideas how we can toggle this back to the original default color scheme ? I can't seem to make this work.
Thanks!

I would like to know if there is a way to configure the color scheme for the walls in 2d mode ? in order to better differentiate between blocking and non-blocking walls: on my screen, the non-blocking walls are red and the blocking walls are in purple: two colors too close to make the distinction easy....
how to do this ?
An idea ? Thank you in advance !

[Paul B]

zazo, on 17 January 2021 - 06:16 AM, said:

I would like to know if there is a way to configure the color scheme for the walls in 2d mode ? in order to better differentiate between blocking and non-blocking walls: on my screen, the non-blocking walls are red and the blocking walls are in purple: two colors too close to make the distinction easy....
how to do this ?
An idea ? Thank you in advance !

There was a way to sort of make it a bit better but uncommenting / restoring lines in a config file but if I remember correctly it wasn't quite as good as the original look. In all honesty the easiest way is just to keep a new build of Eduke32 and use the old version of Mapster. Most people are probably doing this anyway beacuse it was around the same time when they started messing with the color scheme in Mapster the entire editor went downhill and you'll probably find less problems with older builds than in the newer releases. The build I am currently is: r4879

But if you still want to try reverting colors even though its not perfect and i'm not sure if it still applies you'll need to follow Helix's advice:

Helixhorned, on 15 November 2015 - 07:18 AM, said:

The file tiles.cfg, packaged in the synthesis zip, contains instructions. The important part is that the DEF gets loaded, e.g. by passing its file name as a positional argument to the mapster32 executable:

mapster32 my_own_mapster32.def

and that you uncomment the section marked "[OLD_COLOR_SCHEME]" with the hidden "All" tile group.

The necessity of specifying the DEF file is somewhat clunky. As an alternative, I thought about exposing editorcolors[] to m32script (allowing it to be altered from m32_autoexec.cfg), or simpliy making the editorcolor[] index -> actual color index mapping from 33 onwards hard-coded by default. The directions in tiles.cfg provide some pointers for exploration. For example, check out the "do set showpal 1" mode to see the loaded base palette and the editorcolors[] mapping.

One important change to the coloring scheme is that when an object is highlighted, color indexes are offset in the range [0 .. 4] with respect to the base one. Thus, you can't really use the last 16 (fullbright) colors, only the gradual "ramps" of the Duke3D palette.

[Doom64hunter]

zazo, on 17 January 2021 - 06:16 AM, said:

I would like to know if there is a way to configure the color scheme for the walls in 2d mode ? in order to better differentiate between blocking and non-blocking walls: on my screen, the non-blocking walls are red and the blocking walls are in purple: two colors too close to make the distinction easy....
how to do this ?
An idea ? Thank you in advance !

Create a file called "duke3d.def", if it doesn't already exist. Add the following line to it:

2dcol 5 0 128 256

The blocking line color is now light blue.