[oasiz]

Slopey slopes in build engine

(First of all, thanks to Nuke.YKT, I'm just the messenger here)

And no.. this isnt't some cruel April fools joke.
While the monolith GIF itself was partially faked with frame by frame, what you saw was real. Sprites can now slope!






What does this mean?
- Sloping practically recycles sector sloping code routines
- It's fully integrated to the game, all 3 render modes.
- Backwards compatible
- Slope units == sector slope units
- Collision works... about as well as you can expect from sprites, don't expect miracles
- You may notice seams in surfaces, this is partially due to lack of precision. Things will need more fudging around.

Downloads
Latest EDuke32
Source code
Sloping hotkey sciptfile
Changelog
+ Added a special case when floor slope = sprite slope when using CTRL + PGDN/PGUP, this will flatten the sprite by taking origin from the middle instead of the "tip"

How to use
Slope like you would slope floor/ceiling.
Any change in apparent top/down size due to sloping will be reflected in 2D mode.
For script file, drop it to the directory and run "include slope" in console. Instructions few posts after this one.

Compatibility?
As there is no new map format yet, this takes a similar approach to TROR where some structs WILL get recycled.
The "very" rarely utilized sprite[].xoffset and sprite[].yoffset arrays get combined together in order to provide sprite[].slope, these arrays are practically never touched by mappers unless as a last ditch effort to tweak some things visually.
Things will remain backwards compatible. Sloped sprites will simply cause an "invalid/illegal" combination from now on.
Normally for a floor aligned sprite you use cstat bit 32 but in this case a sloped sprite will have cstat 48, making the sprite both floor and wall aligned.
This normally is reserved for voxels but there is a workaround in the draw loop that hacks around this.
Long story short, No breakage: offsets still work as normal and are only recycled for sloping when using a normally "impossible" cstat combination reserved for voxels (which are not affected here either).

PLEASE NOTE!
<removed> This has been integrated in mainline!

[Danukem]

oasiz, on 01 April 2020 - 10:07 AM, said:

The "very" rarely utilized sprite[].xoffset and sprite[].yoffset arrays get combined together in order to provide sprite[].slope, these arrays are practically never touched by mappers unless as a last ditch effort to tweak some things visually.

Does that mean it will no longer be possible to use those structs for their intended purpose? I do have a mod or two where those get manipulated in code to adjust the offsets on sprites on the fly.

This is very cool, by the way, I'm just trying to figure out whether my mods will be broken and what to do about it.

[Nuke.YKT]

Trooper Dan, on 01 April 2020 - 10:36 AM, said:

Does that mean it will no longer be possible to use those structs for their intended purpose? I do have a mod or two where those get manipulated in code to adjust the offsets on sprites on the fly.

This is very cool, by the way, I'm just trying to figure out whether my mods will be broken and what to do about it.

It still works with flat/wall/non sloped floor sprites. It also will work with sloped sprites once new map format is added

[Phredreeke]

I got the impression that it would only be used if the two cstat bits were both set and would otherwise function normally?

[oasiz]

I'll wait for Nuke to answer that proper but right now I can use x/y offsets in mapping and the sloping only gets applied IF cstat is 32 + 16.
So you might get issues if you want to use those code bits with sloped sprites specifically OR somehow force cstat 48 to that sprite

[UltravoxSapphire]

Evil Witchcraft!

You must be burned at the stake in the name of our masters, Ken Silverman and Todd Replogle!

JK. this is pretty cool!

[Micky C]

This is amazing! Nuke.YKT is a legend!

Some general questions are:

What are the performance of sloped sprites compared to regular floor-aligned ones?

It seems the justification for a brand new map format are growing and growing. Are there any plans in the works to implement that, and if so, will wall-aligned sprites gain rotating functionality too?

[Nuke.YKT]

Micky C, on 01 April 2020 - 02:01 PM, said:

This is amazing! Nuke.YKT is a legend!

Some general questions are:

What are the performance of sloped sprites compared to regular floor-aligned ones?

It seems the justification for a brand new map format are growing and growing. Are there any plans in the works to implement that, and if so, will wall-aligned sprites gain rotating functionality too?

Performance is worse than non sloped floor because of use division operation (regular floor sprite doesn't need division operation as it uses precalculated lookup tables and affine texture mapping), i think performance should be similator to regular sloped floors/ceilings with masked texture enabled.

[oasiz]

Micky C, on 01 April 2020 - 02:01 PM, said:

It seems the justification for a brand new map format are growing and growing. Are there any plans in the works to implement that, and if so, will wall-aligned sprites gain rotating functionality too?

Can't comment on wall aligned sprites much, I don't think there are existing provisions for that the same way as floor ones.

As for new text-map format, this is in constant discussion.
Goal is to ultimately serve beyond just stock duke3d stuff, i.e. you could actually include arbitrary tags in sectors/sprites.
Who knows, maybe we can have a better tile index system as well and finally allow tile number overlaps to co-exist as well.

There are other things on the list such as allowing .blend to be set on floor/ceiling of sectors and walls. In fury we used negative .extra just to use it on maskwalls (no wysiwyg in editor because of this)

[ck3D]

If you'll excuse the unexperienced-but-as-a-mapper perspective, a new map format would be the occasion to completely get rid of the sector/wall/sprite limits too, right? I remember that being brought up around the time JonoF came out and people started to wonder how much those could be pushed. Best of luck writing the new format, I like where your second paragraph is going as well. I'm going to do some research on sprite[].xoffset and sprite[].yoffset now, never bothered with those indeed I don't think, I'm used to the basic, mostly visual 'techniques' in 2D/3D mode to get things to look the way I envision them, but it's always good to be aware of options.

Honestly, I keep learning about yet-unknown-to-me Mapster32 features every day, and those can be some incredible life- or time- savers (e.g.. I know I'm super late on it, but that automatic text entry thing is such a blessing, been loving it lately when for the longest of times I was used to placing every single letter sprite manually). I figure many old school mappers who don't really focus on coding and various 'inner' technicalities are in my situation as well.

[oasiz]

Limits are hardcoded in to the engine, extending those in map format would be trivial, which is why it already has been extended as far as the engine can go.
At the moment it's very unlikely that these limits will ever be extended further as it would require extensive rewrites to many core components.

For time savers, I wish to some time do a proper re-write on the scripts I did for fury so that they can be more modular and useful outside of fury as well.
I've added a dozen on time savers from things like "paste slope" to things like "hide all sector effectors". There is an insane amount of quick wins in the editor that never have been addressed before.

x/y offsets can be useful in very limited cases, what it does is that it basically visually offsets the sprite x/y roughly the same distance as the sprite size itself.
Use cases could be "floating" sprites that are tied to a tiny rotating sector but appear to rotate mid-air (making pivot be at bottom-right instead of center for example).
You can also get around sprites having a tiny sector by placing the sprite in a sector that is more likely to be drawn and then offsetting it to be at the desired place.

It's very much more about fixing corner cases where manually setting sector number for a sprite isn't enough.

[ck3D]

Thanks for all the info, for some reason I remembered reading some forum banter from 10+ years ago on how the limits had to do with the map format as opposed to the engine itself - person must have been misled, then.

Good on you for implementing all the new time savers outside of Fury as well. Might be a long shot, but theoretically I'm inclined to think that making mapping more casual and accessible all the while preserving all the core functions would probably encourage a newer breed of creators who didn't grow up with Brett Gmoser's 1996 FAQ to give it a try. Just the original appearance of Mapster32 on the scene vs. the older editors definitely did just that, I'm willing to bet (virtual bet though - times are dire). Good games are not just timeless, but publicized on popular platforms like YouTube more than ever nowadays and I'm seeing a very blatant resurgence of interest in the Build engine (of course Fury helped a lot there), so I don't think I'm being naively optimistic.

Just for comparison's sake, I remember looking up 'Duke 3D user map' on YouTube just a few years ago and the results would be close to nothing. Now you get video playthroughs by the hundreds, not even counting mod reviews and whatnot, I think that's really cool.

[Jimmy]

Y E S

[Micky C]

Is there a key to align a sprite to a sloped floor?

[oasiz]

None exists.
But see this script: HERE !!!!!
I backported a few similar slope related hotkeys from fury for this one.

[TAB] Read slope value to clipboard (Done along with texture stuff)
[SHIFT + Y] Paste slope to floor/ceiling/sprite
[SHIFT + U] Take ceiling sloping and apply it to sprite
[SHIFT + J] Take floor sloping and apply it to sprite
[CTRL + SHIFT + U] Take ceiling sloping and apply it to sprite and "flatten" against ceiling
[CTRL + SHIFT + J] Take floor sloping and apply it to sprite and "flatten" against floor

Bonus round: [Mouse 5] Reset horiz to 90 (straighten view) -- This one needs to be default honestly.

Bonus Bonus, videos in action:

[oasiz]

EDuke32 goes git, EDuke32 goes slopes in mainline

https://dukeworld.du...8809-8ce0e74bb/

You can consider the support official as no major breakage was detected or reported.

[comorbidity]

dumb question; does this apply to voxels as well?

[oasiz]

no, only floor aligned sprites.

[LeoD]

oasiz, on 06 April 2020 - 08:30 AM, said:

EDuke32 goes git

Is there a way to access/check out by a certain commit number, e.g. 8809, the way it is possible on GitHub, using Subversion or otherwise?
I'd need such a mechanism for easy bisect-compiling without the hassle of those annoying and meaningless Git checksums.

[Hendricks266]

git checkout `git log "--pretty=tformat:%H" "--grep=From-SVN: r2\b"`

However, for bisecting you might as well use git bisect.

[LeoD]

Hendricks266, on 06 April 2020 - 01:00 PM, said:

git checkout `git log "--pretty=tformat:%H" "--grep=From-SVN: r2\b"`

However, for bisecting you might as well use git bisect.

Thx. Will check that out ... whatever keeps my build script working.

[oasiz]

Yes, I've seen that you go quite great lengths when reporting bugs and narrowing down. That stuff is always appreciated!

From my experience, you will have to use commit hashes and I think you might want to create some wrapper for it.
With git rev-list --count HEAD you can get the current revision (number), keep in mind that this is simply a counter for commits, however it's the closest parallel to a revision number.

To get "all commits" with one per line, you can use git --no-pager log --oneline
I'm afraid that you'll have to cook up a shell script to correlate a commit ID with the hash itself (list is linear) git really dislikes using those numbers.
Pretty sure awk combined with some shell scripts you can have a list with: commit number,hash,message -- by using the above git log command.
From there on you can then checkout specific versions but I don't remember the exact commands.

I think there should also be much better diffing tools right out of the box though so you should be able to give HASH1 and HASH2 to see what was exactly changed, of course with a wrapper you could easily populate these hashes too.

[LeoD]

oasiz, on 06 April 2020 - 01:39 PM, said:

Yes, I've seen that you go quite great lengths when reporting bugs and narrowing down. That stuff is always appreciated!

In part that is sheer desperation, tbh.. Anything less than serving on a silver platter seems to be insufficient to get through all too often, and still...
Since no one else seems to keep track of reported issues, this is also helpful when bumping again after some time.

[oasiz]

It's a very time consuming task, if a developer had to repro and analyze every fault he comes across then it can easily take hours or days (as some are hard or impossible to reproduce locally)
Not sure if you've ever experienced "gamedev" game testing but a typical bug report can be flat out rejected if there are no clear reproduction steps, logs, screenshot/video, etc..
Now of course this is not a professional gamedev project and requirements aren't that strict, there have been quite a few reports I've done that I've had to remind again in 6 months and explain the nature again. There is a lot of work constantly being done all around and some things just get a different priority (or pushed aside in order not to constantly context switch).
Imagine the constant context switching if the developer had to spend hours reproducing bug after bug

"Game testing" is a very thankless and tedious job/task, but yes, when this tedious task is lifted then it's much more likely that the dev can focus their energy on fixing it.

[TerminX]

LeoD, on 06 April 2020 - 03:26 PM, said:

In part that is sheer desperation, tbh.. Anything less than serving on a silver platter seems to be insufficient to get through all too often, and still...
Since no one else seems to keep track of reported issues, this is also helpful when bumping again after some time.

Going forward, please register an account on voidpoint.io and file bug reports when you encounter things that are broken. This is something we've been working on putting together for a while now, and it's our answer to the longstanding issues our project has faced regarding issue tracking and discussion/communication of changes.

[LeoD]

TerminX, on 07 April 2020 - 08:42 AM, said:

Going forward, please register an account on voidpoint.io and file bug reports when you encounter things that are broken. This is something we've been working on putting together for a while now, and it's our answer to the longstanding issues our project has faced regarding issue tracking and discussion/communication of changes.

bugs.eduke32.com is now redirected. Did you move over the open entries?

[TerminX]

There isn't a supported migration path but I'm looking at options.

[Jan Satcitananda]

Impressive to see that somebody is still tweakng Build engine in such fundamental ways. Just gave this a test and it looks really useful and inspiring! Two years ago I was working on sloped sprite rendering in my game engine too. Great to have a similar feature in EDuke32, gonna support it by my map converter, as I'm using Build maps for testing.

A question: how do you quickly reset the slope to zero in Mapster? The slash key doesn't affect sprite slopes for a reason. =(

[TerminX]

Jan Satcitananda, on 14 April 2020 - 05:39 AM, said:

A question: how do you quickly reset the slope to zero in Mapster? The slash key doesn't affect sprite slopes for a reason. =(

It does now.

[necroslut]

Wow. This is something I guess most of us have wished for at some point, but never thought would actually come – especially not with actual collision. The possiblities are huge for this.