[oasiz]

Updated 10/1/2021


TL;DR
Makes mapster work with SW while adding a ton of additional stuff, with few omissions aside (i.e. FAF preview) you will get pretty much the best way to edit SW maps.
Get the latest version from: https://lerppu.net/s...w-scriptset.zip

NOW ->  v7 Fixes an oversight for TAG15 input, allowed range is now much higher.
v6 - Changes to mapster32, allow TAG4 editing beyond 2048. Fixing the last major omission compared to DOS editor. Practically feature complete.
v5 - Adds BREAKABLE SPRITE, TRACK and GRATING documentation. TAG3 now treated as unsigned (0-255) during number input. Repeat tweaks to evil ninja
v4 - Proper documentation and custom handling for SO BOUND Upper/Lower etc..
v3 - Updated mapster32.exe with correct scale and increased maxquotes. Walltag/ST documentation added & Fixes to MP sprite display. Add fullscreen display of all common tags
v2 - Added more 3D visuals for tags, 2D documentation, 2D tags for ST1

Brief
As SW's aging DOS build is starting to get quite cumbersome to use and SWPBuild is getting quite old as well at this rate, I kind of wanted to take a shot at fixing this.
This started out as a personal curiosity and also main motivation was to get a tool done that can bring more fun in to SW mapping, as mapster32 is quite powerful these days with it's scripting and features.

Initial goal was to tack in missing features from SW to Duke3D editor codebase. This has resulted in an editor that can utilize GL mode, scripts and such for SW map editing, base support was just the beginning as I have started to move on to features that can hopefully bring SW mapping closer to a true "next step" rather than a curiosity.

Pictures generally tell the most.

What used to be without scripts on the left now has custom icons, proper sprite shading, auto-sizing, etc..


Key features

- In-editor documentation for ST1 sprite hitags using what I've dubbed "Q_MENU" system
- tprite modifications:
* Sprites take proper ceiling/floor shades, mirroring SW behavior where they are offsets
* Highlight sprites as fullbright if targeted and hotkeys are being held
* Display pickups and such with the proper repeat values
* Apply voxel spinning if enabled
* Skill preview, applies cstat + pal
* Visually represent ST1 sprite hitags with editor specific tiles
* MP Item preview
- Represent booleans visually and allow easy toggle without modal input
- SW Skill preview ability and show enemy skills when hovering on top
- Complain about incorrect repeats for sprites that do not get autosized in-game
- Custom handler for underwater palette preview
- Custom Top HUD quote system that tells status messages
- Custom mouse HUD quote system that displays messages near cursor
- Force any new sprites to have extra of "2", which is HARD skill
- Warn when opening a map with force overrided visibility
- During save, fix any walls that lack wall extra of 0. This fixes issues with moving SO.
- SO Bound sprites will draw a rectangle for the bounding box
- Documentation for walltags, grating, breakable sprites, sector tags, etc..

Features demonstrated

Hover on top of ST1 sprites to see documentation about them, including tag values and how to use them


All major tags documented, however this is still WIP and some of the bounding tags, etc.. will have better documentation.
Some of the documentation notes will cut short as they need to be rewritten.


Proper palette for fog and underwater


The palette for fog is based on Fogpal values that were found in source code and underwater had to be ripped from the video memory (PCXs thankfully store this)


3D mode skill preview


On the top left you have a skill preview notification when enabled, any enemies that are above current skill will have a skill specific PAL applied and show as transparent.


Tagging tags 1-15 in 2D or 3D mode, also can be applied to selected sprites in 2D in bulk!




New Boolean tagging


A new boolean tagging sytem is used in 2D and 3D modes that uses the same key (colon) but no longer asks to input 1 or 0, instead the button is toggled instantly on/off.
This now only speeds up boolean use but also shows instantly the status.
NOTE: This is currently not friendly with resolutions other than 1920x1080, you will see visual gaps on lower resolutions. WIP.


10+ new 3D keys, that might be familiar to Fury map editor users




Pickup sprite repeat "watch" and multiplayer handling


Most pickup sprites in SW get auto-sized on map load but many do not.
This results in many inconsistent sprites around the base game and this can be used to help you with adjusting sizes correctly.
What this means:
- Sprites that DO get auto-sized will also be visually forced to a certain size no matter what you do (like SW Build does)
- Sprites that do NOT get auto-sized will flash red instead and you can use ALT + C optionally to resize these to the internal default of 64,64


ST1 visual wrangler


