Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

dunno if anything like this has been reported :

MWSnap00166.jpg

 

all effects became blurry like this, after i went from windowed to full screen and back to windowed

Share this post


Link to post
Share on other sites

Beaverhunter: As I stated, that question was in reference to shadows, not lighting.

 

Alia: I'll work on that today.

 

Hmms, well what info is it that you want then? I allready said that I have tried with all options including shadows disabled and enabled with no changes. Excluding the new light + new weather however made it light again, how can that be shadow related? And if it is, then what do you need to fix it?

Share this post


Link to post
Share on other sites

It has, and it's actually not related to eye candy. It's something more serious that's corrupting memory when you change vid modes. Usually, that's been asymptomatic, but now it's not.

 

I haven't had chance to dig into it.

Share this post


Link to post
Share on other sites

It has, and it's actually not related to eye candy. It's something more serious that's corrupting memory when you change vid modes. Usually, that's been asymptomatic, but now it's not.

 

I haven't had chance to dig into it.

 

I have noticed a strange thing before when changing from windowed to fullscreen a few times... instead of the Seridia/Irrilion world map I got a texture of the fonts. So changing video modes sure has weird effects.

 

Also about that "world map" why isn't there a X where the player is anymore?

Share this post


Link to post
Share on other sites

Sounds likely. You might want to look into it.

 

Oh, and meanwhile, I'm probably going to get a new -DDEBUG_TTLANHIL_TRANSPARENCY in tonight, just so you know.

Share this post


Link to post
Share on other sites

Why do you guys keep adding variables only to the C part in eye_candy_wrapper.h

 

#ifdef __cplusplus

extern "C" int use_eye_candy;

#else

extern int use_eye_candy;

extern int use_lamp_halo;

extern float min_ec_framerate;

extern float max_ec_framerate;

#endif

 

You should add them to the __cplusplus part as well

extern "C" int use_lamp_halo;

extern "C" float min_ec_framerate;

extern "C" float max_ec_framerate;

Share this post


Link to post
Share on other sites
...You should add them to the __cplusplus part as well
Adding to this:

It really pays in the long run to only define global variables once. The 'extern "C"' part should wrap, if possible, the entire C header file, or the entire single definition/declaration block in a C++ source file.

#ifdef __cplusplus
extern "C"
{
#endif /* __cplusplus */
extern int   use_eye_candy;
extern int   use_lamp_halo;
extern float min_ec_framerate;
extern float max_ec_framerate;
#ifdef __cplusplus
}
#endif /* __cplusplus */

If a C header does not support inclusion in a C++ TU, then it is useful to throw an error during CPP stage. For example:

#ifdef __cplusplus
#error "C only header in C++ TU!"
#endif /* __cplusplus */

Edited by trollson

Share this post


Link to post
Share on other sites

Haha kibora=D I got exactly the same thing right now:

 

eternallands0225hb9.th.jpg

 

It's like a force field that you could move around with your camera, pretty cool effect when it slightly turned transperent/blue but well:D Might be a bug there.

Note: It happened right after exiting the storage. It dissappeared after walking around abit towards the toadstools. I didn't disable any options.

 

ttlanhil:

Yes, that fullscreen/windowed change I made when I got font texture instead was with the official client so yes maybe it's fixed in CVS.

What exactly do you mean that the mapinfo is wrong? Your saying I did something to it or you saying that you got a working one somehow and all others don't? Why aren't we getting X on our maps? Yes I know this isn't right place for it but well, so is many other topics in here.

Edited by Beaverhunter

Share this post


Link to post
Share on other sites
ttlanhil:

Yes, that fullscreen/windowed change I made when I got font texture instead was with the official client so yes maybe it's fixed in CVS.

it is, though a similar problem could still be present (ed: rest removed due to irrelevancy to thread)

 

 

and to karen... please test things before you commit... in this case, weather.c, declaring a const float inside an if() with no other code there is baaad (it was declared as const float and set outside an if() before, and then used later. so it was okay then)

I've fixed this in CVS, but it's not the first time I've had compile fails after your commits

 

are you aware of the mailing list that will tell you of all the CVS commits? if not, log into berlios, and go to the mailing-lists page on ELC's berlios section (it didn't use to require being logged into berlios, but does now *shrug*)

Edited by ttlanhil

Share this post


Link to post
Share on other sites

ttlanhil:

 

I do test all of my code before I commit. Perhaps not with the same *flags* that you do, but I do test all of my code. Problems happen. And in my case, without so much as a warning:

 

