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

Jump to content

  • 213 Pages +
  • « First
  • 167
  • 168
  • 169
  • 170
  • 171
  • 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   Hendricks266 

  • Weaponized Autism

  #5041

View Postdarkprince227, on 28 December 2014 - 12:26 PM, said:

Also, there seems to be this litle problem with the User maps menu----

Attachment duke0006.png

I'm very sure it shouldn't be like that.

I don't understand what you think is the problem. Also, that is not a screenshot from the most recent build.
0

#5042

View PostHendricks266, on 28 December 2014 - 12:35 PM, said:

I don't understand what you think is the problem. Also, that is not a screenshot from the most recent build.


Sorry, wrong picture :) Here it is....

Attached Image: duke0009.png

Is the background square supposed to be completely black? because didn't it used to be transparent?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5043

It's intended, yes, though I agree that the translucent background looked better. I'll make it translucent again once I extend rotatesprite (internally) to take crop parameters, which I'll need to do anyway to make TX happy with how lines of text disappear when scrolled off the top or bottom of a scrolling region.
0

#5044

Cheers, Hendricks :P

By the way, I love the new sliding menu thing. Nice touch :)
0

User is offline   Helixhorned 

  • EDuke32 Developer

#5045

View PostFox, on 28 December 2014 - 12:06 PM, said:

Hit it with an RPG.

r4863 said:

actors.c: replace hard-coded list with missing check for SFLAG_NODAMAGEPUSH.

In A_RadiusDamage(). The code snippet that is disabled for such actors
increases the damaged actor's .xvel by (4 times the) damage amount and
is responsible for the strange effect of enemies becoming faster TOWARDS
the player on being hit with an RPG frontally.

Thanks to Fox for a keen eye.

3

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5046

View PostHendricks266, on 28 December 2014 - 12:45 PM, said:

It's intended, yes, though I agree that the translucent background looked better. I'll make it translucent again once I extend rotatesprite (internally) to take crop parameters, which I'll need to do anyway to make TX happy with how lines of text disappear when scrolled off the top or bottom of a scrolling region.

Just leave the text without black boxes, translucent or not. If you are worried about mods that use custom backgrounds, use a separate background like the Save/Load menus.

This post has been edited by Fox: 28 December 2014 - 01:04 PM

0

User is offline   Helixhorned 

  • EDuke32 Developer

#5047

View PostFox, on 28 December 2014 - 01:02 PM, said:

Just leave the text without black boxes, translucent or not. If you are worried about mods that use custom backgrounds, use a separate background like the Save/Load menus.

IMO a translucent black background looks classy. I'm biased though, since I originally implemented it in order to prevent a scene drawn underneath rendering the text unreadable.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5048

View PostHelixhorned, on 28 December 2014 - 01:13 PM, said:

IMO a translucent black background looks classy.

Agreed. I had to replace the xdim/ydim-based cropping of the tile with M_BlackRectangle() so that it would animate properly, and I had to disable the translucency because the patchwork displayed multiple layers of the tile in certain places.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5049

The mouse cursor is cropped at the bottom of the screen if the full status bar is visible.
0

User is offline   LeoD 

  • Duke4.net topic/3513

#5050

View PostRoma Loom, on 02 December 2014 - 11:38 PM, said:

Is it just me or loading a savegame doesn't load maphacked polymer light sources?
Roma, does your problem persist?

View PostHelixhorned, on 15 December 2014 - 12:15 PM, said:

For a simple test -- saving E1L1 on Polymer+HRP and loading from a just started EDuke32 instance -- everything works as expected for me. However, that doesn't exclude the possibility of failure for more complicated usage paths. Map hack light info is not stored in the savegame itself. Rather, the file map name stored in the savegame is used to construct that of a .mhk file (by replacing .map with .mhk) and that one is attempted to be loaded. So, if there's a discrepancy of what EDuke32 sees as its virtual file system between when the savegame was made and at load time, issues can arise.
Helix, could you save the relative (virtual FS) path of the loaded MHK separately? This would be an important first step into actually implementing the UserMapHack system...

View Postdarkprince227, on 28 December 2014 - 12:26 PM, said:

