Duke4.net Forums: EDuke32 2.0 and Polymer! - Duke4.net Forums

Jump to content

  • 213 Pages +
  • « First
  • 155
  • 156
  • 157
  • 158
  • 159
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 2.0 and Polymer!  "talk about the wonders of EDuke32 and the new renderer"

User is offline   Micky C 

  • Honored Donor

#4681

It's because the original mappers compensated for the issue by shifting the textures in their maps. The bug's still there, they just covered it up.
0

User is offline   MetHy 

#4682

View PostMickey C, on 26 May 2014 - 03:30 AM, said:

It's because the original mappers compensated for the issue by shifting the textures in their maps. The bug's still there, they just covered it up.


That's assuming that the issue do come from the fact that the texture isn't power of two; by if that was the case I'm inclined to think ALL the use of that textures would look glitchy; except only about half do (like I said, the same non power of two texture used in the same manner, only about half look glitchy).

This post has been edited by MetHy: 26 May 2014 - 03:43 AM

0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4683

Not sure what you meant. Isn't it because half the textures are bottom-aligned?

This post has been edited by Fox: 26 May 2014 - 04:19 AM

0

User is offline   MetHy 

#4684

Check the example I joined here
http://forums.duke4....post__p__196956

They're all bottom aligned, but only half glitch.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4685

The left and right sides have different y-pannings, 107 and 11 respectively. Which is a problem of non-power of two textures (107 - 11 = 96 = 2^4 * 6).

This post has been edited by Fox: 26 May 2014 - 04:34 AM

0

User is offline   MetHy 

#4686

Yeah I noticed that, but of course it you set the same panning it won't look aligned. And that still doesn't change the fact that alignment will be different in 32bit, no matter the panning, but only for the part on the left.
0

User is offline   Daedolon 

  • Ancient Blood God

#4687

View PostMetHy, on 26 May 2014 - 02:58 AM, said:

Edit : it seems that the reason why I can't fix the glitchy textures simply by pasting the same non glitchy texture onto it, is because in this case the glichty textures are at the bottom of a texture swap bit (=2 textures on the same wall).


The way I get around this is just change the texture from top/bottom to the other one. Sometimes moving the sector just by a notch vertically helps too (alt and mouse or just changing the Z in 2D mode).


EDIT: So yeah, I took a look at the map and the Cstat for the walls with the bug were different from the working ones, looks like they were flipped. I'm thinking since it's not power-by-two, the wall still gets shifted either way in 8bit because of the rendering issue. I just think due to sheer luck it ended up being shifted to the correct place on the wall to the right, but because of the vertical flipping the wall on the left had, it got shifted in a different way and ended up being rendered wrong always in one of the renderers.

This post has been edited by Daedolon: 26 May 2014 - 07:59 AM

0

User is offline   OpenMaw 

  • Judge Mental

#4688

Does showview still not work in Polymer? Posted Image
0

User is offline   Daedolon 

  • Ancient Blood God

#4689

Nope. Waiting for it to be fixed so one of our mods can be actually released.
0

User is offline   MetHy 

#4690

View PostDaedolon, on 26 May 2014 - 07:07 AM, said:

The way I get around this is just change the texture from top/bottom to the other one. Sometimes moving the sector just by a notch vertically helps too (alt and mouse or just changing the Z in 2D mode).


EDIT: So yeah, I took a look at the map and the Cstat for the walls with the bug were different from the working ones, looks like they were flipped. I'm thinking since it's not power-by-two, the wall still gets shifted either way in 8bit because of the rendering issue. I just think due to sheer luck it ended up being shifted to the correct place on the wall to the right, but because of the vertical flipping the wall on the left had, it got shifted in a different way and ended up being rendered wrong always in one of the renderers.


I'm not certain the flipping is related to the glitch. I've seen other textures glitch while they weren't flipped and while the same texture, same flipping, just next to it, didn't glitch. I also don't believe it's by luck that it ended up being correct; in the map there were a few of those all the around the map which didn't glitch, while all the glitchy ones glitched in the same way.

It's the 4th time I see this glitch, to me it's completely random. Thanks for finding a way to get around the problem though.

This post has been edited by MetHy: 26 May 2014 - 08:22 AM

0

User is offline   Daedolon 

  • Ancient Blood God

#4691