[meme@daughtersoftiresias elc]$ make -f Makefile.linux
gcc -march=i686 -Wall  -O0 -ggdb -pipe -DLINUX -DELC  -DAFK_FIX  -DALPHA_ACTORS  -DATI_9200_FIX  -DAUTO_UPDATE  -DBUG_FIX_3D_OBJECTS_MIN_MAX  -DCOUNTERS  -DCUSTOM_LOOK  -DCUSTOM_UPDATE  -DEYE_CANDY  -DFIX_NORMALS  -DFONTS_FIX  -DFUZZY_PATHS  -DMASKING  -DNEW_ACTOR_ANIMATION  -DNEW_ALPHA  -DNEW_FRUSTUM  -DNEW_LIGHTING  -DNEW_TEX  -DNOTEPAD  -DOPTIONS_I18N  -DSFX  -DSIMPLE_LOD  -DUSE_INLINE  -DZLIB -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing  -c -o weather.o weather.c
gcc -march=i686 -Wall  -O0 -ggdb -pipe -DLINUX -DELC  -DAFK_FIX  -DALPHA_ACTORS  -DATI_9200_FIX  -DAUTO_UPDATE  -DBUG_FIX_3D_OBJECTS_MIN_MAX  -DCOUNTERS  -DCUSTOM_LOOK  -DCUSTOM_UPDATE  -DEYE_CANDY  -DFIX_NORMALS  -DFONTS_FIX  -DFUZZY_PATHS  -DMASKING  -DNEW_ACTOR_ANIMATION  -DNEW_ALPHA  -DNEW_FRUSTUM  -DNEW_LIGHTING  -DNEW_TEX  -DNOTEPAD  -DOPTIONS_I18N  -DSFX  -DSIMPLE_LOD  -DUSE_INLINE  -DZLIB -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml2 -fno-strict-aliasing  -L/usr/lib -lSDL -lpthread -L/usr/lib -lxml2 -lz -lm -lSDL_net -lopenal -L/usr/X11R6/lib -lGL -lGLU -lvorbis -lvorbisfile -lcal3d -lm  -lalut				  -lSDL_image -lpng							  -lz -o el.x86.linux.bin 2d_objects.o 3d_objects.o actor_scripts.o actors.o alphamap.o asc.o books.o buddy.o bags.o cache.o cal.o chat.o colors.o console.o consolewin.o counters.o cursors.o dialogues.o draw_scene.o elconfig.o elwindows.o encyclopedia.o errors.o events.o filter.o font.o framebuffer.o frustum.o gamewin.o gl_init.o hud.o help.o highlight.o ignore.o init.o interface.o items.o keys.o knowledge.o lights.o list.o loginwin.o loading_win.o main.o manufacture.o map_io.o mapwin.o md5.o misc.o multiplayer.o new_actors.o new_character.o openingwin.o particles.o paste.o pathfinder.o pm_log.o questlog.o queue.o reflection.o	 rules.o skills.o sector.o serverpopup.o session.o shadows.o sound.o spells.o stats.o storage.o tabs.o text.o textures.o tile_map.o timers.o translate.o trade.o update.o weather.o widgets.o								bbox_tree.o	  notepad.o	special_effects.o	   cal3d_wrapper.o				  eye_candy_wrapper.o eye_candy/eye_candy.o eye_candy/math_cache.o eye_candy/effect_lamp.o eye_candy/effect_campfire.o eye_candy/effect_fountain.o eye_candy/effect_teleporter.o eye_candy/effect_firefly.o eye_candy/effect_sword.o eye_candy/effect_summon.o eye_candy/effect_selfmagic.o eye_candy/effect_targetmagic.o eye_candy/effect_ongoing.o eye_candy/effect_impact.o eye_candy/effect_smoke.o eye_candy/effect_bag.o eye_candy/effect_cloud.o eye_candy/effect_harvesting.o eye_candy/effect_wind.o eye_candy/effect_breath.o
You have new mail in /var/spool/mail/meme
[meme@daughtersoftiresias elc]$

 

It ran fine, too. I'm not perfect, so mistakes will occasionally get in, but please don't tell me that I'm not testing when I am :P

 

Didn't know about that mailing list; I'll subscribe today.

Share this post


Link to post
Share on other sites

if you're posting here, you had better have a CVS client, so why in the world would you report bugs that no longer exist? sheesh...

 

Well since we were on the subject that fullscreen/windowed changes was causing weird stuffs I remembered some time ago when I did alt+enter like 2-4 times in a row to get rid of a bug in another application that could be fixed with resolution changes... So I figured since there are tons of other weird stuffs happening with current CVS, why not add this one too.

 

there's a file called mapinfo.lst that has locations of maps on continental maps. if the map you're on doesn't have it set up, you don't get Xs on the cont map. if it is set up, you will. the only solution is to talk to roja/acelon about having a more complete version included in the client. no, other people probably don't have a newer one. everyone will see cont map Xs on some maps, and not others (and the same, each way. so like I said above, where votd works, and irilion maps with a seridia cont-map obviously aren't set up right)