Also, the polymost override and Z-pack addons get totally cancelled out, maybe I should tell LeoD about this though.
Delete textures, textures.cache and retry. Post your eduke32.log in the Z-Pack thread if the problem persists. Btw, I actually stick to r4495 (synthesis 4488) for daily usage. As far as I'm concerned all later versions are broken in one way or the other, on one hardware or the other.

This post has been edited by LeoD: 28 December 2014 - 02:39 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #5051

View PostFox, on 28 December 2014 - 01:51 PM, said:

The mouse cursor is cropped at the bottom of the screen if the full status bar is visible.

I don't have this issue with the latest synthesis.
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5052

Is it possible to add an .htflags so enemies are not eaten by Protozoid Slimers like the bosses?

This post has been edited by Fox: 29 December 2014 - 07:53 PM

0

User is offline   Diaz 

#5053

It's been a while since I last worked on my EDuke32 stuff, and when I returned I noticed some changes:

First of all, the enemy palette issue is fixed, thanks Helixhorned.

Second, Polymer performance seems much, much worse now - maybe some added extra stuff that needs to be turned off?

Third, I had coded some actors to get the floor shade instead of the ceiling shade when under a parallaxed sky. That code doesn't work anymore and the ceiling shade is being applied, which I don't want.

More reports as I keep testing...
0

User is offline   Helixhorned 

  • EDuke32 Developer

#5054

View PostDiaz, on 30 December 2014 - 04:01 AM, said:

Third, I had coded some actors to get the floor shade instead of the ceiling shade when under a parallaxed sky. That code doesn't work anymore and the ceiling shade is being applied, which I don't want.

If you wish to change displayed sprite shade, there are two viable options. G_DoSpriteAnimation() will set the tsprite's shade to that of the ceiling or floor unconditionally, unless the corresponding actor has SFLAG_NOSHADE set, or the sprite CSTAT_SPRITE_NOSHADE ([N] from Mapster32).

This means that the options are:

1) to set any of these bits on the sprite. Then, sprite[].shade can be changed and will be taken over to the tsprite.

2) modifiy the tsprite's shade in EVENT_ANIMATESPRITES. Example:
gamevar tmp 0 0
 
state setup_animatesprites
    ifactor LIZTROOP
    {
        getactor[THISACTOR].mdflags tmp
        orvar tmp 16
        setactor[THISACTOR].mdflags tmp
    }
ends

onevent EVENT_EGS
    state setup_animatesprites
endevent

onevent EVENT_LOADACTOR
    state setup_animatesprites
endevent

onevent EVENT_ANIMATESPRITES
    ifactor LIZTROOP
    {
        setvarvar tmp totalclock
        andvar tmp 255
        settspr[THISACTOR].tsprshade tmp
    }
endevent


I'm not sure which recent change might have affected your code in that regard. Could you post the relevant parts of it?
0

User is offline   Helixhorned 

  • EDuke32 Developer

#5055

View PostLeoD, on 28 December 2014 - 02:30 PM, said:

Helix, could you save the relative (virtual FS) path of the loaded MHK separately? This would be an important first step into actually implementing the UserMapHack system...

What would the immediate gain be? If it's likely to be implemented as part of that system, why not wait for it to appear naturally?

Quote

Btw, I actually stick to r4495 (synthesis 4488) for daily usage. As far as I'm concerned all later versions are broken in one way or the other, on one hardware or the other.

Are these 'hard' issues like crashes or incorrect rendering? Which ones would be the most critical in your opinion?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5056

View PostLeoD, on 28 December 2014 - 02:30 PM, said:

Helix, could you save the relative (virtual FS) path of the loaded MHK separately? This would be an important first step into actually implementing the UserMapHack system...

My to-do list goes like this:
Enhance some visual aspects of the new menus
UserMaphacks
[Other stuff for 64 and TM]
[Other stuff for Android]
0

User is offline   LeoD 

  • Duke4.net topic/3513

#5057

View PostHelixhorned, on 30 December 2014 - 01:05 PM, said:

What would the immediate gain be? If it's likely to be implemented as part of that system, why not wait for it to appear naturally?
I don't trust nature, it may force me to do it on my own. And that part could be especially hard for me, as far as I can tell from thinking about an implementation concept.

View PostHelixhorned, on 30 December 2014 - 01:05 PM, said:

Are these 'hard' issues like crashes or incorrect rendering? Which ones would be the most critical in your opinion?
I'm quite tolerant to rendering issues. But recently, crashes at startup or when leaving the game have sneaked in. Some of them seem hardware dependent. Sometimes it's the normal executable, sometimes it's the debug version.
I've kept telling myself that I'll hunt all those down once I've reached my mystic UserMapHack milestone, but it appears that I'm constantly about fifty maps away from it :)
Maybe I should take a break from that mostly comfortable task and switch to some painful bug hunting. (Spell check just offered me 'Hermaphroditus' for 'UserMapHack' :P )
Other than that, two annoying things reported back in June are still present:
- USE and left mouse click as confirmation/proceed action in save/load game menus and maybe elsewhere, too, do not work as in the DOS executable.
- Start the game, use the left mouse click only to proceed to the top menu. Use the mouse wheel to scroll down to LOAD GAME. Confirm with left mouse click. Use the mouse wheel to scroll to a used slot of your choice. Use left mouse click to load that savegame -> the selection jumps to the slot above.

Feature request: Please put basic information about the CPU into eduke32.log.

View PostHendricks266, on 30 December 2014 - 02:34 PM, said:

My to-do list goes like this:
Enhance some visual aspects of the new menus
Those side-scrolling menus are quite annoying on a wide screen.

View PostHendricks266, on 30 December 2014 - 02:34 PM, said:

My to-do list goes like this:
UserMaphacks
I was about to post this in the UserMapHacks thread totay:
Spoiler


I tried to upvote, but my quota on this topic seems to be spent already. B)

This post has been edited by LeoD: 02 January 2015 - 03:34 PM

0

User is offline   TerminX 

  • el fundador

  #5058

I have a theory that some of the crashes are somehow related to the keyboard layout switching. I feel like I've seen a couple of logs where there were duplicate messages about switching the layout (e.g one message for switching from a foreign layout to the US layout but more than one message about switching back), which shouldn't be possible. Maybe try manually setting your system keyboard layout to US before launching the game and see if that does anything...
0

User is offline   Micky C 

  • Honored Donor

#5059

I've noticed that with the classic renderer, mapster seems to display overlapping sprites (sharing the same x-y coordinates) differently to eduke32, and in a superior and less glitchy way. I can provide example pics if needed, but is there anything that would explain this? Ideally whatever's going on with mapster can be moved over to eduke32 which should improve some things. I wonder if it has anything to do with Helix's modifying of stuff regarding sprites and masked walls a while back.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#5060

View PostMicky C, on 04 January 2015 - 03:46 AM, said:

I can provide example pics if needed

Please do.
0

User is offline   Micky C 

  • Honored Donor

#5061

Ah the joy of avoiding spoilers.
Running both mapster and eduke from r4873.



Mapster, view-alligned sprite sharing x-y coords with a floor-alligned sprite. Perfection.
Posted Image

In-game, floor-alligned sprite gets drawn over the top one, including the lens flair sprite that's positioned higher up on the z axis (everything candle-related disappears completely when looking down enough).
Posted Image

Voxel in mapster. Uses a separate floor-alligned sprite as a shadow. So far so good.
Posted Image

In-game same thing as before, the floor-alligned sprite is drawn on-top. This happens both when the voxel is wall-alligned and view-alligned.
Edit: When the voxel is floor-alligned the shadow sprite starts to show through in mapster too, however less consistently than it does in-game (where it is drawn on top from all angles).
Posted Image

This post has been edited by Micky C: 04 January 2015 - 04:57 AM

0

User is offline   TerminX 

  • el fundador

  #5062

Pretty sure that's related to my flawed attempts at fixing z fighting issues with wall and floor sprites. I have something that revises it in my tree that I'll commit soon.
2

User is offline   Helixhorned 

  • EDuke32 Developer

#5063

View PostTerminX, on 04 January 2015 - 06:24 AM, said:

I have something that revises it in my tree that I'll commit soon.

Oh. Me too. I just removed that sort-by-statnum, which is not very meaningful. That's since Duke3D though, so maybe we're not conflicting?

Edit:

Quote

Pretty sure that's related to my flawed attempts at fixing z fighting issues with wall and floor sprites.

Ah, that was in polymost.c, so it looks like we shouldn't step on each other's toes. My changes are mostly in engine.c.

EDIT2: Congrats for deceiving me into initially thinking that the first one is a Polymer shot BTW, Micky!
0

User is offline   TerminX 

  • el fundador

  #5064

View PostHelixhorned, on 04 January 2015 - 06:37 AM, said:

Oh. Me too. I just removed that sort-by-statnum, which is not very meaningful. That's since Duke3D though, so maybe we're not conflicting?

Edit:

Ah, that was in polymost.c, so it looks like we shouldn't step on each other's toes. My changes are mostly in engine.c.

I'd be careful removing that, I think I tried it once and ended up with oddities involving the sprites that spawn when shooting things.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#5065

View PostTerminX, on 04 January 2015 - 06:49 AM, said:

I'd be careful removing that, I think I tried it once and ended up with oddities involving the sprites that spawn when shooting things.

That's interesting. Maybe an upcoming bug report will shed light about what purpose that code served then :). I find the way it's written strange though: as far as I can see it overrides the preceding sort-by-z-difference, which is definitely not a good thing.
0

User is offline   Helixhorned 

  • EDuke32 Developer

#5066

View PostLeoD, on 02 January 2015 - 03:30 PM, said:

I'm quite tolerant to rendering issues.

Yeah, there's quite a number of glitches across all renderers. What I meant were deal-breakers like your monsters turning up faceless like reported earlier. Speaking of which, I first had the suspicion of it being related to AMD graphics hardware, but could not reproduce it on such a system either.

View PostFox, on 29 December 2014 - 07:07 PM, said:

Is it possible to add an .htflags so enemies are not eaten by Protozoid Slimers like the bosses?

I began looking through the GREENSLIME-related code but found it hard to read. Would you know where to find that condition check ("can facehug") in the source code?
0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5067

From actors.c:
            //Check randomly to see of there is an actor near
            if (rnd(32))
            {
                for (SPRITES_OF_SECT(sect, j))
                {
                    switch (DYNAMICTILEMAP(sprite[j].picnum))
                    {
                    case LIZTROOP__STATIC:
                    case LIZMAN__STATIC:
                    case PIGCOP__STATIC:
                    case NEWBEAST__STATIC:
                        if (ldist(s,&sprite[j]) < 768 && (klabs(s->z-sprite[j].z)<8192))   //Gulp them
                        {
                            t[5] = j;
                            t[0] = -2;
                            t[1] = 0;
                            goto BOLT;
                        }
                    }
                }
            }

Not sure if I understand why it eats new useractors.

This post has been edited by Fox: 04 January 2015 - 12:29 PM

0

#5068

Hi! I don't know if this is anything to do with eduke32, but I was testing the newest built and I seem to be having issues with the colour blue.

1- When I have HRP on, whenever I unlock a door, Duke's hand ALWAYS uses the blue card even if it's a yellow or red slot.
Attached Image: duke0000.png

2- Are the Assault Troopers and Captains supposed to all be wearing blue?

BTW, are the crosshairs supposed to be white?

This post has been edited by darkprince227: 04 January 2015 - 01:51 PM

0

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#5069

View Postdarkprince227, on 04 January 2015 - 01:51 PM, said:

BTW, are the crosshairs supposed to be white?

Yes, Eduke has a feature to remap the crosshair color.
0

#5070

View PostFox, on 04 January 2015 - 02:22 PM, said:

Yes, Eduke has a feature to remap the crosshair color.

Can you tell me how? I'm not sure how to use the 'crosshaircolor' thing in the console, I type 'crosshaircolor 252' or 'crosshaircolor r' etc but nothing seems to work.
Maybe I'm typing it wrong?
0

Share this topic:


  • 213 Pages +
  • « First
  • 167
  • 168
  • 169
  • 170
  • 171
  • 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