[OpenMaw]

 Fox, on 06 August 2013 - 07:23 PM, said:

The breaking news is that Polymer runs at 10 fps with a few light sources, so I don't trust it can handle a geosphere with enough polygons to make it look realistic (like 50,000).

Why would you need such a dense sphere? Jesus. Even 20,000 is extreme. You're just putting a texture on it. Even at 15 to 20 thousand polies you'd be hard pressed to find any overt distortions or... I mean damn, dude!

[Plagman]

What does a sphere or cylinder offer over a skybox, outside of more resolution near the edges?

[Fox]

 Commando Nukem, on 06 August 2013 - 10:06 PM, said:

Why would you need such a dense sphere? Jesus. Even 20,000 is extreme. You're just putting a texture on it. Even at 15 to 20 thousand polies you'd be hard pressed to find any overt distortions or... I mean damn, dude!

With just 20,000 sides, the horizon line would be split less than 160 times. The distance beetween polygons would be roughly 32 pixels in a 1280×960 resolution. I don't think I can feel comfortable if that's an "extreme" case. But I have no idea how many polygons modern games use...

 Plagman, on 06 August 2013 - 11:19 PM, said:

What does a sphere or cylinder offer over a skybox, outside of more resolution near the edges?

Why not give the option? At least I believe Eduke32 is meant to support a variety of games (or mods), not enclosed around a single case. So I don't think that more artistic liberty would hurt.

And I can think of a particular case which it would be usefull.

[Helixhorned]

 Plagman, on 06 August 2013 - 04:45 PM, said:

The way Polymer is going to handle skies going forward is the proper way, where the parallaxed ceilings/floors are actually drawn instead of cutouts to a pre-rendered skybox/cylinder. For parallaxed skies the shader that's used to draw them will do the unrolling and display it like Classic mode, and for skyboxes it's just going to be sampling from a cubemap. That stuff is fairly obvious and was never a mystery (as with most things), it's just a matter of writing the code.

