Jump to content
Eternal Lands Official Forums
Entropy

Special effects

Recommended Posts

I just got the lates CVS (a lot of changes today it seems) and made a clean build. When I run, after login is finished and the map should be displayed... I crash with access violation on

 

glDrawArrays(GL_TRIANGLES, idx, num); in shadows.c; draw_3d_object_shadow_detail

Hey Kindar. I added NEW_E3D_FORMAT and I do not get the problem now. Try it and let me know.

Share this post


Link to post
Share on other sites

Instead of defining a special effect for each summons, how about saying it's a summon effect and add one or two bytes to define the actor type being added? We already have the actor XML's to define information about each actor already, so any extra info the special effects needs could be added there instead of having a massic case statement.

 

Would consume more bandwidth that way. Besides, we are already using a big case for the special effects anyway, so a few more here and there won't matter.

Share this post


Link to post
Share on other sites
glDrawArrays(GL_TRIANGLES, idx, num); in shadows.c; draw_3d_object_shadow_detail

Hey Kindar. I added NEW_E3D_FORMAT and I do not get the problem now. Try it and let me know.

Oops. Nope. I get the error still. Hmmm.... seems a bit random, but I too get it for glDrawArrays (as mentioned in a previous post). Below is the info posted in the console, but I am unsure if the hex codes will help much.

[RTFM:~/Desktop/Eternal Lands/el_osx1331a] % el_osx.app/Contents/MacOS/el_osx
WindEffect (0x1d86bfc0) created.
WindEffect (0x1d86c120) created.
Deactivating effect 0x1d86bfc0(7301 > 250)
Deactivating effect 0x1d86c120(8381 > 250)
Bus error
[RTFM:~/Desktop/Eternal Lands/el_osx1331a] % el_osx.app/Contents/MacOS/el_osx
WindEffect (0x1d86b800) created.
WindEffect (0x1d86be20) created.
Deactivating effect 0x1d86b800(7301 > 250)
Deactivating effect 0x1d86be20(8381 > 250)
Bus error

Share this post


Link to post
Share on other sites

Given that this doesn't seem to have to do with eye_candy, eye_candy outputs won't be much help. All those outputs are good for are seeing what effects are running and what aren't. In your case, no effects are running.

Share this post


Link to post
Share on other sites

I made some minor changes to the campfire effect. Nothing big, but at least it should reduce the incidence of greenish particles.

 

After some testing, I really don't think it has to do with level of detail. Your fire doesn't resemble a LOD 1 fire. Rather, I think what it appears to be is that your particles are drawing:

 

A) all the same size, and

:o without any use of transparency apart from the particle's texture.

 

This to me says "rendering issue". I'm betting that the values for the particles would be the right sizes/alphas/textures, but it's not rendering with them. If someone who has the problem would run the effect with the DEBUG_CAMPFIRE define, the output would be useful to me. Also, try toggling point particles in your config. If my theory is right, this would also explain the size; the particles that are really far away would normally be almost invisible.

Share this post


Link to post
Share on other sites

Entropy:

 

Of the summons that you listed, are they roughly in order from weakest to strongest? The general style I've taken with them is that color indicates how strong of a summon it is, the shape indicates what kind of creature it is (similar creatures have similar shapes), and the size of the effect is somewhat a mix of the size of the creature and the difficulty of the creature.

Share this post


Link to post
Share on other sites

Spider is down around wolf/skeleton.

Tiger is around armed orcs.

"Giant Snake" aka Sslessar is around fluffy

Phantom Warrior is also lower, but has a strong immunity to physical attacks and weaker against magic.

 

The rest seems close enough.

 

Also remember, spider/tiger/bear have special effects, if that helps you with anything.

Share this post