One of the nicer new features, this will visually map editor-specific tiles to 20k range and these get swapped to ST1 sprites based on their hitag (function) visually!
Now there are only some of the most common ones covered for now but goal is to have quite a few more, this can really ease with those clusters of 40 ST1 sprites.




Status

This is considered stable for everyday use, based on testing done by me and Methy.
Confirmed to work on complex FAF testing, drivable SO stuff and so on.
Although a clause always remains that make backups!
Base feature set is implemented about 99%,
missing: "Global VIS" adjustment, this can be modified but editor preview doesn't support it. AND FAF preview. These are only in-editor visuals mind you, not deal breakers.
There are tons of SW-specific extra features that add convenience and QoL beyond the original editor, enough to speed up mapping a lot!

NOTE: SW uses .extra on sprites for booleans and other things, ONLY modify .extra through official means!
Avoid using F8 menu as some tags are 16bit entries split in to two and some are two 8bit combined.
Only use intended tagging/bool keys outside of hitag/lotag !
Also voxels when aligned on walls might exhibit slight size differences due to cstat differences between .def token voxels and SW voxels.


Thanks

Methy, helped a lot with the testing and feedback.
Hendricks266, Provided lookup.dat for alt palettes


Download / Usage

https://lerppu.net/s...w-scriptset.zip

Extract these on a SW Dir (tested against a GOG copy).
---> Optional: Get the latest VoidSW (bundled with eduke) and place the .exe in the dir, playtesting has been configured for this.
Run mapster.bat

Script set should be loaded automatically.

SHARED 2D / 3D
QUOTE + 1 - 9, 0        Modify TAG 1 - 10
QUOTE + SHIFT + 1-5     Modify TAG 11 - 15  (original SW bind)
QUOTE + Q - T           Modify TAG 11 - 15  (New, QOL bind)
QUOTE + X               Toggle voxel spin

COMMA + 1 - 9, 0        Modify BOOL 1 - 10
COMMA + SHIFT + 1       Modify BOOL 11  (original SW bind)
COMMA + Q               Modify BOOL 11  (New, QOL bind)


2D MODE specific
TAB in 2D               Show walls left
N in 2D                 Display extended note info for Q_MENU
SHIFT                   Display wall tag info and focus on wall tags instead of sector
SHIFT + CTRL + ALT	Display all common tags (quick reference)


3D MODE specific
TAB                     Read values in to clipboard (Y panning, slope, Floor/Ceiling Z)

RIGHT SHIFT             Clear selections inherited from 2D mode for most new stuff
SHIFT + Y               Paste slope from clipboard
SHIFT + U               Fine Z up: Raise selected/pointed sector(s) or sprite(s) by one unit
SHIFT + J               Fine Z down: Lower selected/pointed sector(s) or sprite(s) by one unit
SHIFT + W               Flips the value of pointed slope, i.e. -512 becomes 512

CTRL + D                Clone selected/pointed sprite(s), this includes ALL tag values/etc..
CTRL + Y                Paste shade from clipboard
CTRL + U                Paste Y-Panning from clipboard
CTRL + W                Paste picnum from clipboard

ALT + C                 "Corrector", pointed sprite 
ALT + Y                 Paste palette from clipboard
ALT + U                 Round Floor/Ceiling/Sprite to closest 1024 (Pg UP/DOWN)
ALT + j                 Round Floor/Ceiling/Sprite to closest 128 (Mouse Z / Home+INS+Pg UP/DOWN)

SHIFT + CTRL + U        Add Z noise to selection inherited from 3D mode
SHIFT + CTRL + W        Paste Z from clipboard to pointed Floor/Ceiling/Sprite
SHIFT + CTRL + I        "Slap" selected/pointed sprite(s) to floor

CTRL + ALT + U          Move sector selected Floor/Ceiling/Sprites "as one" UP by 1024
CTRL + ALT + J          Move sector selected Floor/Ceiling/Sprites "as one" DOWN by 1024
CTRL + ALT + W          Cycle through skills on a pointed enemy

SHIFT + CTRL + ALT + U  Move sector selected Floor/Ceiling/Sprites "as one" UP by 128
SHIFT + CTRL + ALT + J  Move sector selected Floor/Ceiling/Sprites "as one" DOWN by 128
SHIFT + CTRL + ALT + P  Adjust global visibility override for map, this modifies sector[0].extra

MOUSE 5                 Reset Horiz (up/down looking) to middle

[MetHy]