Ah, cool, so you already have plans for that. My idea is a fairly mild modification to support multiple skies per map, as that usage is rather common (I haven't yet found a map that uses two multi-tile pskies though).

Basically, at map load time, I want to construct a sector->sector mapping, let's call it "skysect". For sectors s, s₁ and s₂, the following would hold:

• skysect[s] = s, if sector s has a parallaxed ceiling
  
• skysect[s₁] = s₂, if sector s₂ has a parallaxed ceiling and can be reached through red walls from s₁.

The latter would be constructed using a breadth-first search.
At the beginning of a frame (where skies are always drawn in Polymer, in contrast to classic/Polymost where they're drawn when their ceilings or floors are), Polymer would consult this array and look up the ceiling picnum of skysect[cursectnum]. Based on that, it would draw the appropriate (potentially multi-tile) psky. A benefit of this additional indirection is that skies could be manipulated at run-time, for example simulating times of the day.

What do you think? It seems like a local change to me, so I probably wouldn't step on your toes by implementing it. Also, it seems somewhat orthogonal to what you described (the actual rendering method).

A coule more thoughts:

• Skies that have a horizon like CLOUDYOCEAN are best drawn in alignment with the rest of the scene. For example, it looks pretty bad if sky tile #94 (blue water below yellow sky) is drawn with a "horiz fraction" other than 1. With my recent commits, we could just add it as another multipsky[], but maybe that should be a user option.
  
• Actually, I kind of like the eight-sided prism for certain types of skies like LA. With the "paper sky", wouldn't the city background look a bit inconsistent with the 3D projection of the scene, particularly when looking up or down?

 Plagman, on 06 August 2013 - 11:19 PM, said:

What does a sphere or cylinder offer over a skybox, outside of more resolution near the edges?

As Fox hinted, space skies look pretty bad if they're projected onto a small number of quads, particularly if an edge goes midway through a huge planet as with BIGORBIT1. This one is probably better off as paper sky.

[Plagman]

Skyboxes in the Polymost sense are supposed to be authored that way, eg. warped like cubemaps such that their content is displayed without distortion when mapped to a cube. Certainly using planar ART tiles and mapping them to faces of a skybox isn't going to yield good results, but that isn't what the feature is for.

[Plagman]

Helix, that approach would be superior to what we have now for sure, but would be made redundant with the proper sky rendering I described. If you already have the code handy I suppose that's fine but otherwise your time is probably better spent somewhere where the code is going to stay, isn't it?

[Fox]

 Helixhorned, on 07 August 2013 - 12:33 AM, said:

• Skies that have a horizon like CLOUDYOCEAN are best drawn in alignment with the rest of the scene. For example, it looks pretty bad if sky tile #94 (blue water below yellow sky) is drawn with a "horiz fraction" other than 1. With my recent commits, we could just add it as another multipsky[], but maybe that should be a user option.

The problem is that if you align these textures with the horizon you would have a void space on the top and bottom. If they didn't moved with the view in the classic mode you would be seeing the texture repeat, and in fact that actually happens with CLOUDYOCEAN, but you can't notice it because the top and of bottom of the texture are a flat color.

Right now there is a problem with CLOUDYOCEAN in Polymer, because the top and bottom of it is pitch black.

Spoiler

I suppose the space on the top and bottom should equal the average color of the end line.

Note that the same wouldn't work with REDSKY2, because the top is supposed to show a starry sky, not a flat color.

[Helixhorned]

 Plagman, on 07 August 2013 - 12:49 AM, said:

Helix, that approach would be superior to what we have now for sure, but would be made redundant with the proper sky rendering I described.

So this means that the shader sky rendering would proceed when the ceiling or floor is drawn instead of the beginning of each frame? Otherwise, you'd still have to decice up-front what sky to draw. (Well, or draw a bit until encountering a sky, then back off and draw anew, but that's not so great.)

Quote

If you already have the code handy I suppose that's fine but otherwise your time is probably better spent somewhere where the code is going to stay, isn't it?

No, I haven't started, only pondered the idea.

 Fox, on 07 August 2013 - 12:57 AM, said:

The problem is that if you align these textures with the horizon you would have a void space on the top and bottom. If they didn't moved with the view in the classic mode you would be seeing the texture repeat, and in fact that actually happens with CLOUDYOCEAN, but you can't notice it because the top and of bottom of the texture are a flat color.

Right now there is a problem with CLOUDYOCEAN in Polymer, because the top and bottom of it is pitch black.

Spoiler

I suppose the space on the top and bottom should equal the average color of the end line.

Yeah, I know, and I agree with your proposed workaround. I just think that this issue is the lesser evil compared with the horizon moving into the sky.

Quote

Note that the same wouldn't work with REDSKY2, because the top is supposed to show a starry sky, not a flat color.

Hhm, now that would be an ideal candidate for a sphere then if you ask me.

[Mblackwell]

 Fox, on 06 August 2013 - 07:38 PM, said:

Which is not something obvious.

Edit: I did some tests, and I had a massive drop in the fps while displaying so many polygons.

How did you do this test? Was it a single high polygon object in a simple room with no lights? If you draw multiple objects particularly with lights you won't get the same result. If it's not faster than Polymost in this instance then there's something going on since Polymer should come out on top.

[RichardStorm]

This is not about eduke, but blender software... i downloaded 2.65, 2.68, 2.68a ; in each the addons menu shows nothing in there, so i can't load any plugin, rather than my working 2.61 version.

It's a common problem ? i have no python installed or environment variables right now...

// edit: i got Win7 32 bit

[Plagman]

 Helixhorned, on 07 August 2013 - 01:47 AM, said:

So this means that the shader sky rendering would proceed when the ceiling or floor is drawn instead of the beginning of each frame? Otherwise, you'd still have to decice up-front what sky to draw. (Well, or draw a bit until encountering a sky, then back off and draw anew, but that's not so great.)

Yes, the ceiling/floor polygons would be drawn as usual, even if parallaxed. Then the rendering inside these polygons would be in sky space rather than aligned to their plane. That's pretty much how Classic and Polymost do it and is really the only way to keep showview semantics consistent across renderers, as well as (not) seeing other sectors through skies, such as described there:

http://sourceforge.n...duke32/bugs/21/

[Plagman]

 RichardStorm, on 07 August 2013 - 11:49 AM, said:

This is not about eduke, but blender software... i downloaded 2.65, 2.68, 2.68a ; in each and the addons menu shows nothing in there, so i can't load any plugin, rather than my working 2.61 version.

It's a common problem ? i have no python installed or environment variables right now...

// edit: i got Win7 32 bit

I think you need Python for any of the plug-ins to show up, but I haven't dealt with Blender on Windows in a while so I might be wrong about that.