Link to post
Share on other sites
32 bit by 64 bit? Hmm. That only affects pointers, right? The only case that I can think of where I do anything unusual with pointers is in the wind effect: to give each particle a bit of an identity of its own, I use the lower order bits of the memory address of the particle as a number. However, nothing ever gets *written* to that address; it's just used as a component in the formula for determining how the particle reacts to wind. So, if the blowing leaves were moving strangely, I'd suspect that, but apart from that, I can't picture it having an effect. The rest of my use of pointers is pretty straightforward. I tend not to use pointers for arrays, either -- std::vector and std::map are better, with their automatic management of memory and autocleanup. If you grep through the eye candy code, you'll only see four instances of "delete[]", corresponding to the only four pointer arrays. The rest are all vectors and maps.
my bot, vakana, is my excersize in C++, so I'll agree on using the STL... I'm hardly an expert in 64bit issues, it's just all I can think of besides the graphics card/drivers

 

as far as FPS, however... I can get around 200-300 away from storages, but going near beam cuts it down a lot.

I just tested then, and even when I didn't see the fire going, fps dropped to about 13. (this was in the leaves effect, but leaving the area by a certain amount, still within the leaves, made it jump back up... I figured it might be the fireplace, so I walked back to see if it went down again... didn't see a fire, though it did drop out

as for using larger particles for low LOD, that's fine, except that the fire also seems to be a lot taller than it should be (considering the size of the particles I'm seeing, you'd be able to get away with a lot fewer if it was the right size)

also, I cap my FPS at 25, there's not much increase in quality above that(in fact, at 30+ it looks too smooth, which makes it look unnatural to me), and it's quite possible others may too... so being based on FPS might be a bad thing

 

I'll test out -DDEBUG_CAMPFIRE later on this evening (a few other things to chase first) and we'll see if that comes up with anything interesting

 

ed: okay, I gave it a run after a cvs-up... campfire was still oversized... here's some of the output:

[New Thread 1091070304 (LWP 16155)]
CampfireEffect (0x7d363d0) created.
WindEffect (0x7753730) created.
WindEffect (0x7dbd7a0) created.
Deactivating effect 0x7d363d0(8148.12 > 250)
<snip>
Deactivating effect 0x7753730(7301 > 250)
Deactivating effect 0x7dbd7a0(8381 > 250)
Activating effect 0x7d363d0(5 < 250)
<snip>
Activating effect 0x7753730(16.5275 < 250)
Activating effect 0x7dbd7a0(41.5275 < 250)
<snip>
Creating particle: RGB=1, 0.369734, 0.2; size=2.62955; alpha=0.652648; LOD=10; state=0
Creating particle: RGB=1, 0.363801, 0.2; size=0.614861; alpha=0.548111; LOD=10; state=0
Creating particle: RGB=1, 0.636689, 0.2; size=2.93272; alpha=0.829311; LOD=10; state=0
Creating particle: RGB=1, 0.51396, 0.2; size=1.1218; alpha=0.986705; LOD=10; state=0
Creating particle: RGB=1, 0.718456, 0.2; size=1.51587; alpha=0.997382; LOD=10; state=0
Creating particle: RGB=1, 0.472002, 0.2; size=2.10838; alpha=0.59755; LOD=10; state=1
Creating particle: RGB=1, 0.496278, 0.2; size=1.04296; alpha=0.864946; LOD=10; state=1
Creating particle: RGB=1, 0.65361, 0.2; size=2.03205; alpha=0.993994; LOD=10; state=0
Creating particle: RGB=1, 0.388485, 0.2; size=0.752295; alpha=0.898521; LOD=10; state=0
Creating particle: RGB=1, 0.590572, 0.2; size=1.91956; alpha=0.799353; LOD=10; state=0
Creating particle: RGB=1, 0.590572, 0.2; size=1.91956; alpha=0.799353; LOD=10; state=0
Creating particle: RGB=1, 0.388729, 0.2; size=0.629879; alpha=0.577087; LOD=10; state=1
Creating particle: RGB=1, 0.409122, 0.2; size=0.725136; alpha=0.725055; LOD=10; state=1
Creating particle: RGB=1, 0.669613, 0.2; size=3.11881; alpha=0.995198; LOD=10; state=0
Creating particle: RGB=1, 0.530203, 0.2; size=1.12784; alpha=0.627204; LOD=10; state=0
Creating particle: RGB=1, 0.669613, 0.2; size=3.11881; alpha=0.995198; LOD=10; state=0
Creating particle: RGB=1, 0.530203, 0.2; size=1.12784; alpha=0.627204; LOD=10; state=0
Creating particle: RGB=1, 0.406125, 0.2; size=0.54612; alpha=0.604209; LOD=10; state=0
Creating particle: RGB=1, 0.354573, 0.2; size=0.34744; alpha=0.855135; LOD=10; state=0
Creating particle: RGB=1, 0.684912, 0.2; size=1.47618; alpha=0.602338; LOD=10; state=1
Creating particle: RGB=1, 0.609185, 0.2; size=3.03646; alpha=0.639396; LOD=10; state=0
Creating particle: RGB=1, 0.464235, 0.2; size=1.09339; alpha=0.603417; LOD=7; state=0
Creating particle: RGB=1, 0.619391, 0.2; size=2.35827; alpha=0.762577; LOD=7; state=1
Creating particle: RGB=1, 0.464235, 0.2; size=0.820039; alpha=0.553417; LOD=10; state=0
Creating particle: RGB=1, 0.619391, 0.2; size=1.76871; alpha=0.712577; LOD=10; state=1
[Thread 1091070304 (zombie) exited]
[Thread 1082677600 (zombie) exited]
CampfireEffect (0x7d363d0) destroyed.
WindEffect (0x7753730) destroyed.
WindEffect (0x7dbd7a0) destroyed.

