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

Jump to content

  • 210 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

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

#4682

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

  #4683

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.

https://i.imgur.com/nfX5Wn7.png

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

https://i.imgur.com/3ySBQ5f.png

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.

https://i.imgur.com/fU6h0sB.png

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.

https://i.imgur.com/QNOtYH6.png https://i.imgur.com/3OJkOni.png https://i.imgur.com/sFiDcTG.png

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.

https://i.imgur.com/HjzgpeO.png https://i.imgur.com/ghzvSif.png

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.

https://i.imgur.com/zO58tyE.png
7

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#4684

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!

#4685

https://forums.duke4.net/public/style_images/cgs/snapback.png' alt='View Post' />Hendricks266, on 31 May 2014 - 04:37 AM, said:


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

#4686

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 Senior Developer

#4687

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 

#4688

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

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#4689

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!

#4690

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 

  • Topic #3513

#4691

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

User is offline   Plagman 

  • Former VP of Media Operations

#4692

Fixed!
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4693

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

User is offline   Diaz 

#4694

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 

#4695

View PostDiaz, 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

#4696

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

User is offline   Mike Norvak 

  • Music Producer

#4697

View PostDiaz, 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.


Yeah, I noticed it as well, on WGR there are pal 17 petrified enemies that don't look like gray stone on fogged sectors. It is definitely a bug.
0

User is offline   Diaz 

#4698

Mickey C, that's nice, but does that mean I have to go through all of my maps to change sector tags?

Though m32script could do the trick.. the new feature shouldn't break old maps/mods though, and it currently does.

This post has been edited by Diaz: 02 June 2014 - 06:22 AM

0

User is offline   Kyanos 

#4699

View PostMike Norvak, on 02 June 2014 - 06:07 AM, said:

Yeah, I noticed it as well, on WGR there are pal 17 petrified enemies that don't look like gray stone on fogged sectors. It is definitely a bug.

That forgettable map foothold had lots of alt pal enemies in fog.

I've been beta testing some maps, and wanted to record screenshots of my level stats but it won't take a pic of the text, just the background sprite gets captured. (rev-4482) Not sure if it's a bug or even a big deal but I know Megaton lets me do it.
0

User is offline   Diaz 

#4700

I'm new to m32script, and this doesn't seem to work (to implement the new fogpal system in existing maps):

gamevar i 0 0
gamevar paltemp 0 0
gamevar isparallax 0 0


for i allsectors 
{
    ifge sector[i].floorpal 30
    {
        setvarvar isparallax sector[i].ceilingstat
        ifvarand isparallax 1 
        {
        }
        else
        {
            setvarvar paltemp sector[i].floorpal
            set sector[i].fogpal paltemp
            set sector[i].floorpal 0 
            set sector[i].ceilingpal 0
        }
    }
}


any idea why?

thanks!
0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#4701

View PostDiaz, 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.

(...)

Is this the new expected behavior or a bug?

It's kind of a bug. It has nothing to do with the introduction of sector[].fogpal, but is a consequence r4335: the predicate that tells whether a sprite should take over the floor pal of its sector was changed with a then-unforeseen side effect. It only concerns nonzero pals that are not the default fog pals (26 .. 29 for the vanilla LOOKUP.DAT). More on that later.

View PostDiaz, on 02 June 2014 - 07:23 AM, said:

I'm new to m32script, and this doesn't seem to work (to implement the new fogpal system in existing maps):

Please post the error output. It should be written out to mapster32.log.
0

User is offline   Diaz 

#4702

No error output, but the sectors are keeping their original palette and looks like the .fogpal member is not being written.

BTW, the sprites do keep their palette "internally" - pal 13 enemies behave like pal 13 enemies in CON code, for example. They just revert to pal 0 visually.

This post has been edited by Diaz: 02 June 2014 - 08:26 AM

0

User is offline   Helixhorned 

  • EDuke32 Senior Developer

#4703

View PostDiaz, on 02 June 2014 - 08:23 AM, said:

No error output, but the sectors are keeping their original palette and looks like the .fogpal member is not being written.

If you're running Polymer, make sure you have ART mapping disabled: r_pr_artmapping 0. There, visibility/fog is done by looking up the shade table of each pal, there's no additional GL fog.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4704

Is it possible to do something about the effect of linear filter in repeating textures? Flat sprites won't blend with the wall texture:

Spoiler


I believe that flat sprites should have the same default behavior as the level architecture. This won't look good in some cases like blood splats but it's the same for masked walls. This is also a problem for rotatesprite.

Maybe it could detected if one of the corners is transparent, at least it's a hack that would work for Duke 3D textures. But we should have the ability to define it for each texture individually.

This post has been edited by Fox: 05 June 2014 - 01:41 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #4705

Why wouldn't you just use a masked wall there?
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4706

That's not the point, this is an hypothetical example.

This post has been edited by Fox: 05 June 2014 - 03:11 PM

0

User is offline   MetHy 

#4707

Version 4500 doesn't ask you whether or not you want to load your latest save when you die; it just loads it.
3

User is offline   Kyanos 

#4708

Also saves don't name themselves as the map name anymore... If I don't name a save it comes up empty and overwrites the old save with nothing.

added
So, I go back to the game and now the saves do exist but they are all named user map.

This post has been edited by Drek: 05 June 2014 - 04:56 PM

1

User is offline   Hendricks266 

  • Weaponized Autism

  #4709

Damn, and I thought the new save menus were all ironed out. Keep the bug reports coming.
1

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#4710

Can you make saved games created with save command to be hidden? I.e. create an autosav#.esv file.
0

Share this topic:


  • 210 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