View PostDaedolon, on 26 May 2014 - 07:07 AM, said:

EDIT: So yeah, I took a look at the map and the Cstat for the walls with the bug were different from the working ones, looks like they were flipped.


Helixhorned: Basically what this means, is that when pasting textures (tab->enter) on the lower portion of a two-textured wall segment (created by pressing 2), the cstat (slash flip) information isn't pasted among other info.

I'd count this as a bug.
0

User is offline   MetHy 

#4692

So I just realized that wall-aligned sprites aren't affected by light changes made with SE8 (up open door lights). Only when they're wall-aligned though, it works for any other type of sprites (like, it works if that same sprite is floor aligned etc); also, wall aligned sprites DO get affected by light changes using SE12 (light changes using a switch).

So, could this be something that could be implemented in eduke32? I don't believe it would influence already existing maps (wether from the original game or usermaps) in a negative way. If anything, I don't think wall aligned sprites and SE8 are used together very often or else somebody would have noticed this sooner...

Rather than being automatic though, perhaps it could be added as a feature the mapper has to 'turn on' by pressing a key on the sprite. I know that would make things more complicated but at least we'd be sure it wouldn't have unwanted consequences on already existing maps...

This post has been edited by MetHy: 30 May 2014 - 06:32 AM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#4693

View PostMetHy, on 30 May 2014 - 06:29 AM, said:

So I just realized that wall-aligned sprites aren't affected by light changes made with SE8 (up open door lights). Only when they're wall-aligned though, it works for any other type of sprites (like, it works if that same sprite is floor aligned etc); also, wall aligned sprites DO get affected by light changes using SE12 (light changes using a switch).

That they're not affected by the shade change has nothing to do with SE8, but with the fact that wall-aligned sprites in particular don't take over the ceiling/floor shade. The code path responsible for this is in G_DoSpriteAnimations(). Note that this means that it's tsprite shade, not sprite shade:

    for (j=spritesortcnt-1; j>=0; j--)  // Loop over drawn sprites
    {
        spritetype *const t = &tsprite[j];  // 't' is a pointer to a drawn sprite
(...)
        if (t->picnum < GREENSLIME || t->picnum > GREENSLIME+7)
            switch (DYNAMICTILEMAP(t->picnum))
            {
(...)
            default:
                // NOTE: wall-aligned sprites will never take on ceiling/floor shade...
                if ((t->cstat&16) || (A_CheckEnemySprite(t) && t->extra > 0) || t->statnum == STAT_PLAYER)
                    continue;
            }

        // ... since this is not reached:
(Code that potentially takes over a ceiling/floor shade to 't'...)
    }


In contrast, the SE12 handling code explicitly sets the shades of wall-aligned (and only those) sprites contained in sectors affected by it. In G_MoveEffectors():

        case SE_12_LIGHT_SWITCH:
            if (t[0] == 3 || t[3] == 1)   //Lights going off
            {
(...)
                for (SPRITES_OF_SECT(SECT, j))
                    if (sprite[j].cstat&16 && A_CheckSpriteFlags(j,SFLAG_NOSHADE) == 0)
                    {
                        if (sc->ceilingstat&1)
                            sprite[j].shade = sc->ceilingshade;
                        else sprite[j].shade = sc->floorshade;
                    }
(...)
            }


^ That potential taking over of shade + SFLAG_NOSHADE check is repeated a couple of times throughout actors.c, but in slightly different variations. Yuck!

Quote

So, could this be something that could be implemented in eduke32? (...)

Rather than being automatic though, perhaps it could be added as a feature the mapper has to 'turn on' by pressing a key on the sprite. I know that would make things more complicated but at least we'd be sure it wouldn't have unwanted consequences on already existing maps...

In principle it could be implemented as another cstat bit. The problem is, this is really ugly... we'd be assigning meaning to a bit of an engine-side structure (sprite[]) in order to work around deficiencies in game code. Maybe these kind of things are good candidates for a (not yet implemented or even thought out) feature of the map-text format to carry ancillary data for map constituents.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4694

View PostDaedolon, on 26 May 2014 - 06:20 PM, said:

Helixhorned: Basically what this means, is that when pasting textures (tab->enter) on the lower portion of a two-textured wall segment (created by pressing 2), the cstat (slash flip) information isn't pasted among other info.

