[MusicallyInspired]

 Plagman, on Jul 27 2010, 02:18 PM, said:

MusicallyInspired,

is the shadow issue illustrated in your screenshots something recent, or has this always happened? I think your GPU falls into the "polygon offset" workaround where I had to disable a functionality that makes shadow look more correct because of a driver bug that caused a software fallback (causing huge performance hits and sprites showing above everything else, not sure if you remember). I think that's the cause of the shadow problems you're seeing, just wanted to confirm that it was always like that and wasn't anything new with the new version.

Yeah, it's been like that for quite a while. As far as I can remember anyway. And I'm the person who had that exact problem you're describing back then. So it's probably my card. Just making sure.

[Mark]

POST DELETED. I will fix my other problem before commenting on the newest version.

[Sobek]

I've been away for a while, but I just started working on some maps again and figured I'd test some particularly nasty sections of some maps (performance-wise) to see if the latest build fared any better on my crappy work PC (which I have since ditched for mapping).

There's definitely a marked improvement. It no longer randomly crashes when switching between 2d/3d with the Polymer renderer active (I normally turn it on and off as needed but it would be nice to not have to), and the overall framerate in some particularly bogged down areas has improved in the order of maybe 20 or 30%... One spot in particular was running at around 15fps with polymer active in Mapster, but now sits at a good 30fps or so the whole time with nowhere near as much random pausing or stuttering.

This is a pretty tame PC by today's standards though - it's just a single core A64 3200+ with an HD3870 and 1gb of ram.

[Mark]

I made the jump from version 1661 to 1676. I did a clean install.
There is about a 10 FPS increase in many parts of the regular duke levels in Eduke32 with this new version. And no other bugs found yet But no increase in the large outdoor areas of my W.I.P. map that could really use a boost

I am having problems with Mapster in this new version. In the Polymer mode sprites are showing up green all over the place.
Second problem is Mapster quits and returns back to my desktop every time I try to load any second map if polymer mode is enabled.



I'll post later with more details and my system info and log file in the other area of the forum for bugs and problems.

[TerminX]

Heh, I actually saw the green sprite thing at some point earlier but didn't get around to figuring out the cause yet. See if you can determine which build started the problem.

[Mark]

I just downloaded and ran the last 4 versions. 1674 and before, no green sprites. 1676, green sprites.

There was no 1675 listed to try out.

[Skulldog]

Had a glich with r1676. On e1l1 I jump off the building in the air duct. and the duct was sealed up at the end, I was
traped inside the air duct. I turn on god mode for jet pack, flew to the top and it was sealed closed too. Restarted
the level and then it was fine.

[Master Fibbles]

You somehow passed up the teleport. That is odd but I think it can happen anyway.

[Skulldog]

 Mr.Flibble, on Jul 28 2010, 10:28 AM, said:

You somehow passed up the teleport. That is odd but I think it can happen anyway.

Yea, it may of had nothing to do with r1676. Maybe it was because I jump in while the gas tanks
exploded.

[Night Wolf]

 Skulldog, on Jul 29 2010, 01:49 AM, said:

Yea, it may of had nothing to do with r1676. Maybe it was because I jump in while the gas tanks
exploded.

Yeah..... that glitch has been there since 1996, It's happened to me a few times..
if you jet pack down you can see how the sectors of the map load, your essentially teleported to the ground.

[RPD Guy]

Hi friends!

The latest version of eduke is the most buged!
my mapster crashes every time, i can't build my maps! :/
and eduke crashes every time too and some times the FPS become 0 FPS
before eduke don't crashes, but now....

i can't understand!
somebody can help me?

My cfg:
AMD athlon X2 245 2.95 ghz
2 Gb Corsair DDR3 1600mhz
Nvidia Geforce 9800 GTX+ Plus
ASUS M4A79XTD EVO 133
HD seagate 1 Tb
OS: Windows 7 x64

My Question: Windows 7 x64 don't supports eduke?

[The Commander]

 Dk2, on Jul 31 2010, 04:53 AM, said:

Crap

Please Read This Before Posting Bugs.

[Hendricks266]

I move for to become a smiley.

[Helixhorned]

DeeperThought, on Jul 16 2010, 06:51 PM, said:

I agree, and I think that hardcoded lights should be kept to a minimum. In addition to the performance issue, there's the fact that mappers didn't consider many sprites to be light sources. Take switches, for example. Sometimes switches that are supposed to be hidden give themselves away in Polymer because of the light they give off. And there is another issue. In a TC, there may be a completely different tile of that number which the light doesn't fit, and it just adds one more annoying hardcoded thing for the scripter to deal with.

I agree with DeeperThoght, hardcoded sprite lights should be kept to a minimum and applied very carefully. There's another issue with them: when there are many light-emitting sprites on a small area, their effects on the textures are added together an the result looks completely "overexposed". The room with the slime babes and explosives in E3L1 is a good example.

High Treason, on Jul 16 2010, 08:15 PM, said:

I've had an idea, how difficult would it be to add a feature to Mapster32 where point lights show a circle on the 2D View like ambient sounds? This would be really useful. Just an idea.

Micky C, on Jul 17 2010, 09:41 AM, said:

I always thought it'd be nice if there was some way to see what colour polymer lights are in 2D mode, the only way to tell at the moment is to switch into 3D mode, which usually takes a few seconds, and it can be a bit time consuming if you have to make constant corrections to get the colour right. Although High Treason's idea would be more practical and easier to implement.

Been hacking that the whole evening (way too long), it's implemented in m32script. To fully display the projection of a spotlight would be pretty tricky, so only the general direction is shown. By the way, you don't need to tweak light parameters in 2d mode: if you enable EVENT_PREKEYS3D, some keypad keys will be overridden for SE light manipulations and some Polymer texture parameters, the usage is documented in a.m32. If you want the script extensions loaded when Mapster starts, you can now have a file m32_autoexec.cfg somewhere on you load path with

include samples/a
enableevent all

I've fixed that Mapster crash but, TX, there's something strange going on with the caching system it seems...

[Stabs]

Can you explain that fiddlewithlights defstate in a bit more detail helix, ive looked over it but cant seem to get it to do anything

[Helixhorned]

You don't actually need to fiddle with it explicitly, it's called from EVENT_PREKEYS3D. Take a look here.

[Night Wolf]

Helixhorned, on Aug 4 2010, 08:51 AM, said:

I agree with DeeperThoght, hardcoded sprite lights should be kept to a minimum and applied very carefully. There's another issue with them: when there are many light-emitting sprites on a small area, their effects on the textures are added together an the result looks completely "overexposed". The room with the slime babes and explosives in E3L1 is a good example.

Yeah the slime canisters look horrible, be good if it wasn't so bright...
The thing is with the "red siren light" sprite, in some of the duke maps people have added a red light source to it , but when the light is destroyed the lighting remains which it stupid.
I agree it should be kept to a minimum, but I think that particular sprite should be hardcoded.

[Stabs]

Helixhorned, on Aug 4 2010, 05:57 AM, said:

You don't actually need to fiddle with it explicitly, it's called from EVENT_PREKEYS3D. Take a look here.

best script ever!

[Searinox Navras]

Pardon me if there is an answer to this but... for 2 years I've been using the HRP and since then and up to polymer one issue has stuck no matter what I did - the hidden text on dark walls supposed to be visible with night vision goggles just doesn't show. Got any ideas?

[Sobek]

DanM, on Aug 5 2010, 08:17 PM, said:

best script ever!

I'll second that. That makes things a heck of a lot simpler.

[Stabs]

there is EVENT_KEYS3D opens swing doors I'am not sure how useful that is too you in space, need something for slide doors, they are a PITA in mapster

Helix seeing as the lights X Y Z can be modified with alt+kp1 can something be made like that for every other sprite, i would love something that could modify those values in 3d mode

[Tea Monster]

Searinox Navras, on Aug 8 2010, 11:20 PM, said:

Pardon me if there is an answer to this but... for 2 years I've been using the HRP and since then and up to polymer one issue has stuck no matter what I did - the hidden text on dark walls supposed to be visible with night vision goggles just doesn't show. Got any ideas?

They glowed due to the way that the ancient palette of Duke 3D worked. Now that everything is using a full colour palette, the engine ignores those colours.
You could do it by having those sprites tagged somehow by the engine, and you could then make glow-maps for them in typically night-vision style.

[Helixhorned]

DanM: which values? The SE lights were good candidates because their properties are directly visible in 3D mode, but for a lot of other effector sprites that's not true. I do have in the back of my head more WYSIWYG-style enhancements, though there's always the question how practicable they are... the swinging door tester for example sometimes corrupts maps in cases where the door sector is not a single island sector, so don't use it for now.

[Stabs]

the x y zvel values, the command alt+kp1 that brings up red green blue could just say xvel yvel zvel anyway, if your using polymer you should already know these things so if it could be extended to effect all sprites that would be quite handy.

[Hendricks266]

Hey Helixhorned, you broke the win32 build.

source/m32exec.c: In function 'VM_OnEvent':
source/m32exec.c:155: error: implicit declaration of function 'alloca'
source/m32exec.c:155: warning: incompatible implicit declaration of built-in function 'alloca'
source/m32exec.c: In function 'VM_Execute':
source/m32exec.c:344: warning: incompatible implicit declaration of built-in function 'alloca'
Failed building obj_win/m32exec.o from source/m32exec.c!
make: *** [obj_win/m32exec.o] Error 1

[Helixhorned]

Heh, I "kinda" knew that. Working on it.

[Searinox Navras]

Tea Monster, on Aug 10 2010, 11:04 AM, said:

They glowed due to the way that the ancient palette of Duke 3D worked. Now that everything is using a full colour palette, the engine ignores those colours.
You could do it by having those sprites tagged somehow by the engine, and you could then make glow-maps for them in typically night-vision style.

Yet monsters do still glow with nightvision.

[MusicallyInspired]

Because they have glowmaps? I don't know why nobody thought to make any for those letters, though. Those are fairly important.

[Hendricks266]

No, monsters glow because they are hardcoded to turn pal 6 when nightvision is on.

[Chip]

And can also be setup through CONs using a simple command.
Use that for all the letter / number tiles and place them somewhere loose within the GAME.con, lets say right at the bottom.