I've been using this a lately and it's great, especially considering SWP Build crashes a lot and is starting to feel outdated. There has been some efforts in the past to make m32 compatible with SW but they lacked things such as proper shade value preview (SW uses a different shade system compared to DN3D, as sprites shade values can be offset from the sector shade value) and m32 scripting seems to have come a long way since then.

A nice tip as well that helps map playtesting from mapster32: set the executable in mapster.cfg to a batch file, and have this batch file launch the game in turn with the startup commands you desire such as skill set, no monster, etc
Example:
Start your playtest on NPNG skill: (NPNG is actually 5 despite the rest being skill 0 to 3)

Quote

start voidsw.exe -map autosave_playtest.map -s5

Start your playtest with no enemies:

Quote

start voidsw.exe -map autosave_playtest.map -monst

I hope in the future source changes can be made to accomedate what currently can't be edited easily by the user such as scale, sprite labels in 2D mode or any 2D mode menu.

[gibfrag]

Great work. I plan on downloading this and trying it out for myself soon!

[jkas789]

Damn dude this is really cool. Thanks for the hard work mate.

[Ninety-Six]

I hope this leads to even a small renaissance of SW mapping.

[oasiz]

I hope it can inspire mapping yes.
The SW effect setup isn't too hard but it's a bit intimidating if coming straight from d3d as it floods you with all these extra tags but it's actually a bit more consistent than it seems at first.
I have some more ideas on stuff I want to add to further help with things like Sector Object construction.

[MetHy]

In case the warning for forced visibility isn't clear, this is how it works:

If extra on sector [0] is -1: each sector in the map will use their respective value for visibility
If extra on sector [0] is any other value: visibility will be forced to 240 in the entire map

We found this out and it doesn't seem to be documented anywhere. This is something to be mindful of when you start a new map considering the default extra value of a sector is not the same whether you use m32 (-1) or DOS SWBuild/SWPBuild (2).
So by default any map you start in the og editors will have forced 240 visibility everywhere which kinda sucks. I think pretty much every single SW map ever made uses the forced visibility due to this system.

This also explains why there are visibility discrepencies between editor and in game, of course if you want to use the forced visibility you can also use this command line in m32 so that it matches:

Quote

do for i allsectors set sector[i].visibility 240

[oasiz]

Correction! The extra will end up as the global vis. I.e. having it as 2048 will give you a very dark map.
But yes, this is a very strange and undocumented feature that had us scratching our heads until I stumbled upon this while analyzing the source code itself.

This script gives you easy full control over it, CTRL ALT SHIFT + P in 3D mode will prompt you for this.
Recommended value is -1.

EDIT: SW uses a different scale for vis which extends beyond just 0-255, something to keep in mind.

[MetHy]

It seems that only given values work and the value entered in sector[0] extra does not correspond to the vis value itself

[MetHy]

I've done some testing in a test map to try and clarify this.

Vis values that I set manually in the editor for the sectors
far left: vis 240
middle (+ where the player the player is standing): vis 0
Far right: vis 16

Here is how it looks with the global vis set to extra -1 (disabled):
https://i.imgur.com/7wtDpjW.png

extra 0:
https://i.imgur.com/g9jq7qp.png

extra 128:
https://i.imgur.com/bS27L27.png

extra 201 (random number I typed in between 128 and 256 to see if it made a difference):
https://i.imgur.com/I4E7M5N.png

extra 256:
https://i.imgur.com/ytB0RSl.png

extra 512:
https://i.imgur.com/PHGeoJD.png

extra 1024:
https://i.imgur.com/icx31Tw.png

extra 2048:
https://i.imgur.com/WK2UnBN.png

extra 4096:
https://i.imgur.com/PZBRcFB.png

extra 8192:
https://i.imgur.com/UScP067.png

extra 16384:
https://i.imgur.com/IuU3CdC.png

