[Micky C]

Yeah that's better. It could benefit a lot from some shadows as well, such as from those couches on the left, desk in the middle, and columns on the right. If you're up for it, some extra trimming on the walls, and potentially some beams or air conditioning ducts on the ceiling would also help.

[TerminX]

[Truck Stop Santa Claus]

Is that 3D

[Micky C]

Truck Stop Santa Claus, on 15 November 2018 - 10:46 PM, said:

Is that 3D

As opposed to...?

[Truck Stop Santa Claus]

I can't really tell whats going on in this screenshot
I maybe a little drunk

[OpenMaw]

Truck Stop Santa Claus, on 15 November 2018 - 11:10 PM, said:

I can't really tell whats going on in this screenshot
I maybe a little drunk

The texture on the box is rotated 90 degrees.

[TerminX]

It's probably one of the biggest "game changers" for overall Duke mapping in the history of EDuke32.

[Forge]

TerminX, on 16 November 2018 - 07:55 AM, said:

It's probably one of the biggest "game changers" for overall Duke mapping in the history of EDuke32.

Checking my calendar to make sure it's not April 1st.

Much appreciated.

Taking requests?
Actual scaling of floor and ceiling textures instead of only being able to use "E"

[TerminX]

Need a new map format for that one.

[Forge]

TerminX, on 16 November 2018 - 08:58 AM, said:

Need a new map format for that one.

Aw well. Thanks for replying. (probably to the same question for the Nth time)

The 90^o rotation is pretty sweet.

[HellFire]

Nice stuff TX.
Does that works on all renderers?
Can we rotate sprites too?

[TerminX]

Yeah, it works on all renderers. Rotating sprites isn't a thing yet, but it probably should be...

[Truck Stop Santa Claus]

Maybe some day after Ion Maiden comes out we can get the 3D skybox stuff from that game into Eduke32
It's one the things I'm dying to play with in mapster 32

[Perro Seco]

Truck Stop Santa Claus, on 17 November 2018 - 05:33 PM, said:

Maybe some day after Ion Maiden comes out we can get the 3D skybox stuff from that game into Eduke32
It's one the things I'm dying to play with in mapster 32

That effect is already possible. Some mods used it years ago, and that was one of the reasons I came to this forum asking about it. Here's the thread, you may find it helpful.

[oasiz]

All IM extensions are CON code. You should be able to replicate everything more or less.
There is currently less than ~1% difference in source code level between "duke" and "standalone" builds, differences are mostly just removals/minor changes of hardcoded stuff (i.e. bugfixing that may break legacy compatibility on minor things). Everything does still work with the latest eduke binaries on our dev builds.
Do keep in mind that in CON everything was coded from scratch so there is a TON of boilerplate code that is IM specific and might not work at all when put to duke as-is.
Access to IM's CON code is not yet supported or intended, that's more for the actual release. However porting of many things is possible in theory (not something we will do).

[Mark]

"i.e. bugfixing that may break legacy compatibility on minor things"

Will a list be published on what those breaks are in case someone wishes to know if their older projects are affected?

[oasiz]

i.e. this was being addressed in one patch where it was fixed but reverted to more original behavior.


This affected stuff like escalators being broken in IM as the player was pushed forwards way too fast.
Right now I think it's proper fixed to match d3d speeds while being refactored.

Correct behavior is to be slower, d3d always had it way too fast. This fixed to be "proper" for IM.

[Forge]

oasiz, on 18 November 2018 - 06:58 AM, said:

This affected stuff like escalators being broken in IM

the comment and the video don't match, so shotgunning it:

escalators have never worked right. They look like epileptic caterpillars, and I only know of a couple of maps that used them (*cough*Gambini*cough*).

Conveyors can be "fixed" via the gpspeed sprite, but that's a popular effect and a lot of d3d releases would be affected.

[Mark]

Conveyor belt speed was "wrong" before HHR was released. Unfortunately it didn't get "fixed" until shortly after release so I had to adjust it in the map and re-release the map. Now its been "fixed" again. If that fix means it reverted back to the old "broken" speed then the HHR map will be faulty again.

I guess I'll just have to wait and see.

[Forge]

Mark, on 18 November 2018 - 08:05 AM, said:

Conveyor belt speed was "wrong" before HHR was released. Unfortunately it didn't get "fixed" until shortly after release so I had to adjust it in the map and re-release the map. Now its been "fixed" again. If that fix means it reverted back to the old "broken" speed then the HHR map will be faulty again.

^this

Not sure why conveyor speed in the IM or eduke32 port has to be adjusted away from the original duke3d behavior. Especially for something that can be tuned during map creation with a gpspeed sprite

[oasiz]

Sorry, I was referring to conveyor belts specifically and fixing friction affecting other things that move the player. I thought I wrote this but I guess I my mind drifted when typing it.
Anyway, I think it had quite widespread things it could affect overall but conveyor belts and escalators are the biggest you will see.
gpseed fixes it to a degree but I believe the texture panning is still offset to the player speed, which was the main issue.
IIRC the only thing broken with duke's escalators are the interpolation as it will try to "fill" in the missing frame if it resetting back and that gives you the jerky motion. You can hold ESC to spam the menu and you will see that 99% of the motion is correct but it's the jerky reset that kinda kills it. IM goes around this and slows them down a bit (in CON).

As for the speed differences: It IS the original DOS behavior now more or less. For a moment in eduke32 it was incorrect (more realistic speed) and didn't match 1.5 speed at all. This was considered to be a bug for sake of legacy compatibility and ended up being manually tweaked to match DOS behavior again.

IM on the other hand was built against the more realistic speed that doesn't match duke's bugged speed and once 1.5 speeds were restored, we had to make a change for IM specific binaries to keep the more realistic speed as any new project that didn't need Duke map compatibility would consider this an obvious bug.

This is part of the "less than 1%" difference that most won't even notice anyway

[Mark]

It keeps getting changed back and forth and I'm confused what the end result is now. I guess I'll have to wait and see if the new speed matches mine or if it screws up my map. Its not a game breaker but during a fancy transport sequence various timed sound effects will jumble on top of each other and ruin the sequence if the speed is different. And IIRC it will be quite noticable because the difference between the slower and faster speeds was 100 percent ( doubled )

I'm a little sensitive on the subject of Eduke32 changes because I remember during the year and a half development time of my GraveyardTC the shading and visibility of the renderer was changed 2-3 times and I had to keep compensating for it in my maps. It was just bad luck in timing but was a pain in the ass none-the-less.

[oasiz]

For clarity: It changed from A > B > A
I believe HHR was done for B
B originates from before IM, quite old.
Whatever changes you do now will match DOS duke and if it ever breaks to C then it will be reverted back to A down the line anyway.

[Mark]

OK. The way I understood it, it was at A for many years. Then got changed to B when I updated the revision in the project. I told the devs and it got reverted to A. So now if it got changed recently its at B again. (or C if its a totally new speed)

It is what it is. Its not as though I'm going to change and release the map a 3rd time. Its the only time I used a conveyor belt so its not a widespread issue for me.

[Forge]

You're confusing yourself, or are just trying to be funny.





the current snapshot has the original speed and is the correct speed. It was changed for X reason for a series of snapshots, but was noticed and got changed back.

[Mark]

That is correct. But that last change was back in Aug-Sept 2017. If it has been changed again since then it backs up my version of the story.
My recollection is A B A B with the 2nd B being the latest. I'm going to be doing testing on all my old projects tonight and tomorrow on the latest revision. That will answer my question.

[Forge]

Mark, on 18 November 2018 - 03:30 PM, said:

My recollection is A B A B .
I'm going to be doing testing

[Zaxtor]

Started Dark Temple part 2.
Due to temple size it has 2 parts.
Part 1 has about 80% of the level, part 2 20% or so.

it will have a part 2, mostly before the last floor and last floor for pt2.

We can still access most of part 1 and entrance from part 2.
Few rooms and areas from Pt1 in Pt2 cannot be accessed (are the parts we passed)

[Sanek]

Just want to say that I finished all the levels and art in SBZ...
Howver, I still don't have all the necessary code, so I don't know when I'll release it.

[Mark]

Slowly but surely still working on the remake of SuburbsTC. Someone found more unfinished maps which means a lot more work for me. Its getting close to the point that I'm considering asking for a helper. We'll see.

Attached thumbnail(s)

•