the snippages are pages of creating-particle messages... I've also trimmed most of the GDB stuff, the rest is there (the de- and re-activation seems a little odd, though I don't know the triggers, as this was less than a minute's running (I have a character who was at beam when logged off))

looking through the (much longer) full output, it's nearly all LOD=10, with a few 7's now and then, so I guess LOD isn't the problem

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Ttlanhil: Yep, that screams "rendering issue" to me (see the post three above yours). The particle data all looks normal; the problem must be in how they're drawing (large, no transparency except for the texture itself). As mentioned, this would also explain the size: normally the particles on the periphery are almost invisible, but here, they're drawing solid. I bet that they just suddenly disappear instead of fading out -- am I right? Also, did you try toggling the point sprites flag like I suggested?

 

Anyone know if there's already a way already in EL to see what GL extensions you have enabled? If not, I'll add a debugging statement for that, along with some other debugging statements. We'll get this one figured out! :)

 

The disable/enable: That's due to the camera not being updated before the effects are spawned. Notice section in parantheses: that's (YourSquaredDistanceFromTheEffect > ) MaxSquaredDistanceFromTheEffect). The camera (camera_x, camera_y, and camera_z) is not yet in its final location (hovering over you), but it moves there during the next frame. I don't think it would be worth the effort to "fake it out" by making it delay by one frame; it takes almost no time to disable or enable an effect. It doesn't even have to iterate across that effect's particles.

 

Fireplace performance: If there was no campfire, then a campfire wouldn't be slowing you down. Even if the campfire effect was created at the time but disabled (which would be a bug if you couldn't see it when you were right next to it), it would use almost no CPU time. There's only perhaps a dozen CPU ops done per inactive effect, no drawing for inactive effects, and even less CPU ops per inactive particle. Now, you could have many inactive particles per inactive effect, but even still, with a particle max of, what, 15k, even with the delay from memory fetches, that works out to essentially no CPU load on a modern processor. I would wager that, without any effects turned on, you'd still be getting that low framerate at the beam point.

 