So, from what I gather, what it does is offset the vis globally:
512 offsets 0, so it's the same as disabling with -1.
Any value below 512 offsets brighter
any value above 512 offsets darker
16384 seems to be the darkest possible, I mean you can type in a value up until 32767 but it doesn't seem to make a difference.
Extra 0 and the values close to it like 2 (the default using SW's editor) seem to give max vis everywhere.
Sectors which are manually set to vis240 in editor seem to be unaffected by this system altogether.

The point of this? At least one of the points is to allow vis values which are not possible otherwise. For instance, check the middle sector and the sector the player is standing (which are set to vis0 in editor) in in the pics with extra 128, 201 and 256: they're brighter than the vis0, yet far from vis240, something which is impossible to do manually.
As to how much each value set in extra exactly offsets? I have no goddamn clue.

I have in the past wished for vis values that are brighter than 0 but not 240 myself, so I can definitely see the potential use for this system (even if it offsets the entire map). My previous claim about every SW map using forced vis seem to be therefore wrong since at least $bullet and $auto use extra 512, which if I'm right this time around, would offset nothing. The more you know!

Edit:
Unrelated but while I'm at it here are a couple of other things which AFAIK are also undocumented: lotag on the serpent and sumo enemies will work as a kill trigger (channel gets triggered when the enemies dies). Works on both the bosses and mini bosses version, doesn't seem to work on any other enemy however. This feature is used in $whirl and Twin Dragon's second map for the Serpent, but from memory I don't think it's used with the Sumo anywhere.

I also wished I knew how ST1 52 and 53 worked. They're supposed to make sectors bob but I can't get them to work, the official doc only tells to refer to $whirl.map but $whirl.map uses another mean for bobbing, and afaik it's not used anywhere else either.
There are indeed 3 other ways to make sector bobs: sprite tracks, sector tag 400 and you can also do it with vators if you set them on loop and use the tag 5 for acceleration to try and mimic the varying speed of bobbing sectors, but it still picked my curiosity.

[oasiz]

Update .71

This one adds labels for sprites & sectors in an unorthodox way.
I managed to modify mapster32 in order to support a higher MAXQUOTES count (16384 instead of 2048) and it also has proper scale!
Without the new mapster .exe, the editor will crash due to too many quotes (documentation & labels take space)
This version also gets rid of the gradient seen in F8 menu to make the test more legible.

Updated mapster
Updated script

[MetHy]

MetHy, on 07 October 2020 - 07:11 AM, said:

Extra 0 and the values close to it like 2 (the default using SW's editor) seem to give max vis everywhere.

I swear I'll stop hijacking this thread about this subject (although it is related to the settings this scriptset allows to change), but here is another correction: only SWP Build uses extra 2 by default. DOS SW Build uses 512, which I guess should confirm that extra 512 offsets 0, and which may explain why the vast majority of maps in both add-ons use extra 512. After checking, all but one do: Auto Factory in Wanton Destruction uses extra 1024 and that map always struck me as quite dark compared to the others indeed, I suppose Cho Yan "Tempest" Wong knew things the others didn't since I still can't find any documentation on this entire matter. In fact, I have no idea if it's even possible to manually change extra on a sector in DOS Build.

[oasiz]

It's valuable info, might just mean that every usermap so far done with SWPBuild from the get go might have wrong values here and cause a lot of pain to mappers.
I hope in the future this can be simulated in a non-destructive way but right now any change to sector struct will require permanent changes to map itself (unlike sprites) :/

[oasiz]

Updated DL link on original post.

Biggest changes:
- 2D Labels on ST1
- 2D labels on walltags
- 2D labels on sector tags
- CTRL - ALT - SHIFT will bring up a tag reference menu in 2D Mode
- Add more sprites (tag 257 + switches) for MP boolean visualizer (That turns things blue & displays MULTI)
- Very slightly modified Mapster32 now bundled! This one has a fixed scale and also bumps MAXQUOTES from a soft limit of 2048 to 16384 (real maximum), required for expanded documentation.

Aside from TAG4 (Angle, very rarely used beyond 2048) -- This is ready for everyday use.

[oasiz]

OP Link updated.

Added SO_BOUND Upper/Lower and ST handling. As an extra it will always draw a green rectangle around the bounding box when both UPPER and LOWER sprites are tagged correctly.
Info boxes and tags track which SO (1-20) is in use to make things a bit easier to live with.

NOTE: Sectors can't have -1 hitag, just use 65535 instead and it will show as -1. Trying to see if I can override this in the future but this is purely visual as internally 65535 == -1 (Just treated as signed in OG SW Build)

[oasiz]

New fix uploaded in ZIP.

This adds BREAKABLE SPRITE, GRATING and TRACK sprite documentation along with fixing TAG3 to be treated as unsigned instead of signed.
x/y repeat tweaked for evil ninja
Added -usecwd in the bat file to increase compatibility with eager auto-search dirs.

[oasiz]

Link updated yet again with an important update.
The bundled mapster32 now has TAG4 editable beyond 2048 now that I found it's location in source code!
This change basically fixes the last major omission compared to DOS editor, remaining one being the "forced global vis" hack that they used.

So far testing feedback has been good (Thanks methy!) and I'd even say that this is practically the best tool available now for SW mapping.


For documentation purposes in case I die tomorrow:
Adjust player height to SW Scale

--- a/source/duke3d/src/astub.cpp
+++ b/source/duke3d/src/astub.cpp
@@ -9957,7 +9957,7 @@ int32_t ExtInit(void)
 //#endif
     Bmemcpy(buildkeys, default_buildkeys, NUMBUILDKEYS);   //Trick to make build use setup.dat keys

-    kensplayerheight = 40; //32
+    kensplayerheight = 58; //32
     zmode = 2;
     zlock = kensplayerheight<<8;

Adjust Editor colours to be more legible (Nullifies gradient)

--- a/source/duke3d/src/m32common.cpp
+++ b/source/duke3d/src/m32common.cpp
@@ -66,7 +66,8 @@ const char *YUPDOWNWALL[2] = {"UPWALL","DOWNWALL"};

 void drawgradient(void)
 {
-    int32_t i, col = editorcolors[25];
+//    int32_t i, col = editorcolors[25];
+    int32_t i, col = 0;
     videoBeginDrawing();
     for (i=ydim-STATUS2DSIZ+16; i<ydim && col>0; i++,col--)
         CLEARLINES2D(i, 1, (col<<24)|(col<<16)|(col<<8)|col);

Adjust Sprite angle to accept beyond 2048 when using script "SET"

--- a/source/duke3d/src/m32structures.cpp
+++ b/source/duke3d/src/m32structures.cpp
@@ -321,9 +321,7 @@ static int32_t __fastcall VM_AccessSprite(int32_t how, int32_t lVar1, int32_t la
         case SPRITE_YOFFSET: sprite[i].yoffset=lValue; break;
         case SPRITE_SECTNUM: changespritesect(i,lValue); break;
         case SPRITE_STATNUM: changespritestat(i,lValue); break;
-        case SPRITE_ANG:
-            sprite[i].ang = lValue&2047;
-            break;
+        case SPRITE_ANG: sprite[i].ang = lValue; break;
         case SPRITE_OWNER: sprite[i].owner=lValue; break;
         case SPRITE_XVEL: sprite[i].xvel=lValue; break;
         case SPRITE_YVEL: sprite[i].yvel=lValue; break;

As MAXQUOTES was bumped to 16384 recently, there currently are only 3 changes that need to be done where 1 really matters (TAG4/Angle)

[MetHy]

Small corrections:

MetHy, on 07 October 2020 - 07:11 AM, said:

Unrelated but while I'm at it here are a couple of other things which AFAIK are also undocumented: lotag on the serpent and sumo enemies will work as a kill trigger (channel gets triggered when the enemies dies). Works on both the bosses and mini bosses version, doesn't seem to work on any other enemy however. This feature is used in $whirl and Twin Dragon's second map for the Serpent, but from memory I don't think it's used with the Sumo anywhere.

It is used on the Sumo boss in the main game: in the Volcano map (for the Serpent also). Wanton Destruction also uses it on the Sumo mini boss in its final map.

The kill trigger doesn't seem to work on Zilla however, and I do not know what his hitag and lotag do (both are tagged in the main game).

Quote

I also wished I knew how ST1 52 and 53 worked. They're supposed to make sectors bob but I can't get them to work, the official doc only tells to refer to $whirl.map but $whirl.map uses another mean for bobbing, and afaik it's not used anywhere else either.
There are indeed 3 other ways to make sector bobs: sprite tracks, sector tag 400 and you can also do it with vators if you set them on loop and use the tag 5 for acceleration to try and mimic the varying speed of bobbing sectors, but it still picked my curiosity.

I realized shortly after but those bobbing ST1s only work on Sector Objects, like their name indicates.

[oasiz]

0.76 - Updated tag15 - Oversight where the allowed value should be much higher in TAG input (although you could always modify sprite Z with F8).

If you're not already using this scriptset for mapping then you're missing out!

[oasiz]

Small bump before a new update...
You can now use the newest mapster with this scriptset if you add "cameraheight 58" to m32_autoexec, this will correct the player height to be SW one as it's now an editable field (Meaning it finally works for other games too!)

I'll still try to figure a way to insert stuff to sprite.ang that doesn't force clamping to 2048 as it's really the only real thing holding back the use of a non-modified editor at this point.
However you can still edit maps with the latest mapster right now as long as you don't need to adjust TAG4 beyond 2048. Otherwise keep using the vanilla package bundled editor.

At this point I'm open for suggestions, I've heard few people using this as a daily driver for SW mapping so if there are any bits missing / "nice to have", I can look in to them next time.

[hxixdxy]

I am a newbie in map making.
I am very grateful to you because your script gave me the opportunity to dare to choose SW.
I know that there are very few SW map creators because of the many restrictions due to SW's "hard coding".

It's a shame that I can't offer you a good suggestion due to my lack of knowledge...
(sorry for my poor "Google Translate" English)

[oasiz]

SW maps actually allow way more to be done than Duke, how they approached it was very interesting to look at when doing this as it's quite similar to Fury.
TAG1-15 are merely renames of existing sprite struct members (plus combining/splitting some). Many effects are more versatile and utilize various parameters in the effect sprite itself (making it sort of easier) and many things can be toggled on/off with boolean bits.. which is just a single 16bit thing.
SW actually did quite well here.

A lot of Z based effects (doors, etc..) got redone as vators. The game still has a lot of undocumented lotag based doors and such as development leftovers.
Earlier effects used to be more sector tag based until it got moved to sprite based (coinciding with duke3d dev team jumping on board)

[hxixdxy]

I see that the SW engine is much more improved and expanded in its capabilities.
So it seems that SW is easier to make complex maps than Duke3D.


I saw several times somewhere that SW is "hard-coded" so I can't add completely new enemies or weapons, and that the user can define very limited things in DEF files.
As far as I have tried, it only seemed to be able to define the map name in the DEF file. This may not be accurate.

I have learned valuable information from you. Thank you very much.
(sorry for my poor English)

[oasiz]

Enemies, etc.. are still hardcoded but maps aren't.
It is true that outside of maps you are more limited, mostly to graphics/sound edits.

[hxixdxy]

Quote

The game still has a lot of undocumented lotag based doors and such as development leftovers.

Very interesting.
I am only a clueless beginner, and I am still playing around with the editor to see what I can do, but I'm frustrated by the many obscure points that are not mentioned anywhere (including official/unofficial tutorial documents in the past).
I thought I would have to experiment and find out for myself...


Oops! Sorry for continuing to digress from the topic. My interest is endless, but I'll stop here.
Thank you so much for your time, it is much appreciated.

[hxixdxy]

A few days ago I casually updated the SWScriptset, ...and found some great improvements!
As far as I've noticed,
1: sprites are displayed in the correct order in 3D mode.
2: fps (displayed in the upper right corner) has greatly improved.
Thank you very much


(If those were caused by my environment problem, ...sorry)

[INGAMEDUKETHREEDEE]

First of all: Thank you for this scriptset oasiz!
Works like a charm for me even though i am new to mapping for dn3d ( i am still working on my first map to be uploaded here to duke4.net - but i will take my time because there are so many really good maps and my goal is that my first one here should be acceptable) and SW (only played the Steam version in DOS before and it did not really work for me this way because i encountered massive lag), but Duke Map/Mod of the Month Club - September 2022 with Twin Dragon brought me back to SW.
First i could not start my testmaps created with your scripset even though i could playtest them in mapster (with T), because i tried to start them with the shortcut properties for voidsw.exe that ran custom maps for SW "...\SW eduke 32\eduke32_current\voidsw.exe" -map newtry", but now it works with the batch file mentioned in this thread "start voidsw.exe -map [mapname].map -s5"
It will take some time til my first SW map will appear but...

YOU NO MESS WITH LO WANG

[hxixdxy]

UPDATE:

It seems I was mistaken that an update was implemented.
My SWMapster is now back to its previous state after that. My apologies...
(However, what was that temporary improvement?)

In any case, it's still a great Scriptset.

hxixdxy, on 21 September 2022 - 09:27 PM, said:

A few days ago I casually updated the SWScriptset, ...and found some great improvements!
As far as I've noticed,
1: sprites are displayed in the correct order in 3D mode.
2: fps (displayed in the upper right corner) has greatly improved.
Thank you very much

(If those were caused by my environment problem, ...sorry)

[oasiz]

Sprite sorting is dependent on the engine and renderer in use, so is FPS

If you're using classic then you will have more issues with both compared to polymost.

Console:
setrendermode 0 (= classic)
setrendermode 3 (= polymost)

If you are using higher resolutions such as 1920x1080 with classic then performance WILL suffer.

One of the config files is used for playtest .exe btw, you might want to check that in case you need to modify it.

[hxixdxy]

It was exactly as you pointed out.
I solved it by changing the rendering mode!
I'm ashamed that I don't understand basic things

Thank you