[RichardStorm]

Pls i don't want to explain the problem at all (it's a mess).... just answer if possible:

-> How to set PythonPath, for python 3.3, to be compatible with Blender 2.68 ? <-
// edit: and if i need to erase/work on bundled version etc

- blender is "as is" when extracted from dowloaded ufficial zip, so bundled python in it etc
- python 3.3 is fresh installed from downloaded .msi
- i got win7 32

[Fox]

 Mblackwell, on 07 August 2013 - 05:19 AM, said:

How did you do this test? Was it a single high polygon object in a simple room with no lights? If you draw multiple objects particularly with lights you won't get the same result. If it's not faster than Polymost in this instance then there's something going on since Polymer should come out on top.

Hmmm, it may have been my fault. But you are right that Polymer was doing better than Polymost.

[Fox]

I noticed that in DOS version, with some effort you can turn off the menu even if there is no demo file.



I am not sure if this is an error of Eduke32 or the DOS version, but is something I noticed.

[LeoD]

 fgsfds, on 02 June 2013 - 10:33 AM, said:

The latest builds show the same screenshot for every save game entry.

 LeoD, on 04 June 2013 - 08:00 AM, said:

To be exact, the first you scroll to if slot 0 is empty.

 LeoD, on 15 July 2013 - 12:08 PM, said:

Introduced in r3741.

Bump.

[TerminX]

Thanks for the reminder, I went ahead and fixed that in r4038.

[oasiz]

Caution, long post ahead

A pretty pointless inconsistency between 1.5 and eduke32 but something that me and
LLCooldave found out while searching for tricks. This thing is really minor but I found it pretty cool

Let's start with the setup:
In E2L9 you are supposed to end the episode by killing the boss, however if you use the Dukematch exit in the final arena, you can get to the next level.

This wouldn't normally be an issue but turns out that there is a way to reach it even in single player.. quite easily actually once you know what to do.

http://lerppu.net/pic/e2l9_1.png Here is the exit that I am talking about
http://lerppu.net/pic/e2l9_2.png Sector highlighted in mapster.

There is this button that is not flagged for MP only, http://lerppu.net/pic/e2l9_3.png
You can actually use this one trough the wall.

Easy way to try this (for replication purposes):
1: Noclip inside, open the door
2: Get outside of the door
3: Hug the wall, get as close as possible to the button, aim the X axis on the button
4: Jump and time use, this should hit the button and close the wall
Do this again but with the wall closed, it works! Just keep the reference point in mind.
The picture e2l9_3.png shows the spot you are looking for pretty well.


Ok, now for the main dish:

(Theory)
Since you are able to reach the secret level with a normal exit, the game kind of gets mixed up. From what I assume, the game has a special routine that gets called when you hit a secret level. In this case the game wont do +1 level but obeys the lotag, problem is that it doesn't tell if you are about to exit the level or enter, the "flag" simply gets toggled when you hit a green NB and gets cleared once you exit it.

(The thing itself)
So you will enter E2L10 like the normal NB should (level +1).
E2L10 has a secret level button, points to L6 so it calls Tiberius station as a secret level, you complete it and the game proceeds to L11 (since the boss was never killed). This calls L9 as a secret level and once you complete it the weird part starts.

1.5 - Sends you to Raw Meat (E3L1)
Eduke - Ends the episode

I guess what causes this is that 1.5 stores the levels in a linear fashion so that the pointer lands on the next entry which are E3 entries. After completing this you will land back at E2L1, this is something I do not understand though.. Does it overflow back to 1 due to having limited level entries per episode?

Episode 1 also suffers from something similar.
From what I remember, L5 MP exit will put you at L6 -> L5 -> ??
Eduke ends the episode
1.5 puts you at L7 (Faces of death).
This one is kind of hard to do without cheats since you need to glitch inside a wall with steroids but still possible to replicate with noclip.

Not sure if this is something that absolutely needs fixing but might be of interest if you want to keep behavior as close as possible to 1.5

[Fox]

 oasiz, on 07 September 2013 - 05:02 AM, said:

1.5 - Sends you to Raw Meat (E3L1)
Eduke - Ends the episode

I know v1.5 do some routines to check if the next map is not >10 (i.e. beyond the 11th level). The difference is likely because Eduke32 increased the limit of levels per episode, and that part was scrapped.