Acelon: Thanks. That'll let me finish hooking in summoning effects this evening. I'll probably get the optional "in-combat blood" hooked in as well, since that should be relatively easy and I already have everything I need to do it.

 

Anyone: Out of curiosity in case anyone knows, what sort of poly count do our player models have? Non-point-sprite particles are one poly each, and leaves are two polys if your framerate is high, one poly if it's low, and I'd like to be able to compare my poly counts to what's already there.

Edited by KarenRei

Share this post


Link to post
Share on other sites

I think I'm seeing the same blocky fire problem as ttlanhil. Thing is I'm on 32-bit pentium, nvidia graphics and Debian Etch. I think from the thread on shadow mapping, we are both using the same OS so it could be a library problem. Etch is approaching release and so many changes are coming though. I have two screen shots, one with point particles on, one with it off. It certainly looks better in the off state. By the way, the F9 private fire looks the same.

 

On the up side, I'm not getting any crashes with the latest cvs version :)

Share this post


Link to post
Share on other sites

okay, yep, turning off point particles shrunk them down a lot (odd, that)... strangely enough, the smoke now looks to alternate between dark purple and dark brown...

also, is there much chance of making the smoke and maybe flames realise what's around? the campfire in DP has a cooking pot on it, and it looks rather odd as the colours move through the pot

the campfire still seems to be the cause of the slowdown though, I zoomed out enough to watch it as I walked away... as soon as it was far enough away not to be rendered, FPS shot back up again... walk back, and down again

 

as for extensions, check cmd_glinfo (from memory) in console.c ... or perhaps the stuff in init.c, that prints out extensions when the client starts

Share this post


Link to post
Share on other sites

Yeay, my suspicions were correct! :) It looks correct in the "off" state (although I should probably make the regular fire bigger and the private fire smaller to help distinguish them if they look the same). The problem is a rendering error (transpareny, scale) when using point particle rendering, then.

 

I won't be able to debug this one on my home laptop (no support for point particles -- did I mention my vid card is lousy? :) ), so I'll go to my PC for this one. I developed the system initially using point particles on my work laptop, but to build EL, I had to switch machines (the work laptop is RHEL, and it's missing libraries), so I haven't messed much with point particles since then.

 

I should have a fix in within a day or two. Until then, having point particles off is a workaround.

 

 

Ttlanhil: I thought you said that the fire wasn't drawing when you had the slowdown. If it is drawing, that's a different matter; now it's an effects performance issue. What sort of slowdown are we talking about here? Is the speedup as soon as it's off the screen, or as soon as you get a deactivation message for the effect? The latest version is designed to draw at minimum detail if you're at FPS 12 or less, and full detail if you're FPS 36 or more. Naturally, full detail is a much bigger processing load than minimum detail (usually 9-10 times more).

 

While I think allowing a person to set a constant "desired level of detail" would be a bad idea (as mentioned previously, because it wouldn't respond to the current graphics load), if different people have different standards for desired framerates, I could have the min/max LOD FPS settable.

 

In theory, point particles should get you better performance once they're fixed, although whether they actually do or not depends on the vid card and driver.

 

Oh, one more thing: particles avoiding objects. The code is already in the special effects; they do it nicely. What's not in is a list of objects to avoid :( Any suggestions on how to get that? We naturally want to keep that list as short as possible.

 

 

Bluap: Odd. Your leaves in that screenshot appear to be grey. Or is it just me? They should be various shades of brown. Oy -- rendering issues. :P

Edited by KarenRei

Share this post


Link to post
Share on other sites

Bluap: Odd. Your leaves in that screenshot appear to be grey. Or is it just me? They should be various shades of brown. Oy -- rendering issues. :)

Now you mention it, yes they are mostly grey, with the occasional yellowy leaf too. While we're on the subject, I get very log FPS on the test server at beam. I assumed it was the leaves causing the problem. Certainly if l move to where there are no leafs my FPS goes back to normal. If I then start a private fire, I get no noticeable drop in FPS.

Share this post


Link to post
Share on other sites

okay, just did another run from the console (didn't have it last time, so didn't see the message)

I got a certain distance away (over a normal screen (yes, I have extra zoom in one of my clients for testing stuff like this)), and the particle creation stops, but FPS is still low. another coupe of steps, and

Deactivating effect 0x7d97090(250.314 > 250)
Deactivating effect 0x77fa880(251.839 > 250)

FPS back to normal. step a bit closer, and

Activating effect 0x77fa880(248.813 < 250)
Activating effect 0x7d97090(249.535 < 250)
Activating effect 0x7d60620(248.901 < 250)

... no particles yes, but FPS back down. a couple steps closer, and particle creation resumes

 

what I said before about it not going... when I was at the fire, it was on, and slow. I walked away until FPS went up and the fire out. walked back towards it, and although the fire didn't reshow, FPS dropped (although this experiment suggests it doesn't take particle creation to cause the lag)

 