I'd count this as a bug.

Yup, kind of. With r4493:

Quote

Mapster32: when pasting onto the bottom part of a [2]-wall, take over y-flipping.

Note that x-flipping is determined by the cstat of the upper part of the wall
(that is, the wall facing the player, not the nextwall, from which the picnum
for the bottom part is taken.)


So, if we were to take over x-flipping, it would affect the top part too.
0

User is offline   Micky C 

  • Honored Donor

#4695

The mapster32 undo feature skips wwwwwwwwwwwwwwwaaaaaaaaaaaaaaaaayyyyyyyyyyyyyyyyyyyyyyyy too many changes involving things like pasting textures and altering texture alignments. Very annoying when you use the feature and have to redo a minute's work every time you wanted to undo one little thing. Is this a bug or an attempt at convenience by skipping potential insignificant changes? It's also a bit ironic because there was some other type of change that takes way too many undos to actually properly undo, but I can't remember what it was.
0

User is offline   Daedolon 

  • Ancient Blood God

#4696

It does? I used it once in my map over a really small thing and saved, now I can't remember what I fucked up :)
0

User is offline   Hendricks266 

  • Weaponized Autism

  #4697

The first WIP of my new menus are committed. This was a task that took me well over 100 man-hours and was 11 years overdue. Besides cleaning up "the single worst fucking mess in all of EDuke32", it also opens up the door to custom menus down the road using Lunatic.

This has nothing to do with scripting for the time being, or CON likely ever.

The main impetus for this was making the menus Android-ready. Otherwise, there are not many changes that are visible but I'll point out the improvements I did make.

First off, all menus will automatically scroll if their contents exceed the page. You can see this with the Game Setup page, which is two screens merged into one, and the Keyboard Key and Joystick Button menus.

Posted Image

Slider bars will generally display a numerical value to their side. (I added a separate music on/off.)

Posted Image

You can press Enter on some menu option toggles to bring up a menu of possible choices. This was initially created for the mouse/joystick button menus, but I thought it natural to extend the functionality to places that could benefit.

Posted Image

In addition to this, you can press left/right on options you may not have been able to before, such as mouse/joystick input screens.

Smoothed out/improved joystick menu, though the underlying functionality is still broken and needs to be addressed.

Posted Image Posted Image Posted Image

One final thing is that you can enter the color escape sequences in a visible manner (like markup) while entering a string, then they will take effect when you exit the editing mode.

Posted Image Posted Image

I still have yet to implement mouse/touch/pointer support, which is its own can of worms due to gesturing and whatnot.

Please test this thoroughly, and report any crashes or misbehavior.

Posted Image
7

User is offline   Helixhorned 

  • EDuke32 Developer

#4698

View PostHendricks266, on 31 May 2014 - 04:37 AM, said:

The first WIP of my new menus are committed. This was a task that took me well over 100 man-hours and was 11 years overdue. Besides cleaning up "the single worst fucking mess in all of EDuke32", it also opens up the door to custom menus down the road using Lunatic.

An enormous effort indeed, but one that will hopefully pay off in the long run. I guess reviewing it will take a while (git --stat shows 8334 changed lines in menus.c!). If I recall properly, you did all of your development in one file, and then kind of merged that in with menus.c, right? I'm asking because it would have been a bit easier to see commits broken down a bit more. But I can understand if that was too cumbersome to pull off given that this was to a large extent coding with a chainsaw.

Right now, it's failing to compile for me:
$ LTO=0 WITHOUT_GTK=1 RELEASE=0 LUNATIC=0 make -j4
(...)
source/menus.c: In function ‘M_MenuEntryOptionModify’:
source/menus.c:2475:24: error: ‘ME_GAMESETUP_UPDATES’ undeclared (first use in this function)
     else if (entry == &ME_GAMESETUP_UPDATES)
                        ^
source/menus.c:2475:24: note: each undeclared identifier is reported only once for each function it appears in


Edit: OK, that one only needed an #ifdef _WIN32. Looks good.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4699

View PostHendricks266, on 31 May 2014 - 04:37 AM, said:

Posted Image

Would it be feasible to classify it by aspect ratio?

Aesthetically, the text should be in the left corner, or center-aligned, or being aligned with the x in the center.
1

User is offline   Daedolon 

  • Ancient Blood God