...

 

Well there's your problem... In other words... you haven't "fixed" it like you said... :P Why you say you have fixed it if the whole system lacks info about the maps? Why aren't someone completing the mapinfo? Shouldn't take too long, at least not for Roja or Acelon.

 

KarenRei:

Is the F9 fire suppose to stack? I mean if I press alot I would expect more volume and such but it creates like a ball on fire rather than a fire. Maybe the base of the fire could be abit more "random"?

eternallands0226ea5.th.jpg

Does my fire look like it is suppose to?

(Note: The FPS drop is only temporary, I have 56-57 FPS constant with VSync 60hz)

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

well, I think the code changed was in NEW_WEATHER, so if you edit that, you should at least try to compile with that on, also with NEW_LIGHTING, but that's the code you wrote anyway... don't think other defines would affect it. here's the commit I made:

--- weather.c   30 Apr 2007 06:15:58 -0000      1.47
+++ weather.c   30 Apr 2007 12:39:28 -0000      1.48
@@ -619,14 +619,15 @@
                return 1.0f;
        } else {
                const float bias = get_weather_light_bias();
+               float result, severity;
 #ifdef NEW_LIGHTING
                if (use_new_lighting)
-                       const float severity = 0.9 * weather_severity; // Bias light by weather severity (the old way obliterates lighting, making everything but shadows black)
+                       severity = 0.9 * weather_severity; // Bias light by weather severity (the old way obliterates lighting, making everything but shadows black)
                else
 #else
-                       const float severity = 0.15f*weather_severity + 0.85f; // slightly bias light by weather severity
+                       severity = 0.15f*weather_severity + 0.85f; // slightly bias light by weather severity
 #endif
-               float result = value*(1.0f - severity*bias);
+               result = value*(1.0f - severity*bias);
 
 #ifdef NEW_LIGHTING
                if (use_new_lighting)
@@ -634,9 +635,8 @@
                        if ((result < 0.1f) && (result < value))
                                result = (value < 0.1 ? value : 0.1);
                }
-               else
 #else
-                       if (result < 0.0f) result = 0.0f;
+               if (result < 0.0f) result = 0.0f;
 #endif
                else if (result > 1.0f) result = 1.0f;

as you can see, the code pre-commit was rather bad

 

ed: other comments removed due to irrelevancy to thread

Edited by ttlanhil

Share this post


Link to post
Share on other sites

guys come on, you're making a total mess here. Please if it's a new bug on a completely different subject MAKE A NEW THREAD!!! If you dont' I think I'll start banning you from the forums.

Share this post


Link to post
Share on other sites

Ttlanhil:

 

well, I think the code changed was in NEW_WEATHER, so if you edit that, you should at least try to compile with that on, also with NEW_LIGHTING, but that's the code you wrote anyway... don't think other defines would affect it

 

I thought I did have it on. However, it appears that someone had pushed a new make.defaults, so my make.conf had gotten updated with NEW_WEATHER off.

 

These things happen in multi-developer environments. No need to harp on them. Have I been naming names on the shadow bugs that I encountered and calling them out for lazy coding by, say, not properly managing their enable client states? No. Why? Because there's no good reason to; it just creates strife. People are putting forth their best efforts, and these things happen. I'm certainly not going to accuse them of "not testing".

 

Anyways, back on topic. Ttlanhil, since you worked on the vid mode change bug before, care to work on it again? Valgrind should let you spot the leaks. Or do I need to stop what I'm doing to work on it? Either way, there should probably be a new thread for that bug.

 

Mailing list: I thought I had checked for one before! I just went to Berlios, and found:

 

Mailing Lists for Eternal Lands Official Client

 

No Lists found for Eternal Lands Official Client

 

Project administrators use the admin link to request mailing lists.

 

If there is a list, could you give me a link?

 

Is the F9 fire suppose to stack?

 

No.

Ent may want to consider having the server disallow multiple F9 fires in the same place if this will be an issue.

 

You should add them to the __cplusplus part as well

 

There's no c++ code that needs them exported. I'm not sure why whoever added that first c++ export did so.

Edited by KarenRei

Share this post


Link to post
Share on other sites
Anyways, back on topic. Ttlanhil, since you worked on the vid mode change bug before, care to work on it again? Valgrind should let you spot the leaks. Or do I need to stop what I'm doing to work on it? Either way, there should probably be a new thread for that bug.
well, I can have a look into it, the only tricky part is finding which opengl textures need to be re-created