in case it matters, this is on IP, at the beam fireplace, and I normally walk south... if you think it matters I can go find another one to test

 

ed: when I walk far enough away for FPS to go back up, I can still see the leaves floating around

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Just been back to IP fire on the the test server and the leafs are gone, I presume the wind has gone for now. Anyway, with the leafs I was getting below 10 FPS, fire or no fire. Now with no leafs I get FPS in the 30s, fire or no fire. I guess ttlanhil and I have different problems with the FPS stuff. I have FPS limited to 35 BTW.

Share this post


Link to post
Share on other sites

Bluap: Ah, the joys of different video cards and video drivers :) Yours has more of a problem with higher poly counts and less of a problem with the total amount of drawn pixels compared to Ttlanhil.

 

Ttlanhil: how low of an FPS are we talking about? Bluap's 10 fps is a significant hit, and that will need to be fixed (I'll have to make the wind effect more aggressive about culling leaves when the framerate gets low), but if your framerate is, say, "30 instead of 200", that's not as major of a problem. Thanks for getting me that info, by the way: that's exactly what I needed. As long as the effect is "active", it will try to draw the particles, whether they get clipped or not, so that makes sense.

 

My TODO list for the next commit:

* Finish hooking in summons (partially finished)

* More aggressive leaf culling at low FPS

* More difference between normal/F9 fire sizes

* Fix the point particles bug

* Put in a debugging statement for Bluap to help determine why the leaves are the wrong colors.

* If Ttlanhil's FPS is low enough that it needs to be improved, then that as well.

* Any windows fixes determined as necessary by LabRat's thread.

 

P.S. -- Ttlanhil, I just noticed that your rank is "Troll". Amusing. Very amusing to see that under someone's name in a forum. :P

Share this post


Link to post
Share on other sites

okay, guess the leaves do affect it...

fps when close enough for fireplace particles: ~12

fps when I step away a bit, so I can see leaves and the fireplace is too far away to be drawn: ~20 (since I cap at 25, it looks close enough to normal here)

fps when a couple steps further away (no more leaves): ~400 (my CPU is great, graphics card quite adequate, a hit down to 13 is pretty serious)

 

I'll go test it out at a different fireplace to compare

 

ed: done

tried the DP campfire. close enough for it to be drawn: ~220

step away: ~550

 

I guess that size a hit is sorta consistent with the fire above, after the leaves... it's not the big culprit, though certainly not innocent either. would the output of #glinfo help?

 

bleh, I forgot what it was like to uncap FPS... almost everything is so smooth it looks artificial... except the actors who are all jerky (but it fits in at fps 25)

Edited by ttlanhil

Share this post


Link to post
Share on other sites

okay, now some graphics bugs. fore-warning: the PNGs are all 700-800 kb. if that's a problem, lemme know so I can crop and jpeg them (though that loses some quality)

 