#4700

I'd like them to be sorted out by height > width and having the largest resolution at the top, with all the text aligned to the right.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4701

View PostMetHy, on 24 May 2014 - 01:20 PM, said:

I've already mentioned this glitch in another thread and I found a way to 'fix" the problem but the 'fix' I found doesn't work anymore.

Here is the thing, some textures get misaligned when switching to 32bit mode.

That's a well-known issue, its root cause being the improper rendering of walls with non-power-of-two height textures in 8-bit mode. Here's an example with BIGORBIT2 which is h := 400 texels high:
Attached Image: npoty_classic.png

See what classic does here. Basically, it renders the wall as if with a texture of a height that's the next power of two greater than h, 512. This pseudo-texture has 400 horizontal lines of the original texture, plus 112 more, made up from the first ones of the same texture. As a result, there is now a seam in the apparent texture. What's the problem with that? Well, the Polymodes have no problems with NPOT height tiles at all:
Attached Image: npoty_pmost.png

But this means that such walls can't always be displayed the same in both renderers. A necessary but not sufficient condition is that a wall can only show at most h texels in height.
In order to overcome certain improperly aligned cases in the original maps, Polymost, and then later Polymer added a hack that modifies the apparent ypanning of a wall when its real .ypanning exceeds some value (that's also dependent on h). However, this workaround suffers from the obvious drawback of introducing a discontinuity with ypanning.

Enter r_npotwallmode (r4498):

Quote

Polymost: r_npotwallmode, emulating 8-bit for walls w/ nonpow2 height textures.

When that mode is enabled (see below for caveats), wall textures that have a
non-power-of-two height (call it 'h') will be modified to look like in classic:
Let 'H' be the next power of two greater than 'h'. The texture will be uploaded
with height 'H', made up from 'h' hlines of the original texture, followed by
'H'-'h' first hlines of the same.
No panning "corrections" will take place. The mode is disabled by default.

Caveats/notes:
* the mode requires that r_hightile is disabled
* it is not implemented in Polymer
* in the Lunatic build, it is ineffective when a VX map is loaded, as those
display walls with NPOT height textures correctly

2

User is offline   Jblade 

#4702

Anyway to disable the darkening effect of the menu on the gameworld?
0

User is offline   Helixhorned 

  • EDuke32 Developer

#4703

View PostJames, on 01 June 2014 - 08:30 AM, said:

Anyway to disable the darkening effect of the menu on the gameworld?

Currently no, but feel free to add it to the suggestions wiki page under a new section.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4704

Can you add a function to offset the menu up or down (at least for the main menu)? This is an issue if you are using an header tile bigger than the original.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#4705

Synthesis builds are broken - last version created is r4488.
0

User is offline   Plagman 

  • Former VP of Media Operations

#4706

Fixed!
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4707

Any chance of having sloped sprites in the future? Or is it just too complicated?
0

User is offline   Diaz 

#4708

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

This means an enemy (or any other sprite) with a different palette (for example the grey cultists I ripped from Blood, which are brown cultists with pal 13) will lose its pal if it's in a fogged sector. In the example I mentioned, now all grey cultists are brown.

Is this the new expected behavior or a bug?

Thanks.
0

User is offline   blizzart 

#4709

 Diaz, on 01 June 2014 - 11:04 PM, said:

I've been away for a while, and after retaking work on Fusion with the latest EDuke32 build, I noticed there's a new behavior for palettes. Sprites on a sector with a fog pal always take that pal.

This means an enemy (or any other sprite) with a different palette (for example the grey cultists I ripped from Blood, which are brown cultists with pal 13) will lose its pal if it's in a fogged sector. In the example I mentioned, now all grey cultists are brown.

Is this the new expected behavior or a bug?

Thanks.


Try to press 'N' on those sprites, so that they keep their own shade and pal should work here.
0

User is offline   Micky C 

  • Honored Donor

#4710

N doesn't ale them keep their pal, only their shade. Although I believe that it should make them keep their pal as well.

Diaz, there's a new fogpal feature for openGL which allows you to set a sector's fogpal independently of pal, using a previously unused sector tag. Can't remember which one though. Press F7 and see if there's anything new.
0

Share this topic:


  • 213 Pages +
  • « First
  • 155
  • 156
  • 157
  • 158
  • 159
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options