ed: waitaminute... that's just a particle effect, isn't it? there's no texture that covers all of them... eh... do you have some sort of bounding box/cube to limit the particles? if so, that will probably need to be re-calculated on size change, but otherwise I have no idea.

what I know: on a full-screen-toggle, the window size changes. that means a viewport change. which means some coords and textures and such are invalidated (due to change of size).

the map one was that the texture was no longer the same size (since it was set to the window size), and became corrupted.

I don't know of anywhere that particle effects would have any sort of reliance on window size (apart from then the opengl call is made, which translates from opengl coords to screen coords)

 

sorry, I can point you to where to insert calls on a resize, but I don't think I'd be able to track down where the corrupted data is... opengl pointing to the wrong texture isn't necessarily even a memory leak or anything (the fix used was to erase the textures and make new ones at the right size)

No.

Ent may want to consider having the server disallow multiple F9 fires in the same place if this will be an issue.

he can't, F9 flares are client-side only :P the server doesn't even know about them Edited by ttlanhil

Share this post


Link to post
Share on other sites

Ahhh... well, in that case, *I* may want to consdier having the client disallow them :P hehe

 

 

ed: waitaminute... that's just a particle effect, isn't it? there's no texture that covers all of them... eh... do you have some sort of bounding box/cube to limit the particles? if so, that will probably need to be re-calculated on size change, but otherwise I have no idea.

 

No, nothing with Eye Candy needs to be resized. The textures are literally being corrupted. I once ran it with valgrind, did a vid mode change, and valgrind caught some out of bounds writes (it was long ago, so I don't have the logs any more). Also, my laptop's EL crashes on vid mode changes, and always has (even with official clients from several releases prior). I used to just assume that it was my laptop's funky vid card, but after seeing the valgrind errors, I suspect that it was not.

 

what I know: on a full-screen-toggle, the window size changes. that means a viewport change. which means some coords and textures and such are invalidated (due to change of size).

 

Could you elaborate on "invalidated"? Are opengl's texture IDs no longer valid after the change? That could be an issue, if that's the case. However, if that's not what you mean -- if you mean that they just need to be stretched differently -- then it's not the issue. The textures themselves are never modified after they're loaded. When EL starts up, eye candy gets its initialization function called. The initialization function calls the loading of each of the textures and saves the openGL texture IDs. These texture IDs are then used as textures for quads (with texture coordinates (0,0), (0,1), (1,1), and (1,0) or point sprites (texture fits the sprite).

Edited by KarenRei

Share this post


Link to post
Share on other sites

okay, to be clear, we're both looking at 2coolfool's square mottled candle? assuming so...

The textures are literally being corrupted.
the odd thing here is that it still looks to be somewhat candle-esque, in that the colour and particle sizes are right, just the locations are all wrong. in comparison, the map-screen (pre-fix) after a size change would go to a totally different (but often valid) texture. for example, you might see something like items1.bmp or items12.bmp (I remember seeing these ones. and it's the entire file, not small chunks as rendered in inventory window. plus they're exactly the right size for the window). many other times, you'd see a texture that's completely white (quite common)
Could you elaborate on "invalidated"? Are opengl's texture IDs no longer valid after the change?
unfortunately, I can't... I know only a basic amount about opengl... I just know that destroying and recreating the texture of the map fixed that particular problem.

for all I know, every texture is still valid, but one is removed from a list (in the linked-list sense) or some of opengl's internal pointers get changed... the end result being that the texture ID used in the client no longer points to the right texture (if it exists and we have a different address, or if the other texture ended up copied/moved over where the texture we want is, I have no idea)

 

actually, I have one idea that I want to test... first thing to do is find a candle and see if I get the same corruption (if not, I can't test very well :P )

ed: I do, goodie... now to see if my guess is right

Edited by ttlanhil

Share this post


Link to post
Share on other sites
I do, goodie... now to see if my guess is right
aaand it is... unfortunately, while the eye-candy was fixed by what I did during early testing, the rest of the textures were lucky enough to get messed up... and it was too funny not to screenshot: link (man, that looks soo cool)

 

the patch that fixed it (and also fixed the middle problem of other textures being messed up... ie, a correctly working patch) is available at http://rafb.net/p/d518ad35.html for the next day or so (as long as the pastebin keeps it).

this does fix the texture corruption. however, I don't know the eye-candy code well enough to know if it's an ideal solution, so I submit it for your review instead of commit-ing it myself :P

 

ed: waaaait a minute! I know why this is, the screen resize includes tearing down some of opengl's stuff to rebuild, no wonder all textures need to be reloaded!

 

oh, and karen, are you following EL PRE RC (windows only) ? there'll probably be a number of eye-candy related bug reports there

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×