First, the fireplace now that particles are better (the issue with the cooking pot having the fire inside it... plus the smoke being purplish): link

next, a 'miss' on a harv event (I saw one a lot further away, but didn't catch that one in a screenie): link

and finally, a TP nexus (which I think looked normal before the debugging and point particles going off): link

 

ed: and I'm not sure if it's your code or not, but the effects for the shield spell seem to be to make a light where I am when I cast it... which stays there as I walk away. if you didn't hook in a shield effect, then please ignore :)

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Here's a rough list of some of the main items particles should avoid (the most commonly used around them)

 

/misc_objects/cookingpot1

/misc_objects/pot_cooking1

/misc_objects/cauldron

/structures/chimney1

/structures/chimneytop1

/structures/chimneytop2

/structures/chimneystovetop1

/misc_objects/portal1

/misc_obects/torch

/misc_objects/brazier1

/misc_objects/brazier2

/misc_objects/fountain1

/misc_objects/fountain2

/misc_objects/fountain3

/misc_objects/fountain7

/misc_objects/fountain8

/structures/forgechimney1

/structures/forgechimney2

/trees/firespit1

Edited by Acelon

Share this post


Link to post
Share on other sites

Oy, more GL bugs, I see. No, that purple isn't normal. For some reason, your smoke is not respecting the instructions to use a non-additive blend function.

 

I sure have my work cut out for me :)

 

Yes, #glinfo would be very useful. Also, could you redo your first step uncapped:

 

Yes, special effects do create lights. However, they're supposed to go away when no longer needed. Chock up another bug that I don't get over here. :P

 

 

"fps when close enough for fireplace particles: ~12

fps when I step away a bit, so I can see leaves and the fireplace is too far away to be drawn: ~20 (since I cap at 25, it looks close enough to normal here)

fps when a couple steps further away (no more leaves): ~400 (my CPU is great, graphics card quite adequate, a hit down to 13 is pretty serious)"

 

This makes no sense as it is, since 400 is greater than 25 :) I don't know in what manner the capping works, so for now, it'll be easiest to figure out what's going on if you're uncapped.

 

 

Acelon:

 

It really depends on the effect. For example, a targetted magic spell would care most about avoiding trees and people, since those are the main obstructions between two points at eye level.

 

Anyways, my TODO list overfloweth, and I have some housework I need to do tonight, so it would be nice if that TODO list didn't keep growing every five minutes. ;) Critical stuff (rendering issues and LOD) first.

Share this post


Link to post
Share on other sites

I was going by the fountain/fire/smoke particles. If you are going to add in trees, your list is going to get pretty big :)

Share this post


Link to post
Share on other sites

Video card: GeForce 6600 GT/PCI/SSE2

Vendor ID: NVIDIA Corporation

OpenGL Version: 2.1.0 NVIDIA 97.46

Supported extensions: GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_sha

 

as for the experiment, my apologies for not explaining better. most of the time, I have FPS capped to 25 (for various reasons). during the tests (maybe not the first couple, but the recent ones), I turned it off, so EL was running at the limit of available CPU. that resulted in the 12/20/400

the comment on 20/25 was that since I normally play at 25, it drawing at 20 didn't look that out of the ordinary, hence why I didn't realise it was a problem earlier

 

the capping works by checking how long since last frame was drawn, and SDL_Delay()ing instead of drawing EL if it's going faster than needed for the limit to FPS. if you're interested, you can see details at gamewin.c:691 and main.c:120

 

ed: actually, more detailed idea, `glxinfo`:

 

direct rendering: Yes

server glx vendor string: NVIDIA Corporation

server glx version string: 1.4

server glx extensions:

GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,

GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control,

GLX_EXT_texture_from_pixmap, GLX_ARB_multisample, GLX_NV_float_buffer,

GLX_ARB_fbconfig_float

client glx vendor string: NVIDIA Corporation

client glx version string: 1.4

client glx extensions:

GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info,

GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync,

GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,

GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float,

GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap,

GLX_EXT_framebuffer_sRGB

GLX version: 1.3

GLX extensions:

GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,

GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control,

GLX_EXT_texture_from_pixmap, GLX_ARB_multisample, GLX_NV_float_buffer,

GLX_ARB_fbconfig_float, GLX_ARB_get_proc_address

OpenGL vendor string: NVIDIA Corporation

OpenGL renderer string: GeForce 6600 GT/PCI/SSE2

OpenGL version string: 2.1.0 NVIDIA 97.46

OpenGL extensions:

GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_draw_buffers,

GL_ARB_fragment_program, GL_ARB_fragment_program_shadow,

GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_imaging,

GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,

GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite,

GL_ARB_shadow, GL_ARB_shader_objects, GL_ARB_shading_language_100,

GL_ARB_texture_border_clamp, GL_ARB_texture_compression,

GL_ARB_texture_cube_map, GL_ARB_texture_env_add,

GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_float,

GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,

GL_ARB_texture_rectangle, GL_ARB_transpose_matrix,

GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader,

GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float,

GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_EXT_texture_env_add,

GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,

GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,

GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array,

GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements,

GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample,

GL_EXT_framebuffer_object, GL_EXT_gpu_program_parameters,

GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil,

GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters,

GL_EXT_rescale_normal, GL_EXT_secondary_color,

GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,

GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D,

GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,

GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,

GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,

GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp,

GL_EXT_texture_object, GL_EXT_texture_sRGB, GL_EXT_timer_query,

GL_EXT_vertex_array, GL_IBM_rasterpos_clip,

GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square,

GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fence,

GL_NV_float_buffer, GL_NV_fog_distance, GL_NV_fragment_program,

GL_NV_fragment_program_option, GL_NV_fragment_program2,

GL_NV_framebuffer_multisample_coverage, GL_NV_half_float,

GL_NV_light_max_exponent, GL_NV_multisample_filter_hint,

GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range,

GL_NV_point_sprite, GL_NV_primitive_restart, GL_NV_register_combiners,

GL_NV_register_combiners2, GL_NV_texgen_reflection,

GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4,

GL_NV_texture_expand_normal, GL_NV_texture_rectangle,

GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3,

GL_NV_vertex_array_range, GL_NV_vertex_array_range2, GL_NV_vertex_program,

GL_NV_vertex_program1_1, GL_NV_vertex_program2,

GL_NV_vertex_program2_option, GL_NV_vertex_program3,

GL_NVX_conditional_render, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod,

GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_slice_accum

glu version: 1.3

glu extensions:

GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

Edited by ttlanhil

Share this post


Link to post
Share on other sites

I was going by the fountain/fire/smoke particles. If you are going to add in trees, your list is going to get pretty big ;)

 

Easy solution: I won't be using one list :) Each effect will have a list of things that are relevant to it. Also, for targetted magic effects, there are only a few particles while the effect flies toward the target. Only once it gets to the target are many particles spawned, and those don't need to be concerned about what's en route.

 

But this is for later. :P

 

 

Thanks, ttlanhil. That should be useful.

 

Oooh, this is nice playing on my PC instead of my laptop. I forgot how smooth this game ran when you use a *real* video card :)

Share this post


Link to post
Share on other sites

Good news: the point particle problems, the silver leaves, and the performance issues are reproducable on my PC. Guess my laptop is just funky. :) I was only able to finish the summon hook-ins tonight, but tomorrow evening I should be able to tackle these issues full on, without having to work through you two. :)

Share this post


Link to post
Share on other sites

Kind of sucks, doesn't it? :)

That's why there are not many Linux games out there, it's a huge pain in the ass to support more than one platform :/

Especially with OpenGL since the standard is very lax (the OpenGL board is not going to revoke ATI's right to use it because of compatibility problems).

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×